Answer Engineering : après le prompt, définir ce qu'une réponse doit respecter

Le terme existe depuis 2021, mais son sens initial est plus étroit que son usage actuel

Le 28 juillet 2021, Pengfei Liu, Weizhe Yuan, Jinlan Fu, Zhengbao Jiang, Hiroaki Hayashi et Graham Neubig déposent sur arXiv Pre-train, Prompt, and Predict: A Systematic Survey of Prompting Methods in Natural Language Processing. Le papier, ensuite publié dans ACM Computing Surveys, contient explicitement une section 5 intitulée "Answer Engineering". Il distingue la conception du prompt de la conception de l'espace dans lequel la réponse est recherchée, notamment à travers l'Answer Shape et l'Answer Space.

Dans ce cadre, l'Answer Shape concerne la forme physique ou la granularité de la sortie : un token, un segment de texte, une phrase ou une réponse plus ouverte. L'Answer Space concerne l'ensemble des candidats possibles. Pour une classification binaire, cet espace peut être réduit à deux valeurs ; pour une tâche générative, il peut rester largement ouvert. Ce n'est donc pas une théorie générale de la "bonne réponse", mais un problème d'ingénierie très concret : comment faire correspondre une production linguistique probabiliste avec l'objet attendu par la tâche.

En 2024, The Prompt Report de Sander Schulhoff et de nombreux coauteurs reprend cette distinction et ajoute explicitement un troisième élément, l'Answer Extractor. Le rapport définit alors l'Answer Engineering comme le processus de développement ou de sélection d'algorithmes permettant d'extraire une réponse précise de la sortie d'un LLM. L'extracteur peut être simple, par exemple une expression régulière, ou plus complexe. Cette extension est importante parce qu'elle fait apparaître une réalité opérationnelle : même lorsqu'on ne maîtrise pas complètement ce que le modèle génère, on peut définir la manière dont la partie utile sera reconnue et transformée.

La réponse devient un objet à concevoir, pas seulement un texte à générer

Prenons un exemple volontairement simple. Demander à un modèle "analyse ce dossier et donne-moi ton avis" laisse ouvertes la forme de la réponse, la nature des conclusions, la manière de distinguer un fait d'une hypothèse et les conditions dans lesquelles le modèle devrait refuser de conclure. On peut améliorer le prompt, mais une partie du problème reste située en sortie.

Une approche orientée Answer Engineering peut au contraire définir que chaque affirmation doit appartenir à un ensemble d'états autorisés, par exemple "supported", "uncertain", "contradicted" ou "unknown", qu'une donnée chiffrée doit être accompagnée d'une source et d'une date, et qu'une conclusion doit rester "unknown" si une preuve obligatoire manque. Le modèle peut continuer à générer du langage naturel, mais le système qui l'entoure sait désormais ce qu'il attend et ce qu'il doit rejeter.

Cette logique complète une autre question déjà abordée sur Kachouri avec PRISM 153, qui cherche à déterminer quelle IA est légitime pour répondre. Le routage demande quel modèle doit prendre la main ; l'Answer Engineering demande quelles propriétés sa sortie doit respecter. Ce sont deux couches différentes d'un même problème d'architecture, et aucune ne dispense de vérifier le contenu final.

Un JSON valide peut toujours raconter quelque chose de faux

Les "structured outputs" et le décodage contraint donnent une traduction moderne et très concrète de cette logique. Il ne s'agit plus seulement d'écrire "réponds en JSON valide" dans une invite. Certaines méthodes contraignent directement les choix possibles pendant la génération afin d'empêcher une sortie incompatible avec le schéma attendu.

Publié en 2025, JSONSchemaBench a précisément été conçu pour mesurer ces mécanismes. Le benchmark réunit 10 000 schémas JSON issus de cas réels et compare six frameworks ou implémentations, dont Guidance, Outlines, llama.cpp, XGrammar, OpenAI et Gemini. Les auteurs évaluent la conformité aux contraintes, mais aussi la couverture des types de contraintes, l'efficacité et la qualité de la génération. Le benchmark existe justement parce que toutes les implémentations ne se valent pas et qu'une garantie de structure ne résume pas le comportement du système.

La distinction essentielle se trouve là : la conformité syntaxique n'est pas la véracité sémantique. Un objet JSON peut respecter exactement son schéma tout en contenant une date inventée, une causalité non démontrée ou une source qui ne soutient pas l'affirmation associée. C'est cohérent avec la ligne éditoriale développée dans le dossier IA responsable : utilité, contrôle, traçabilité et réversibilité : une sortie de modèle ne devient pas une preuve simplement parce qu'elle est propre, structurée ou facile à intégrer dans un logiciel.

