Le vieux castor a une règle simple : quand un outil coupe plus vite que la main ne comprend, on garde les doigts loin de la lame.

Ça vaut pour les scies circulaires.

Ça vaut aussi pour les agents IA.

Ce matin-là, dans l’atelier, la machine avait bien travaillé. Elle avait raboté trois planches, percé deux mortaises, proposé un nouveau plan de barrage et rangé les copeaux dans un joli tas presque rassurant.

Sur le papier, tout semblait propre.

Puis quelqu’un a demandé :

Pourquoi la poutre principale a changé de place ?

Le castor junior a fouillé dans le ticket. Le vieux castor a repris la conversation avec l’agent. Un autre a ouvert la pull request. Quelqu’un a murmuré : “Je crois qu’on avait parlé de ça mardi.”

Le cookie, lui, n’a rien dit.

Il s’est contenté de s’effriter dans l’assiette, avec cette discrétion cruelle des biscuits qui savent déjà comment l’histoire va finir.

Et c’est souvent comme ça qu’on découvre le vrai problème avec les agents IA : ils peuvent aller vite, très vite, sans toujours laisser derrière eux un chemin qu’on peut suivre sans lampe frontale.

Le fil d’Ariane, version copeaux et Markdown

Le vieux castor aime les vieilles histoires : celles qui portent une image forte survivent longtemps, surtout quand elles savent nommer un problème.

Il y en a une avec un labyrinthe, un monstre, un héros un peu trop sûr de lui, et une pelote de fil.

Ariane donne un fil à Thésée pour qu’il puisse entrer dans le labyrinthe, faire ce qu’il a à faire, puis retrouver la sortie. Le fil ne tue pas le Minotaure à sa place. Il ne transforme pas le labyrinthe en couloir bien éclairé. Il ne rend pas l’aventure confortable.

Il permet de revenir.

Dans l’atelier, cette image a fini par se poser sur l’établi.

Quand on délègue une tâche à un agent IA, on l’envoie souvent dans un petit labyrinthe : du code, des tickets, des conventions d’équipe, des contraintes implicites, des décisions passées, des bouts de documentation plus ou moins frais, et quelques monstres tapis dans les coins.

L’agent peut revenir avec une poutre magnifique.

Le souci commence quand personne ne sait par quel couloir il est passé.

C’est de là que vient l’idée de Golden Thread : un fil doré que l’on déroule quand on délègue à l’IA, pour pouvoir relier l’intention de départ, le contexte donné, les choix effectués, les changements produits, les preuves associées et la validation humaine.

Le fil ne fait pas le travail à la place de l’équipe.

Il évite surtout de perdre le chemin.

Quand l’IA accélère, le brouillard s’épaissit

Dans l’article précédent, je posais une question qui me travaille de plus en plus :

Si l’IA accélère les individus, qui garde le fil collectif ?

Avec les agents IA, la question devient moins théorique.

Un assistant conversationnel aide à réfléchir, rédiger ou débloquer une idée. Un agent IA peut aller plus loin : lire le code, modifier des fichiers, lancer des commandes, proposer une architecture, créer une branche, ouvrir une pull request, corriger une erreur qu’il vient lui-même de provoquer.

C’est puissant.

Et comme souvent avec les bons outils, le danger ne vient pas seulement de l’échec. Il vient aussi du succès.

Quand l’agent échoue franchement, on se méfie. Quand il produit quelque chose de propre, cohérent, bien formaté, avec des tests qui passent et une petite explication rassurante, on baisse la garde.

Le vieux castor connaît ça.

Une planche bien poncée peut quand même être coupée trop court.

Un agent IA peut répondre avec brio à une demande mal posée. Il peut optimiser ce qu’il voit, compenser ce qu’on a oublié de préciser, remplir les trous avec quelque chose de plausible, puis présenter le tout avec l’aplomb tranquille d’un apprenti qui revient couvert de sciure en disant : “C’est bon, j’ai réparé le barrage.”

Parfois, c’est vrai.

Parfois, il a juste déplacé le problème trois mètres plus loin.

Le plan a disparu, mais les copeaux sont bien rangés

Le plus étrange, avec ce genre de problème, c’est qu’il ne ressemble pas toujours à un problème.

Le build passe.
Les tests sont verts.
La pull request est polie.
L’agent a même ajouté un petit résumé très propre, avec des phrases rassurantes et une confiance de labrador.

Dans l’atelier, tout semble rangé.

Et pourtant, quand on cherche le plan, il manque un morceau.

