L’assistant doré releva enfin la tête du terminal.

— C’est terminé.

Le Vieux Castor continua de touiller son café.

— Ah.

— Tous les tests passent.

Cette fois, il leva les yeux.

— Combien ?

— Quatre cent vingt-sept.

Petit Castor se pencha vers l’écran. Une belle colonne de coches vertes descendait presque jusqu’en bas du terminal.

unit tests          ✅
acceptance tests    ✅
coverage            ✅
lint                ✅
security scan       ✅

— Bon. On ferme la tâche ?

Le Vieux Castor contempla l’écran quelques secondes.

— Une magnifique pastèque.

Petit Castor fronça les sourcils.

— Une quoi ?

— Verte à l’extérieur.

Il mima un coup de couteau.

— Rouge à l’intérieur.

L’assistant doré resta silencieux.

Le café, lui, commençait déjà à refroidir.

Le piège des pastèques

Un pipeline entièrement vert procure une sensation assez agréable.

Tout va bien.

Ou, plus exactement : tout ce que nous avons regardé va bien.

La nuance compte.

Un test peut être excellent et laisser malgré tout un angle mort. Il répond à la question qu’on lui a posée. L’erreur peut très bien habiter dans celle que personne n’a pensé à poser.

Prenons une fonctionnalité composée de plusieurs morceaux.

Chaque composant fonctionne. Les tests unitaires passent. Les scénarios d’acceptation aussi.

Puis quelqu’un essaye réellement d’utiliser la fonctionnalité.

Rien.

Toutes les pièces ont été fabriquées.

Personne n’a branché les fils.

Imaginez trois microservices testés unitairement, chacun vert dans son coin. L’agent a ajouté un champ customerId côté commande, mais oublié de le propager à la facturation. Les tests d’intégration entre services n’existent pas. Résultat : quatre cent vingt-sept coches vertes, et un parcours utilisateur qui s’arrête net au moment du paiement.

Petit Castor fixa de nouveau le pipeline.

— Donc mes quatre cent vingt-sept tests ne valent rien ?

— Bien sûr que si.

Le Vieux Castor attrapa un crayon.

— Ils disent beaucoup de choses. Le problème commence quand ton cerveau ajoute tout seul cette ligne à la fin.

correct              ✅

— Ah.

— Oui. Celle-là, personne ne l’a exécutée.

Voilà notre pastèque.

Beaucoup de vert parfaitement légitime autour d’une zone rouge que personne n’avait pensé à ouvrir.

Comment faisait-on avant les agents ?

Le Vieux Castor repoussa le terminal.

— Imagine que ce code ait été écrit par Marcel.

— Marcel ?

— Il nous fallait un développeur pour l’histoire.

— D’accord. Marcel.

Marcel ouvre une pull request.

Le lead dev ne cherche généralement pas à démontrer que chaque ligne est correcte. Il essaye surtout de comprendre assez bien le changement pour décider s’il peut l’accepter.

Il regarde si la demande a été comprise, si les tests lui semblent convaincants et si quelque chose d’existant risque d’avoir été cassé. Il parcourt le code, repère une dépendance étrange, une abstraction douteuse ou un raccourci qui vieillira mal.

Et parfois il demande simplement :

« Pourquoi tu as fait ça comme ça ? »

Tout cela mélange expérience, pratiques d’équipe et outils.

En somme, du craft — l’artisanat logiciel : savoir quoi regarder, avec quels instruments, plutôt que relire tout à l’aveugle.

Un artisan ne juge pas une planche uniquement à sa longueur. Il regarde comment elle a été coupée, comment elle va travailler une fois assemblée et si elle convient vraiment à la pièce qu’il construit.

Et il s’aide d’outils.

Une équerre suffit parfois à lui éviter dix minutes d’hésitation.

Et puis l’agent arrive

Petit Castor rouvrit le terminal.

— D’accord. Alors je review le code de l’agent exactement comme celui de Marcel.

Le Vieux Castor lui montra la quantité de modifications.

— Tu as combien de lignes ?

