On entend de plus en plus parler d’ingénierie de harnais (souvent traduit de l’anglais harness engineering) : l’idée n’est pas un outil SaaS précis, mais une manière d’organiser le travail logiciel lorsque le dépôt est manipulé par plusieurs agents autonomes en parallèle : revue, refactor, docs, CI, parfois plusieurs « personas » ou pipelines qui poussent des changements sans qu’un humain écrive chaque ligne.
Qu’est-ce que l’ingénierie de harnais multi-agents ?
Le concept : au lieu de traiter l’IA comme un copilote ponctuel dans un éditeur, vous concevez un environnement (structure du repo, règles, garde-fous, scripts, documentation machine-lisible, boucles de feedback) pour que des agents puissent exécuter des tâches de bout en bout : ouvrir des branches, modifier du code, lancer des tests, proposer des correctifs. Les humains se déplacent vers l’intention, la priorisation, et la validation des résultats, du moins en théorie.
C’est proche de ce que font les équipes qui industrialisent Cursor, OpenAI Codex (CLI, PR, pipelines), des workers en CI, des agents de revue, ou des orchestrations maison : le harnais, ce sont les rails qui empêchent l’autonomie de devenir du chaos.
Ce que contient le harnais : CI, documentation et règles pour agents
Concrètement : instructions versionnées, qualité mécanisée (formatage, types, tests, politique de dépendances), CI qui bloque si des invariants cassent, parfois des tâches planifiées pour des PR de « jardinage ». Avec plusieurs agents, le harnais ajoute des règles de territoire (auth, schéma SQL, secrets), des garde-fous contre les collisions entre workers, et une trace de ce qui est généré vs validé.
C’est une technique générale, indépendante d’un seul outil. Le vrai changement, c’est le couplage : chaque automate lit une version partielle du monde et pousse une modification ; sans cadre, la base devient une conversation entre modèles, pas un produit.
Promesse : vélocité machine et plusieurs agents sur le dépôt
La promesse est séduisante pour un fondateur qui a construit un MVP avec du code généré par IA : si le dépôt est bien câblé, le débit de changements peut dépasser largement ce qu’un petit noyau humain peut relire ligne à ligne. Les agents ne se fatiguent pas ; ils peuvent enchaîner des itérations la nuit. Sur le papier, vous rattrapez de la dette, vous ajoutez des tests, vous documentez, sans recruter tout de suite une équipe plateforme.
Quand la vélocité machine dépasse votre capacité à contradire vite, vous reportez le coût : les décisions implicites finissent encodées dans le code.
Hallucination LLM, contexte partiel et dérive cumulative
Le piège apparaît quand cette vélocité entre en collision avec deux réalités des LLM : l’hallucination (le modèle invente des faits ou des interfaces qui n’existent pas) et la fenêtre de contexte (aucun agent ne « voit » tout le produit, l’historique client, les promesses implicites du pitch, ni la dette politique entre deux modules).
Des mesures publiques rappellent que « rare », à l’échelle, revient souvent. Le classement Vectara sur l’hallucination évalue les modèles avec HHEM-2.3 sur de la synthèse de courts documents, en imposant d’utiliser uniquement le texte fourni (souvent température 0). Dans le tableau actualisé le 28 avril 2026, les taux d’hallucination annoncés s’étendent d’environ 1,8 % à 24,2 % selon les API ; beaucoup de modèles courants se situent plutôt autour de 5 à 12 %. Ce n’est pas une évaluation du code, mais les auteurs la présentent comme un indicateur pour les chaînes type RAG ou agents « lire un contexte ancré, puis produire », où la dérive se chiffre.
Les agents n’ont pas non plus la profondeur d’objectif du fondateur : ils optimisent la tâche décrite dans le prompt, pas la cohérence stratégique sur six mois. Quand plusieurs agents écrivent en parallèle, les erreurs ne restent pas isolées : elles se cumulent. Un agent « répare » ce qu’un autre a cassé en s’appuyant sur une hypothèse fausse, un troisième consolide la mauvaise abstraction. C’est une forme d’hallucination cumulative : le repo avance vite, mais la carte du territoire qu’utilisent les agents est incomplète, donc la trajectoire dérive.
Exemple rapide : un agent « durcit » une route API avec des checks qui ne collent pas tout à fait au modèle ; un second met à jour le client en supposant un champ absent ; un troisième « harmonise » les types avec un contournement silencieux. Les tests peuvent passer sur des cas étroits, et pourtant le système dérive de l’intention, souvent restée hors contexte.
Zéro pilotage humain ou dépôt trop verbeux pour LLM : deux impasses
Extrémité A : « On laisse faire » : peu de pilotage humain, on espère que CI + agents suffisent. En pratique, sans jugement humain sur le quoi et le pourquoi, vous obtenez du code plausible, parfois dangereux (sécurité, permissions, edge cases métier). Ce n’est pas tenable : le produit a besoin d’un gardien qui comprend le risque, ce que décrit aussi notre angle sur sortir de la boucle infernale quand l’IA s’égare.
Extrémité B : « On travaille pour les agents » : vous transformez le dépôt en flux de tokens entre LLM : commentaires longs, journaux verbeux, docs redondantes, formats pensés pour qu’un autre modèle « lise » sans ambiguïté. Pour l’inter-agent, cette verbosité peut aider. Pour un humain qui doit trancher une PR, lire une spec ou recadrer une roadmap, c’est l’inverse : surcharge cognitive, fatigue, temps perdu. Vous ne construisez plus seulement un produit pour des utilisateurs ; vous maintenez une interface humain-machine déséquilibrée où l’humain paie le coût d’attention.
Plus le dépôt est « lisible agents », plus la revue humaine peut devenir coûteuse, surtout quand vous avez besoin d’un humain vite (lancement, incident). La verbosité utile à un LLM n’aide pas toujours un fondateur à trancher en dix minutes.
Bon compromis : pilotage humain, garde-fous et petites surfaces agent
Action : traiter l’ingénierie de harnais comme un complément à une gouvernance humaine claire, pas comme un substitut. Gardez des artefacts courts et stables pour les humains (vision produit, critères d’acceptation, risques), et réservez la verbosité structurée aux zones où les agents en ont besoin (schémas, tests, linters). Fixez des limites : qui merge, quelles surfaces sont interdites aux agents sans revue, quels signaux d’observabilité sont obligatoires avant prod.
En pratique : propriétaire clair qui tranche, garde-fous mécaniques, et petites surfaces par agent pour limiter la propagation d’hypothèses fausses. Plusieurs agents, oui, si les erreurs deviennent chères tôt et les corrections localisées.
Si votre base est née chez Lovable, Bolt ou Replit, le passage à ce régime est souvent un moment de vérité : le prototype « vibe » doit devenir un système observable et sécurisable. Pour cadrer les risques avant d’ajouter encore des agents sur le feu, un audit de sécurité aide à voir où la vélocité masque des failles : permissions, données exposées, dépendances fragiles.
Synthèse pour fondateurs : harnais, hallucination et contrôle humain
Environnement + règles + feedback pour amplifier le débit avec plusieurs agents. Angle utilement sceptique : hallucinations et contexte partiel rendent le 100 % agent fragile ; un dépôt trop « LLM-first » frictionne les humains au pire moment. Milieu durable : agents utiles, garde-fous mécaniques, pilotage humain léger mais non négociable.