Pourquoi cette poutre a-t-elle été déplacée ? Quelle contrainte a guidé ce choix ? Est-ce qu’on a accepté ce compromis, ou est-ce que l’agent l’a déduit tout seul ? Est-ce qu’un humain a relu l’intention, ou seulement le résultat ?

Rien ne fume. Rien ne clignote en rouge.

On continue.

Puis, quelques jours plus tard, quelqu’un doit modifier le même endroit. Il ouvre le ticket, la conversation, la pull request, les commits. Il retrouve des traces, mais pas vraiment le chemin. Il y a des morceaux de réponse partout, comme des bouts de ficelle coupés trop court.

Alors il reconstitue.

Il suppose.

Il demande à quelqu’un qui “était là”.

Et parfois, il finit par refaire le travail mental que l’équipe pensait avoir déjà payé.

C’est peut-être là que le vieux castor commence à se méfier.

L’agent a peut-être bien travaillé. Le problème vient plutôt de ce que l’équipe ne sait plus très bien ce qu’elle a compris.

Les gens plus sérieux que lui pourraient appeler ça de la dette cognitive.

Dans l’atelier, on dit plutôt : “on a encore livré un meuble avec le plan coincé dans la sciure”.

Golden Thread, une discipline de continuité

Golden Thread répond à une question assez simple à formuler, et beaucoup moins simple à traiter :

Comment fait-on pour développer avec l’IA sans perdre la maîtrise collective ?

Dans mon esprit, Golden Thread n’est pas seulement un outil, un framework ou un harnais d’agent.

C’est une discipline de continuité.

Attention au homonyme : dans certains secteurs régulés, « golden thread » désigne la traçabilité formelle entre exigences, conception et tests. Dans l’atelier Mentursidae, le terme désigne autre chose : un fil conducteur pour déléguer à l’IA sans perdre la maîtrise collective.

Une manière de garder un lien lisible entre ce qu’on voulait faire, ce qu’on a demandé, ce que l’agent a compris, ce qu’il a modifié, ce qu’on a vérifié, ce qu’on a validé, et ce que l’équipe pourra encore expliquer plus tard.

Le mot important, ici, c’est “équipe”.

Parce qu’un développeur seul peut bricoler son setup, ses prompts, ses règles Cursor, son Claude.md, ses scripts, ses habitudes, ses petits raccourcis. Il peut obtenir de très bons résultats. Il peut même devenir très rapide.

Mais à l’échelle d’une équipe, la question change.

Comment un autre développeur reprend-il le travail ? Comment un tech lead comprend-il une décision prise avec l’aide d’un agent ? Comment la sécurité vérifie-t-elle qu’une contrainte n’a pas été oubliée ? Comment un SRE voit-il l’impact opérationnel ? Comment une organisation évite-t-elle de dépendre du style de prompting d’une seule personne ?

Golden Thread commence là.

Au moment où l’on arrête de voir l’IA comme une accélération individuelle isolée, et où l’on commence à se demander comment l’équipe garde une mémoire commune de ce qui est en train d’être fabriqué.

Le harnais vient ensuite

Le harnais reste important.

Dans l’atelier, c’est l’ensemble des guides, des serre-joints, des gabarits, des règles tracées au crayon sur l’établi. Ce sont les choses qui empêchent la pièce de bois de partir de travers quand la scie démarre.

Dans un environnement de développement avec IA, ce harnais peut prendre plusieurs formes : des templates de spécification, des commandes d’agent, des règles de dépôt, des hooks, des tests, des scans, des policies, des conventions de pull request, des agents spécialisés, des checkpoints humains.

C’est très concret.

Et c’est nécessaire.

Mais le harnais matérialise une intention plus large. Il rend le fil praticable dans le quotidien de l’équipe.

Sans discipline de continuité, le harnais devient vite une collection d’outils. On ajoute une règle ici, un agent là, un template ailleurs. L’ensemble peut être impressionnant, mais le chemin reste flou.

Avec un fil clair, l’outillage trouve sa place.

On sait pourquoi on demande une intention avant génération. On sait pourquoi une PR doit raconter le changement. On sait pourquoi certaines preuves sont attendues. On sait pourquoi certaines tâches doivent repasser par un humain. On sait pourquoi une décision importante ne doit pas rester coincée dans une conversation temporaire.

Le harnais aide l’agent à travailler.

Le fil aide l’équipe à comprendre ce qu’elle délègue.

Avant le prompt, il y a la demande

On parle souvent de “bien prompter”.

C’est utile. Mais le prompt arrive déjà tard dans l’histoire.

Avant le prompt, il y a la demande. Et parfois, elle est molle comme une planche humide.

“Refactor ce module.”

“Améliore cette API.”

“Ajoute la gestion des erreurs.”

“Fais un truc plus propre.”

