Il est 4 h 40, un vendredi d’octobre. Personne n'est devant l'écran. Sur la machine de développement, vingt-deux agents d'IA travaillent en parallèle : l'un corrige une interface, un autre traque une faille dans un lecteur PDF, un troisième réécrit la documentation d'un outil qui sort la semaine suivante. Le matin, un tableau attend sur le bureau : ce qui est prêt, ce qui est à reprendre, et pourquoi.
Ce n'est pas de la magie, et ce n'est pas non plus « laisser l'IA coder toute seule ». C'est un harnais : un petit ensemble de règles et d'outils qui fait travailler des modèles de plusieurs éditeurs, et surtout qui ne les croit jamais sur parole.
Le problème : une IA qui se juge elle-même dit « fini » trop tôt
Quand on confie une tâche de code à un agent, il finit presque toujours par annoncer que c'est terminé et testé. Sur des mois d'usage quotidien, nous avons vu ce « terminé » être faux de trois façons :
- Il croit avoir testé. Un test qui passe sur une fonction isolée ne prouve pas que la fonction est réellement appelée par le programme.
- Il partage ses angles morts. Relu par un modèle de la même famille, un défaut passe deux fois.
- Son verdict flotte. « Prêt », mais pour quelle version du code ? Si on ne peut pas rattacher un verdict à une révision précise, il ne prouve rien.
Le principe : un auteur, un relecteur d'une autre famille, une preuve
Chaque chantier suit le même cycle.
- Un auteur écrit le code, le teste et rédige un rapport. Ce peut être un modèle d'OpenAI, d'Anthropic ou un autre.
- Une porte vérifie que le rapport déclare le travail livré. Sinon, tout s'arrête.
- Un relecteur d'une autre famille de modèles reprend tout : il rejoue les preuves, annule le correctif dans une copie pour vérifier que le test échoue bien, et cherche la variante d'à côté.
- Un verdict : « prêt » pour une version précise du code, avec l'empreinte exacte du changement relu, ou « à reprendre » avec la liste des points bloquants.
Le détail qui change tout, c'est l'empreinte. Avant d'enregistrer un travail, nous recalculons l'empreinte du changement et vérifions qu'elle est identique à celle que le relecteur a examinée. Ce qui entre dans le code est exactement ce qui a été vérifié, pas une version voisine.
Le motif qui revient : la variante d'à côté
La leçon la plus constante de ces semaines tient en une phrase : l'auteur corrige le cas signalé, et le relecteur d'une autre famille trouve la variante d'à côté.
Une nuit récente en donne une bonne illustration. Un correctif de sécurité est livré et déclaré prêt par son auteur. Le relecteur, d'une autre famille, le confirme sur le cas d'origine, puis trouve un second chemin qui contourne la protection. Une fois ce chemin fermé, il en trouve un troisième. Les trois sont aujourd'hui fermés et prouvés, avant toute publication. Un relecteur de la même famille, avec les mêmes réflexes, serait passé à côté des deux derniers.
Quand ça bloque : monter d'un cran, pas tourner en rond
Le relecteur refuse, l'auteur reprend, et ainsi de suite. La plupart des chantiers convergent en une ou deux reprises. Mais certains tournaient en rond : jusqu'à sept reprises, avec un nouveau cas trouvé à chaque relecture, et du quota de calcul brûlé pour rien.
Nous avons donc ajouté une échelle d'escalade :
| Refus | Ce qui se passe |
|---|---|
| 1 | Le même auteur corrige, avec la liste précise des points bloquants |
| 2 | Un modèle plus fort reprend, dans une session neuve, après avoir lu toutes les relectures |
| 3 | Ce modèle fort doit consulter un conseiller encore plus puissant avant d'agir, à chaque échec et avant de conclure |
| 4 | Un conseil de plusieurs familles de modèles délibère sur la cause racine, un juge neutre tranche, puis un dernier essai a lieu |
| 5 | Arrêt : une fiche pour l'humain — réduire, découper ou abandonner |
Le premier essai a été parlant. Un défaut sur lequel un modèle intermédiaire avait échoué six fois a été compris par le modèle fort dès sa première passe. La cause n'était pas un cas de plus à traiter : il fallait changer de principe. Au lieu de deviner, d'après le contenu de la sortie, quand elle était sûre à réduire, l'outil ne la réduit plus que dans les cas qu'il connaît avec certitude, et laisse tout le reste intact.
Trois couches de vérification
| Couche | Qui | Quand |
|---|---|---|
| Relecture croisée | un modèle d'une autre famille que l'auteur | à chaque chantier |
| Audit offensif | un modèle dédié qui doit rejouer chaque exploit | avant chaque version |
| Analyse continue | le service OSS Scanner d'Anthropic, dans son propre environnement | périodiquement, sur le code publié |
La troisième couche est récente et gratuite pour les projets open source admis. Son intérêt : elle regarde ce que verrait un attaquant, le code publié et non nos branches de travail. Et l'inscription nous a déjà servi avant même d'être soumise : en construisant notre projet dans son environnement isolé, l'outil de vérification du service a révélé un test instable chez nous.
Ce que l'humain garde
La flotte travaille seule, mais ne publie jamais seule. Aucun agent ne fusionne, ne pousse de code public ni ne publie une version. Les tests et les audits tournent dans des environnements isolés, avec des clés factices. Chaque règle de ce harnais vient d'un incident réel, documenté, et non d'une bonne pratique lue quelque part.
Les chiffres
- 890 lots de travail depuis la mi-septembre ;
- environ 3 200 étapes exécutées ;
- environ 1 060 reprises demandées par un relecteur ;
- jusqu'à 22 agents en parallèle en une nuit.
Ce sont des ordres de grandeur, comptés à partir des dossiers de travail.
Limites honnêtes
- Le harnais est lié à notre machine. Chemins, services système, outils installés : rien n'est portable tel quel aujourd'hui.
- Un pilote reste nécessaire. Il relance les étapes bloquées, vérifie au moins une affirmation de chaque rapport et décide quand s'arrêter.
- L'escalade est toute neuve. Nous mesurons dans les prochaines semaines ce que débloque chaque cran et ce qu'il coûte.
- Une relecture d'IA reste une relecture d'IA. Elle trouve beaucoup, pas tout. C'est pour cela que la dernière marche de l'échelle est humaine.
Et maintenant
Ce harnais est aujourd'hui un ensemble de scripts. La prochaine étape est de l'intégrer dans Code Buddy, notre agent de code, pour que n'importe quel développeur puisse faire relire le travail d'une IA par une autre famille de modèles, avec les mêmes garde-fous.
Si vous faites déjà travailler des agents d'IA sur du code de production, et que vous vous demandez comment leur faire confiance sans tout relire vous-même, parlons-en.
