Comment encadrer un génie imprévisible

• Pour réduire les erreurs répétées dans des produits d’IA dont les résultats varient même pour une même requête, il faut les contrôler non pas en multipliant les consignes, mais avec du code déterministe que le modèle ne peut pas contredire
• La structure de contrôle se divise en quatre couches — modèle, harnais, documentation et hooks — et seuls les hooks qui s’exécutent indépendamment dans certaines conditions peuvent faire appliquer des règles
• Les tâches dont l’exactitude peut être évaluée par du code peuvent être garanties, mais celles qui exigent un jugement, comme des erreurs d’analyse subtiles, dépendent à nouveau d’un modèle ; même si les modèles progressent, le vide de vérification ne disparaît pas
• Les produits d’IA ont besoin d’une ingénierie de harnais qui distingue ce qui doit relever du jugement du modèle de ce qui doit être garanti par du code ; avec trop peu de contrôle ils produisent des réponses fausses, avec trop de contrôle ils deviennent des logiciels classiques coûteux
• Si tout le monde peut louer le même modèle, la couche d’enrobage (wrapper) qui accumule les critères, le code, les données et l’environnement d’intégration propres à chaque produit devient un avantage défendable ; la croissance de Cursor l’illustre

---

Transformer les règles de la documentation en code

• Même si l’on interdit explicitement certains comportements dans un fichier que Claude Code lit à chaque session, il arrive qu’il comprenne le contenu, l’approuve, puis répète le même comportement
• Une fois la règle déplacée dans du code qui bloque une commande dès que la condition est remplie, le comportement interdit cesse, indépendamment du jugement du modèle
• Le coût de revue des sorties d’IA traité par The Verification Tax peut être réduit par de l’ingénierie en amont plutôt qu’en augmentant les revues a posteriori
• Même une structure de contrôle minimale créée par une seule personne avec ses outils personnels présente la même forme que le problème que doivent résoudre les grands produits d’IA
• Des consignes pratiques qui relient les types d’échecs aux types de hooks et clarifient ce qui est mesurable couche par couche sont disponibles dans un post X séparé

Les quatre couches qui composent le contrôle

• La capacité de contrôle se compose de quatre couches, de plus en plus fortes du bas vers le haut
  • Modèle : même excellents, Claude Opus 4.8 ou GPT-5.5 peuvent donner des réponses différentes à une même requête, et aucune consigne ne peut éliminer complètement cette propriété
  • Harnais : Claude Code, Codex ou OpenClaw exécutent le modèle et décident de ce qu’il peut voir, mais ne peuvent guider que les grandes orientations
  • Documentation : CLAUDE.md et AGENTS.md contiennent préférences, contexte du projet, règles et corrections accumulées, mais le modèle les évalue avec d’autres informations et peut donc ne pas les suivre
  • Hooks : du code qui surveille des situations spécifiques et s’exécute indépendamment, bloquant les commandes interdites que le modèle soit d’accord ou non
• Parmi ces quatre couches, seule la couche supérieure des hooks ne négocie pas
  • Les règles transférées dans des hooks ne peuvent pas être contournées par le modèle, ce qui élimine les erreurs répétées et réduit aussi le périmètre à examiner par des humains

Le domaine du jugement que le code ne peut pas garantir

• On peut réduire la surface à contrôler, mais pas la fermer complètement
  • Une condition comme « ne pas exécuter cette commande » peut être vérifiée par du code
  • Une condition comme « éviter que l’analyse ne dérive subtilement dans la mauvaise direction » exige du jugement, et un autre modèle chargé de l’évaluer reste lui aussi imprévisible
• Les systèmes capables de prouver réellement leurs sorties comparent par du code des critères et des résultats écrits à l’avance par des humains, et ne fonctionnent que dans les domaines où la bonne réponse peut être définie précisément
• Même lorsque les modèles sont mis à niveau, les problèmes de jugement ne disparaissent pas ; les couches de contrôle qui enveloppent les modèles restent donc nécessaires

