Une recherche de Microsoft Research (centre de recherches dédié de Microsoft) vient de mettre en évidence un risque que la plupart des organisations n’ont pas encore intégré dans leurs pratiques : déléguer l’édition de documents à un LLM sur la durée, c’est accepter une dégradation silencieuse et cumulative du contenu.
Ce que la recherche montre
L’étude s’est basée sur le benchmark DELEGATE-52 qui est le protocole d’évaluation couvrant 52 domaines professionnels (comptabilité, code, notation musicale, généalogie, sous-titres, plans, recettes, et bien d’autres.) et 310 environnements de travail réels, dans lesquels 19 modèles ont été soumis aux mêmes tâches d’édition documentaire dans des conditions identiques et contrôlées.
Le protocole mis en place était rigoureux. Ils ont soumis un document à un LLM, lui ont demandé de l’éditer puis d’annuler cette édition. Si le modèle était fiable, on retrouvait le document d’origine. Ils ont répété l’opération 20 fois de suite.
Le résultat fut sans ambiguïté.
Même les meilleurs modèles du marché ont dégradé, en moyenne , 25% du contenu d’un document après 20 interactions. La moyenne, tous modèles confondus, a atteint 50% de dégradation.
Python est le seul des 52 domaines où la majorité des modèles a réussi à maintenir une fiabilité acceptable. Partout ailleurs, les erreurs se sont accumulées.
La nature du problème : des erreurs rares, graves et invisibles
Ce qui rend ce risque de dégradation particulièrement difficile à gérer, c’est précisément sa structure.
Contrairement à ce qu’on pourrait croire, les LLM ne dégradent pas les documents goutte à goutte. La dégradation résulte d’accidents soudains et rares. La plupart des itérations laissent le document intact mais une itération isolée peut provoquer une chute de 10 à 30 % de qualité. Et ce sont ces accidents, pourtant minoritaires, qui font à eux seuls près de 80 % des dégâts observés.
Autrement dit, on peut travailler sans problème apparent pendant de nombreuses sessions et se retrouver avec un document substantiellement altéré après un épisode de corruption qu’on n’a pas détecté sur le moment.
Les modèles les plus performants ne font pas moins d’erreurs critiques mais ils les font plus tard. Cela ne les rend pas plus fiables : cela rallonge simplement la période avant que la confiance utilisateur-IA ne se brise.
Autre enseignement important : ajouter une couche agentique par-dessus le modèle, avec accès aux fichiers et exécution de code, n’améliore pas la situation. Pire, dans les expériences DELEGATE-52, les modèles équipés d’outils dégradent les documents davantage que les mêmes modèles opérant sans, à hauteur d’environ 6 % supplémentaires. Autrement dit, l’agentivité, souvent présentée comme le correctif aux limites actuelles des LLM ne fait que déplacer le problème. Le défaut se situe au niveau du modèle lui-même. Pas d’orchestration qui l’entoure et aucune architecture ne le résout en surface.
Ce que cela signifie pour les organisations
Ce risque n’est pas théorique. Il correspond exactement aux scénarios que l’on observe dans les organisations qui ont déployé l’IA en production.
Les workflows longs sont les plus exposés. Plus le nombre d’interactions augmente, plus les erreurs se cumulent. Un document retravaillé sur plusieurs sessions, par plusieurs personnes, avec des allers-retours fréquents avec un LLM, est beaucoup plus vulnérable qu’un document édité une fois.
Les domaines à fort enjeu de précision sont les plus risqués. Les résultats varient fortement selon le type de contenu. Les formats structurés et répétitifs résistent mieux. Les contenus en langage naturel complexe, comme les documents contractuels, les rapports réglementaires ou la documentation métier, sont les plus sensibles.
La taille du document aggrave les effets. L’étude montre que chaque tranche de 1.000 tokens supplémentaires dans un document amplifie la dégradation de manière non linéaire sur la durée. Un document de 10.000 tokens édité 20 fois perd en moyenne 40% de son contenu. Dans les mêmes conditions, c’est moins de 9% de perte pour un document de 2.000 tokens.
Les fichiers contextuels parasites amplifient le problème. Lorsque des documents non pertinents sont présents dans le contexte du LLM, ce qui est courant dans les environnements RAG ou multi-fichiers, la dégradation s’accélère. L’effet est marginalement visible à court terme mais devient significatif sur des workflows prolongés.
Ce que cela change dans la gouvernance des usages IA
Ce que DELEGATE-52 documente rigoureusement, c’est ce que nous observons régulièrement sur le terrain : le risque IA n’est pas dans le modèle. Il est dans le workflow.
Un LLM peut produire des résultats satisfaisants à court terme et dégrader progressivement la qualité d’une base documentaire sur la durée, sans que personne ne le détecte, parce que chaque interaction prise isolément semble correcte.
Ces résultats devraient nous faire reconsidérer des réflexes adoptés un peu vite.
Le premier, c’est de déléguer un travail long à un LLM et de ne contrôler que ce qui sort à la fin. Sur un workflow de vingt itérations, ça revient à parier que chacune des vingt étapes s’est bien passée. L’étude de Microsoft prouve que c’est un mauvais pari puisqu’il suffit d’une seule itération pour faire dérailler le document. Mieux vaut donc relire à plusieurs moments du processus que de tout miser sur la version finale.
Le deuxième, c’est de ne pas garder le document d’origine. Quand un LLM introduit une erreur, c’est rarement spectaculaire. Ca se limite souvent à un chiffre qui change, une phrase qui disparaît, une nuance qui se perd en chemin. Sans la version de départ sous la main, ces petites altérations passent inaperçues. C’est une précaution de bon sens et pourtant la plupart des entreprises l’oublient.
Le troisième est plus subtil. On a tous tendance à penser qu’un document n’a pas changé tant qu’on ne l’a pas soi-même modifié. Si c’était vrai avec Word, ça ne l’est plus avec un LLM. Le document peut avoir traversé plusieurs allers-retours qui paraissent inoffensifs et contenir pourtant une ou plusieurs erreurs graves. Tant qu’on n’a pas intégré ça, on ne voit pas le risque venir.
Ce qu’il faut mettre en place
La réponse n’est pas de renoncer aux LLM pour l’édition de documents mais de les intégrer avec les garde-fous adaptés.
- Versioning systématique. Toute édition déléguée à un LLM doit être tracée. Le document d’origine doit rester accessible et comparable. Ce n’est pas une contrainte technique lourde mais une discipline de workflow.
- Supervision humaine proportionnelle au risque. Sur des contenus à faible enjeu, une relecture légère suffit. Sur des documents contractuels, réglementaires ou stratégiques, une validation structurée par un expert métier reste indispensable. Le LLM ne peut pas être juge et partie sur la qualité de sa propre production.
- Classification des cas d’usage par niveau d’exposition. Tous les documents ne présentent pas le même risque. Un compte-rendu de réunion interne n’appelle pas les mêmes précautions qu’une note d’analyse destinée à un comité d’investissement ou une documentation réglementaire. Cartographier ces niveaux est le préalable à toute politique d’usage cohérente.
- Limitation de la longueur des workflows sans point de contrôle. La recherche montre que la dégradation s’accélère avec le nombre d’interactions. Définir des seuils au-delà desquels une vérification humaine est déclenchée n’est pas du conservatisme : bien au contraire, c’est de la gestion de risque opérationnel.
En synthèse
La recherche DELEGATE-52 apporte une contribution importante qui quantifie un risque que beaucoup pressentaient sans pouvoir le mesurer.
Les LLM sont des outils puissants pour l’édition de documents mais leur fiabilité est asymétrique dans le temps, correcte à court terme et dégradée à moyen/long terme. Leurs erreurs sont discrètes : pas de signal d’alarme, pas de message d’erreur, juste un contenu qui s’éloigne progressivement de sa version d’origine.
Rien de tout ce qui précède ne plaide contre l’usage de l’intelligence artificielle en entreprise ce qui serait une mauvaise lecture de cette étude. Ce qui est en cause, c’est l’idée qu’il suffirait de brancher un LLM sur un workflow existant pour en récolter mécaniquement les bénéfices.
Entre un déploiement qui apporte une valeur réelle et un autre qui finit par abîmer les documents qu’il était censé produire, la différence ne tient pas au modèle choisi mais à tout ce que l’on construit autour : les moments où l’on relit, les versions que l’on prend soin de conserver, les étapes où l’on réintroduit un regard humain dans la boucle. Et ce travail d’architecture, qui suppose une compréhension fine de la technologie autant qu’une connaissance des processus métier qu’elle vient assister, aucun fournisseur de LLM ne le fera à la place de l’entreprise qui le déploie.
Cet article s’appuie sur les travaux de Philippe Laban, Tobias Schnabel et Jennifer Neville (Microsoft Research), « LLMs Corrupt Your Documents When You Delegate« , avril 2026.
A lire aussi : IA générative en entreprise : la conformité commence bien avant le choix de l’outil
