Golden Thread : demain matin, je commence par quoi ?

Entrez.

Le café est chaud et les cookies aux noisettes viennent de sortir du four. Prenez-en un avant que les castors juniors ne trouvent la boîte.

La dernière fois, dans Golden Thread : retrouver le fil, nous avons parlé de Golden Thread : un chemin commun pour développer avec des agents IA, sans que chaque membre de l’équipe invente sa méthode dans son coin.

Aujourd’hui, la question est plus terre à terre : par où commencer demain matin ?

Avant de sortir les outils, remettons le plan de l’atelier sur la table.

Besoin
   ↓
Readiness
   ↓
Délégation à l’agent
   ↓
Validation
   ↓
Capitalisation

Un besoin apparaît.

L’équipe le prépare jusqu’à ce qu’il soit suffisamment clair pour être confié à un agent. Elle encadre ensuite la délégation, vérifie le résultat et conserve les décisions, les preuves et les enseignements qui pourront servir au collectif.

Ce fil forme le cœur de Golden Thread.

Il rend notre manière de travailler avec l’IA explicite, partageable et améliorable. Les outils pourront changer. Les modèles aussi. Le chemin restera compréhensible par toute l’équipe.

Seulement, ce schéma commence un peu trop tard.

Avant la Readiness, une décision nous attend sur le pas de la porte.

« D’accord, Vieux Castor… mais demain matin, je commence par quoi ? »

Demain matin, ne commencez pas par installer un nouvel outil.

Prenez une tâche réelle de votre backlog.

Une tâche que vous aviez prévu de confier à Cursor, Claude Code, Copilot ou à l’agent du moment.

Posez-la sur l’établi.

Puis prenez quelques minutes pour décider si vous souhaitez réellement la déléguer — et jusqu’où.

Avant la Readiness, il y a une décision

Quand une tâche arrive devant nous, l’usage de l’IA devient vite un réflexe.

On ouvre l’agent. On colle le ticket. On ajoute quelques explications. Puis on attend que la machine produise quelque chose.

Parfois, le résultat est bon.

Parfois, il a simplement l’air bon.

Le problème commence souvent avant le premier prompt : personne n’a vraiment décidé quelle partie du travail devait être confiée à l’agent.

Or, « déléguer une tâche » peut vouloir dire beaucoup de choses.

On peut demander à l’agent de chercher plusieurs pistes, d’écrire un premier jet ou de modifier le code. On peut également lui laisser le soin de choisir une architecture ou de décider si une solution est acceptable.

Ces actions n’engagent ni les mêmes compétences ni les mêmes responsabilités.

Alors, avant d’envoyer votre tâche à l’IA, je vous propose quatre questions.

Gardez la checklist rigide pour plus tard. Ici, nous cherchons plutôt à provoquer une petite conversation avec vous-même, un collègue ou l’équipe.

Qu’est-ce que vous voulez vraiment déléguer ?

Prenons une migration de bibliothèque.

Vous pouvez demander à un agent de repérer les appels concernés, de proposer un plan de migration ou de modifier les fichiers.

Vous pouvez aussi lui demander de décider si cette migration est pertinente, quelle stratégie adopter et quels risques l’équipe doit accepter.

Dans les deux cas, vous utilisez l’IA. Le niveau de délégation, lui, n’a rien à voir.

Commencez donc par nommer précisément ce que vous lui confiez.

L’exploration ?

L’exécution ?

La préparation d’une décision ?

La décision elle-même ?

Plus la tâche se rapproche d’un choix structurant, plus le jugement humain doit rester visible.

L’agent peut comparer des options, chercher des contradictions et faire apparaître des angles morts. Il peut nourrir la décision. La responsabilité du choix reste de notre côté de l’établi.

Qu’avez-vous besoin de comprendre vous-même ?

Certaines tâches sont pénibles sans être particulièrement formatrices.

Renommer une série de méthodes, produire une première version de tests répétitifs ou adapter vingt fichiers à une convention déjà décidée : la délégation peut libérer du temps sans affaiblir l’équipe.

D’autres tâches participent directement à la construction de votre compréhension.

Découvrir une partie inconnue du système. Analyser la cause d’un incident. Prendre en main un framework que vous devrez maintenir. Comprendre pourquoi une transaction se comporte mal en production.

Dans ces situations, déléguer trop tôt peut produire un résultat tout en vous privant du chemin qui permet de le comprendre.

Je ne vais pas vous demander de tout faire à la main pour mériter votre café.

Repérez simplement ce que vous devez encore apprendre.