En 2026, un préprint propose de contrôler aussi la trajectoire de génération

Un travail plus récent pousse le terme plus loin. Le 19 juin 2026, Victor Lavrenko et Anastasiia Molodnitskaia publient sur arXiv Answer Engineering: Local Trajectory Editing for Protocol-Constrained Decision Making in Large Language Models. Les auteurs décrivent une couche déterministe au runtime capable d'appliquer des interventions locales guidées par des règles sur la trajectoire visible de génération, sans réentraînement du modèle, modification de ses poids ou recherche globale.

Leur évaluation porte sur un benchmark clinique contrôlé consacré à la surdité brusque. Dans ce cadre précis, la conformité au protocole passe de 54,5 % en génération non guidée à 25,1 % avec une condition de raisonnement pas à pas, puis à 83,5 % avec l'édition locale de trajectoire. Sur la condition de contraste conductif, l'adhérence atteint 77,9 %, tandis que l'exactitude équilibrée passe de 42,0 % sous la condition de raisonnement seule à 80,7 % avec l'intervention proposée.

Ces résultats sont intéressants, mais leur portée doit rester exactement celle de l'expérience. Il s'agit d'un préprint de 2026, évalué sur un protocole clinique contrôlé, et les auteurs signalent eux-mêmes des limites liées à la couverture des règles, à la fiabilité des déclencheurs et à certains comportements persistants du modèle. Ce papier ne démontre donc pas qu'une couche d'Answer Engineering rendrait n'importe quel LLM "fiable". Il montre qu'un contrôle externe, explicite et auditable peut améliorer l'adhérence à un protocole dans le dispositif testé.

Prompt, contexte, récupération et réponse ne contrôlent pas la même chose

Une partie de la confusion vient du fait que plusieurs couches sont souvent présentées comme des recettes concurrentes alors qu'elles répondent à des questions différentes. Le Prompt Engineering travaille d'abord sur la formulation de l'instruction. Le Context Engineering organise ce que le modèle peut voir au moment de répondre. Un pipeline RAG ajoute une mécanique de récupération, de sélection et d'injection de documents. L'Answer Engineering intervient sur l'espace de sortie, sa forme, son extraction ou, dans certaines approches récentes, son contrôle pendant la génération.

Ces briques peuvent fonctionner ensemble. Elles peuvent aussi échouer indépendamment les unes des autres. Un excellent prompt alimenté par une documentation périmée reste un excellent moyen d'obtenir une réponse périmée. Un RAG peut récupérer le mauvais passage. Un schéma parfaitement respecté peut transporter une mauvaise conclusion. Une architecture multi-modèles peut enfin devenir difficile à remplacer si l'état, la mémoire et les règles restent enfermés dans une plateforme unique, un problème déjà développé dans l'analyse sur l'IA et la dépendance technologique.

L'Answer Engineering n'est donc pas "l'après Prompt Engineering" au sens d'une technologie qui rendrait les précédentes obsolètes. Il complète la chaîne en traitant une question que l'on laisse trop souvent implicite : quand le système reçoit une production du modèle, à quelles conditions peut-il réellement l'utiliser ?

Quand le SEO reprend le mot, le mécanisme change

Le même syntagme circule désormais dans un autre univers. En décembre 2025, l'agence Nooki publie par exemple un article intitulé Answer Engineering : la nouvelle façon d'écrire pour ChatGPT, Perplexity et les IA. Le terme y désigne une méthode éditoriale "answer-first" : question identifiable, réponse directe, blocs autonomes, structure pensée pour faciliter la reprise par un moteur génératif.

Cette pratique peut avoir un intérêt éditorial. Elle ne correspond cependant pas au mécanisme décrit par Liu et al. ou Schulhoff et al. Le propriétaire d'une page web ne contrôle ni le retriever, ni le reranking, ni le contexte finalement présenté au modèle, ni la décision de citer son contenu. Il optimise un document soumis à un système tiers, alors que l'Answer Engineering académique agit sur la définition ou l'extraction de la sortie d'un modèle que l'on intègre à une tâche.

Les travaux sur le Generative Engine Optimization montrent qu'il ne faut pas pour autant balayer la question. En 2023, Pranjal Aggarwal et ses coauteurs introduisent GEO et GEO-bench, avec des gains de visibilité pouvant atteindre 40 % dans leur environnement expérimental. Leur propre papier insiste toutefois sur le caractère "black-box" des moteurs génératifs et sur le faible contrôle des créateurs quant au moment et à la manière dont leurs contenus sont affichés.