Un humain expérimenté peut parfois deviner l’intention derrière ces phrases. Il va poser des questions, se souvenir d’une discussion, sentir qu’un détail est louche, repérer que le vrai sujet est caché sous le ticket.

Un agent IA, lui, travaille avec ce qu’on lui donne. Quand le contexte manque, il complète. Quand l’objectif est flou, il optimise quelque chose. Quand les contraintes sont implicites, il peut passer à côté avec une élégance remarquable.

Le Golden Thread commence donc avant la génération.

Il commence au moment où l’on se demande si la tâche est prête à être confiée à un agent : ce qu’on appelle la readiness dans l’atelier.

L’intention tient-elle debout ? Le périmètre est-il clair ? Les contraintes importantes sont-elles visibles ? Les critères d’acceptation permettent-ils de reconnaître une bonne réponse ?

Rien de très spectaculaire.

Juste le vieux geste artisanal : mesurer avant de couper.

Pendant le travail, garder une main sur le fil

Une fois l’agent lancé, le fil continue.

Là encore, l’objectif n’est pas de regarder chaque copeau tomber au ralenti. Si l’on délègue, il faut accepter que l’agent travaille.

Mais déléguer ne veut pas dire disparaître.

Le vieux castor laisse le castor junior aller chercher une planche. Il peut même le laisser raboter un morceau. En revanche, s’il entend démarrer la tronçonneuse près de la poutre maîtresse, il lève un sourcil.

Le bon niveau de contrôle dépend du risque.

Corriger une faute dans une documentation interne ne demande pas les mêmes garde-fous que modifier un mécanisme d’authentification. Générer un squelette de composant ne pèse pas aussi lourd que refactorer un module critique. Expérimenter dans une branche locale n’engage pas l’équipe comme une modification poussée vers un environnement partagé.

Une bonne pratique Golden Thread devrait donc aider à doser l’attention.

Elle laisse respirer les gestes simples. Elle ralentit quand l’impact augmente. Elle remet un humain dans la boucle aux endroits où une mauvaise décision coûterait cher.

Le but n’est pas de transformer chaque délégation en cérémonie administrative.

Les équipes feraient comme l’eau : elles passeraient ailleurs.

Le bon chemin doit rester praticable, surtout les jours où l’atelier est bruyant.

Après la génération, les preuves comptent

Quand un agent propose une modification, la revue humaine peut vite devenir pénible.

Le code a l’air propre. Les fichiers sont nombreux. L’explication semble raisonnable. La PR est longue comme un dimanche sans café.

Alors l’humain fait ce qu’il peut.

Il lit en diagonale. Il zoome sur les endroits qui sentent le risque. Il fait confiance à son intuition. Il espère que les tests couvrent le bon comportement. Il se promet de revenir plus tard sur ce passage étrange, puis une notification Slack surgit, et le monde continue.

C’est là que les preuves changent la conversation.

Le mot « preuve » peut sembler solennel. Dans l’atelier, il est très simple.

Tu as déplacé cette poutre ?

Montre pourquoi.

Montre ce que ça change.

Montre que le barrage tient encore.

Une preuve peut être un test, une analyse d’impact, une vérification de sécurité, une comparaison avant/après, une règle de policy respectée, une trace de décision. Rien n’oblige à tout ritualiser. Mais plus le risque augmente, plus il devient dangereux de se contenter d’un “ça a l’air bon”.

Sans preuves, on demande à l’attention humaine de compenser la vitesse de production de la machine. Mauvais marché. L’attention humaine est précieuse, limitée, souvent déjà bien entamée par trois réunions, deux urgences et un cookie trop sec.

Avec des preuves attachées au fil, la revue devient moins archéologique.

On ne fouille plus un chantier au hasard. On suit le chemin.

Garder le fil ne veut pas dire tout stocker

Dans un monde anxieux, on peut vite confondre traçabilité et accumulation.

Alors on garde tout.

Les prompts, les réponses, les logs, les commits, les tickets, les captures, les commentaires, les bouts de conversation, les fichiers temporaires, les résumés automatiques, les résumés des résumés automatiques.

Et très vite, l’atelier ressemble à une remise où l’on aurait empilé toutes les chutes de bois depuis 2017 “au cas où”.

Le vieux castor connaît cette phrase.

“Au cas où.”

C’est souvent comme ça qu’on fabrique des cimetières à contexte.

Garder le fil, c’est conserver ce qui permettra de comprendre plus tard.

Quelle était l’intention ? Quelles hypothèses ont été utilisées ? Qu’est-ce qui a changé ? Quelles options ont été écartées ? Quelles preuves montrent que le résultat est acceptable ? Qui a validé quoi ?