Vous pouvez confier la recherche à l’agent, lui demander des explications, faire générer des hypothèses ou travailler avec lui en binôme. Gardez toutefois les mains sur les parties qui construisent une compétence dont vous aurez besoin demain.

Comment découvrirez-vous que l’agent s’est trompé ?

Une IA peut produire du code propre, une explication fluide et une pull request parfaitement présentée tout en ayant mal compris le problème.

Avant de déléguer, demandez-vous comment vous reconnaîtrez une erreur.

Disposez-vous de tests pertinents ? D’un comportement attendu que vous savez reproduire ? D’une documentation fiable ? D’un collègue capable de relire le résultat ?

Peut-être connaissez-vous suffisamment le domaine pour repérer une proposition absurde dès la première lecture.

Si vous ne voyez aucun moyen sérieux de vérifier le travail, la tâche est probablement trop large pour être confiée d’un seul bloc.

Découpez-la.

Demandez d’abord à l’agent de cartographier le problème. Faites-lui ensuite proposer plusieurs options. Validez cette compréhension avant de l’autoriser à modifier quoi que ce soit.

Cette délégation par étapes ralentira peut-être les premières minutes. Elle évitera parfois de passer l’après-midi à réparer une solution très efficace au mauvais problème.

Que se passe-t-il si le résultat est mauvais ?

Toutes les erreurs n’ont pas le même poids.

Une mauvaise proposition de nom pour une variable coûte quelques secondes.

Une erreur dans un script de migration de données peut coûter beaucoup plus cher.

Une recommandation incorrecte concernant les droits d’accès, la facturation ou des données de santé change encore la nature du problème.

Regardez donc la tâche sous deux angles : l’impact d’une erreur et la possibilité de revenir en arrière.

Un changement local, testé et facilement annulable peut être largement délégué.

Une action irréversible, sensible ou difficile à observer demande davantage de contrôle humain. Elle peut nécessiter un découpage plus fin, des validations intermédiaires ou une seconde paire d’yeux.

La frontière entre ce que nous confions à l’IA et ce que nous gardons sous responsabilité humaine dépend du contexte, du niveau de maîtrise de l’équipe et des garde-fous disponibles.

Golden Thread sert à rendre cette frontière visible.

Déléguer n’est pas toujours une réponse binaire

Après cette discussion, vous n’obtiendrez pas forcément un simple oui ou non.

Vous pourrez confier entièrement une tâche bornée et facilement vérifiable à l’agent.

Vous pourrez travailler avec lui en binôme, en gardant la compréhension et les choix importants de votre côté de l’établi.

Vous pourrez découper la tâche pour ne lui confier que les parties réversibles.

Vous pourrez enfin décider que, cette fois, le travail restera humain.

Dans les quatre cas, vous aurez avancé.

Vous aurez remplacé un réflexe par une décision.

Ce n’est pas encore un contrat de délégation IA complet : on décide d’abord si et jusqu’où déléguer. Le contrat précisera ensuite objectif, limites et preuves attendues au moment de confier le travail.

Maintenant, créez le dépôt

Une décision gardée dans un coin de la tête disparaît souvent avec le prochain café.

Une décision écrite, partagée et améliorable commence à devenir une pratique d’équipe — le même souci que dans L’IA accélère les individus, mais qui protège le collectif ? : ce qui reste seulement dans une tête ne protège personne.

Créez donc un dépôt Git nommé golden-thread.

Vous pouvez partir de l’exemple public sebastien-ribiere/golden-thread : forkez-le, clonez-le, ou recopiez sa structure dans votre organisation.

git clone https://github.com/sebastien-ribiere/golden-thread.git

La structure de départ ressemble à ceci :

golden-thread/
├── README.md
├── delegation/
│   └── decision.md
├── readiness/
├── harness/
├── proof/
├── memory/
└── docs/

Les dossiers hors delegation/ sont encore presque vides.

C’est prévu.

Ce sont des places réservées pour la suite du chemin — pas un process à remplir d’un coup. Aujourd’hui, ils représentent une promesse : votre manière de développer avec des agents IA deviendra explicite, partageable et améliorable.

L’équipe choisira consciemment ce qu’elle délègue. Elle préparera les tâches avant de les confier à un agent, exigera des éléments vérifiables et conservera ce qu’elle apprend en chemin.

Vous pouvez commencer votre README.md par quelques lignes seulement :

# Golden Thread

Ce dépôt porte la manière dont notre équipe développe avec des agents IA :
une pratique explicite, partageable et améliorable.

Puis créez delegation/decision.md.

