Prompt, context, loop, harness engineering : où s'arrête chacun

Il y a un schéma amusant dans le vocabulaire de l'IA appliquée. Tous les six mois environ, un nouveau terme en -engineering apparaît. Et à chaque fois, il apparaît au moment exact où la discipline précédente a cessé de suffire.

D'abord le prompt engineering. Puis, quand il est devenu clair que la formulation n'était pas le levier principal, le context engineering. Puis, quand les agents se sont mis à enchaîner des dizaines d'étapes, le loop engineering. Et maintenant le harness engineering, à mesure qu'on découvre que l'outillage autour du modèle pèse autant que le modèle lui-même.

Avertissement d'usage : ces noms ne sont pas stabilisés. « Context engineering » fait consensus, « harness » circule surtout chez ceux qui font tourner des évaluations, « loop engineering » signifie deux ou trois choses selon l'interlocuteur. Cette instabilité fait partie du sujet — on nomme vite ce qu'on découvre en marchant.

Passons-les en revue honnêtement : ce que chacune a réellement résolu, et où elle s'arrête.

# Quatre disciplines, quatre plafonds

prompt    comment je formule
          ↳ plafond : les astuces ne survivent pas au modèle suivant

context   ce que le modèle voit
          ↳ plafond : qui l'entretient sur douze mois ?

loop      comment l'agent itère
          ↳ plafond : une bonne boucle, un mauvais objectif

harness   ce qui entoure le modèle
          ↳ plafond : mesuré à la tâche, pas au produit

1. Prompt engineering : la formulation

Ce que ça a résolu. Que la manière de demander compte. Décomposer une tâche, donner un format de sortie, montrer un exemple : ce sont des gestes qui marchent, et qui ont fait gagner un temps considérable à beaucoup de monde.

Où ça s'arrête. Le laboratoire d'IA générative de Wharton a passé au banc d'essai les recettes les plus populaires — politesse, pourboires, menaces, personas d'expert, « think step by step ». Le verdict est sans appel : effets contingents, imprévisibles, parfois coûteux en tokens pour un gain nul. Ethan Mollick résume : ce qui marche, c'est de « spécifier vos objectifs, votre sortie, ce à quoi ressemblent un bon et un mauvais résultat, et comment tester ».

Et il y a pire que l'inefficacité : la péremption. Un prompt système finement ciselé pour un modèle donné peut brider le suivant, dont les capacités de planification ont changé. Les bibliothèques de prompts « génériques » vieillissent en silence. C'est de la dette technique, avec la particularité qu'elle ne casse pas le build — elle dégrade juste les résultats sans prévenir.

2. Context engineering : ce que le modèle voit

Ce que ça a résolu. Le déplacement le plus important des deux dernières années. On a compris que le levier n'était pas la formule mais la matière : quels fichiers, quelles règles, quelles décisions passées, quelle documentation entrent dans la fenêtre. Le cabinet Archwise le formule bien — traiter le contexte comme une infrastructure, au même titre que le code ou les données.

Où ça s'arrête. Sur une question de propriété, pas de technique. La discipline dit très bien quoi mettre dans le contexte. Elle dit beaucoup moins bien qui le maintient quand l'équipe grandit, quand le produit change, quand celui qui a écrit le fichier d'orientation est parti.

Le symptôme est universel : un fichier de contexte à la racine du dépôt, excellent le jour où il est écrit, obsolète six mois plus tard, et que personne ne se sent responsable de mettre à jour parce qu'il n'appartient à aucun ticket. Le contexte est traité comme une infrastructure dans le discours, et comme un brouillon dans les faits.

3. Loop engineering : la forme de l'itération

Ce que ça a résolu. Un agent n'est pas une réponse, c'est une boucle : planifier, agir, observer, recommencer. La façon dont on dessine cette boucle change tout — quand s'arrêter, quand relire son propre travail, quand déléguer à un sous-agent, quand demander à un humain. Les boucles qui intègrent une étape de vérification produisent des résultats nettement plus fiables que celles qui foncent.

Où ça s'arrête. Sur une évidence désagréable : une boucle excellente qui vérifie le mauvais critère converge, avec assurance, vers le mauvais résultat. C'est même la propriété la plus dangereuse d'une bonne boucle — elle est persuasive. Elle a itéré, elle a testé, elle a corrigé. Simplement, personne ne lui avait dit que la fonctionnalité demandée n'était pas celle-là.

Deuxième limite, plus discrète : une boucle est conçue par tâche. Elle ne capitalise pas. Ce qu'elle a appris en corrigeant une erreur reste dans sa trace d'exécution, et disparaît avec elle.

4. Harness engineering : l'outillage autour du modèle

Ce que ça a résolu. La prise de conscience la plus récente, et probablement la plus sous-estimée : ce qu'on consomme n'est jamais « un modèle », c'est un modèle plus son harnais. Les outils qu'on lui donne, le bac à sable dans lequel il s'exécute, les permissions, les hooks, la mémoire, l'orchestration de sous-agents, les jeux d'évaluation. À modèle identique, deux harnais donnent deux produits différents — les écarts observés sur des benchmarks comme ARC-AGI l'ont rendu impossible à ignorer.

