Pourquoi les modèles de langage détériorent la structure d’un document quand vous leur confiez l’édition

Éditer des documents avec un modèle de langage semble être une solution évidente : insérez du texte, donnez une instruction, obtenez un résultat sans heures de travail manuel. En pratique, cependant, le document retourné s'avère souvent différent — avec des en-têtes décalés, des paragraphes manquants ou des fragments reformulés que personne n'a demandé de toucher. Au lieu d'une édition, une dégradation invisible de la structure se produit.

Génération versus édition

La contradiction clé réside dans l'architecture même des transformateurs. Les modèles de langage sont entraînés à prédire le prochain token en fonction du contexte — ils n'« éditent » pas au sens où le fait un traitement de texte. Lorsqu'un modèle reçoit l'instruction « corrigez la grammaire dans la troisième section », il n'applique pas une règle précise aux lignes — il génère ce qu'il croit que le texte mis à jour devrait ressembler dans son intégralité.

La limite « éditez uniquement ceci » est fondamentalement floue pour un LLM : le modèle évalue l'ensemble du contexte et génère une nouvelle version plutôt que d'appliquer des éditions atomiques. C'est particulièrement visible sur les documents volumineux — plus le « matériel » est important, plus la dérive par rapport à la source est forte.

Le phénomène de ce qui se perd au milieu

Même les modèles avec une fenêtre de contexte de 200k tokens créent des problèmes structurels avec les documents longs. La recherche identifie systématiquement l'effet « lost in the middle » : les modèles retiennent bien les informations du début et de la fin du contexte, mais perdent systématiquement les détails du milieu. Plus le document est long, plus l'effet est fort. Pour les fichiers réels, cela signifie que les éléments structurels des sections du milieu sont les plus susceptibles d'être corrompus. Victimes typiques :

• Listes imbriquées — les niveaux d'imbrication s'aplatissent à un
• Tableaux — perdent l'alignement des colonnes ou se convertissent en prose
• Références croisées — se transforment en texte brut sans ancres
• Entête YAML et balises personnalisées — sont supprimées comme « désordre inutile »
• Numérotation des sections — se brouille après toute insertion ou suppression de contenu

Formatage en tant que tokens sans sémantique

Markdown, HTML, LaTeX — le modèle voit tout cela comme des tokens ordinaires, pas comme une syntaxe avec des règles. Pour un réseau de neurones, les symboles `##` sont simplement deux dièses, pas « un titre de deuxième niveau aligné sur la table des matières ». Les modèles de formatage sont reproduits par analogie statistique avec les données d'entraînement, non par des règles syntaxiques explicites. Le résultat est prévisible : indentation incohérente, niveaux de titre mélangés, ancres de lien cassées, permutation aléatoire entre les formats au sein d'un même document. Chacune de ces violations est à peine perceptible en soi, mais ensemble, elles rendent le document inutilisable pour le traitement automatisé ou la publication.

«

Le modèle ne comprend pas votre document — il comprend la distribution de probabilité du prochain token dans son contexte. »

Concurrence entre instruction et modèles

Un autre facteur est la concurrence entre l'instruction explicite de l'utilisateur et les modèles statistiques appris lors de l'entraînement. Si Markdown standard prédominait dans les données d'entraînement, le modèle sera attiré vers lui même contre une interdiction explicite. Les modèles corporatifs non-standard, le balisage spécifique aux normes techniques, le style structurel spécifique à l'auteur — tout cela est vulnérable à la « mémoire » du corpus d'entraînement. De plus, les longues instructions s'« estompent » au fur et à mesure de la génération. À la fin d'un gros document, l'attention aux contraintes du prompt initial s'affaiblit — et la dérive structurelle s'accumule.

Ce que cela signifie

Pour le travail pratique, la conclusion est claire : les LLM sont meilleurs pour les tâches ponctuelles que pour l'édition complète d'un document entier en une seule passe. Pour les fichiers structurés complexes — spécifications techniques, contrats juridiques, articles académiques avec références croisées — il est judicieux de diviser le document en sections isolées et de travailler avec chacune séparément. Les instructions doivent être aussi explicites que possible : « modifiez uniquement ce paragraphe, laissez tout le reste tranquille ». Après toute édition par LLM, une vérification explicite des éléments structurels est requise — ce sont les premiers à souffrir.