Voici une première version volontairement simple (celle du dépôt d’exemple) :

# Décision de délégation

> Utilisez ce document sur une tâche réelle.
> Le but est de rendre la décision de délégation explicite,
> pas de produire une fiche parfaite.

## Tâche

Décrire la tâche que nous envisageons de déléguer.

## Ce que nous voulons déléguer

Préciser la partie confiée à l’agent :

- exploration ;
- préparation ;
- exécution ;
- aide à la décision ;
- autre.

## Ce qui reste sous responsabilité humaine

Indiquer les choix, connaissances, validations ou actions
que l’équipe conserve.

## Ce que nous devons comprendre nous-mêmes

Préciser les parties qui construisent une compétence
ou une compréhension que l’équipe doit garder.

## Vérification

Expliquer comment une erreur sera détectée :

- tests ;
- revue humaine ;
- comportement attendu ;
- documentation de référence ;
- validation métier ;
- autre preuve vérifiable.

## Impact d’une erreur

Décrire brièvement les conséquences possibles,
la facilité de retour arrière et le niveau de contrôle nécessaire.

## Décision

- [ ] Déléguer
- [ ] Travailler en binôme avec l’agent
- [ ] Découper avant de déléguer
- [ ] Garder la tâche humaine

## Pourquoi ?

Résumer la décision en quelques lignes.

## Limites données à l’agent

Préciser ce que l’agent peut modifier, proposer ou exécuter,
et ce qui lui est interdit.

## Condition de passage à la Readiness

Décrire ce qui doit être vrai avant de préparer
réellement la délégation.

Ne passez pas la matinée à perfectionner ce modèle.

Utilisez-le sur la tâche que vous avez posée sur l’établi. Discutez-en avec un collègue si la réponse ne vous paraît pas évidente.

Puis faites un premier commit.

Commit #1 — Décider avant de déléguer

Et la Readiness dans tout cela ?

La décision de délégation se situe juste avant le chemin que nous avons tracé au début de l’article.

Elle répond à une première question :

Devons-nous faire entrer tout ou partie de ce travail dans Golden Thread ?

La Readiness prend ensuite le relais :

Avons-nous suffisamment préparé cette tâche pour que l’agent puisse réussir ?

Une tâche peut mériter d’être déléguée tout en manquant encore de contexte, de contraintes ou de critères de validation.

C’est ce que nous déplierons au prochain passage dans l’atelier.

Sur l’établi aujourd’hui

Demain matin, choisissez une véritable tâche.

Décidez ce que vous souhaitez déléguer, ce que vous gardez sous responsabilité humaine et comment vous découvrirez une erreur.

Créez ensuite le dépôt — ou partez de l’exemple golden-thread — et remplissez votre premier delegation/decision.md.

Votre Golden Thread reste léger.

Il ne contient encore ni harness sophistiqué, ni armée de sous-agents : seulement le début d’une méthode commune.

FAQ

Faut-il commencer Golden Thread par la Readiness ?

Non. Avant la Readiness, il y a une décision : déléguer ou non, et jusqu’où. La Readiness prépare ensuite une tâche déjà jugée digne d’être confiée en tout ou partie à un agent.

Qu’est-ce qu’une décision de délégation ?

C’est le choix explicite de ce que l’on confie à l’agent, de ce que l’on garde sous responsabilité humaine, et de la manière dont on détectera une erreur. Ce n’est pas encore le contrat de délégation IA, qui précisera objectif, limites et preuves au moment de confier le travail.

Déléguer signifie-t-il tout confier à l’agent ?

Non. Déléguer peut vouloir dire explorer, préparer, exécuter, aider à décider — ou seulement une partie de la tâche. On peut aussi travailler en binôme, découper, ou garder le travail humain.

Que mettre dans delegation/decision.md ?

Une tâche réelle, ce qui est délégué, ce qui reste humain, ce qu’il faut encore comprendre, comment vérifier, l’impact d’une erreur, la décision prise et ses limites. Un modèle simple suffit : l’essentiel est de l’utiliser, pas de le perfectionner.

En résumé

Avant d’ouvrir un agent, prenez une tâche réelle et décidez explicitement : quoi déléguer, quoi comprendre vous-même, comment détecter une erreur, quel impact si ça rate. Formalisez cette décision dans un dépôt partagé (delegation/decision.md). Déléguer n’est pas un oui/non : vous pouvez déléguer, travailler en binôme, découper ou garder humain. La Readiness vient après cette décision, pas à sa place.

Servez-vous un autre café.

Il reste quelques cookies aux noisettes derrière la boîte à outils.