Ces questions ne demandent pas une montagne d’archives. Elles demandent des traces bien placées.

Un fil, pas une pelote emmêlée dans un tiroir.

Une première pelote suffit

On peut commencer petit.

Pas besoin d’un portail interne magnifique, d’un essaim d’agents spécialisés, d’un moteur de gouvernance complet et d’un logo avec dégradé doré.

Une première version peut tenir sur quelques habitudes solides — la fiche Golden Thread en résume l’essentiel.

Une tâche confiée à un agent devrait avoir une intention claire, un contexte explicite, des limites, des critères d’acceptation et une trace des preuves — un contrat de délégation IA en quelques lignes suffit souvent. La pull request devrait raconter ce qui a été changé et pourquoi. Les décisions importantes devraient sortir de la conversation temporaire pour rejoindre un endroit retrouvable.

Ce n’est pas grandiose.

C’est exactement pour ça que ça peut marcher.

Le vieux castor se méfie des grands systèmes qui promettent de tout ranger à sa place. Il préfère les premiers gestes qui tiennent même quand l’atelier est bruyant, que le café refroidit, et qu’un castor junior vient de demander si “normalement, les logs en production, ça peut contenir un token d’API”.

À partir de là, on peut enrichir.

Des commandes pour préparer les tâches. Des skills pour relire les spécifications. Des policies pour bloquer certains changements. Des agents spécialisés pour produire des tests, de la documentation ou une analyse d’impact. Une mémoire collective vivante — ou une piste du type Morpheus — pour retrouver les décisions.

Mais le cœur reste simple : chaque délégation déroule un fil.

Revenir avec autre chose qu’un tas de copeaux

Ariane avait compris quelque chose que les équipes modernes redécouvrent avec les agents IA : entrer dans le labyrinthe, c’est parfois la partie facile.

Le plus dur, c’est d’en ressortir avec une histoire claire.

Dans l’atelier, le vieux castor n’a rien contre les machines. Il aime les bons outils. Il aime quand une scie coupe droit, quand un plan devient une charpente, quand un agent IA l’aide à sortir une idée de sa tête avant que le café soit froid.

Mais il garde une méfiance saine.

Une machine qui travaille vite peut aussi cacher vite. Elle peut produire du code, de la documentation, des décisions implicites et des copeaux dans le même mouvement.

Alors il garde une pelote sur l’établi.

Un fil doré.

À chaque délégation, on l’accroche au premier clou : intention, contexte, hypothèses, changements, preuves, validation.

Quand l’agent revient, on regarde ce qu’il a rapporté.

Puis on tire doucement sur le fil.

On refait le chemin.

Et si le chemin tient, alors peut-être qu’on peut garder la poutre.

Peut-être même qu’on peut reprendre un cookie.

En résumé

Quand on délègue à un agent IA, le risque principal n’est pas seulement l’erreur — c’est la perte du fil entre l’intention et le résultat. Golden Thread est la discipline qui maintient ce lien : préparer la demande (readiness) avant le prompt, doser le contrôle pendant le travail, exiger des preuves après la génération, et conserver des traces utiles sans tout archiver. Le harnais matérialise le fil ; il ne le remplace pas.

Questions fréquentes

Golden Thread, c’est quoi concrètement ?

Une discipline de continuité : garder un lien lisible entre l’intention de départ, le contexte donné, les choix effectués, les changements produits, les preuves associées et la validation humaine — surtout quand un agent IA a fait une partie du travail.

En quoi cela diffère-t-il du « golden thread » des secteurs régulés ?

Dans l’industrie régulée (construction, santé), le terme désigne souvent une traçabilité formelle entre exigences, conception et tests. Ici, Golden Thread désigne un fil conducteur pour déléguer à l’IA sans perdre la maîtrise collective — moins une conformité documentaire qu’une habitude d’équipe.

Faut-il archiver toutes les conversations avec l’agent ?

Non. Garder le fil, ce n’est pas tout stocker. L’objectif est de conserver les traces qui permettront de comprendre plus tard : intention, hypothèses, changements, preuves et validation — pas une pelote emmêlée de logs et de captures « au cas où ».

Par où commencer sans construire une usine à process ?

Quelques habitudes suffisent : une demande ready avant le prompt, un court contrat de délégation, une pull request qui raconte le changement, et des preuves proportionnées au risque. Le reste peut venir ensuite.

Dans le prochain article, on descend dans le concret : comment préparer une tâche avant de lancer un agent, quels garde-fous poser dans un dépôt, et à quoi ressemble un premier harnais Golden Thread quand on arrête de théoriser pour couper du bois.