La contrainte n'a jamais été dans le prompt

Anthropic a publié de nouvelles règles d’ingénierie de contexte pour sa dernière génération de modèles. Le titre est frappant : plus de 80 % du prompt système de Claude Code a été retiré pour ces modèles, sans perte mesurable sur ses évaluations de code.

L’article décrit six changements. Les règles cèdent la place au jugement. Les exemples cèdent la place à des interfaces conçues. Le contexte est chargé progressivement plutôt qu’en une seule fois. Les consignes d’outillage sont écrites une fois plutôt que répétées. La mémoire devient automatique. Les spécifications simples sont remplacées par des références plus riches : code, tests, grilles d’évaluation et artefacts réels.

Le changement le plus important n’est pas que le prompt ait raccourci. C’est qu’une plus grande part du travail est sortie de la prose.

C’est aussi le chemin qu’emprunte Solario. Nous avons commencé avec des documents Markdown et des expressions régulières. Nous avons ajouté une analyse syntaxique consciente de la structure. Nous avons introduit des artefacts YAML et JSON, des contrats d’exécution typés et des sorties de modèle contraintes par schéma. Puis nous avons pris une décision plus lourde de conséquences : là où un artefact pilote l’exécution, l’enregistrement structuré doit devenir canonique et le Markdown doit devenir une projection destinée aux personnes.

La migration n’est pas terminée. C’est précisément pour cela qu’elle mérite d’être décrite.

Le Markdown nous a mis en mouvement

Le Markdown était un bon point de départ pour une usine logicielle IA. Il est lisible, versionnable et facile à produire pour les personnes comme pour les modèles. Un product owner peut relire une exigence. Un architecte peut annoter un plan. Un ingénieur peut inspecter une liste de tâches dans une pull request.

Il nous a aussi permis d’avancer vite. Des expressions régulières pouvaient récupérer identifiants, titres, fichiers cibles et liens de traçabilité dans des documents qui restaient agréables à lire.

Mais l’approche demande à un seul fichier d’assurer deux métiers différents.

Pour une personne, une phrase peut être claire parce que son sens se comprend en contexte. Pour une machine, la même phrase n’est exécutable que si sa structure et ses conditions d’achèvement peuvent être récupérées sans interprétation. Une tâche telle que améliorer la gestion des erreurs peut être un conseil raisonnable. Ce n’est pas un contrat d’exécution borné. Elle ne nomme ni livrable exact, ni vérification observable, ni état final décidable.

Les expressions régulières savent trouver des étiquettes. Elles ne savent pas transformer une promesse ambiguë en contrat.

Une meilleure analyse était une étape intermédiaire

En avril, nous avons introduit un arbre syntaxique abstrait Markdown partagé. Cela a supprimé toute une classe de problèmes d’analyse fragiles. Les tableaux sont devenus des tableaux plutôt que des lignes attrapées par motif textuel. Les blocs de code, les titres, les commentaires et la prose pouvaient être distingués structurellement. Les vérifications de gouvernance pouvaient inspecter la partie pertinente d’un document au lieu de parcourir chaque caractère avec la même attention.

C’était nettement mieux que les expressions régulières seules. Ce n’était pas la destination.

Un arbre syntaxique abstrait dit au système quel type de nœud Markdown il est en train de lire. Il ne lui dit pas nécessairement ce que l’enregistrement signifie. Un titre peut être reconnu comme titre alors que l’exigence qu’il coiffe reste non typée. Un tableau peut être analysé correctement alors que deux consommateurs interprètent encore différemment l’une de ses colonnes.

L’analyseur était devenu plus fiable, mais on demandait toujours au Markdown de servir à la fois de vue humaine et d’autorité machine.

Le contrat a commencé à remonter en amont

En juillet, nous avions commencé à déplacer le contrôle des instructions vers les contrats.

Les appels de modèle ont cessé de porter des paramètres d’échantillonnage arbitraires à chaque étape. Une étape déclare une intention bornée, qui se résout à travers une configuration de modèle validée. Les tâches de workflow ont gagné des contrats d’entrée et de sortie explicites. Des portes déterministes ont commencé à vérifier des propriétés qu’un modèle ne devrait pas être autorisé à certifier sur son propre travail.

La décision d’architecture est devenue explicite début août : les enregistrements sont canoniques ; les documents lisibles sont des projections.

L’artefact de tâche illustre désormais le schéma complet :

1. Le modèle produit une sortie structurée conforme à un JSON Schema.
2. L’application analyse le résultat en enregistrements typés.
3. La validation Zod rejette tout ce qui sort du contrat applicatif.
4. Les enregistrements validés sont persistés comme artefact JSON faisant autorité.
5. Le Markdown est rendu de façon déterministe à partir de ces enregistrements pour la relecture humaine.
6. La phase Build lit le manifeste typé, pas le Markdown rendu.
7. Un garde de cohérence détecte toute divergence entre l’autorité et sa projection.

Cela change davantage que le format de fichier. La structure survit à la frontière entre étapes.

Le modèle ne peut pas inventer silencieusement une nouvelle forme de tâche. Une étape ultérieure n’a pas à redécouvrir les fichiers cibles à partir de la ponctuation. Un moteur de rendu ne peut pas devenir une source accidentelle de sémantique d’exécution. Si la vue humaine et l’enregistrement machine divergent, le désaccord est détectable.

Le JSON Schema contraint ce qui peut être généré. Zod est la dernière ligne de défense quand cette sortie entre dans l’application. Les consommateurs typés préservent le contrat après persistance. Des portes déterministes décident si le résultat peut avancer.