Où ça s'arrête. Le harnais est une pièce d'ingénierie, mesurée sur des tâches. C'est sa force — et sa frontière. Un harnais excellent vous dit à quel point l'agent réussit ce qu'on lui donne à faire. Il ne dit rien de ce qu'il aurait fallu lui donner à faire, ni de qui en a décidé, ni de ce que ça a coûté rapporté à ce qui a été livré aux utilisateurs.

Et comme le prompt et le contexte, il appartient à celui qui écrit du code. La personne qui décide du produit n'y a pas accès, et n'a d'ailleurs aucune raison d'y toucher.

Le point commun : ces quatre disciplines optimisent une exécution

Prises ensemble, elles couvrent remarquablement bien le trajet qui va du moment où l'on appuie sur Entrée jusqu'au moment où l'agent s'arrête. C'est un vrai progrès, et rien de ce qui suit ne le remet en cause.

Mais elles partagent trois angles morts, qui sont les mêmes à chaque étage :

• Elles sont à la session. Ce qu'on a appris, arbitré, corrigé pendant une exécution ne survit pas à l'exécution suivante — sauf à le réinjecter à la main, ce que personne ne tient sur douze mois.
• Elles appartiennent à celui qui code. Le prompt, le contexte, la boucle et le harnais vivent dans le dépôt et sur la machine du développeur. La personne qui décide de ce qu'il faut construire n'est pas dans la boucle — au sens propre.
• Elles optimisent la réponse, pas la question. Aucune ne vous dira si l'objectif méritait d'être poursuivi, qui en a convenu, ni ce que la fonctionnalité livrée a réellement coûté.

Ce que Survol ajoute — et à quel endroit précis

Nous n'avons pas de cinquième terme en -engineering à proposer, et ce serait un peu ridicule. Ce que nous constatons, c'est qu'à partir d'un certain point, ce n'est plus de l'ingénierie : c'est du pilotage produit, outillé. Trois angles morts, trois réponses concrètes.

Faire survivre le contexte à la session

Dans Survol, ce qui compte n'est pas rechargé à chaque exécution : il persiste. La spécification de chaque fonctionnalité est versionnée et reliée à ses versions livrées. Les décisions produit ont un cycle de vie complet — ouverte, acceptée ou refusée, puis implémentée — avec leurs dates, leurs votants et le pourquoi. Les contraintes techniques de l'organisation sont injectées au début de chaque session, à trois niveaux d'autorité, et chaque application est journalisée.

La conséquence est que le contexte cesse d'être un fichier que quelqu'un doit penser à mettre à jour. Il devient un sous-produit du travail : décider, c'est déjà l'écrire.

Sortir le pilotage de la machine du développeur

Le prompt, le contexte, la boucle, le harnais : quatre choses qu'un PM ne verra jamais. Survol est web d'abord, et c'est un choix de conception assumé — la personne qui décide du produit ne devrait rien avoir à installer pour voir où en est ce qu'elle a demandé. Elle décrit la fonctionnalité, l'équipe tranche les décisions ouvertes, et c'est cette spec validée qui devient l'instruction envoyée à l'agent. Le prompt n'est plus tapé : il est dérivé de ce qui a été décidé.

Relier l'exécution à ce qui est livré

C'est là que les quatre disciplines n'ont structurellement rien à dire, et c'est pourtant la question que posent les directions. Survol suit la consommation par session, par version et par fonctionnalité — pas seulement par personne. Et le statut d'une fonctionnalité est dérivé de ce qui est réellement déployé : préview validée, cahier de tests déroulé sur tel environnement, mise en production. Une boucle qui tourne magnifiquement sans jamais aboutir à une version livrée se voit immédiatement.

Ce que ça ne dispense pas de faire

Soyons clairs, parce que l'inverse serait malhonnête : Survol ne remplace aucune des quatre disciplines.

• Vous aurez toujours besoin d'un bon harnais — c'est le rôle de l'outil qui exécute, pas du nôtre.
• Vous aurez toujours besoin d'une boucle bien dessinée, avec ses étapes de vérification.
• Vous aurez toujours besoin d'un contexte bien composé. Nous en fabriquons une partie à partir de la spec et des décisions, mais la discipline reste la même.
• Et il restera des prompts, quelque part. Simplement, plus personne ne devrait avoir à les écrire à la main pour lancer une fonctionnalité.

Ce que nous affirmons est plus modeste, et plus précis : ces quatre disciplines ont un plafond commun, ce plafond n'est pas technique, et aucune d'elles n'a vocation à le franchir.

Ce qu'on en retient

1. Chaque terme en -engineering est apparu quand le précédent a cessé de suffire. C'est un bon indicateur de l'endroit où se déplace la difficulté.
2. Les quatre optimisent une exécution : ce qui se passe entre Entrée et l'arrêt de l'agent. Aucune ne prétend faire plus, et c'est légitime.
3. Leurs angles morts sont identiques : rien ne persiste, tout appartient à celui qui code, rien ne relie la dépense au livré.
4. Franchir ce plafond ne demande pas un modèle plus gros ni un harnais plus fin. Ça demande de traiter la spec, les décisions et les coûts comme des objets de premier plan. C'est ce que nous construisons.

Le prochain terme en -engineering arrivera de toute façon — on prend les paris pour l'automne. Mais il y a une hypothèse plus intéressante : peut-être que le prochain saut ne portera pas de nom en -engineering du tout. Parce qu'à cet endroit-là, comme le dit Mollick, « c'est juste du management ».