Petit Castor fit défiler.

Puis encore.

Puis encore.

— Beaucoup.

L’IA change surtout l’échelle.

Un agent peut produire en quelques minutes une quantité de code qu’un humain aurait mis des heures à écrire. C’est précisément pour cela qu’on lui délègue du travail.

Mais si chaque minute gagnée à la production se transforme en dix minutes de relecture, le goulot d’étranglement a simplement changé d’établi.

Le lead doit pourtant toujours répondre à la même question :

Est-ce que j’ai suffisamment confiance dans ce changement pour l’accepter ?

Il va donc avoir besoin d’autres façons de regarder le travail.

Remettre des instruments sur l’établi

Le Vieux Castor prit une planche et posa une équerre dessus.

— Je peux regarder cette planche pendant dix minutes.

Il vérifia l’angle.

— Ou utiliser ça.

Petit Castor sourit.

— Elle est droite.

— Pour cet angle, oui.

— Encore une pastèque ?

— Tu apprends vite.

Avec les agents, l’idée est assez proche.

Les tests d’acceptation donnent une vue du comportement attendu. Les tests unitaires permettent de serrer de près certaines parties du code et facilitent la détection des régressions.

La couverture ajoute une autre information : quelles zones ont réellement été exercées ? Le mutation testing pousse la question un peu plus loin en modifiant volontairement le programme pour vérifier que les tests s’en aperçoivent.

On peut aussi regarder la qualité interne. Une fonction très complexe et peu couverte mérite probablement plus d’attention qu’une petite fonction simple et bien testée. Des métriques comme CRAP (Change Risk Analysis and Predictions) — qui combine complexité cyclomatique et couverture — servent justement à rendre ce genre de situation visible.

L’architecture peut, elle aussi, être observée. Un contrôle de dépendances dira, par exemple, qu’un module métier commence soudainement à dépendre d’un détail d’infrastructure.

Et puis il reste le test le plus terre à terre : utiliser réellement le système. Une QA depuis l’interface utilisateur voit parfois immédiatement ce que plusieurs couches de tests n’ont jamais eu l’occasion de rencontrer.

Aucun de ces instruments n’imprime un grand tampon :

LE CODE EST BON

En revanche, ils rendent visible une partie du travail qui devient difficile à suivre à l’œil nu.

Le Vieux Castor aligna quelques outils sur son établi.

— Une équerre ne fabrique pas un bon meuble.

— Mais elle évite de mesurer chaque angle à l’œil.

— Voilà.

Du craft, avec un agent dans l’atelier

Nous parlons beaucoup de nouveaux modèles, de nouveaux agents et de nouveaux frameworks.

Pourtant, beaucoup des problèmes qui apparaissent restent familiers.

Un code trop complexe reste difficile à maintenir. Une architecture qui se délite reste une mauvaise nouvelle. Des tests faibles rassurent toujours davantage qu’ils ne protègent.

L’agent accélère surtout la vitesse à laquelle tout cela peut arriver.

Il peut produire du bon code plus vite.

Il peut aussi produire beaucoup de dette plus vite.

Petit Castor regarda l’assistant doré.

— Donc on lui apprend le craft ?

— Entre autres.

— Avec un gros fichier d’instructions ?

Le Vieux Castor regarda son équerre.

— Si je colle sur le mur « pensez à faire des angles droits », ça aide.

Il posa l’outil sur la planche.

— Ça aide encore plus.

L’agent peut connaître les pratiques de l’équipe.

Un golden path peut surtout lui donner accès aux outils qui les rendent concrètes.

Et Golden Thread — la discipline qui relie intention, choix, preuves et validation quand on délègue à des agents IA — retrouve ici quelque chose de très naturel : préparer l’atelier avant l’arrivée de l’agent.

Le chemin le plus facile

Un golden path porte une promesse assez simple :

Si tu empruntes ce chemin, le travail courant devient plus facile.

Il reste possible de sortir du chemin balisé. Certains changements auront besoin d’autre chose, et c’est très bien ainsi.