• Garanties fondées sur des spécifications formelles

  • SEVerA peut garantir que la sortie d’un agent respecte un contrat formel, mais ce contrat doit être écrit à l’avance en logique formelle, et cela ne s’applique qu’aux domaines où ce type de vérification est possible
  • VeriGuard ajoute une sûreté vérifiée aux agents LLM, mais la vérification manuelle par l’utilisateur reste nécessaire
  • L’étape où un LLM traduit l’intention de l’utilisateur en règles formelles est elle-même imprévisible
  • En pratique, les garanties reposent donc sur des vérifications fixes par rapport à des spécifications écrites par des humains
  • Les « agents auto-améliorants » évaluent les résultats obtenus pour améliorer leurs actions futures, mais ce n’est pas la même chose que prouver qu’une sortie précise est correcte

Envelopper un moteur probabiliste dans un logiciel déterministe

• Les tests logiciels traditionnels se sont développés autour de l’idée que l’on définit une sortie attendue et une bonne réponse unique, puis que l’on vérifie un code prévisible
• Les produits AI-native placent au centre un moteur probabiliste qui peut produire des résultats différents avec le même prompt, ce qui casse les présupposés des tests existants
• Comme le souligne Hamel Husain, la discipline du test logiciel construite au fil de décennies suppose une bonne réponse unique ; avec l’IA, c’est précisément cette réponse qui disparaît
• De nombreux développeurs convergent vers une approche qui conserve le moteur imprévisible, mais l’enveloppe de code déterministe qui fonctionne de la même manière à chaque fois
  • Les 12-factor agents de Dex Horthy définissent un bon agent comme un système « composé majoritairement de logiciel »
  • building effective agents d’Anthropic recommande d’exécuter les tâches via des « chemins de code prédéfinis » et d’ajouter des « vérifications programmatiques »
• Dans Claude Code, on peut choisir la manière de vérifier une condition
  • Si le code décide indépendamment du succès ou de l’échec, on obtient une garantie
  • Si le modèle décide si la condition est remplie, on n’obtient qu’un jugement

• Skills et /goal de Claude Code

  • Les Skills sont des procédures structurées qu’un agent peut appeler, mais comme le modèle choisit de les exécuter ou non et peut s’en écarter en cours de route, elles relèvent de la couche documentaire
  • /goal se rapproche d’une couche coercitive, car il force la poursuite du travail jusqu’à ce que les conditions indiquées soient remplies
  • Toutefois, après chaque tour, un petit modèle rapide juge si les conditions sont satisfaites, et peut donc se tromper comme n’importe quel autre modèle
  • /goal est une fonctionnalité qui enveloppe un hook Stop ; dans un hook Stop écrit directement, un script peut décider indépendamment du succès ou de l’échec à la place du modèle
  • La documentation de Claude Code distingue les deux approches : des scripts pour les vérifications déterministes, des modèles pour les vérifications qui exigent du jugement

Quand la configuration personnelle passe à l’échelle de l’organisation

• Dans un environnement personnel, si un agent ignore une règle, cela ne coûte que quelques minutes, et les cas importants peuvent être bloqués par des hooks personnels
• Dans une entreprise de 200 personnes utilisant le même agent, chaque membre ne dispose pas forcément de hooks personnels et les règles peuvent se trouver dans un fichier partagé unique
• Si une règle partagée est ignorée une fois, le même problème peut apparaître partout où ce fichier s’exécute, et le niveau de protection de l’organisation dépend de la règle écrite de la manière la plus permissive
• La structure de contrôle est la même que dans une configuration personnelle, mais à mesure que l’échelle augmente, le coût des erreurs change

Que garantir et que laisser ouvert