Une revue critique publiée en juillet 2026 par Olivier Martinez apporte une limite supplémentaire. Après examen de 45 études, elle conclut que les gains du papier fondateur sont valides dans leur cadre expérimental, notamment lorsque la source est déjà présente dans un contexte fixé, mais qu'ils ne démontrent ni une découvrabilité organique durable ni un effet causal stable sur plusieurs plateformes. Autrement dit, rendre un contenu plus clair, attribué et exploitable peut être utile ; promettre qu'une structure éditoriale "force" ChatGPT, Perplexity ou Google à citer une page serait une conclusion que les travaux disponibles ne permettent pas d'établir.

Une citation n'est pas une preuve, même lorsqu'elle en a l'apparence

Cette distinction entre forme et preuve devient encore plus importante lorsque la réponse contient des références. En 2023, Nelson F. Liu, Tianyi Zhang et Percy Liang ont audité Bing Chat, NeevaAI, Perplexity.ai et YouChat. Dans leur évaluation humaine, 51,5 % des phrases générées étaient entièrement soutenues par les citations affichées, et 74,5 % des citations soutenaient réellement la phrase à laquelle elles étaient associées.

Ces chiffres décrivent des systèmes observés en 2023. Ils ne doivent pas être utilisés comme mesure des versions de 2026 de ChatGPT, Perplexity ou d'autres moteurs. Leur intérêt est ailleurs : ils montrent expérimentalement qu'une réponse peut présenter l'apparence documentaire de la vérifiabilité sans que chaque affirmation soit effectivement soutenue.

Une architecture sérieuse doit donc traiter séparément la présence d'une source et la relation entre cette source et l'affirmation. Vérifier qu'un champ source n'est pas vide est une vérification de structure. Vérifier que le document existe, qu'il est authentique, qu'il dit bien ce qu'on lui attribue, qu'il concerne la bonne période et la bonne population relève d'un autre niveau. Mélanger les deux revient à transformer une interface propre en fausse assurance.

Kerkito offre un terrain d'application, pas une preuve du concept

Cette recherche rejoint directement une piste de travail autour de Kerkito, qui fait partie de mon propre écosystème de projets. Je précise cette proximité parce qu'elle compte pour la lecture : Kerkito n'est pas utilisé ici pour prouver l'Answer Engineering, mais comme terrain possible d'application de ce que les sources décrivent.

Dans son état public documenté au 17 septembre 2026, Kerkito est présenté comme un moteur déterministe, sans LLM requis, qui aide à structurer une intention en distinguant notamment faits, hypothèses, contraintes et preuves. L'évolution envisagée consisterait à prolonger cette logique après la clarification de la demande : non pas produire la réponse à la place d'un modèle ou d'un humain, mais compiler un contrat de réponse indiquant la forme attendue, les états admissibles, les preuves exigées, les inconnues acceptables et les conditions de rejet.

Il faut maintenir ici une frontière nette entre le produit actuel et cette piste. Ce "contrat de réponse" est une direction de conception, pas une fonctionnalité que cet article présente comme déjà déployée. Son intérêt est justement de rester testable : Kerkito pourrait contrôler localement qu'une section obligatoire existe, qu'une date est présente ou qu'un statut appartient à une nomenclature, sans prétendre pour autant que la source citée est vraie ou que la conclusion est scientifiquement valide.

Le vrai déplacement est de définir la réponse avant de la croire

L'intérêt de l'Answer Engineering n'est finalement pas de fournir un nouveau mot à coller après "Prompt Engineering". Il est de rendre visible une question que l'usage conversationnel des LLM masque facilement. Tant qu'une IA répond dans une fenêtre de chat, une phrase plausible peut suffire à donner l'impression que le travail est terminé. Dès que cette réponse alimente une décision, un logiciel, une recherche ou une procédure, il faut savoir ce qui est acceptable, ce qui manque et ce qui doit empêcher l'exécution.

C'est là que le concept devient utile : une réponse peut être pensée comme un objet avec une forme, un espace admissible, une méthode d'extraction, des exigences de preuve et des conditions de refus. La génération reste probabiliste, mais toutes les règles qui l'entourent ne sont pas obligées de l'être.

Le changement le plus intéressant n'est donc peut-être pas de mieux demander à l'IA de répondre. C'est de décider, avant qu'elle parle, ce qui nous autorisera réellement à utiliser sa réponse.