Pour le cas courant, en revanche, la plateforme peut éviter de demander à chaque équipe de reconstruire son atelier.

Golden Thread peut par exemple faire en sorte que l’agent sache comment lancer les tests du projet, où trouver les critères d’acceptation, quels outils de qualité sont utilisés et quelles règles d’architecture l’équipe veut préserver.

Il peut aussi normaliser la manière de rendre les résultats au développeur : voilà ce qui a été testé, voilà ce qui a changé, voilà ce qui mérite peut-être ton attention.

Le développeur évite alors le rituel :

« Ah oui, ici on lance cette commande. Les end-to-end sont ailleurs. Pour l’architecture, demande à Gérard, il connaît le script. Et surtout ne touche pas à ce fichier. »

Le chemin connaît déjà un peu l’atelier.

L’agent peut s’y installer plus facilement.

Et l’humain retrouve les repères qu’il utilise pour juger un changement — souvent via un test gauntlet calibré plutôt qu’une relecture exhaustive du diff.

Une review quand on voit moins le code

Petit Castor prit une nouvelle fiche.

— Donc quand l’agent revient, je regarde quoi ?

Le Vieux Castor réfléchit.

— Commence comme avec Marcel.

D’abord, le comportement.

Est-ce que ce qui a été demandé fonctionne réellement ?

Les critères d’acceptation, les scénarios métier ou une QA peuvent apporter une réponse.

Ensuite, les dégâts collatéraux.

Qu’est-ce que ce changement risque d’avoir cassé ?

La suite existante et les tests de non-régression deviennent intéressants ici.

Puis viennent les tests eux-mêmes.

Est-ce qu’ils me donnent réellement confiance ?

La couverture apporte un indice. Le mutation testing peut en apporter un autre lorsqu’il vaut son coût.

Le Vieux Castor griffonna encore quelques mots.

Et quel état l’agent laisse-t-il derrière lui ?

On regarde alors la complexité, la lisibilité, la duplication ou les alertes remontées par les outils habituels.

Enfin, il y a la structure de l’ensemble.

Est-ce que notre construction tient toujours debout ?

Les règles de dépendances, les contraintes d’architecture ou certains contrôles de sécurité aident à répondre.

Petit Castor regarda la fiche.

— Ça ressemble quand même beaucoup à une review normale.

Le Vieux Castor sourit.

— C’est plutôt rassurant.

L’enjeu n’est pas de relire chaque ligne produite par l’agent. C’est de savoir quelles preuves permettent une décision éclairée alors que la quantité de code augmente.

Les instruments changent un peu.

Le métier, beaucoup moins.

La pastèque reste sur l’établi

L’assistant doré était toujours là.

— J’ai donc terminé ?

Le Vieux Castor consulta les critères d’acceptation.

Puis les tests.

Une alerte de complexité avait disparu après refactoring.

La suite de non-régression était verte.

La QA montrait le parcours utilisateur attendu.

Il parcourut rapidement les endroits du diff que les instruments avaient signalés.

— Cette fois, ça me va.

Petit Castor désigna le terminal.

— Pourtant tout était déjà vert au début.

— Oui.

— Qu’est-ce qui a changé ?

Le Vieux Castor attrapa la pastèque imaginaire.

— On l’a ouverte.

Il reprit son café.

— Et surtout, on savait un peu mieux où planter le couteau.

Golden Thread cherche à rendre l’utilisation des agents plus simple dans la plateforme sans faire table rase de ce que les équipes savent déjà faire.

Le craft fournit justement une bonne partie des repères.

Les pratiques de test, de conception et de validation peuvent continuer à jouer leur rôle. L’enjeu consiste surtout à les rendre praticables lorsque l’agent produit davantage et plus vite.

Le golden path prépare alors l’atelier.

Il place les bons outils à portée de main.

Il montre à l’agent comment s’en servir.

Et il rend leur résultat lisible pour celui qui devra, à la fin, décider s’il accepte le travail.

L’IA peut accélérer le geste.

L’équerre reste utile.

Et la pastèque aussi.

En résumé

