En bref

Les grands modèles de langage (LLM) sont entraînés sur des milliards de mots en langue naturelle, et pourtant les ingénieurs qui les pilotent en production utilisent massivement XML, YAML et Markdown structuré — pas des phrases ordinaires. Ce paradoxe n’est pas un détail d’implémentation : il reflète une propriété structurelle des LLM que le marketing grand public masque souvent. Comprendre pourquoi le langage structuré surpasse la prose libre est la base du context engineering sérieux.

Le mythe du “parler naturellement”

L’interface la plus visible des LLM — une boîte de texte où l’on tape en français ou en anglais — a installé l’idée qu’il suffit de s’adresser au modèle comme à un humain. Cette intuition est partiellement vraie pour les usages conversationnels simples. Elle devient fausse dès qu’on cherche à obtenir un comportement précis, reproductible, et composable.

Un LLM ne “comprend” pas une instruction au sens humain. Il prédit la suite statistiquement probable d’une séquence de tokens. Quand on écrit “réponds en JSON”, le modèle a appris, depuis ses données d’entraînement, que cette formule est souvent suivie d’un bloc JSON. La structure de la requête active des patterns de complétion, pas un mécanisme de compréhension indépendant.

La conséquence pratique : une instruction floue produit un comportement flou. Une instruction structurée produit un comportement structuré — non pas parce que le modèle est “plus à l’aise”, mais parce que la structure réduit l’espace des complétions possibles.

Pourquoi le langage structuré performe mieux

Délimitation sans ambiguïté

Le langage naturel est riche en ambiguïté contextuelle. “Résume en 3 points le texte suivant” laisse ouverte la question de ce qui constitue “le texte suivant” si le prompt contient plusieurs blocs. Une balise XML comme <texte_a_resumer>...</texte_a_resumer> délimite sans ambiguïté.

Anthropic documente explicitement que XML améliore les performances pour les tâches structurées, en particulier quand le prompt contient plusieurs sections (contexte, contraintes, tâche, exemples). La raison : les balises constituent des séparateurs que le modèle a appris à reconnaître comme des frontières sémantiques fortes lors de son entraînement sur du code et de la documentation technique.

Compression sans perte d’information

Un test concret : un ensemble de règles exprimé en prose libre sur 425 lignes peut être reformulé en Markdown structuré (sections fixes, listes, tableaux) sur 119 lignes — avec le même taux de respect des contraintes mesuré à l’usage [NON VÉRIFIÉ sur un corpus indépendant]. Le gain ne vient pas d’une suppression d’information mais de l’élimination du bruit : transitions, reformulations, répétitions implicites propres au style prose.

Le Markdown structuré force une granularité explicite. Chaque point de liste est une unité distincte. Chaque en-tête délimite un domaine. Le modèle traite ces séparateurs comme des signaux forts, ce que la prose continue ne fournit pas.

L’effet des exemples structurés

Parmi les patterns les plus efficaces pour piloter un LLM : l’exemple structuré qui décompose le processus en étapes nommées (Besoin → Recherche → Résultat → Action → Vérification) plutôt qu’un exemple narratif (“voici comment j’ai résolu un problème similaire…”). L’analyse de 116 fichiers de configuration de workflows IA réels montre que 93 % utilisent des structures à sections fixes — aucun n’utilise de prose libre comme format principal.

L’explication probable : la structure nommée crée un espace de complétion contraint. Après “Résultat :”, le modèle sait qu’il doit produire un résultat, pas une question ou une transition. La prose laisse ce choix ouvert.

Ce que les 116 fichiers révèlent

Une analyse systématique de 116 fichiers de configuration de workflows IA (skills, instructions système, prompts orchestrateurs) fait apparaître un consensus de terrain :

FormatFréquenceUsage typique
Markdown structuré (sections + listes)93 %Instructions, règles, contraintes
Frontmatter YAML~80 %Métadonnées, classification
Balises XML~40 %Délimitation de blocs, inputs/outputs
Prose libre<5 %Introduction ou contexte seulement

Taille médiane : 240 lignes. Taille optimale observée pour un fichier d’instructions : 100–300 lignes. Au-delà, la densité d’information par token décroît et le modèle dilue sa conformité aux contraintes.

Ce corpus représente des practitioners actifs, pas des recommandations théoriques. Le choix quasi-unanime du Markdown structuré est le résultat d’itérations empiriques, pas d’une décision théorique.

Limites et nuances

Ce tableau n’est pas complet. Le langage structuré n’est pas universellement supérieur :

  • Pour les tâches créatives ouvertes, une contrainte structurelle forte peut brider la génération. Un romancier qui pilote un LLM en YAML risque d’obtenir une prose rigide.
  • Pour les utilisateurs non techniques, XML et YAML créent une barrière d’entrée réelle. Les interfaces grand public simplifient à raison.
  • L’optimisation est dépendante du modèle : un format très efficace sur GPT-4 peut se comporter différemment sur Claude ou Mistral. Les mesures de “gain” circulent souvent sans préciser le modèle et la version [NON VÉRIFIÉ sur modèles multiples].
  • La structure peut masquer des prompts défaillants : un XML parfaitement balisé avec une tâche mal définie reste un mauvais prompt.

Ce qu’il faut retenir

  • Les LLM génèrent par complétion statistique de tokens : la structure réduit l’espace des réponses possibles et améliore la conformité.
  • XML, YAML et Markdown structuré surpassent la prose libre pour les instructions complexes, multi-sections ou répétables — pas par magie, mais parce que ces formats sont présents en masse dans les données d’entraînement avec des patterns cohérents.
  • La compression prose → format structuré peut diviser la longueur par 3 sans perte fonctionnelle ; nos tests montrent que le taux de respect des contraintes reste stable voire s’améliore.
  • L’analyse de 116 configurations réelles confirme que les practitioners convergent vers le Markdown structuré indépendamment des guidelines officielles.
  • “Parler naturellement” reste valide pour les usages conversationnels ; il devient un anti-pattern dès qu’on cherche reproductibilité et contrôle fin du comportement.

Sources