• Le guide d’architecture agent-native d’Every définit une fonctionnalité non pas comme du code écrit, mais comme « un résultat décrit, atteint par un agent opérant dans une boucle »
• Cette approche laisse le modèle improviser et conçoit le produit autour du résultat, mais revient au code aux endroits qui nécessitent du contrôle
  • Elle recommande de déplacer dans le code les hot paths, c’est-à-dire les chemins fréquents ou importants
  • Elle reconnaît que certaines tâches exigent une vérification qui ne doit pas être laissée au jugement de l’agent
• La conception de produit centrée sur le modèle et l’ingénierie centrée sur le contrôle semblent opposées, mais elles traitent la même architecture par ses deux extrémités
• En conception réelle, il faut décider quels points du produit figer dans le code et jusqu’à quel degré
  • Avec trop peu de points figés, même dans des tâches qui exigent des garanties, le modèle peut juger de manière improvisée et transmettre aux clients des réponses fausses avec assurance
  • Avec trop de points figés, tous les chemins sont codés comme dans un logiciel classique, et le modèle exécute lentement et cher ce que le code existant faisait déjà
• Ce que l’équipe d’OpenAI appelle ingénierie de harnais consiste à répartir intentionnellement, à chaque point du produit, ce qui doit relever du jugement du modèle et ce qui doit être garanti par le code

La couche d’enrobage qui s’accumule plus longtemps que le modèle

• Les modèles sont la couche la plus difficile à défendre : tout le monde peut louer les mêmes, et ils s’améliorent pour tous les utilisateurs en même temps selon le calendrier des laboratoires de modèles
• Même si un concurrent lit tout le dépôt de code, il n’obtient pas pour autant le jugement accumulé sur ce qu’il faut garantir et ce qu’il faut laisser ouvert dans un métier donné
• Ces jugements sont implémentés dans des couches que le modèle ne peut pas contredire et s’accumulent avec la structure de contrôle propre à chaque produit
• La somme du code, des critères, des données et des environnements d’intégration métier qui entourent le modèle constitue un avantage concurrentiel de long terme

La couche de contrôle accumulée par Cursor

• L’outil de codage IA Cursor ne construit pas son propre modèle généraliste ; il route les requêtes entre Claude, GPT, Gemini et Grok, et traite les modèles comme des produits que l’on peut louer
• Même si Claude Code d’Anthropic accède en premier à d’excellents modèles, cela ne suffit pas à remplacer Cursor
• Le chiffre d’affaires de Cursor est passé d’environ 1 milliard de dollars en novembre dernier à environ 4 milliards de dollars en juin
• SpaceX a exercé la semaine dernière une option obtenue en avril et accepté d’acquérir Cursor pour 60 milliards de dollars, ce qui en fait la plus grande acquisition de startup financée par capital-risque de l’histoire
• Ce que Cursor a accumulé n’est pas un meilleur modèle généraliste, mais la couche qui enveloppe le produit
  • Un index de codebase qui synchronise des dépôts entiers et les maintient consultables
  • Son propre modèle d’autocomplétion, entraîné à partir de centaines de millions d’éditions quotidiennes pour apprendre quelles suggestions les développeurs acceptent ou rejettent
  • Un environnement d’intégration entreprise présent dans la plupart des entreprises du Fortune 500
• Même si une entreprise de modèles possède un meilleur modèle, elle ne possède pas pour autant l’éditeur, l’index ni les habitudes d’utilisation des développeurs

La question qui détermine la durabilité des produits AI-native

• Les exemples qui, comme Cursor, ont construit des couches de contrôle sont rares ; beaucoup d’utilisateurs professionnels de l’IA n’ont pas créé ce type de couche d’enrobage, ou n’en connaissent même pas l’existence
• À l’échelle d’une entreprise, la manière de construire cette couche distingue les produits AI-native capables de résister à un usage réel des démos impressionnantes bâties sur un modèle que tout le monde peut louer
• Même si les modèles de base deviennent gratuits, la question de ce qui reste détermine les actifs durables du produit