Un pipeline entièrement vert ne prouve pas qu’un changement agentique est correct : il prouve seulement que les contrôles exécutés ont passé. Avant d’accepter le travail, vérifiez le comportement demandé, les régressions, la confiance réelle des tests (couverture, mutation si pertinent), l’état laissé derrière (complexité, duplication) et la solidité architecturale. Golden Thread prépare l’atelier pour que ces preuves soient accessibles à l’agent et lisibles pour l’humain — souvent via un test gauntlet plutôt qu’une relecture ligne à ligne.

Pour aller plus loin dans l’atelier

Sur le même fil : Golden Thread : retrouver le fil, Readiness : avant de laisser coder l’IA, savez-vous ce que vous lui déléguez ?, Laisser l’agent boucler sans le laisser tourner en rond, Déléguer à une IA : quel pouvoir lui donnez-vous vraiment ?, Un bon agent sait aussi rendre la main.

Dans la caisse à outils : Golden Thread, preuve, test gauntlet, CRAP, craft, golden path, harness.

FAQ

Un pipeline vert suffit-il pour merger du code agentique ?

Non. Il valide ce qui a été mesuré, pas nécessairement le bon comportement ni les angles morts entre composants. C’est la différence entre « tout ce qu’on a regardé va bien » et la ligne imaginaire correct ✅ que personne n’a exécutée.

Quelles preuves regarder en premier ?

Le comportement demandé (critères d’acceptation, QA), puis les régressions, puis la solidité des tests eux-mêmes, puis l’état laissé derrière et la cohérence architecturale. Voir la fiche preuve et la section « Une review quand on voit moins le code ».

À quoi sert le mutation testing ici ?

À vérifier si les tests détecteraient un changement de comportement — pas seulement s’ils s’exécutent. Une couverture élevée peut masquer des tests faibles ; le mutation testing pousse la question un peu plus loin, lorsqu’il vaut son coût.

Golden Thread remplace-t-il le jugement humain ?

Non. Il rend les instruments et les preuves praticables à l’échelle agentique. La décision finale reste humaine ; elle s’appuie sur des signaux observables plutôt que sur une lecture exhaustive du diff.

Pour creuser : Clean AI, Agentic Discipline

Robert C. Martin et Justin Martin explorent cette idée beaucoup plus loin dans la série vidéo Clean AI: Agentic Discipline (O’Reilly).

Martin parle de physical barriers : des outils capables de donner une information objective sur le code produit par les agents. Il utilise notamment les tests, la couverture, le mutation testing, des métriques de complexité, des linters et des contrôles de dépendances pour garder une vue sur le système lorsque la quantité de code rend la lecture exhaustive de plus en plus difficile.

Il insiste particulièrement sur les limites de la couverture : une ligne exécutée reste une information assez faible si aucun test ne vérifie réellement son comportement. Le mutation testing permet de tester la solidité de cette couverture en introduisant volontairement des modifications et en observant si la suite les détecte.

Pour la maintenabilité, Martin utilise aussi CRAP, une métrique qui combine complexité cyclomatique et couverture afin de repérer les fonctions qui méritent une attention particulière.

Ses expérimentations montrent également les limites de l’approche. Une spécification mal revue peut alimenter toute une chaîne de développement parfaitement disciplinée et conduire malgré tout au mauvais résultat. Les instruments améliorent le jugement ; ils ne dispensent jamais d’en avoir un.

Dans leur approche la plus poussée, les Martin vont plus loin : ils proposent un test gauntlet où la relecture du code d’implémentation devient secondaire, voire inutile, dès lors que les barrières automatisées tiennent — les humains se concentrent surtout sur les spécifications de comportement. Notre atelier ne tranche pas ce débat une fois pour toutes : l’enjeu ici est de savoir quelles preuves regarder avant d’accepter un changement agentique, que la décision finale passe par une QA manuelle, un examen ciblé du diff ou une confiance calibrée dans la pile de tests.

Pour pousser cette manière de travailler beaucoup plus loin que notre petit atelier, Agentic Discipline constitue une excellente suite.