Une contrainte de structure est presque toujours suivie, une contrainte de longueur presque jamais. La différence tient à ce qu’un modèle sait faire : compléter un motif, et sûrement pas compter.
Toutes les contraintes de forme ne se valent pas. Celles qui décrivent une structure, nombre de puces, colonnes d’un tableau, gabarit de fichier, sont très bien suivies, parce que le modèle complète un motif qu’il reconnaît. Celles qui exigent un comptage, trois cents mots exactement, échouent régulièrement, parce qu’il n’y a aucun compteur dans la machine. Entre les deux, le ton se transmet par un exemple et non par un adjectif. Et quand deux contraintes se contredisent, l’une est sacrifiée en silence : à vous de désigner laquelle.
Vous demandez un tableau comparatif de trois devis, avec quatre colonnes et une ligne par prestation. La réponse arrive avec cinq colonnes, dont une que vous n’avez pas demandée, neuf lignes au lieu de douze, et deux cases remplies par des montants que vous n’avez jamais fournis. Le tableau est beau. Il est faux, et il faut le refaire à la main.
Le réflexe consiste à accuser le modèle d’être inconstant. C’est mal poser le problème. Certaines contraintes sont tenues avec une régularité remarquable, d’autres ne le sont presque jamais, et la frontière entre les deux est nette. Elle ne passe pas là où on l’imagine.
Le constat vaut pour tous les assistants et pour toutes les versions. Il ne s’agit pas d’un défaut de tel produit, mais d’une propriété de la façon dont le texte est fabriqué. Savoir de quel côté de la frontière se trouve votre exigence permet de la reformuler avant de perdre trois essais.
Un modèle de langage produit un jeton après l’autre, chacun tiré dans une distribution de probabilités calculée à partir de tout ce qui précède, selon le mécanisme exposé dans le fonctionnement d’un modèle de langage. Il n’exécute aucune vérification pendant qu’il écrit et ne relit rien.
De là découle la ligne de partage. Une contrainte de motif est portée par le texte lui-même : après un tiret de puce, la probabilité d’un tiret de puce suivant est écrasante. Le format s’auto-entretient à chaque jeton. Une contrainte de quantité, elle, exige un état interne qui n’existe pas : un compteur. Rien dans l’architecture ne tient le décompte des mots déjà écrits.
| Contrainte | Exemple | Fiabilité | Pourquoi |
|---|---|---|---|
| Structure répétée | Cinq puces, une par ligne | Très bonne | Le motif se reproduit de lui-même |
| Gabarit fourni | Un exemple de sortie rempli | Très bonne | L’imitation est le point fort du modèle |
| Ordre imposé | Constat, puis analyse, puis proposition | Bonne | Chaque titre relance le motif suivant |
| Registre et ton | Ton factuel, sans adjectif | Moyenne | Tient au début, se relâche à la fin |
| Nombre d’éléments | Exactement douze lignes | Faible à moyenne | Suppose un décompte, souvent approché |
| Nombre de mots | 300 mots exactement | Faible | Aucun compteur, estimation par ressemblance |
La conclusion pratique tient en une phrase : formulez toute contrainte de quantité sous la forme d’une contrainte de structure. « Trois cents mots » devient « trois paragraphes de quatre à six lignes ». « Un résumé court » devient « cinq puces d’une phrase chacune ».
Le modèle ne manipule pas des mots mais des jetons, fragments de mots issus d’un découpage statistique. En français, un mot courant coûte souvent deux jetons, parfois trois sur les termes accentués ou peu fréquents, pour les raisons détaillées dans le découpage en jetons et le français. La correspondance entre le compte que vous demandez et l’unité qu’il produit n’est donc même pas fixe.
S’y ajoute un biais venu de l’entraînement. Lors de la phase d’ajustement par retour humain, décrite dans les trois étapes de l’entraînement d’un modèle, les évaluateurs ont massivement préféré les réponses développées, structurées, exhaustives. Cette préférence est encodée dans le modèle. Elle pousse vers le long, y compris quand vous demandez court. Un plafond de mots lutte donc contre une pente.
Trois précisions transforment un tableau approximatif en tableau exploitable, et la troisième est celle que presque personne ne donne.
non fourni. » Une case vide est, pour un modèle, une case à remplir de façon vraisemblable. C’est le point de contact exact avec le mécanisme des hallucinations : la structure demandée crée elle-même une pression à inventer.Pour un usage en tableur, ne demandez pas un tableau visuel mais un format de données : valeurs séparées par des points-virgules, une ligne d’en-tête, aucun texte autour. Le point-virgule s’impose en France, la virgule y servant de séparateur décimal. Le choix du bon format d’échange selon l’usage est traité dans les formats de fichiers essentiels.
Décrire une structure de données en français prend dix lignes et laisse dix ambiguïtés. Montrer un exemple rempli prend cinq lignes et n’en laisse aucune. Écrivez le gabarit avec des valeurs plausibles, pas avec des noms de types : {"fournisseur": "Société Y", "montant_ht": 1240.50, "delai_jours": 12} vaut mieux que « un objet avec un champ fournisseur de type chaîne ».
Quatre règles évitent l’essentiel des rejets à l’étape suivante.
Une précision utile sur les fonctions dites de sortie structurée, proposées par les interfaces destinées aux développeurs : elles garantissent qu’un document syntaxiquement valide sera produit, conforme au gabarit annoncé. Elles ne garantissent rien du tout sur l’exactitude des valeurs. Un JSON impeccable peut contenir un montant inventé. La validation de forme ne remplace jamais la vérification du contenu.
« Professionnel », « clair », « dynamique », « pédagogique » : ces adjectifs qualifient des millions de textes différents, donc ne restreignent presque rien. Trois techniques marchent nettement mieux, par ordre d’efficacité croissante.
La première consiste à nommer un genre réel : compte rendu de réunion, note de synthèse pour un comité, courrier de relance, message interne de deux lignes. Le genre porte avec lui une longueur, un vocabulaire et une structure. C’est le levier utilisé dans les comptes rendus de réunion automatiques.
La deuxième consiste à interdire des tics précis plutôt qu’à demander un style : pas de question rhétorique, pas de phrase d’introduction générale, pas de conclusion qui résume, pas de superlatif. Une interdiction fonctionne quand elle porte sur une forme repérable, pas sur une idée.
La troisième, la plus efficace, consiste à coller un paragraphe que vous avez écrit vous-même et à demander de s’en approcher. L’imitation est le point fort du modèle. Deux cents mots de votre écriture valent tous les adjectifs du monde, et c’est aussi le seul moyen d’obtenir un texte qui ressemble à vous plutôt qu’à la moyenne du web.
Un effet secondaire mérite d’être connu : le registre de votre consigne déteint sur la réponse, même quand vous ne demandez rien de tel. Une demande tapée en abrégé obtient un texte relâché ; une demande écrite en phrases complètes obtient un texte tenu. Autrement dit, votre consigne est déjà, qu’on le veuille ou non, un premier exemple de style.
« Exhaustif et en deux cents mots. » « Simple à comprendre et juridiquement rigoureux. » « Chaleureux et strictement factuel. » Chacune de ces demandes contient une tension réelle, que le modèle ne signale pas : il arbitre seul, différemment d’une exécution à l’autre, ce qui explique une bonne part de l’impression d’inconstance.
Ce comportement rejoint une erreur de consigne classique, la demande empilée, recensée avec neuf autres dans les dix erreurs de consigne les plus fréquentes. Un signe permet de la repérer avant l’envoi : si vous ne savez pas vous-même laquelle des deux exigences prime, le modèle ne le devinera pas non plus.
Le même raisonnement s’applique aux contraintes muettes, celles que vous n’avez pas écrites parce qu’elles vous paraissent évidentes. L’absence de tutoiement, la monnaie utilisée, l’interdiction d’ajouter une recommandation personnelle : rien de tout cela ne va de soi. Ce qui n’est pas écrit est arbitré, et l’arbitrage change à chaque exécution.
Un format tient très bien sur les premiers éléments d’une liste et se délite vers la fin : les puces s’allongent, un paragraphe réapparaît, la colonne oubliée disparaît. Le phénomène s’amplifie sur les sorties longues, où le début de la consigne s’éloigne à mesure que le texte produit occupe le contexte, avec les effets décrits dans la fenêtre de contexte.
Trois parades, simples et cumulables. Découpez la production en lots (dix lignes à la fois plutôt que cinquante). Répétez la contrainte de format à la fin de votre message, là où elle est le mieux suivie, en plus du début. Et régénérez uniquement le passage défaillant, en le recollant seul, plutôt que l’ensemble du document.
Sur un fil de conversation qui dure, la même érosion se produit d’un tour à l’autre. Une contrainte posée au premier message n’est plus qu’un détail lointain au quinzième. Réénoncer les deux exigences essentielles dans le dernier message coûte dix secondes. Pour une tâche répétée chaque semaine, la bonne pratique consiste à conserver la consigne complète dans un fichier et à la recoller entière : le constructeur de prompt range précisément le bloc de format en dernière position pour cette raison.
Une contrainte n’est utile que si vous pouvez vérifier son respect sans lire le texte en entier. Compter cinq puces, ouvrir une accolade, repérer une colonne manquante, valider un fichier : tout cela se contrôle en quelques secondes, donc se corrige. Une exigence de ton juste, de longueur exacte ou d’exhaustivité ne se vérifie pas d’un coup d’œil, et c’est exactement pour cette raison qu’elle ne tiendra pas. Avant d’envoyer votre demande, formulée selon l’anatomie d’une consigne qui marche, posez-vous une seule question : comment saurai-je, en dix secondes, que la contrainte a été respectée.
Parce que la longueur n’est pas une contrainte que le modèle peut vérifier pendant qu’il écrit. Il produit un jeton après l’autre et estime la taille du texte par ressemblance avec ce qu’il a appris. S’ajoute un biais d’entraînement : les réponses longues et détaillées ont été jugées meilleures par les évaluateurs humains, donc récompensées. Contraindre la structure, cinq puces d’une phrase, produit un résultat bien plus fiable qu’un plafond de mots.
Demandez explicitement un format de données, pas un tableau visuel : des valeurs séparées par des points-virgules, une ligne d’en-tête, et rien d’autre autour. Précisez le séparateur, car le point-virgule est le séparateur attendu par les tableurs configurés en français, où la virgule sert de séparateur décimal. Demandez aussi que les nombres soient écrits sans espace ni symbole d’unité, sinon la colonne sera importée comme du texte.
Formulez la contrainte en négatif utile : « ta réponse commence par une accolade ouvrante et se termine par une accolade fermante ». C’est vérifiable d’un coup d’œil, contrairement à « ne mets pas de commentaire ». Ajoutez un gabarit d’exemple complet. Et validez systématiquement avec un outil de vérification de syntaxe : un JSON invalide se repère en une seconde, un JSON valide au contenu faux ne se repère qu’en lisant.
Non. Régénérer l’ensemble fait souvent perdre les parties réussies, puisque chaque exécution est un nouveau tirage. Isolez le passage : recollez-le et demandez de le retravailler seul, avec la contrainte qui a lâché. Cette méthode conserve le reste intact et coûte beaucoup moins de contexte, ce qui compte sur les documents longs.
Écrire une consigne en capitales ne lui donne aucun poids particulier, et alourdit le texte en jetons. Ce qui compte réellement, c’est la position (début et fin de consigne), la séparation visuelle des blocs par des titres courts, et le caractère vérifiable de la contrainte. Un intitulé de bloc en capitales, du type « FORMAT DE SORTIE », reste utile comme repère de structure, pas comme signal d’insistance.
Les liens ci-dessus renvoient vers les textes et les organismes cités. Les dates de consultation sont celles de la dernière relecture, le 13 septembre 2026.
Dans ce thème
Dans la rubrique
Modèles de langage, IA générative, deepfakes et règlement européen sur l’IA, expliqués sans hype ni panique.