Chaque mécanisme a un seul métier. Ensemble, ils retirent une grande quantité de prose qui tentait auparavant d’assurer les quatre.

Le document demeure, mais son rôle change

Le JSON d’abord ne signifie pas remplacer chaque document par un déversement d’objets.

Les personnes ont toujours besoin d’une spécification, d’un plan et d’une liste de tâches lisibles. Elles ont besoin de hiérarchie, de justification et de la possibilité de relire une modification sans ouvrir une structure de données interne. Le Markdown reste une surface de relecture efficace.

La distinction importante porte sur l’autorité.

Quand le Markdown est canonique, chaque consommateur doit l’analyser et reconstituer sa propre interprétation. Quand un enregistrement structuré est canonique, chaque vue peut être générée depuis la même source validée. Le document devient une projection : assez stable pour être relu, assez jetable pour être régénéré, et jamais confondu avec le contrat d’exécution.

C’est comparable au logiciel compilé. Les personnes travaillent avec une matière source expressive, mais la production n’exécute pas une interprétation de la documentation. Elle exécute un artefact produit par une transformation définie.

Le même principe devrait s’appliquer à l’intention logicielle.

Un fichier structuré n’est toujours pas une porte

Anthropic a raison : outils, schémas, code et suites de tests peuvent donner à un modèle un contexte plus riche et plus précis qu’une page d’instructions de plus. Une interface bien conçue enseigne souvent mieux son usage correct que plusieurs exemples.

Il reste une frontière entre contexte et contrôle.

Un JSON Schema inclus dans un prompt est du contexte. Un JSON Schema appliqué par le décodeur contraint la génération. Un schéma Zod évalué par l’application valide la frontière. Une suite de tests montrée à un modèle est une référence. La même suite exécutée indépendamment, avec son résultat acheminé par une politique approuvée, est un contrôle.

Le fichier peut être identique. Son rôle opérationnel ne l’est pas.

C’est là que l’ingénierie de contexte rencontre la gouvernance. Le modèle reçoit le plus petit ensemble utile de preuves structurées. Le système valide indépendamment ce qui revient. La politique détermine si le résultat avance, s’arrête ou atteint un point de contrôle humain. La piste d’audit consigne quel contrat, quelles entrées, quels contrôles et quelles décisions se sont appliqués.

Les prompts guident le jugement. Les artefacts structurés préservent le sens. Les contrôles exécutés établissent la preuve.

Des prompts plus courts sont un résultat, pas l’objectif

Anthropic circonscrit soigneusement ses conclusions à une nouvelle génération de ses propres modèles. Cela compte. Des modèles différents ont besoin de quantités et de formes d’échafaudage différentes, surtout quand des charges doivent tourner sur des modèles à poids ouverts dans le périmètre d’un client.

Nous ne devrions pas transformer la réduction de prompt d’un fournisseur en instruction universelle de retirer du contexte.

La règle durable est de retirer la prose qui duplique un contrat applicable. Garder le contexte qui apporte une information que le modèle ne peut obtenir ailleurs. Charger la matière spécialisée quand elle devient pertinente. Ajuster la densité au modèle et à la tâche. Conserver dessous les mêmes portes indépendantes.

Cela nous donne une meilleure cible d’optimisation que la longueur du prompt. Nous pouvons demander si chaque instruction a un rôle unique :

• Apporte-t-elle un contexte nécessaire ?
• Définit-elle une interface structurée ?
• Est-elle déjà appliquée par un contrôle déterministe ?
• Peut-elle n’être chargée qu’au besoin ?
• Le système peut-il mesurer ce qui se passe quand on la retire ?

Si un paragraphe ne fait que répéter une règle qu’un schéma ou une porte applique déjà, c’est probablement du gaspillage. Si le retirer change la capacité d’un modèle à poids ouverts à produire un enregistrement valide, c’est encore un échafaudage utile. La décision devrait être mesurée, pas à la mode.

La migration est le travail produit

Solario est déjà mixte, par conception et par histoire. Des chemins importants sont liés par contrat et JSON d’abord. D’autres artefacts sont générés comme enregistrements structurés mais perdent encore cette structure après rendu. Certains consommateurs en aval lisent encore du Markdown parce que leur enregistrement canonique n’a pas encore franchi la frontière d’étape. La famille des plans reste de forme plus narrative que le chemin des tâches.

L’étape suivante n’est pas de déclarer la migration terminée. C’est de continuer à déplacer l’autorité vers les enregistrements structurés, de faire migrer les consommateurs hors des projections, et de relier ces enregistrements au graphe de spécification et aux contrôles qui les évaluent.

Ce travail produit un système où exigences, décisions d’architecture, contrats, tâches, code et tests peuvent être mis en relation sans réanalyser le récit à chaque étape. Il rend aussi la divulgation progressive plus sûre : l’usine peut assembler les enregistrements précis pertinents pour une décision plutôt que de verser tout l’historique d’un projet dans un prompt.

Notre article précédent soutenait que la porte doit passer à l’échelle avec le travail généré par des machines. Voici comment la matière qui atteint cette porte devient assez fiable pour être jugée.

La réduction de prompt d’Anthropic est une validation utile. La transition plus profonde va de demander à un modèle de se souvenir des règles, à construire un système de production où les règles importantes ont une structure, un validateur et un propriétaire.

La contrainte n’a jamais été dans le prompt. Elle était dans le contrat que le prompt ne pouvait pas contourner par le discours.