{"id":1222,"date":"2026-08-21T14:28:42","date_gmt":"2026-08-21T14:28:42","guid":{"rendered":"https:\/\/matforge.org\/?p=1222","raw":"https:\/\/matforge.org\/?p=1222"},"modified":"2026-08-21T14:28:42","modified_gmt":"2026-08-21T14:28:42","slug":"using-tickets-to-improve-scientific-transparency","status":"publish","type":"post","link":"https:\/\/matforge.org\/fr\/using-tickets-to-improve-scientific-transparency\/","title":{"rendered":"Utiliser les billets pour am\u00e9liorer la transparence scientifique","raw":"Utiliser les billets pour am\u00e9liorer la transparence scientifique"},"content":{"rendered":"Reading Time: <\/span> 7<\/span> minutes<\/span><\/span>

La transparence scientifique est souvent discut\u00e9e en termes de r\u00e9sultats finaux : articles publi\u00e9s, ensembles de donn\u00e9es partag\u00e9s, code open source et r\u00e9sultats archiv\u00e9s. Celles-ci sont importantes, mais elles ne montrent pas toujours comment une \u00e9quipe de recherche a pris une d\u00e9cision. Un article peut expliquer la m\u00e9thode finale, tandis que l’historique du projet peut contenir des questions non r\u00e9solues, des rapports de bogues, des hypoth\u00e8ses de mod\u00e8les, des tests \u00e9chou\u00e9s et des compromis techniques qui ont fa\u00e7onn\u00e9 le r\u00e9sultat.<\/p>\n

C’est l\u00e0 que les billets deviennent utiles. Dans les projets de logiciels de recherche, un ticket est plus qu’un rappel de t\u00e2che. Il peut devenir un enregistrement structur\u00e9 de probl\u00e8mes, de discussions, de d\u00e9cisions et de corrections. Lorsqu’ils sont bien utilis\u00e9s, les tickets aident \u00e0 connecter les modifications de code au raisonnement scientifique, ce qui facilite la compr\u00e9hension, la r\u00e9vision et la reproduction du processus de d\u00e9veloppement.<\/p>\n

Que signifient les billets dans les logiciels scientifiques<\/h2>\n

Un ticket est une unit\u00e9 de travail ou de discussion document\u00e9e. Il peut d\u00e9crire un bogue, demander une fonctionnalit\u00e9, demander de la documentation, signaler un probl\u00e8me d’installation ou poser une question sur un mod\u00e8le. Dans des outils tels que les probl\u00e8mes GitHub, les probl\u00e8mes GitLab, JIRA ou des syst\u00e8mes similaires, les tickets donnent aux \u00e9quipes un lieu partag\u00e9 pour discuter et suivre le travail technique.<\/p>\n

Dans les logiciels scientifiques, les billets ont souvent un sens suppl\u00e9mentaire. Un ticket peut expliquer pourquoi un param\u00e8tre de solveur a \u00e9t\u00e9 modifi\u00e9, pourquoi un ensemble de donn\u00e9es a provoqu\u00e9 un comportement inattendu, pourquoi un exemple ne reproduit plus un ancien r\u00e9sultat ou pourquoi une certaine hypoth\u00e8se de mod\u00e9lisation doit \u00eatre clarifi\u00e9e. Ces d\u00e9tails peuvent ne jamais appara\u00eetre dans la publication finale, mais ils peuvent \u00eatre essentiels pour comprendre le processus de recherche.<\/p>\n

Pour cette raison, les tickets ne doivent pas \u00eatre trait\u00e9s uniquement comme des \u00e9l\u00e9ments de gestion de projet. Ils font \u00e9galement partie du dossier scientifique. Ils aident \u00e0 pr\u00e9server le raisonnement derri\u00e8re les changements qui resteraient autrement dans des notes priv\u00e9es, des fils de discussion ou la m\u00e9moire de d\u00e9veloppeurs individuels.<\/p>\n

Comment les billets rendent visibles les d\u00e9cisions de recherche<\/h2>\n

De nombreuses d\u00e9cisions scientifiques se produisent progressivement. Un chercheur remarque une production inhabituelle. Un d\u00e9veloppeur teste un exemple plus petit. Un collaborateur sugg\u00e8re que le probl\u00e8me peut provenir d’une d\u00e9pendance, d’un param\u00e8tre de maillage, d’une condition aux limites ou d’un probl\u00e8me de formatage des donn\u00e9es. Apr\u00e8s plusieurs commentaires, l’\u00e9quipe s’accorde sur un correctif ou d\u00e9cide que le comportement est attendu.<\/p>\n

Sans ticket, ce processus peut dispara\u00eetre. Le code final peut montrer ce qui a chang\u00e9, mais pas pourquoi il a chang\u00e9. Un ticket capture le contexte autour du changement : qui a signal\u00e9 le probl\u00e8me, lorsqu’il est apparu, quel exemple l’a reproduit, quelles alternatives ont \u00e9t\u00e9 discut\u00e9es et pourquoi une solution a \u00e9t\u00e9 choisie.<\/p>\n

Cette visibilit\u00e9 est particuli\u00e8rement pr\u00e9cieuse dans les projets \u00e0 long terme. Les futurs contributeurs peuvent lire le ticket et \u00e9viter de r\u00e9p\u00e9ter la m\u00eame enqu\u00eate. Les examinateurs peuvent voir si une limitation connue a \u00e9t\u00e9 prise en compte. Les \u00e9tudiants peuvent apprendre non seulement ce qu’est le flux de travail correct, mais aussi comment l’\u00e9quipe a d\u00e9couvert et affin\u00e9e.<\/p>\n

Billets comme pont entre le code, la documentation et les r\u00e9sultats<\/h2>\n

Les logiciels scientifiques vivent rarement au m\u00eame endroit. Un seul probl\u00e8me peut affecter le code, la documentation, les tests, les exemples et l’interpr\u00e9tation des r\u00e9sultats. Les billets aident \u00e0 connecter ces pi\u00e8ces.<\/p>\n

Par exemple, un ticket peut commencer par un utilisateur signalant une sortie de simulation inattendue. La discussion peut r\u00e9v\u00e9ler qu’un exemple dans la documentation est obsol\u00e8te. Une demande d’extraction met ensuite \u00e0 jour l’exemple, ajoute un test et ajuste un message d’avertissement. Plus tard, les notes de version r\u00e9sument le changement pour les utilisateurs.<\/p>\n

Dans cette cha\u00eene, le ticket agit comme le pont. Il connecte le probl\u00e8me d’origine au correctif de code, \u00e0 la mise \u00e0 jour de la documentation et au r\u00e9sum\u00e9 de la version. Sans cela, chaque partie peut sembler s\u00e9par\u00e9e. Avec lui, le projet a une histoire plus claire de ce qui s’est pass\u00e9 et pourquoi.<\/p>\n

C’est l’un des r\u00f4les les plus utiles que les billets peuvent jouer dans la transparence scientifique. Ils montrent la relation entre la maintenance technique et la signification scientifique.<\/p>\n

Qu’est-ce qu’un ticket scientifique transparent<\/h2>\n

Un ticket utile n’a pas besoin d’\u00eatre long, mais il devrait \u00eatre suffisamment clair pour qu’une autre personne puisse les comprendre et les tester. Les meilleurs billets r\u00e9duisent l’ambigu\u00eft\u00e9. Ils expliquent le probl\u00e8me, fournissent un contexte et facilitent la prochaine \u00e9tape.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
\u00e9l\u00e9ment du ticket<\/th>\nPourquoi c’est important<\/th>\n<\/tr>\n
Titre clair<\/td>\nAide les autres \u00e0 comprendre le probl\u00e8me avant d’ouvrir le ticket complet.<\/td>\n<\/tr>\n
\u00e9nonc\u00e9 de probl\u00e8me<\/td>\nExplique ce qui ne va pas, ne sait pas, manquant ou inattendu.<\/td>\n<\/tr>\n
\u00c9tapes pour reproduire<\/td>\nRend le probl\u00e8me testable au lieu de seulement descriptif.<\/td>\n<\/tr>\n
Comportement attendu<\/td>\nMontre ce que l’utilisateur ou le chercheur pensait que cela devait arriver.<\/td>\n<\/tr>\n
Comportement observ\u00e9<\/td>\nEnregistre ce qui s’est r\u00e9ellement pass\u00e9 dans le logiciel ou le r\u00e9sultat.<\/td>\n<\/tr>\n
D\u00e9tails d’environnement<\/td>\nAide \u00e0 identifier les probl\u00e8mes de version, de d\u00e9pendance, de plate-forme ou d’installation.<\/td>\n<\/tr>\n
Exemple minimal<\/td>\nR\u00e9duit le bruit et aide les mainteneurs \u00e0 se concentrer sur le probl\u00e8me central.<\/td>\n<\/tr>\n
R\u00e9sum\u00e9 de la d\u00e9cision<\/td>\nPr\u00e9serve pourquoi la solution finale a \u00e9t\u00e9 choisie.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Le r\u00e9sum\u00e9 de la d\u00e9cision est particuli\u00e8rement important. De nombreuses \u00e9quipes discutent soigneusement d’un probl\u00e8me, fusionnent un correctif, puis ferment le ticket sans expliquer la conclusion. Un court commentaire final peut rendre le ticket beaucoup plus utile : ce qui a \u00e9t\u00e9 modifi\u00e9, ce qui n’a pas \u00e9t\u00e9 modifi\u00e9 et ce que les utilisateurs doivent comprendre \u00e0 l’avenir.<\/p>\n

Comment les billets prennent en charge la reproductibilit\u00e9<\/h2>\n

La reproductibilit\u00e9 d\u00e9pend de plus que la disponibilit\u00e9 du code. Un futur chercheur devra peut-\u00eatre savoir quelle version a \u00e9t\u00e9 utilis\u00e9e, quel bogue a \u00e9t\u00e9 corrig\u00e9, quel comportement a chang\u00e9 et si une limitation connue a affect\u00e9 le r\u00e9sultat. Les tickets peuvent fournir cette couche de contexte manquante.<\/p>\n

Par exemple, si un r\u00e9sultat de simulation change apr\u00e8s une mise \u00e0 jour logicielle, un ticket peut expliquer que la version ant\u00e9rieure avait un bogue dans un cas EDGE sp\u00e9cifique. Si une installation \u00e9choue sur une certaine plate-forme, un ticket peut r\u00e9v\u00e9ler un conflit de d\u00e9pendance. Si une hypoth\u00e8se de mod\u00e8le \u00e9tait remise en question mais accept\u00e9e, le ticket peut expliquer le raisonnement.<\/p>\n

Ces enregistrements aident les futurs utilisateurs \u00e0 comprendre la diff\u00e9rence entre une erreur, un changement attendu et un choix de conception intentionnel. Ils aident \u00e9galement les mainteneurs \u00e0 pr\u00e9parer des journaux de modifications et des notes de version plus clairs.<\/p>\n

En ce sens, les tickets am\u00e9liorent la reproductibilit\u00e9 en documentant le chemin entre le probl\u00e8me et la r\u00e9solution. Ils facilitent l’inspection de l’historique du d\u00e9veloppement, pas seulement l’\u00e9tat final du code.<\/p>\n

Erreurs courantes qui rendent les billets moins utiles<\/h2>\n

L’erreur la plus courante est d’\u00e9crire des billets vagues. Un titre tel que \u00ab\u00a0Probl\u00e8me avec le mod\u00e8le\u00a0\u00bb ou \u00ab\u00a0Simulation bris\u00e9e\u00a0\u00bb n’aide pas les autres \u00e0 comprendre le probl\u00e8me. Un meilleur titre nomme le composant, le comportement ou l’exemple affect\u00e9.<\/p>\n

Une autre erreur est de laisser de c\u00f4t\u00e9 les \u00e9tapes de reproduction. Si d’autres ne peuvent pas r\u00e9p\u00e9ter le probl\u00e8me, ils ne pourront peut-\u00eatre pas le r\u00e9soudre. M\u00eame un petit exemple de code, un journal court ou une description claire des conditions d’entr\u00e9e peut rendre un ticket beaucoup plus utile.<\/p>\n

Les \u00e9quipes affaiblissent \u00e9galement la transparence lorsqu’elles d\u00e9placent des d\u00e9cisions importantes dans des discussions priv\u00e9es et ne les r\u00e9sume jamais dans le ticket. Une discussion priv\u00e9e peut \u00eatre pratique, mais le ticket final devrait toujours contenir la conclusion principale.<\/p>\n

D’autres probl\u00e8mes courants incluent le m\u00e9lange de plusieurs probl\u00e8mes non li\u00e9s dans un ticket, la fermeture d’un ticket sans explication, le fait de ne pas lier la demande d’extraction associ\u00e9e ou d’utiliser des \u00e9tiquettes de mani\u00e8re incoh\u00e9rente. Ces erreurs ne rendent pas les tickets inutiles, mais ils r\u00e9duisent leur valeur en tant que couche de m\u00e9moire scientifique.<\/p>\n

Un flux de travail simple pour une meilleure billetterie scientifique<\/h2>\n

Un workflow de billetterie transparent n’a pas besoin d’\u00eatre compliqu\u00e9. L’objectif est de cr\u00e9er suffisamment de structure pour pr\u00e9server le contexte sans transformer le processus en bureaucratie.<\/p>\n

Ouvrir les billets t\u00f4t<\/h3>\n

Si un probl\u00e8me semble important, ouvrez un ticket avant que les d\u00e9tails ne soient oubli\u00e9s. La premi\u00e8re version peut \u00eatre incompl\u00e8te. Il est pr\u00e9f\u00e9rable d’enregistrer t\u00f4t l’observation et d’affiner le ticket au fur et \u00e0 mesure que de nouvelles informations seront disponibles.<\/p>\n

Ajouter un contexte technique minimal<\/h3>\n

Incluez la version du logiciel, l’environnement, les conditions d’entr\u00e9e, le comportement attendu, le comportement observ\u00e9 et toute sortie pertinente. Si le probl\u00e8me implique une simulation, essayez de fournir le plus petit exemple qui reproduise le probl\u00e8me.<\/p>\n

Lien travail li\u00e9<\/h3>\n

Connectez le ticket \u00e0 des probl\u00e8mes connexes, des demandes d’extraction, des validations, des pages de documentation, des tests ou des notes de version. Ces liens aident les autres \u00e0 suivre toute la cha\u00eene, du rapport \u00e0 la r\u00e9solution.<\/p>\n

Utilisez les \u00e9tiquettes de mani\u00e8re coh\u00e9rente<\/h3>\n

Des \u00e9tiquettes telles que bug<\/code>, documentation<\/code>, reproducibility<\/code>, model-assumption<\/code>, question<\/code> et release<\/code> peuvent faciliter la recherche et l’organisation. Les \u00e9tiquettes sont plus utiles lorsque l’\u00e9quipe les applique de mani\u00e8re coh\u00e9rente.<\/p>\n

R\u00e9sumer avant la fermeture<\/h3>\n

Avant de fermer un ticket, ajoutez un bref r\u00e9sum\u00e9 de la d\u00e9cision finale. Expliquez ce qui a \u00e9t\u00e9 corrig\u00e9, ce qui a \u00e9t\u00e9 modifi\u00e9, s’il reste une limitation et o\u00f9 la mise \u00e0 jour du code ou de la documentation associ\u00e9e peut \u00eatre trouv\u00e9e.<\/p>\n

Billets et culture scientifique ouverte<\/h2>\n

Les bons billets rendent les logiciels de recherche plus accueillants. Les nouveaux contributeurs peuvent comprendre les d\u00e9cisions pass\u00e9es. Les examinateurs peuvent inspecter la fa\u00e7on dont les probl\u00e8mes ont \u00e9t\u00e9 trait\u00e9s. Les \u00e9tudiants peuvent voir comment les logiciels scientifiques \u00e9voluent. Les utilisateurs peuvent signaler des probl\u00e8mes de mani\u00e8re structur\u00e9e et suivre la r\u00e9solution.<\/p>\n

Cela ne signifie pas que chaque petite pens\u00e9e a besoin d’un ticket formel. Le but n’est pas de cr\u00e9er des documents. Le but est de pr\u00e9server le raisonnement technique qui affecte le travail scientifique.<\/p>\n

Lorsque les billets sont clairs, li\u00e9s et r\u00e9sum\u00e9s, ils r\u00e9duisent la confusion. Ils montrent \u00e9galement que le projet est maintenu avec soin. Cela peut augmenter la confiance, en particulier dans les logiciels de recherche open source, o\u00f9 les utilisateurs ont souvent besoin de comprendre non seulement ce que fait le logiciel, mais aussi de quelle mani\u00e8re active et responsable il est maintenu.<\/p>\n

Conclusion : Tickets comme m\u00e9moire scientifique<\/h2>\n

Les tickets sont souvent consid\u00e9r\u00e9s comme de simples outils de gestion des t\u00e2ches, mais dans les logiciels scientifiques, ils peuvent faire beaucoup plus. Ils documentent les probl\u00e8mes, pr\u00e9servent les d\u00e9cisions, connectent le code \u00e0 la documentation et expliquent pourquoi un projet a chang\u00e9 au fil du temps.<\/p>\n

Bien utilis\u00e9, les tickets font partie de la m\u00e9moire scientifique d’un projet. Ils ne remplacent pas les papiers, la documentation, les tests ou les notes de version. Ils les relient. En rendant les discussions techniques plus faciles \u00e0 retracer, les tickets aident les \u00e9quipes de recherche \u00e0 cr\u00e9er des logiciels non seulement fonctionnels, mais \u00e9galement plus transparents, reproductibles et dignes de confiance.<\/p>\n","protected":false,"raw":"

La transparence scientifique est souvent discut\u00e9e en termes de r\u00e9sultats finaux : articles publi\u00e9s, ensembles de donn\u00e9es partag\u00e9s, code open source et r\u00e9sultats archiv\u00e9s. Celles-ci sont importantes, mais elles ne montrent pas toujours comment une \u00e9quipe de recherche a pris une d\u00e9cision. Un article peut expliquer la m\u00e9thode finale, tandis que l'historique du projet peut contenir des questions non r\u00e9solues, des rapports de bogues, des hypoth\u00e8ses de mod\u00e8les, des tests \u00e9chou\u00e9s et des compromis techniques qui ont fa\u00e7onn\u00e9 le r\u00e9sultat.<\/p>\n

C'est l\u00e0 que les billets deviennent utiles. Dans les projets de logiciels de recherche, un ticket est plus qu'un rappel de t\u00e2che. Il peut devenir un enregistrement structur\u00e9 de probl\u00e8mes, de discussions, de d\u00e9cisions et de corrections. Lorsqu'ils sont bien utilis\u00e9s, les tickets aident \u00e0 connecter les modifications de code au raisonnement scientifique, ce qui facilite la compr\u00e9hension, la r\u00e9vision et la reproduction du processus de d\u00e9veloppement.<\/p>\n

Que signifient les billets dans les logiciels scientifiques<\/h2>\n

Un ticket est une unit\u00e9 de travail ou de discussion document\u00e9e. Il peut d\u00e9crire un bogue, demander une fonctionnalit\u00e9, demander de la documentation, signaler un probl\u00e8me d'installation ou poser une question sur un mod\u00e8le. Dans des outils tels que les probl\u00e8mes GitHub, les probl\u00e8mes GitLab, JIRA ou des syst\u00e8mes similaires, les tickets donnent aux \u00e9quipes un lieu partag\u00e9 pour discuter et suivre le travail technique.<\/p>\n

Dans les logiciels scientifiques, les billets ont souvent un sens suppl\u00e9mentaire. Un ticket peut expliquer pourquoi un param\u00e8tre de solveur a \u00e9t\u00e9 modifi\u00e9, pourquoi un ensemble de donn\u00e9es a provoqu\u00e9 un comportement inattendu, pourquoi un exemple ne reproduit plus un ancien r\u00e9sultat ou pourquoi une certaine hypoth\u00e8se de mod\u00e9lisation doit \u00eatre clarifi\u00e9e. Ces d\u00e9tails peuvent ne jamais appara\u00eetre dans la publication finale, mais ils peuvent \u00eatre essentiels pour comprendre le processus de recherche.<\/p>\n

Pour cette raison, les tickets ne doivent pas \u00eatre trait\u00e9s uniquement comme des \u00e9l\u00e9ments de gestion de projet. Ils font \u00e9galement partie du dossier scientifique. Ils aident \u00e0 pr\u00e9server le raisonnement derri\u00e8re les changements qui resteraient autrement dans des notes priv\u00e9es, des fils de discussion ou la m\u00e9moire de d\u00e9veloppeurs individuels.<\/p>\n

Comment les billets rendent visibles les d\u00e9cisions de recherche<\/h2>\n

De nombreuses d\u00e9cisions scientifiques se produisent progressivement. Un chercheur remarque une production inhabituelle. Un d\u00e9veloppeur teste un exemple plus petit. Un collaborateur sugg\u00e8re que le probl\u00e8me peut provenir d'une d\u00e9pendance, d'un param\u00e8tre de maillage, d'une condition aux limites ou d'un probl\u00e8me de formatage des donn\u00e9es. Apr\u00e8s plusieurs commentaires, l'\u00e9quipe s'accorde sur un correctif ou d\u00e9cide que le comportement est attendu.<\/p>\n

Sans ticket, ce processus peut dispara\u00eetre. Le code final peut montrer ce qui a chang\u00e9, mais pas pourquoi il a chang\u00e9. Un ticket capture le contexte autour du changement : qui a signal\u00e9 le probl\u00e8me, lorsqu'il est apparu, quel exemple l'a reproduit, quelles alternatives ont \u00e9t\u00e9 discut\u00e9es et pourquoi une solution a \u00e9t\u00e9 choisie.<\/p>\n

Cette visibilit\u00e9 est particuli\u00e8rement pr\u00e9cieuse dans les projets \u00e0 long terme. Les futurs contributeurs peuvent lire le ticket et \u00e9viter de r\u00e9p\u00e9ter la m\u00eame enqu\u00eate. Les examinateurs peuvent voir si une limitation connue a \u00e9t\u00e9 prise en compte. Les \u00e9tudiants peuvent apprendre non seulement ce qu'est le flux de travail correct, mais aussi comment l'\u00e9quipe a d\u00e9couvert et affin\u00e9e.<\/p>\n

Billets comme pont entre le code, la documentation et les r\u00e9sultats<\/h2>\n

Les logiciels scientifiques vivent rarement au m\u00eame endroit. Un seul probl\u00e8me peut affecter le code, la documentation, les tests, les exemples et l'interpr\u00e9tation des r\u00e9sultats. Les billets aident \u00e0 connecter ces pi\u00e8ces.<\/p>\n

Par exemple, un ticket peut commencer par un utilisateur signalant une sortie de simulation inattendue. La discussion peut r\u00e9v\u00e9ler qu'un exemple dans la documentation est obsol\u00e8te. Une demande d'extraction met ensuite \u00e0 jour l'exemple, ajoute un test et ajuste un message d'avertissement. Plus tard, les notes de version r\u00e9sument le changement pour les utilisateurs.<\/p>\n

Dans cette cha\u00eene, le ticket agit comme le pont. Il connecte le probl\u00e8me d'origine au correctif de code, \u00e0 la mise \u00e0 jour de la documentation et au r\u00e9sum\u00e9 de la version. Sans cela, chaque partie peut sembler s\u00e9par\u00e9e. Avec lui, le projet a une histoire plus claire de ce qui s'est pass\u00e9 et pourquoi.<\/p>\n

C'est l'un des r\u00f4les les plus utiles que les billets peuvent jouer dans la transparence scientifique. Ils montrent la relation entre la maintenance technique et la signification scientifique.<\/p>\n

Qu'est-ce qu'un ticket scientifique transparent<\/h2>\n

Un ticket utile n'a pas besoin d'\u00eatre long, mais il devrait \u00eatre suffisamment clair pour qu'une autre personne puisse les comprendre et les tester. Les meilleurs billets r\u00e9duisent l'ambigu\u00eft\u00e9. Ils expliquent le probl\u00e8me, fournissent un contexte et facilitent la prochaine \u00e9tape.<\/p>\n\n\n\n\n\n\n\n\n\n\n
\u00e9l\u00e9ment du ticket<\/th>\nPourquoi c'est important<\/th>\n<\/tr>\n
Titre clair<\/td>\nAide les autres \u00e0 comprendre le probl\u00e8me avant d'ouvrir le ticket complet.<\/td>\n<\/tr>\n
\u00e9nonc\u00e9 de probl\u00e8me<\/td>\nExplique ce qui ne va pas, ne sait pas, manquant ou inattendu.<\/td>\n<\/tr>\n
\u00c9tapes pour reproduire<\/td>\nRend le probl\u00e8me testable au lieu de seulement descriptif.<\/td>\n<\/tr>\n
Comportement attendu<\/td>\nMontre ce que l'utilisateur ou le chercheur pensait que cela devait arriver.<\/td>\n<\/tr>\n
Comportement observ\u00e9<\/td>\nEnregistre ce qui s'est r\u00e9ellement pass\u00e9 dans le logiciel ou le r\u00e9sultat.<\/td>\n<\/tr>\n
D\u00e9tails d'environnement<\/td>\nAide \u00e0 identifier les probl\u00e8mes de version, de d\u00e9pendance, de plate-forme ou d'installation.<\/td>\n<\/tr>\n
Exemple minimal<\/td>\nR\u00e9duit le bruit et aide les mainteneurs \u00e0 se concentrer sur le probl\u00e8me central.<\/td>\n<\/tr>\n
R\u00e9sum\u00e9 de la d\u00e9cision<\/td>\nPr\u00e9serve pourquoi la solution finale a \u00e9t\u00e9 choisie.<\/td>\n<\/tr>\n<\/tbody><\/table>\n

Le r\u00e9sum\u00e9 de la d\u00e9cision est particuli\u00e8rement important. De nombreuses \u00e9quipes discutent soigneusement d'un probl\u00e8me, fusionnent un correctif, puis ferment le ticket sans expliquer la conclusion. Un court commentaire final peut rendre le ticket beaucoup plus utile : ce qui a \u00e9t\u00e9 modifi\u00e9, ce qui n'a pas \u00e9t\u00e9 modifi\u00e9 et ce que les utilisateurs doivent comprendre \u00e0 l'avenir.<\/p>\n

Comment les billets prennent en charge la reproductibilit\u00e9<\/h2>\n

La reproductibilit\u00e9 d\u00e9pend de plus que la disponibilit\u00e9 du code. Un futur chercheur devra peut-\u00eatre savoir quelle version a \u00e9t\u00e9 utilis\u00e9e, quel bogue a \u00e9t\u00e9 corrig\u00e9, quel comportement a chang\u00e9 et si une limitation connue a affect\u00e9 le r\u00e9sultat. Les tickets peuvent fournir cette couche de contexte manquante.<\/p>\n

Par exemple, si un r\u00e9sultat de simulation change apr\u00e8s une mise \u00e0 jour logicielle, un ticket peut expliquer que la version ant\u00e9rieure avait un bogue dans un cas EDGE sp\u00e9cifique. Si une installation \u00e9choue sur une certaine plate-forme, un ticket peut r\u00e9v\u00e9ler un conflit de d\u00e9pendance. Si une hypoth\u00e8se de mod\u00e8le \u00e9tait remise en question mais accept\u00e9e, le ticket peut expliquer le raisonnement.<\/p>\n

Ces enregistrements aident les futurs utilisateurs \u00e0 comprendre la diff\u00e9rence entre une erreur, un changement attendu et un choix de conception intentionnel. Ils aident \u00e9galement les mainteneurs \u00e0 pr\u00e9parer des journaux de modifications et des notes de version plus clairs.<\/p>\n

En ce sens, les tickets am\u00e9liorent la reproductibilit\u00e9 en documentant le chemin entre le probl\u00e8me et la r\u00e9solution. Ils facilitent l'inspection de l'historique du d\u00e9veloppement, pas seulement l'\u00e9tat final du code.<\/p>\n

Erreurs courantes qui rendent les billets moins utiles<\/h2>\n

L'erreur la plus courante est d'\u00e9crire des billets vagues. Un titre tel que \"Probl\u00e8me avec le mod\u00e8le\" ou \"Simulation bris\u00e9e\" n'aide pas les autres \u00e0 comprendre le probl\u00e8me. Un meilleur titre nomme le composant, le comportement ou l'exemple affect\u00e9.<\/p>\n

Une autre erreur est de laisser de c\u00f4t\u00e9 les \u00e9tapes de reproduction. Si d'autres ne peuvent pas r\u00e9p\u00e9ter le probl\u00e8me, ils ne pourront peut-\u00eatre pas le r\u00e9soudre. M\u00eame un petit exemple de code, un journal court ou une description claire des conditions d'entr\u00e9e peut rendre un ticket beaucoup plus utile.<\/p>\n

Les \u00e9quipes affaiblissent \u00e9galement la transparence lorsqu'elles d\u00e9placent des d\u00e9cisions importantes dans des discussions priv\u00e9es et ne les r\u00e9sume jamais dans le ticket. Une discussion priv\u00e9e peut \u00eatre pratique, mais le ticket final devrait toujours contenir la conclusion principale.<\/p>\n

D'autres probl\u00e8mes courants incluent le m\u00e9lange de plusieurs probl\u00e8mes non li\u00e9s dans un ticket, la fermeture d'un ticket sans explication, le fait de ne pas lier la demande d'extraction associ\u00e9e ou d'utiliser des \u00e9tiquettes de mani\u00e8re incoh\u00e9rente. Ces erreurs ne rendent pas les tickets inutiles, mais ils r\u00e9duisent leur valeur en tant que couche de m\u00e9moire scientifique.<\/p>\n

Un flux de travail simple pour une meilleure billetterie scientifique<\/h2>\n

Un workflow de billetterie transparent n'a pas besoin d'\u00eatre compliqu\u00e9. L'objectif est de cr\u00e9er suffisamment de structure pour pr\u00e9server le contexte sans transformer le processus en bureaucratie.<\/p>\n

Ouvrir les billets t\u00f4t<\/h3>\n

Si un probl\u00e8me semble important, ouvrez un ticket avant que les d\u00e9tails ne soient oubli\u00e9s. La premi\u00e8re version peut \u00eatre incompl\u00e8te. Il est pr\u00e9f\u00e9rable d'enregistrer t\u00f4t l'observation et d'affiner le ticket au fur et \u00e0 mesure que de nouvelles informations seront disponibles.<\/p>\n

Ajouter un contexte technique minimal<\/h3>\n

Incluez la version du logiciel, l'environnement, les conditions d'entr\u00e9e, le comportement attendu, le comportement observ\u00e9 et toute sortie pertinente. Si le probl\u00e8me implique une simulation, essayez de fournir le plus petit exemple qui reproduise le probl\u00e8me.<\/p>\n

Lien travail li\u00e9<\/h3>\n

Connectez le ticket \u00e0 des probl\u00e8mes connexes, des demandes d'extraction, des validations, des pages de documentation, des tests ou des notes de version. Ces liens aident les autres \u00e0 suivre toute la cha\u00eene, du rapport \u00e0 la r\u00e9solution.<\/p>\n

Utilisez les \u00e9tiquettes de mani\u00e8re coh\u00e9rente<\/h3>\n

Des \u00e9tiquettes telles que bug<\/code>, documentation<\/code>, reproducibility<\/code>, model-assumption<\/code>, question<\/code> et release<\/code> peuvent faciliter la recherche et l'organisation. Les \u00e9tiquettes sont plus utiles lorsque l'\u00e9quipe les applique de mani\u00e8re coh\u00e9rente.<\/p>\n

R\u00e9sumer avant la fermeture<\/h3>\n

Avant de fermer un ticket, ajoutez un bref r\u00e9sum\u00e9 de la d\u00e9cision finale. Expliquez ce qui a \u00e9t\u00e9 corrig\u00e9, ce qui a \u00e9t\u00e9 modifi\u00e9, s'il reste une limitation et o\u00f9 la mise \u00e0 jour du code ou de la documentation associ\u00e9e peut \u00eatre trouv\u00e9e.<\/p>\n

Billets et culture scientifique ouverte<\/h2>\n

Les bons billets rendent les logiciels de recherche plus accueillants. Les nouveaux contributeurs peuvent comprendre les d\u00e9cisions pass\u00e9es. Les examinateurs peuvent inspecter la fa\u00e7on dont les probl\u00e8mes ont \u00e9t\u00e9 trait\u00e9s. Les \u00e9tudiants peuvent voir comment les logiciels scientifiques \u00e9voluent. Les utilisateurs peuvent signaler des probl\u00e8mes de mani\u00e8re structur\u00e9e et suivre la r\u00e9solution.<\/p>\n

Cela ne signifie pas que chaque petite pens\u00e9e a besoin d'un ticket formel. Le but n'est pas de cr\u00e9er des documents. Le but est de pr\u00e9server le raisonnement technique qui affecte le travail scientifique.<\/p>\n

Lorsque les billets sont clairs, li\u00e9s et r\u00e9sum\u00e9s, ils r\u00e9duisent la confusion. Ils montrent \u00e9galement que le projet est maintenu avec soin. Cela peut augmenter la confiance, en particulier dans les logiciels de recherche open source, o\u00f9 les utilisateurs ont souvent besoin de comprendre non seulement ce que fait le logiciel, mais aussi de quelle mani\u00e8re active et responsable il est maintenu.<\/p>\n

Conclusion : Tickets comme m\u00e9moire scientifique<\/h2>\n

Les tickets sont souvent consid\u00e9r\u00e9s comme de simples outils de gestion des t\u00e2ches, mais dans les logiciels scientifiques, ils peuvent faire beaucoup plus. Ils documentent les probl\u00e8mes, pr\u00e9servent les d\u00e9cisions, connectent le code \u00e0 la documentation et expliquent pourquoi un projet a chang\u00e9 au fil du temps.<\/p>\n

Bien utilis\u00e9, les tickets font partie de la m\u00e9moire scientifique d'un projet. Ils ne remplacent pas les papiers, la documentation, les tests ou les notes de version. Ils les relient. En rendant les discussions techniques plus faciles \u00e0 retracer, les tickets aident les \u00e9quipes de recherche \u00e0 cr\u00e9er des logiciels non seulement fonctionnels, mais \u00e9galement plus transparents, reproductibles et dignes de confiance.<\/p>\n"},"excerpt":{"rendered":"

Reading Time: <\/span> 7<\/span> minutes<\/span><\/span>La transparence scientifique est souvent discut\u00e9e en termes de r\u00e9sultats finaux : articles publi\u00e9s, ensembles de donn\u00e9es partag\u00e9s, code open source et r\u00e9sultats archiv\u00e9s. Celles-ci sont importantes, mais elles ne montrent pas toujours comment une \u00e9quipe de recherche a pris une d\u00e9cision. Un article peut expliquer la m\u00e9thode finale, tandis que l’historique du projet peut contenir […]<\/p>\n","protected":false,"raw":""},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_locale":"fr_FR","_original_post":"https:\/\/matforge.org\/?p=310","iawp_total_views":1,"footnotes":""},"categories":[3],"tags":[],"class_list":["post-1222","post","type-post","status-publish","format-standard","hentry","category-issue-tracking-tickets-technical-requests","fr-FR"],"yoast_head":"\nUtiliser les billets pour am\u00e9liorer la transparence scientifique<\/title>\n<meta name=\"description\" content=\"D\u00e9couvrez comment les tickets d'\u00e9mission aident les \u00e9quipes de recherche \u00e0 documenter les bogues, les d\u00e9cisions, les modifications de code, les hypoth\u00e8ses de mod\u00e8les et les mises \u00e0 jour logicielles de mani\u00e8re plus transparente.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/matforge.org\/fr\/using-tickets-to-improve-scientific-transparency\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Utiliser les billets pour am\u00e9liorer la transparence scientifique\" \/>\n<meta property=\"og:description\" content=\"D\u00e9couvrez comment les tickets d'\u00e9mission aident les \u00e9quipes de recherche \u00e0 documenter les bogues, les d\u00e9cisions, les modifications de code, les hypoth\u00e8ses de mod\u00e8les et les mises \u00e0 jour logicielles de mani\u00e8re plus transparente.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/matforge.org\/fr\/using-tickets-to-improve-scientific-transparency\/\" \/>\n<meta property=\"og:site_name\" content=\"matforge.org\" \/>\n<meta property=\"article:published_time\" content=\"2026-08-21T14:28:42+00:00\" \/>\n<meta name=\"author\" content=\"Priya Nair\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"\u00c9crit par\" \/>\n\t<meta name=\"twitter:data1\" content=\"Priya Nair\" \/>\n\t<meta name=\"twitter:label2\" content=\"Dur\u00e9e de lecture estim\u00e9e\" \/>\n\t<meta name=\"twitter:data2\" content=\"10 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/matforge.org\\\/fr\\\/using-tickets-to-improve-scientific-transparency\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/fr\\\/using-tickets-to-improve-scientific-transparency\\\/\"},\"author\":{\"name\":\"Priya Nair\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/2effd7bc155a5e6357f31dac970c5795\"},\"headline\":\"Utiliser les billets pour am\u00e9liorer la transparence scientifique\",\"datePublished\":\"2026-08-21T14:28:42+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/fr\\\/using-tickets-to-improve-scientific-transparency\\\/\"},\"wordCount\":2075,\"commentCount\":0,\"articleSection\":[\"Suivi des probl\u00e8mes, billets & Demandes techniques\"],\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/matforge.org\\\/fr\\\/using-tickets-to-improve-scientific-transparency\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/matforge.org\\\/fr\\\/using-tickets-to-improve-scientific-transparency\\\/\",\"url\":\"https:\\\/\\\/matforge.org\\\/fr\\\/using-tickets-to-improve-scientific-transparency\\\/\",\"name\":\"Utiliser les billets pour am\u00e9liorer la transparence scientifique\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/#website\"},\"datePublished\":\"2026-08-21T14:28:42+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/2effd7bc155a5e6357f31dac970c5795\"},\"description\":\"D\u00e9couvrez comment les tickets d'\u00e9mission aident les \u00e9quipes de recherche \u00e0 documenter les bogues, les d\u00e9cisions, les modifications de code, les hypoth\u00e8ses de mod\u00e8les et les mises \u00e0 jour logicielles de mani\u00e8re plus transparente.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/fr\\\/using-tickets-to-improve-scientific-transparency\\\/#breadcrumb\"},\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/matforge.org\\\/fr\\\/using-tickets-to-improve-scientific-transparency\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/matforge.org\\\/fr\\\/using-tickets-to-improve-scientific-transparency\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/matforge.org\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Utiliser les billets pour am\u00e9liorer la transparence scientifique\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#website\",\"url\":\"https:\\\/\\\/matforge.org\\\/\",\"name\":\"matforge.org\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/matforge.org\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"fr-FR\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/2effd7bc155a5e6357f31dac970c5795\",\"name\":\"Priya Nair\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g\",\"caption\":\"Priya Nair\"},\"sameAs\":[\"http:\\\/\\\/matforge.org\"],\"url\":\"https:\\\/\\\/matforge.org\\\/author\\\/priya-nair\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Utiliser les billets pour am\u00e9liorer la transparence scientifique","description":"D\u00e9couvrez comment les tickets d'\u00e9mission aident les \u00e9quipes de recherche \u00e0 documenter les bogues, les d\u00e9cisions, les modifications de code, les hypoth\u00e8ses de mod\u00e8les et les mises \u00e0 jour logicielles de mani\u00e8re plus transparente.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/matforge.org\/fr\/using-tickets-to-improve-scientific-transparency\/","og_locale":"fr_FR","og_type":"article","og_title":"Utiliser les billets pour am\u00e9liorer la transparence scientifique","og_description":"D\u00e9couvrez comment les tickets d'\u00e9mission aident les \u00e9quipes de recherche \u00e0 documenter les bogues, les d\u00e9cisions, les modifications de code, les hypoth\u00e8ses de mod\u00e8les et les mises \u00e0 jour logicielles de mani\u00e8re plus transparente.","og_url":"https:\/\/matforge.org\/fr\/using-tickets-to-improve-scientific-transparency\/","og_site_name":"matforge.org","article_published_time":"2026-08-21T14:28:42+00:00","author":"Priya Nair","twitter_card":"summary_large_image","twitter_misc":{"\u00c9crit par":"Priya Nair","Dur\u00e9e de lecture estim\u00e9e":"10 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/matforge.org\/fr\/using-tickets-to-improve-scientific-transparency\/#article","isPartOf":{"@id":"https:\/\/matforge.org\/fr\/using-tickets-to-improve-scientific-transparency\/"},"author":{"name":"Priya Nair","@id":"https:\/\/matforge.org\/#\/schema\/person\/2effd7bc155a5e6357f31dac970c5795"},"headline":"Utiliser les billets pour am\u00e9liorer la transparence scientifique","datePublished":"2026-08-21T14:28:42+00:00","mainEntityOfPage":{"@id":"https:\/\/matforge.org\/fr\/using-tickets-to-improve-scientific-transparency\/"},"wordCount":2075,"commentCount":0,"articleSection":["Suivi des probl\u00e8mes, billets & Demandes techniques"],"inLanguage":"fr-FR","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/matforge.org\/fr\/using-tickets-to-improve-scientific-transparency\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/matforge.org\/fr\/using-tickets-to-improve-scientific-transparency\/","url":"https:\/\/matforge.org\/fr\/using-tickets-to-improve-scientific-transparency\/","name":"Utiliser les billets pour am\u00e9liorer la transparence scientifique","isPartOf":{"@id":"https:\/\/matforge.org\/#website"},"datePublished":"2026-08-21T14:28:42+00:00","author":{"@id":"https:\/\/matforge.org\/#\/schema\/person\/2effd7bc155a5e6357f31dac970c5795"},"description":"D\u00e9couvrez comment les tickets d'\u00e9mission aident les \u00e9quipes de recherche \u00e0 documenter les bogues, les d\u00e9cisions, les modifications de code, les hypoth\u00e8ses de mod\u00e8les et les mises \u00e0 jour logicielles de mani\u00e8re plus transparente.","breadcrumb":{"@id":"https:\/\/matforge.org\/fr\/using-tickets-to-improve-scientific-transparency\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/matforge.org\/fr\/using-tickets-to-improve-scientific-transparency\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/matforge.org\/fr\/using-tickets-to-improve-scientific-transparency\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/matforge.org\/"},{"@type":"ListItem","position":2,"name":"Utiliser les billets pour am\u00e9liorer la transparence scientifique"}]},{"@type":"WebSite","@id":"https:\/\/matforge.org\/#website","url":"https:\/\/matforge.org\/","name":"matforge.org","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/matforge.org\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"fr-FR"},{"@type":"Person","@id":"https:\/\/matforge.org\/#\/schema\/person\/2effd7bc155a5e6357f31dac970c5795","name":"Priya Nair","image":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/secure.gravatar.com\/avatar\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f11e168d4cd2f1eff83cbb851d6cff42d81d88bb59d8831ee77468aa4a5eea88?s=96&d=mm&r=g","caption":"Priya Nair"},"sameAs":["http:\/\/matforge.org"],"url":"https:\/\/matforge.org\/author\/priya-nair\/"}]}},"_links":{"self":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/1222","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/comments?post=1222"}],"version-history":[{"count":1,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/1222\/revisions"}],"predecessor-version":[{"id":1368,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/1222\/revisions\/1368"}],"wp:attachment":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/media?parent=1222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/categories?post=1222"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/tags?post=1222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}