Une étude Microsoft montre que les LLM corrompent silencieusement près d'un quart des documents sur les workflows longs, sauf là où une validation mécanique tranche à chaque étape, ce qui plaide moins contre la délégation que pour le harness.

Summary
Une étude Microsoft (« LLMs Corrupt Your Documents When You Delegate », arXiv, avril 2026) affirme que les LLM corrompent vos documents. Le mouvement harness pousse au contraire à déléguer toujours plus à ces mêmes modèles. Deux directions opposées, une seule question : qui croire ?
Microsoft Research a donc demandé à dix-neuf modèles, dont les plus avancés du moment à l'époque (Gemini 3.1 Pro, Claude Opus 4.6, GPT-5.4), d'éditer des documents sur des workflows longs, dans cinquante-deux métiers différents.
Le verdict est sévère : en fin de parcours, près d'un quart du contenu ressort corrompu, même chez les meilleurs. Et cette corruption est silencieuse, pas de charabia ni de signal d'alarme, mais des erreurs rares, graves, et assez plausibles pour passer la relecture. Plus le document grossit et plus le workflow s'étire, plus le phénomène s'aggrave.
Faut-il donner raison aux sceptiques ? Sur les cinquante-deux métiers testés, un seul résiste, celui qui utilise du code Python. Non parce que les modèles y seraient meilleurs, mais parce qu'un juge mécanique tranche à chaque étape : le test casse ou passe. Résultat, dix-sept des dix-neuf modèles testés y restent fiables jusqu'au bout.
La corruption ne surgit donc qu'en l'absence de validation.
Tout se joue ainsi dans la façon d'outiller le modèle. Lui donner des outils pour agir seul (l'approche agentique) aggrave même le résultat de 6 % dans l'étude : plus il peut faire, plus il peut se tromper avec assurance. Poser autour de lui des juges qui valident, en revanche, sauve la mise : tests unitaires, revue de code par un humain, analyse de qualité automatique avec un outil comme SonarQube.
C'est toute la différence entre lâcher un agent et construire un harness, ce harnais de validation qui encadre ce que le modèle produit.
J'en fais l'expérience depuis deux ans. Je n'écris plus une ligne de code moi-même. Pourtant, le code produit par mon harness franchit les mêmes portes que celui de n'importe quel développeur des équipes où je suis passé : revue de PR humaine, tests unitaires, SonarQube, etc.
Ces portes ne m'appartiennent pas, ce sont celles des équipes. Voilà ce qui rend la délégation sûre, pas ma confiance dans les modèles.
Lue ainsi, l'étude rassure plus qu'elle n'inquiète. Elle ne condamne pas la délégation, elle indique où porter l'effort : dans la validation, pas dans le prompt.
Il faut, pour finir, rester honnête sur la portée de la démonstration : elle ne vaut que là où la validation se mécanise. Pour du texte libre, un contrat, une note, un rapport, aucun test ne tranche seul pour le moment. Le harness doit alors intégrer des juges : diff entre versions, relecture, points de contrôle, autres LLM spécialisés, etc.