Dictionnaire de l'IA

Une appellation qui évolue, pas une technologie. « IA » ne désigne pas une chose fixe comme le font modèle ou jeton : le terme pointe vers ce que les ordinateurs savent faire de nouveau et d’impressionnant. Aujourd’hui, il désigne les grands modèles de langage. Il a désigné des choses très différentes auparavant :

Le déplacement de cette appellation suit un mécanisme connu, parfois appelé effet IA : dès qu’une technique fonctionne de façon fiable, on la rebaptise — « ce n’est que » de la recherche, « que » des statistiques — et « IA » avance vers le prochain problème non résolu. L’observation est ancienne. Bertram Raphael l’a formulée ainsi en 1971 : « L’IA est un nom collectif pour les problèmes que nous ne savons pas encore résoudre correctement par ordinateur. » La version de Larry Tesler, vers 1979 : « L’intelligence, c’est ce que les machines ne savent pas encore faire. »

C’est pourquoi les conversations sur l’IA se croisent si souvent sans se répondre. Une affirmation comme « l’IA ne sait pas raisonner » ou « l’IA est surestimée » porte une date cachée : elle peut concerner les systèmes experts, les classificateurs d’images des années 2010 ou le LLM du mois dernier, et chaque référence mène à une conclusion différente. Lorsqu’une discussion sur l’IA s’enlise, la solution consiste généralement à remplacer le mot par le terme précis visé : le modèle, le harness, l’agent, le contexte qui lui a été fourni.

À éviter : employer « IA » dans une affirmation technique — nommez plutôt l’élément concerné. L’expression « codage IA » pour désigner cette pratique convient ; « l’IA hallucine » ne convient pas.

Exemple d’utilisation :

« Le CTO veut savoir si l’IA pourrait gérer la file de triage. »

« Précise ce que cela veut dire avant de cadrer le travail — elle parle d’un LLM dans un harness qui accède au système de tickets. À lui seul, “IA” ne constitue pas une spécification. »

Les paramètres. Stateless : le modèle effectue une prédiction du prochain jeton, et rien d’autre. « Claude Opus 4.x » et « GPT-5.x » sont des modèles. Un modèle ne peut rien faire d’agentique par lui-même ; il doit être intégré à un harness.

Les modèles ne peuvent ni lire des fichiers, ni exécuter des commandes, ni naviguer sur le Web, ni se souvenir de la veille : ils reçoivent des jetons et prédisent les jetons suivants, à chaque requête au fournisseur de modèle. Tout ce qui donne l’impression qu’un agent travaille — choisir des outils, lire des résultats, répéter le cycle jusqu’à la fin de la tâche — vient du harness, qui orchestre une série de ces prédictions.

Les fournisseurs de modèles proposent des modèles par catégories : un grand modèle, plus intelligent mais lent et coûteux, et des modèles plus petits, plus rapides et moins chers, mais moins capables. Choisir une catégorie est une véritable décision — modèle puissant pour la planification et le débogage difficile, modèle léger pour les modifications mécaniques — et les harnesses permettent de changer de modèle au cours d’une session.

Employer le terme avec précision aide aussi au diagnostic. « Le modèle est mauvais pour cette tâche » est une affirmation précise : le même modèle peut se comporter tout autrement dans un autre harness ou avec un contexte différent. Avant de l’accuser, vérifiez ce qui lui a été fourni : la plupart des réponses décevantes s’expliquent par le contexte ou le harness, pas par les paramètres.

Exemple d’utilisation :

« Devrait-on passer de Sonnet à Opus pour l’étape de planification ? »

« Essayez, mais le harness fait l’essentiel du travail ici. Changer de modèle n’aidera pas si l’invite système et les outils sont mal configurés. »

Les nombres qui composent un modèle — souvent des milliards — ajustés pendant l’entraînement. Tout ce que le modèle « sait » réside en eux. L’entraînement les définit ; l’inférence les utilise sans les modifier. On les appelle aussi poids.

Concrètement, les paramètres transforment l’entrée en sortie. La prédiction du prochain jeton est un calcul gigantesque : les jetons de la fenêtre de contexte sont multipliés par les paramètres, ce qui produit une prédiction du jeton suivant. Le modèle ne contient ni base de données de faits ni table de recherche de code ; il contient simplement ces nombres, organisés de façon à produire généralement des réponses utiles. Les faits que le modèle peut réciter grâce à l’entraînement, comme l’API d’une bibliothèque standard, sont des connaissances paramétriques : ils sont stockés dans les paramètres, et non récupérés ailleurs.

Le point à retenir est que les paramètres sont figés après l’entraînement. Rien de ce que vous faites au cours d’une session ne les modifie : ni vos corrections, ni le codebase que vous lui montrez, ni les erreurs dont il semble tirer une leçon. Chaque session repose sur les mêmes nombres. C’est pourquoi le modèle est stateless, pourquoi ses connaissances intégrées s’arrêtent à la date limite des connaissances et pourquoi les informations propres à un projet doivent lui parvenir par le contexte. Les paramètres ne changent qu’avec un nouvel entraînement, qui produit en pratique un modèle différent.

Exemple d’utilisation :

« Peut-on l’ajuster sur notre codebase ? »

« Cela modifierait les paramètres et produirait un modèle différent. Pour un seul projet, charger la codebase dans le contexte coûte presque toujours moins cher que de réentraîner le modèle. »

Le processus qui définit les paramètres d’un modèle en l’exposant à de très grandes quantités de texte et en ajustant ces paramètres pour améliorer la prédiction du prochain jeton. C’est un processus coûteux, effectué une fois par le fournisseur de modèle. Il comprend le préentraînement — la phase principale — et le post-entraînement — des affinements ultérieurs tels que le suivi des instructions et la sécurité. À l’échelle de ce glossaire, cette distinction n’est pas importante.

Le mécanisme repose sur la répétition à grande échelle : on présente un passage de texte au modèle, on lui fait prédire le jeton suivant, on ajuste ses paramètres vers le véritable jeton suivant, puis on répète l’opération sur des billions de jetons. Aucun fait ni aucune règle ne sont stockés comme tels. Tout ce que le modèle « sait » découle de son apprentissage de la prédiction et se trouve compressé dans ses paramètres sous forme de connaissances paramétriques.

Deux conséquences comptent au quotidien. L’entraînement s’arrête à une date donnée : le modèle a donc une date limite des connaissances et n’a pas vu la version de la bibliothèque que vous avez mise à jour le mois dernier. Et vous ne pouvez pas effectuer vous-même cet entraînement. Quand le modèle ne connaît pas votre codebase, vos conventions ou vos API internes, la solution n’est jamais de « lui apprendre » : il faut intégrer ces éléments au contexte, le seul paramètre d’entrée que vous contrôlez.

Exemple d’utilisation :

« Peut-on lui faire connaître notre API interne ? »

« Pas par l’entraînement : cela prendrait des mois et relève du fournisseur de modèle. Chargez plutôt la documentation de l’API dans le contexte ; c’est le levier que vous pouvez réellement actionner. »

Exécuter un modèle entraîné afin de générer une réponse — c’est ce qui se passe à chaque requête au fournisseur de modèle. Les paramètres restent fixes ; le modèle effectue simplement une prédiction du prochain jeton à partir du contexte qui lui est fourni. L’inférence coûte peu par rapport à l’entraînement, mais elle est facturée par jeton et constitue le principal coût d’utilisation d’un modèle.

La vie d’un modèle se divise en deux phases :

Rien de ce que vous faites au moment de l’inférence ne modifie les paramètres. C’est pourquoi une correction donnée aujourd’hui ne sera pas retenue demain. Si le modèle répète la même erreur à la session suivante après que vous avez soigneusement expliqué la correction, il ne vous a pas ignoré : il est incapable d’apprendre de cet échange. Le modèle est stateless ; la continuité doit venir de l’extérieur, de la fenêtre de contexte ou d’un système de mémoire.

Ce mécanisme explique aussi la facturation. Chaque requête exécute le modèle sur l’ensemble du contexte ; le coût dépend donc des jetons d’entrée et des jetons de sortie. Un agent qui effectue des dizaines d’appels d’outil paie l’inférence à chaque aller-retour. C’est pourquoi la taille du contexte est à la fois une question de coût et de qualité.

Exemple d’utilisation :

« Pourquoi la facture dépend-elle de l’utilisation au lieu d’être une licence à prix fixe ? »

« Vous payez l’inférence : chaque requête au fournisseur de modèle exécute le modèle sur le matériel du fournisseur. L’entraînement est déjà terminé, mais les coûts d’inférence s’accumulent à chaque requête ; un seul tour peut en déclencher beaucoup lorsque des outils sont appelés. »

L’effort est une molette qui règle la quantité de raisonnement effectuée par un modèle avant de répondre. Défini pour chaque requête au fournisseur de modèle, il détermine la longueur du raisonnement que le modèle développe avant de rédiger la réponse que vous voyez. Ce raisonnement est généré au moment de l’inférence, comme le reste ; le harness le masque souvent, mais il s’agit bien d’un travail effectué par le modèle.

Un effort élevé coûte plus cher et ralentit le traitement. Le raisonnement est émis sous forme de jetons, facturé comme des jetons de sortie même si vous ne le voyez jamais, et produit un jeton à la fois. Augmenter l’effort allonge donc l’attente avant la réponse et augmente la facture. Le compromis oppose réflexion, vitesse et coût.

La plupart des harnesses proposent une petite échelle d’effort :

Un mauvais réglage a des effets dans les deux sens. Si l’effort est trop faible pour un problème difficile, vous obtenez une réponse superficielle et assurée qui omet le raisonnement nécessaire : elle paraît correcte, mais une erreur vous coûtera plus tard. À l’inverse, régler l’effort au maximum pour renommer une seule ligne vous fait attendre une longue réflexion sans résultat différent de celui du réglage minimal.

Adaptez l’effort à la tâche, pas à la session. Augmentez-le pour les éléments qui exigent réellement un raisonnement difficile, puis réduisez-le pour les opérations routinières qui les entourent.

Exemple d’utilisation :

« Il rate sans cesse cette correction de concurrence ; je la lui ai réexpliquée trois fois. »

« Augmentez l’effort. Ce bug exige beaucoup de raisonnement et, avec le réglage par défaut, le modèle ne réfléchit pas assez longtemps avant de choisir une approche. »

L’unité atomique que le modèle lit et écrit. Sa taille correspond approximativement à celle d’un mot, mais pas exactement : les mots courants forment un jeton, tandis que les mots rares ou longs sont divisés en plusieurs. La taille de la fenêtre de contexte, le coût et la latence sont tous comptés en jetons.

Le texte est converti en jetons par un tokenizer : un vocabulaire fixe de dizaines de milliers de fragments, appris avant l’entraînement, qui découpe toute entrée en une séquence d’éléments du vocabulaire. Le modèle ne voit jamais de caractères ni de mots : chaque texte est converti en jetons à l’entrée et la prédiction du prochain jeton produit la réponse un jeton à la fois.

En règle générale, un jeton représente environ les trois quarts d’un mot anglais ; mille jetons correspondent donc à peu près à 750 mots. Le code est moins prévisible : les mots-clés et expressions courants sont tokenisés de façon compacte, tandis que les identifiants générés, les hachages, les chaînes base64 et le code minifié peuvent être divisés en de nombreux jetons par « mot ». Le principe est le suivant : le texte fréquent dans les données ayant servi au tokenizer reçoit des encodages courts et efficaces ; le texte absent de ces données est découpé en nombreux petits fragments. Un hachage comme `a3f9c2e1` n’est jamais apparu dans ces données et se divise donc en plusieurs jetons, tandis que `function` n’en forme qu’un. Voilà pourquoi un petit fichier rempli de chaînes inhabituelles peut occuper une part étonnamment importante de la fenêtre de contexte.

Les jetons sont l’unité de mesure de tout le reste. Le coût est calculé par jeton : les fournisseurs facturent séparément les jetons d’entrée et les jetons de sortie. La vitesse est exprimée en jetons par seconde, puisque la sortie est générée un jeton à la fois. Enfin, la fenêtre de contexte contient un nombre fixe de jetons : leur nombre détermine donc la quantité de vos fichiers qui peut y tenir.

À éviter : « mot » — les frontières entre jetons ne correspondent pas à celles des mots, et les unités qui comptent vraiment sont les jetons par seconde et les jetons par dollar.

Exemple d’utilisation :

« Quelle taille aura cette invite ? »

« Faites-la passer dans le tokenizer : le schéma est compact, mais les clés JSON sont inhabituelles et se diviseront en plus de jetons que prévu. »

Ce que fait réellement le modèle. À partir d’un contexte, il échantillonne un jeton suivant, l’ajoute et recommence. Toute sortie — phrase, appel d’outil ou fichier de mille lignes — est construite un jeton à la fois. Le modèle ne fonctionne pas autrement.

Chaque étape suit le même processus : les jetons de la fenêtre de contexte passent par les paramètres, qui attribuent une probabilité à chaque jeton du vocabulaire — celui-ci a de fortes chances de suivre, celui-là moins. Un jeton est échantillonné parmi ces probabilités, ajouté à la séquence, puis la boucle recommence avec un contexte légèrement plus long. Cette étape d’échantillonnage explique pourquoi la même invite produit des sorties différentes d’une exécution à l’autre : le non-déterminisme est inhérent au mécanisme, il ne s’agit pas d’un défaut ajouté par-dessus.

Comprendre ce mécanisme explique des comportements qui paraissent autrement étranges. Avant d’émettre un jeton, le modèle ne vérifie jamais s’il est vrai, seulement s’il est probable — c’est l’origine des hallucinations. Il s’engage sur chaque jeton au fur et à mesure ; une phrase d’ouverture formulée avec assurance peut donc orienter toute la suite dans la mauvaise direction. Enfin, comme les jetons de sortie sont produits strictement un par un, la vitesse de génération limite la vitesse à laquelle un agent peut travailler.

Exemple d’utilisation :

« Comment l’agent “décide-t-il” d’appeler un outil ? »

« Il ne décide pas : tout se ramène à la prédiction du prochain jeton. L’appel d’outil est simplement une chaîne structurée que le harness extrait du flux de sortie. »

Une même entrée peut produire des sorties différentes. Exécutez deux fois un modèle avec un contexte identique et il peut donner deux réponses différentes — parfois un mot change, parfois l’approche entière. Rien dans votre code n’a besoin de changer pour que cela se produise.

C’est une propriété de la génération de texte par les modèles et de la façon dont les fournisseurs de modèles traitent les requêtes. Pendant l’inférence, le modèle établit une distribution de probabilités sur les jetons suivants possibles, puis en échantillonne un. Une part d’aléatoire est généralement intentionnelle : toujours choisir le jeton le plus probable produit un texte répétitif et de moindre qualité. Un jeton échantillonné différemment au début d’une réponse modifie tous les jetons suivants ; c’est ainsi qu’un seul mot différent peut mener à une approche entièrement différente. Le traitement côté fournisseur ajoute d’autres variations : les requêtes sont regroupées sur du matériel partagé et de minuscules différences de calcul en virgule flottante entre groupes peuvent faire pencher un choix serré entre deux jetons. Aucun réglage ne permet d’éliminer tout cela.

Attendez-vous à des résultats variables d’un agent confronté à la même tâche. La plupart des réponses restent dans une courbe de qualité raisonnable — c’est ce qui rend le non-déterminisme tolérable — mais les écarts existent : certains jours, le modèle paraît vif ; d’autres, il semble avoir perdu le fil. Même tâche, résultats différents. Deux conséquences pratiques en découlent. Réessayer est une stratégie légitime : une tentative ratée n’est qu’un tirage de la distribution, et une nouvelle tentative peut simplement donner un meilleur résultat. La vérification est également plus importante qu’avec des outils déterministes : vous ne pouvez pas tester une fois le comportement d’un agent en comptant sur sa répétition exacte ; les vérifications automatisées doivent détecter les mauvais tirages.

Évitez de tirer des conclusions excessives. Les humains repèrent naturellement des motifs, et une série d’exécutions ratées peut donner l’impression que « le modèle est devenu moins bon cette semaine ». Il s’agit généralement simplement de la distribution.

Exemple d’utilisation :

« Claude a été mauvais toute la journée. Ont-ils publié une version moins bonne ? »

« Probablement pas : les sorties du modèle sont non déterministes. Il y aura de bonnes et de mauvaises journées pour la même tâche. Réessayez demain avant de chercher une cause. »

Ce qui fournit un service d’inférence à un modèle. Il s’agit généralement d’un service distant (Anthropic, OpenAI, Google), mais il peut aussi être local — Ollama, LM Studio ou llama.cpp exécuté sur votre machine. Le harness n’exécute pas le modèle lui-même ; il fait appel à un fournisseur pour cela.

Le fournisseur possède l’infrastructure : les paramètres résident sur son matériel et, à chaque requête au fournisseur de modèle, le harness lui envoie des jetons par le réseau et reçoit des prédictions en retour. Le fournisseur est ainsi à l’origine de toute une catégorie de problèmes souvent attribués à tort au modèle ou au harness : limites de débit, capacité dégradée et pannes. Quand l’agent se bloque au milieu d’une session ou échoue à chaque tour, il est préférable de consulter d’abord la page d’état du fournisseur.

Le fournisseur fixe aussi les conditions commerciales : prix par jeton pour les jetons d’entrée et les jetons de sortie, réductions liées au cache de préfixe et modèles disponibles. Le fournisseur et le créateur du modèle peuvent être des entreprises différentes : Bedrock, Vertex et OpenRouter proposent les modèles d’autres sociétés.

Les fournisseurs locaux échangent des capacités contre du contrôle : les modèles qui tiennent sur votre matériel sont bien plus petits que les modèles de pointe, mais rien ne quitte votre machine et aucun jeton n’est facturé.

Exemple d’utilisation :

« Peut-on exécuter cela hors ligne chez le client en environnement isolé ? »

« Remplacez le fournisseur de modèle par un fournisseur local — Ollama ou llama.cpp sur sa machine. Le harness s’en moque ; il envoie simplement les requêtes vers un autre point d’accès. »

Tout ce qui entoure le modèle et le transforme en agent : les outils, l’invite système, la gestion de la fenêtre de contexte, les autorisations et les hooks. Claude.ai et Claude Code utilisent le même modèle, mais se comportent différemment parce que leurs harnesses diffèrent.

Le modèle ne fait qu’une chose : recevoir du texte et produire du texte. Il ne peut ni lire un fichier, ni exécuter une commande, ni se souvenir du tour précédent. Le harness fournit tout cela. Il assemble le contexte de chaque requête au fournisseur de modèle, exécute les appels d’outil demandés par le modèle, lui renvoie les résultats d’outil, conserve l’historique de la session, vous demande l’autorisation avant les actions risquées et décide du moment où il faut faire une compaction. La boucle de l’agent — le modèle propose, le harness exécute, puis le cycle recommence — est orchestrée par le harness.

C’est important pour diagnostiquer les problèmes. Quand le comportement diffère entre deux produits ou entre hier et aujourd’hui, le modèle n’est souvent pas la variable : c’est le harness. Une invite système différente, un autre ensemble d’outils, une autorisation par défaut modifiée ou une nouvelle stratégie de gestion du contexte changent tous le comportement sans modifier le modèle. Cela signifie aussi que l’essentiel de votre configuration se trouve dans le harness : les fichiers AGENTS.md, les paramètres d’autorisation et les hooks lui donnent des instructions, pas au modèle.

Exemples : Claude Code, Cursor, Codex CLI et Claude.ai, qui est un harness de discussion plutôt qu’un harness de codage.

Exemple d’utilisation :

« Même modèle : pourquoi Claude Code modifie-t-il des fichiers alors que Claude.ai se contente de répondre aux questions ? »

« Les harnesses diffèrent : Claude Code dispose d’outils de système de fichiers, d’une autre invite système et d’une couche d’autorisations. Le modèle n’est pas la variable ici. »

Un aller-retour entre le harness et le fournisseur de modèle. Le harness envoie le contexte actuel ; le fournisseur renvoie une réponse — un appel d’outil ou une réponse finale. Un seul message de l’utilisateur peut déclencher de nombreuses requêtes au fournisseur de modèle si l’agent appelle des outils : chaque résultat d’outil déclenche une nouvelle requête.

Chaque requête transporte tout : l’invite système, l’intégralité de la conversation jusque-là et chaque résultat d’outil. Le modèle est stateless ; le fournisseur ne conserve donc rien d’une requête à l’autre. La requête quarante renvoie ce que contenait la requête trente-neuf, plus un résultat d’outil. Le cache de préfixe sert à rendre cette répétition abordable.

La requête est aussi l’unité de facturation. Les jetons d’entrée, les jetons de sortie et les réductions liées au cache sont tous comptés par requête. Voilà pourquoi une question qui paraît anodine peut coûter étonnamment cher : le coût n’est pas proportionnel à votre message, mais au nombre de requêtes multiplié par la taille du contexte transporté par chacune.

Il convient de distinguer la requête du tour. Un tour est un échange avec vous ; un seul tour — « corrige le test qui échoue » — peut se dérouler en chaîne de requêtes :

Six requêtes pour un seul tour — chacune renvoie tout le contexte. Si vous vous demandez où sont passés les jetons, comptez les requêtes, pas les tours.

Exemple d’utilisation :

« Une question a consommé quarante mille jetons ? »

« Regardez les appels d’outil : douze grep, huit lectures, quatre modifications. Chaque résultat d’outil déclenche une nouvelle requête au fournisseur de modèle, qui renvoie à chaque fois tout le préfixe de la session. »

Les jetons envoyés par le harness à chaque requête au fournisseur de modèle : l’invite système, l’historique de la conversation, les résultats d’outil, tout ce que le modèle lit avant d’écrire. Ils sont facturés à un tarif inférieur aux jetons de sortie, car ils coûtent moins cher à traiter.

Pour le codage par IA, les jetons d’entrée représentent la majeure partie de la facture. Le modèle est stateless, donc chaque tour renvoie toute la session sous forme d’entrée : votre premier message, chaque réponse et chaque résultat d’outil depuis. L’entrée du cinquantième tour contient les quarante-neuf tours précédents. Une seule requête au fournisseur de modèle peut produire quelques centaines de jetons de sortie tout en renvoyant cent mille jetons d’entrée d’historique accumulé.

Le cache de préfixe réduit le coût : l’historique identique à celui d’une requête antérieure est facturé comme des jetons de cache bon marché plutôt qu’au tarif plein des jetons d’entrée. Si les coûts d’entrée restent élevés, réduisez ce qui est renvoyé : faites un effacement ou une compaction entre les tâches.

Exemple d’utilisation :

« La facture est élevée alors que l’agent écrit à peine. »

« Ce sont les jetons d’entrée : chaque tour renvoie toute la session. Sans le cache de préfixe, vous paieriez de nouveau l’historique à chaque requête. »

Les jetons générés par le modèle. Ils sont facturés à un tarif supérieur aux jetons d’entrée — souvent environ cinq fois plus cher — car leur production demande davantage de calcul.

Tout ce que le modèle écrit compte : le texte que vous lisez, le code qu’il produit, les appels d’outil et le raisonnement approfondi qu’il effectue avant de répondre. Ce dernier surprend souvent : les jetons de raisonnement sont facturés comme des jetons de sortie même lorsque le harness ne les affiche généralement pas ; augmenter l’effort en consomme davantage.

Les jetons de sortie déterminent également le rythme d’une session. Le modèle lit rapidement les entrées, mais génère sa sortie un jeton à la fois. Lorsqu’un tour paraît lent, c’est presque toujours parce que la sortie est en cours d’écriture, et non parce que l’entrée est lue. Une longue attente annonce généralement une longue réponse.

Exemple d’utilisation :

« La session de refactorisation consomme tout mon crédit alors que les entrées sont petites. »

« L’agent réécrit des fichiers entiers au lieu de produire des modifications ciblées. Les jetons de sortie coûtent environ cinq fois plus que les jetons d’entrée : faites-lui émettre des modifications et la facture baissera. »

Le stockage côté fournisseur qui permet aux requêtes au fournisseur de modèle successives d’éviter de retraiter un préfixe commun. Lorsque le début d’une requête correspond au début d’une requête récente — même invite système, même historique jusqu’à un certain point — le fournisseur réutilise le travail précédent et facture ces jetons comme des jetons de cache, à un tarif bien inférieur.

Le cache est utile parce que les sessions grandissent par ajout. Chaque requête renvoie tout l’historique sous forme de jetons d’entrée (voir cette entrée pour en comprendre la raison), et, dans une session normale, l’historique ne change qu’à la fin : chaque requête reprend la précédente et y ajoute quelques nouveaux messages. Le fournisseur traite une fois le long début commun, en stocke le résultat, puis poursuit à partir de la fin du préfixe. Sans cache, une session de 50 tours paierait le retraitement du premier tour cinquante fois.

Les caches expirent également. La durée de validité d’une entrée varie selon le fournisseur de modèles — généralement quelques minutes, et non plusieurs heures. Si vous laissez une session inactive au-delà de cette fenêtre, la requête suivante reconstruit une fois le préfixe au tarif complet, puis le cache reprend. Cela concerne surtout les créateurs de harness ; en tant qu’utilisateur, vous constaterez simplement que les requêtes suivant une longue pause coûtent plus cher que les précédentes.

Exemple d’utilisation :

« Pourquoi la facture a-t-elle augmenté en plein milieu de la session ? »

« Le harness a commencé à insérer l’heure actuelle dans l’invite système à chaque tour. Le cache de préfixe cesse de correspondre dès le premier jeton modifié ; toutes les requêtes suivantes ont donc été facturées au tarif complet. »

Les jetons d’entrée que le fournisseur a conservés en cache depuis une précédente requête au fournisseur de modèle, afin de ne pas avoir à les traiter de nouveau. Lorsque des requêtes consécutives partagent un préfixe, le fournisseur réutilise le travail grâce à son cache de préfixe et facture la partie mise en cache à un tarif bien inférieur. C’est ce qui rend abordables les longues sessions : sans cela, chaque tour ferait payer de nouveau tout l’historique.

Cela compte en raison du mode de facturation des sessions. Le modèle est stateless ; chaque requête renvoie donc toute la conversation — l’invite système, chaque message, chaque résultat d’outil — sous forme de jetons d’entrée. Au cinquantième tour, chaque requête contient l’historique des cinquante tours et vous paieriez le tarif plein sur l’ensemble, à chaque fois. Le cache change le calcul : les jetons déjà traités par le fournisseur dans un préfixe identique sont facturés comme jetons de cache, souvent à un dixième du tarif d’entrée ou moins. Au cours d’une longue session, la majeure partie du contenu envoyé est mise en cache et la facture reste raisonnable.

Cet exemple montre quels jetons sont mis en cache : chaque lettre représente un bloc de conversation et chaque requête renvoie tout l’historique jusque-là.

Le cache est fragile d’une façon précise : il compare des préfixes exacts. Si un élément antérieur de la conversation change — le harness réordonne le contenu, un horodatage est mis à jour, la représentation d’un fichier varie —, le cache cesse de correspondre à partir de ce point et tout le reste est facturé au tarif plein des jetons d’entrée. Les caches expirent également après quelques minutes d’inactivité ; si une session reprend après une longue pause, son historique est facturé une fois de nouveau. Quand le coût d’une session augmente sans raison évidente, comparez les jetons de cache aux jetons d’entrée dans le rapport d’utilisation : une rupture du cache y apparaît en premier.

Exemple d’utilisation :

« Les longues sessions coûtent une fortune — huit dollars pour une refactorisation. »

« Vérifiez les jetons de cache. Si le harness réordonne l’invite système ou les fichiers entre les tours, le préfixe change et chaque requête est facturée au tarif plein des jetons d’entrée. »

Ne transmet aucune information. Le modèle est sans état entre les requêtes au fournisseur de modèle : chaque requête renvoie la totalité de la fenêtre de contexte, car le modèle ne peut rien voir d’autre. Par défaut, un agent est sans état entre les sessions : une nouvelle session commence à vide, sans aucune trace des précédentes. C’est le contraire de stateful.

Le modèle lui-même est définitivement sans état : ses paramètres sont figés après l’entraînement, et rien de ce que vous faites à l’inférence ne les modifie. Le modèle n’apprend pas de vos corrections, ne se souvient pas qu’on lui a déjà dit la même chose hier et ne fait pas votre connaissance — même si la conversation donne cette impression. La continuité ressentie au cours d’une session est fabriquée par le harness, qui conserve la transcription et la renvoie à chaque requête. Le modèle ne se souvient pas de la conversation : il la relit.

Conséquence pratique : si vous voulez qu’un élément soit retenu d’une session à l’autre, vous devez l’écrire quelque part où l’agent pourra le relire. C’est le rôle des fichiers AGENTS.md, des systèmes de mémoire et des artefacts de transfert : ce sont des fichiers chargés dans le contexte des sessions futures, qui tiennent lieu de mémoire au modèle. Quand l’agent répète une erreur que vous avez déjà corrigée, la question n’est pas de savoir pourquoi il n’a pas appris — il ne le peut pas — mais où consigner cette correction pour que chaque session future la lise.

Exemple d’utilisation :

« Pourquoi oublie-t-il la convention chaque fois que je fais un effacement ? »

« Le modèle est sans état : la nouvelle session commence à vide. Si vous voulez conserver cette information, consignez-la dans AGENTS.md ou dans un fichier mémoire que le harness charge au démarrage de la session. »

Les informations pertinentes auxquelles l’agent a accès à l’instant présent. C’est un nom abstrait : il ne désigne ni l’entrée brute vue par le modèle — c’est la fenêtre de contexte — ni l’historique en cours — c’est la session — mais ce que l’agent sait et qui est pertinent pour la tâche. « Charger quelque chose dans le contexte » signifie l’ajouter à cet ensemble ; l’« ingénierie du contexte » consiste à le sélectionner et à le gérer.

Les trois termes se distinguent clairement :

Cette distinction compte, car le contexte mesure la qualité, pas la quantité. Une fenêtre de contexte presque pleine peut contenir un contexte médiocre : des milliers de jetons de résultats d’outil périmés, sans rapport avec la tâche actuelle. À l’inverse, une fenêtre presque vide peut offrir un excellent contexte : la seule définition de type dont dépend la tâche.

La plupart des échecs quotidiens remontent au contexte. Quand l’agent invente une API, contredit une décision ou devine un schéma, demandez d’abord ce qui se trouvait dans son contexte à ce moment-là. Généralement, le fait pertinent n’a jamais été chargé ou était enfoui sous la dégradation de l’attention. La solution consiste à sélectionner le contexte : charger ce dont la tâche a besoin et écarter le reste.

Exemple d’utilisation :

« Il invente sans cesse des champs qui ne figurent pas dans le type. »

« Le fichier de type ne fait pas partie du contexte ; il lit les sites d’appel et devine. Chargez d’abord la définition. »

Tout ce que le modèle voit à chaque requête au fournisseur de modèle. Cette fenêtre est limitée, propre au modèle et constitue la seule surface par laquelle le modèle perçoit quoi que ce soit.

Il s’agit d’une seule séquence de jetons : l’invite système, la conversation jusque-là et chaque résultat d’outil renvoyé par le harness. Si un élément figure dans cette séquence, le modèle peut l’utiliser ; sinon, il ignore son existence — votre codebase, le fichier modifié hier ou la consigne donnée trois sessions plus tôt. Tout ce qui se trouve hors de la fenêtre doit y être apporté, généralement au moyen d’un appel d’outil, avant de pouvoir influencer quoi que ce soit.

La fenêtre étant limitée, elle finit par se remplir. Chaque tour y ajoute vos messages, les réponses du modèle et les résultats d’outil ; une longue session atteint donc tôt ou tard la limite, ce qui impose une compaction ou un effacement. Cela signifie également que tout ce qui se trouve dans la fenêtre entre en concurrence : chaque jeton chargé en laisse un de moins pour le reste, et le contenu inutile occupe malgré tout l’attention du modèle. En pratique, traitez la fenêtre comme un budget : chargez ce dont la tâche a besoin et laissez le reste de côté.

À éviter : « mémoire » — la fenêtre de contexte est un état de travail qui ne persiste pas entre les sessions. La mémoire est un concept distinct qui s’y ajoute.

Exemple d’utilisation :

« Puis-je simplement coller tout le monorepo dans l’invite ? »

« La fenêtre de contexte contient 200 000 jetons, soit peut-être un cinquième du dépôt. Choisissez les fichiers concernés par la tâche et laissez les autres accessibles par un appel d’outil. »

Transmet des informations vers l’avenir. Une session conserve son état d’un tour à l’autre : le contexte s’accumule au fil de la session, ce qui explique pourquoi les longues sessions dérivent vers la zone stupide. Un agent peut conserver son état entre plusieurs sessions grâce à un système de mémoire qui enregistre des informations dans l’environnement et les recharge au début des sessions suivantes. Le modèle, lui, n’a jamais d’état persistant ; toute continuité apparente vient du harness qui lui retransmet le contexte. Le pendant de sans état.

Où se trouve l’état à chaque niveau :

L’état de chaque niveau est créé en relisant un élément stocké au niveau inférieur : la session semble continue parce que le harness renvoie l’historique des messages au modèle sans état ; l’agent se souvient d’une session à l’autre parce que le harness recharge les fichiers depuis l’environnement. Aucun état n’est jamais stocké dans le modèle lui-même.

La persistance de l’état n’est pas toujours souhaitable. Tout ce qui est transmis influence la suite, donc une mauvaise hypothèse formulée au début d’une session est également conservée. L’effacement consiste délibérément à jeter l’état de la session et à repartir de ce qui a été consigné.

Exemple d’utilisation :

« Il se souvenait de mes préférences d’hier — cela veut-il dire que le modèle les a apprises ? »

« Non, l’agent conserve son état parce que le harness a écrit ces informations dans un fichier mémoire et l’a rechargé au début de la session. Le modèle lui-même n’a rien vu d’hier. »

Un modèle orchestré avec des outils, une invite système et une fenêtre de contexte, qui échange des tours avec un utilisateur. Claude Code est un agent. Cursor est un agent. Claude.ai est un agent. Un agent, c’est ce à qui vous parlez réellement : le modèle en action, configuré pour un objectif.

Contrairement à la plupart des termes de ce dictionnaire, « agent » ne désigne pas une pièce mécanique. Le modèle est un fichier de paramètres ; le harness est un logiciel que l’on peut désigner. L’agent n’est ni l’un ni l’autre : c’est l’entité à laquelle vous vous adressez. Les gens anthropomorphisent sans cesse l’IA, et l’agent est l’entité ainsi anthropomorphisée : celle à qui vous déléguez, qui lit votre message et répond, le « il » dans « il a encore cassé la compilation ». Quand vous dites que l’agent a fait quelque chose, vous voulez dire que le modèle et son harness l’ont fait, mais vous vous adressez à cette combinaison comme à un seul acteur.

L’idée est plus ancienne que cette vague d’IA. Les agents logiciels — des programmes auxquels on délègue un objectif et qui agissent pour notre compte — sont un concept aussi ancien que l’IA.

À éviter : « l’IA », « le bot » (trop vague : ces termes ne permettent pas de savoir si vous parlez des paramètres ou de leur orchestration).

Exemple d’utilisation :

« Quel agent utilises-tu pour la migration ? »

« Claude Code en local, Cursor pour l’interface — le même modèle sous-jacent, des harnesses différents. »

Les instructions que le harness ajoute au début de chaque requête au fournisseur de modèle — le brief permanent de l’agent : qui il est, comment il doit se comporter, quels outils il peut appeler et quelles conventions suivre. Elles restent généralement stables pendant toute une session.

L’invite système est écrite par le fournisseur du harness, pas par vous ; dans les harnesses de codage, elle est volumineuse — souvent des dizaines de milliers de jetons de règles de comportement, de descriptions d’outils et de gestion des cas particuliers, tous facturés comme jetons d’entrée à chaque tour. Vos propres instructions permanentes s’y ajoutent : les fichiers comme AGENTS.md sont chargés à côté de l’invite système au début de la session. Le modèle lit donc le brief du fournisseur et le vôtre avant même de voir votre message.

Comme elle reste identique d’une requête à l’autre, l’invite système forme le début du cache de préfixe. C’est l’une des raisons pour lesquelles les harnesses la conservent pendant toute une session au lieu de la modifier au fil du travail.

Les modèles sont entraînés à donner la priorité à l’invite système sur les messages de l’utilisateur. Ainsi, lorsqu’un agent insiste sur une convention que vous n’avez jamais demandée, ou impose un format de sortie impossible à changer, il obéit généralement à son invite système et votre message perd la confrontation. Certains harnesses sont personnalisables : ils donnent un accès complet à l’invite système, afin que vous puissiez lire ce que l’agent reçoit réellement et le modifier.

Exemple d’utilisation :

« Deux harnesses, le même modèle, mais un comportement totalement différent avec la même invite. »

« Les invites système diffèrent. L’une est réglée pour effectuer des modifications de code concises, l’autre pour expliquer : la différence commence là, avant même l’arrivée de votre message. »

Une séquence d’interaction limitée avec un agent. Elle commence à vide, accumule les messages, les résultats d’outil et les fichiers lus, puis prend fin quand elle est effacée, fermée ou compactée dans une nouvelle session. C’est la session qui remplit la fenêtre de contexte : si la fenêtre est une boîte, la session est ce qui la remplit peu à peu. Un travail trop volumineux pour une seule fenêtre doit être réparti entre plusieurs sessions.

L’historique des messages de la session constitue la mémoire de travail de l’agent. Le modèle est stateless ; tout ce dont il semble se souvenir — votre demande, les résultats des tests, sa décision d’il y a trois tours — se trouve dans l’historique des messages, renvoyé à chaque requête au fournisseur de modèle. Tout ce qui ne figure pas dans la session n’existe pas pour l’agent.

Cette mémoire disparaît avec la session. Une nouvelle session repart de rien : l’agent qui connaissait bien votre codebase à la fin de la veille n’en sait plus rien le lendemain matin. Ce qui subsiste, c’est le système de fichiers : les fichiers écrits au cours d’une session peuvent être lus par la suivante. C’est sur ce principe que reposent les transferts, les systèmes de mémoire et les fichiers AGENTS.md.

C’est vous qui choisissez quand une session se termine. Tout ce qu’elle contient influence les tours suivants ; les tâches sans rapport effectuées dans la même session laissent donc des résidus qui orientent la réponse suivante. Une tâche par session permet de garder un contexte pertinent ; la fin d’une tâche est un bon moment pour faire un effacement.

Exemple d’utilisation :

« Combien de temps une session peut-elle durer avant de se dégrader ? »

« Cela dépend du travail : une refactorisation ciblée reste nette plus longtemps qu’une recherche sans limites. Quand la session enfle, faites un transfert ou une compaction ; ne forcez pas la poursuite. »

Un message de l’utilisateur, plus tout ce que fait l’agent en réponse, jusqu’à ce qu’il vous rende la main. Un tour contient une ou plusieurs requêtes au fournisseur de modèle — plusieurs si l’agent appelle des outils. Une question de clarification clôt le tour ; votre réponse ouvre le suivant. La hiérarchie est : session > Tour > Requête au fournisseur de modèle.

Le tour mérite un nom parce que sa durée dépend de la décision de l’agent, pas de la vôtre. Vous lui confiez un message ; il décide du nombre d’appels d’outil à enchaîner avant de vous rendre la main. Un tour peut durer une phrase ou vingt minutes de lecture, de modifications et de tests. Cette propriété a deux aspects : les tours longs permettent le travail AFK, mais c’est aussi pendant ces longues périodes sans supervision que les choses peuvent mal tourner. Lorsque l’agent vous rend la main, il peut s’être éloigné de ce que vous vouliez.

Le tour est aussi l’unité naturelle pour orienter le travail. Tout ce qui se déroule à l’intérieur d’un tour se passe sans vous ; vous pouvez réorienter l’agent entre deux tours. La plupart des harnesses atténuent cette contrainte : vous pouvez interrompre l’agent en cours de tour pour l’arrêter et le réorienter, ou lui envoyer un message pendant qu’il travaille, qu’il lira à la fin du tour. Si vous êtes souvent déçu par le résultat des tours, demandez généralement des tours plus courts — un plan d’abord, puis une étape à la fois — au prix d’une autonomie moindre, mais avec des occasions plus fréquentes de réorienter le travail.

Exemple d’utilisation :

« Un tour a duré deux minutes ? »

« Il a effectué quatorze appels d’outil pendant ce tour — chacun correspond à une requête distincte au fournisseur de modèle. La latence s’accumule avant que l’agent ne vous rende enfin la main. »

Le monde sur lequel agit l’agent : tout ce qui se trouve hors du harness, que l’agent perçoit au moyen des résultats d’outil et modifie au moyen des appels d’outil. Le harness exécute l’agent ; l’environnement est ce dans quoi l’agent travaille. Un fichier comme `AGENTS.md` réside dans l’environnement ; c’est le harness qui le charge dans la fenêtre de contexte. Le système de fichiers est le type d’environnement le plus courant, mais ce n’est pas le seul : une base de données, une API distante ou une session de navigateur peuvent également constituer des environnements.

L’agent ne voit l’environnement que lorsqu’il le consulte. Tout ce qu’il sait de cet environnement lui est parvenu par un résultat d’outil ; sa représentation est donc une collection d’instantanés, chacun exact au moment où il a été pris. Si un fichier change après sa lecture — vous le modifiez à la main ou une étape de compilation le régénère — l’agent continue de raisonner à partir de sa copie périmée jusqu’à ce qu’un événement l’incite à le relire. Quand un agent décrit avec assurance un fichier qui ne ressemble plus à cela, c’est généralement ce qui s’est passé : l’environnement a changé, pas l’instantané.

L’environnement est aussi la couche qui persiste : la seule qui soit toujours stateful. Le contexte d’une session disparaît à la fin de celle-ci, mais les fichiers écrits dans l’environnement restent accessibles à la suivante. C’est sur cela que reposent les systèmes de mémoire, les artefacts de transfert et les fichiers `AGENTS.md`. Tout ce que l’agent doit encore savoir demain doit se trouver dans l’environnement.

C’est vous qui déterminez la taille de l’environnement. Un bac à sable le réduit en limitant ce à quoi l’agent peut accéder ; l’ajout d’un outil l’étend en rendant une base de données ou une API accessible. Le contenu situé dans les limites est ce que l’agent peut percevoir et modifier ; tout ce qui se trouve au-delà n’existe pas pour lui. La qualité de la configuration de l’environnement au service de l’agent constitue l’AX de la codebase.

À éviter : employer « environnement » pour désigner l’exécution ou le harness lui-même : le harness est l’enveloppe, l’environnement est l’espace de travail.

Exemple d’utilisation :

« L’agent ne voit pas le schéma de la base de données de staging. »

« Ajoutez-le à l’environnement : donnez-lui un outil `psql` en lecture seule sur staging. Le harness fonctionne bien, il n’a simplement rien sur quoi agir. »

Un arbre de fichiers et de répertoires que l’agent lit, modifie et dans lequel il exécute ses actions : le type d’environnement par défaut d’un agent de codage. AGENTS.md, les compétences, le code source, les scripts de compilation et les configurations d’outil résident dans un système de fichiers. Lorsqu’un harness « démarre dans votre projet », il oriente l’agent vers un système de fichiers.

L’agent n’y accède que par des appels d’outil : lire un fichier, en écrire un ou exécuter une commande shell. Rien sur le disque n’entre dans la fenêtre de contexte tant qu’un appel d’outil ne le charge pas. C’est ce qui permet à l’agent de travailler dans un dépôt bien plus vaste que cette fenêtre : le système de fichiers contient tout, tandis que le contexte ne contient que ce que la tâche en cours lui a fait lire. Certains harnesses chargent par défaut dans la fenêtre de contexte les noms des fichiers du répertoire courant — pas leur contenu, seulement l’arborescence — qui sert alors de pointeurs de contexte : l’agent voit ce qui existe et lit les fichiers dont il a besoin.

Et ce système est partagé avec vous. Les fichiers modifiés par l’agent sont les mêmes que ceux que vous ouvrez dans votre éditeur et consultez dans le diff Git : le système de fichiers est l’espace de travail commun où vous examinez ce que l’agent a fait.

Exemple d’utilisation :

« Pourquoi ne trouve-t-il pas mon AGENTS.md ? »

« Il utilise un autre système de fichiers : le bac à sable a monté le répertoire parent, pas la racine du projet. Réorientez le harness. »

Une fonction que le harness met à la disposition de l’agent : Read, Write, Bash, Search. Les outils permettent à un agent de percevoir l’environnement et d’agir sur lui : il ne peut pas voir l’environnement autrement que par les résultats d’outil, ni le modifier autrement que par les appels d’outil. Chaque appel d’outil coûte une requête supplémentaire au fournisseur de modèle, car le résultat doit revenir au modèle avant qu’il puisse décider de la suite.

Les outils fournis par la plupart des agents de codage :

Un outil est défini par trois éléments : un nom, une description de sa fonction et un schéma de paramètres. À chaque requête, le harness transmet ces définitions au modèle, qui choisit un outil comme il produit tout le reste — en écrivant des jetons, ici un appel structuré avec des arguments. Le modèle n’exécute jamais rien lui-même ; le harness lit l’appel, exécute la fonction et renvoie le résultat.

La liste des outils détermine ce que l’agent peut faire. Un modèle capable avec un jeu d’outils étroit reste un agent limité : il fera tout passer par ce qu’il a, d’où la forte dépendance des agents à Bash — un seul outil shell donne accès à la majeure partie du système. Pour donner proprement une capacité à un agent, ajoutez-lui un outil ; MCP est la norme pour connecter des outils provenant de l’extérieur du harness.

Les définitions d’outils occupent du contexte à chaque requête : un grand jeu d’outils a donc un coût permanent avant même qu’un outil soit appelé, et de nombreux outils décrits de façon similaire rendent le modèle moins apte à choisir le bon.

Exemple d’utilisation :

« L’agent peut-il interroger directement l’environnement de préproduction ? »

« Ajoute un outil `psql` au harness, limité à la lecture sur l’environnement de préproduction. Sans outil dédié, l’agent ne voit rien en dehors du système de fichiers. »

La réponse du modèle qui désigne un outil et ses arguments — rien de plus qu’un texte structuré. Elle n’effectue aucune action par elle-même ; le harness doit la lire et l’exécuter. Le modèle la produit au cours d’une requête au fournisseur de modèle.

Cycle de vie d’un appel d’outil :

Un tour de travail d’un agent comporte généralement plusieurs de ces allers-retours enchaînés.

Comme l’appel est généré par prédiction du prochain jeton, comme toute autre sortie, il peut être erroné : chemin inexistant, option inconnue de la commande, arguments plausibles mais incorrects. Le harness exécute ce qui a été écrit, pas ce qui était voulu ; un chemin mal saisi ne provoque pas nécessairement une erreur maîtrisée, il peut modifier le mauvais fichier.

Exemple d’utilisation :

« Il a dit avoir lancé les tests, mais les horodatages des fichiers n’ont pas changé. »

« Consultez la transcription : a-t-il réellement émis un appel d’outil, ou s’est-il contenté de décrire l’exécution ? Le modèle produit l’appel, mais si le harness ne l’a pas exécuté, rien ne s’est passé. »

Ce que le harness renvoie après l’exécution d’un appel d’outil : le contenu d’un fichier, la sortie d’une commande ou l’erreur. C’est la seule vue qu’a l’agent de l’environnement. Le résultat revient au modèle dans la requête au fournisseur de modèle suivante, où il décide quoi en faire. L’appel d’outil et le résultat d’outil sont les deux extrémités du même échange, toutes deux comprises dans un tour.

Cycle de vie d’un résultat d’outil :

Le résultat reste dans le contexte pour le reste de la session. Les résultats d’outil constituent généralement la majeure partie du contexte d’une session de codage : chaque fichier lu, chaque test exécuté et chaque recherche y est ajouté intégralement, puis continue d’occuper des jetons longtemps après avoir cessé d’être utile. Quelques résultats volumineux — journal de test verbeux ou fichier généré lu en entier — peuvent rapprocher une session de la limite de la fenêtre de contexte plus vite que la conversation elle-même.

Comme le résultat est tout ce que le modèle voit, celui-ci ne peut pas vérifier l’environnement derrière ce résultat. Si la sortie a été tronquée, si la commande a échoué silencieusement ou si le harness a renvoyé une erreur à la place du contenu, le modèle raisonne à partir de ce qui lui a été fourni. Quand sa représentation de votre système paraît fausse, examinez les résultats d’outil : quelque part dans la transcription, l’un d’eux contredit ce que vous savez être vrai.

Exemple d’utilisation :

« Il raisonne comme si le fichier était vide. »

« Le résultat d’outil indiquait un refus d’autorisation, pas le contenu. Le modèle n’a vu que le texte de l’erreur ; il n’a aucun autre moyen de voir le fichier. »

Model Context Protocol. Un protocole permettant de connecter des serveurs d’outils externes à un harness : il permet à un agent d’obtenir des outils supplémentaires par rapport à ceux fournis par le harness. L’agent ne « fait jamais un appel MCP » ; il appelle un outil, et le harness se trouve simplement avoir obtenu cet outil auprès d’un serveur MCP. Le protocole expose aussi des ressources (données en lecture seule) et des invites (modèles réutilisables), mais la mise à disposition d’outils reste son usage principal.

Le protocole résout un problème d’intégration. Sans norme, chaque harness devrait avoir sa propre intégration Linear, sa propre intégration Slack, sa propre intégration de base de données, chacune écrite et maintenue séparément. Avec MCP, l’intégration est écrite une seule fois sous forme de serveur, et tout harness compatible MCP peut l’utiliser. Le harness se connecte au serveur, le serveur annonce les outils qu’il propose, et ces outils deviennent accessibles à l’agent aux côtés des outils intégrés.

Le coût se paie en contexte. Chaque outil annoncé par un serveur arrive sous forme de définition — nom, description, schéma des paramètres — et le modèle ne peut appeler que les outils qu’il connaît. L’approche naïve charge d’emblée toutes les définitions dans la fenêtre de contexte : installez quelques serveurs généreux et une session commence avec des milliers de jetons de schémas d’outils avant même que vous ayez saisi quoi que ce soit, dépensant le budget d’attention pour des outils dont la tâche n’aura jamais besoin.

De nombreux harnesses atténuent désormais ce problème avec la recherche d’outils : au lieu de charger toutes les définitions, le contexte contient un pointeur de contexte vers les outils disponibles ; l’agent recherche un outil par son nom ou son objectif et ne charge sa définition qu’au moment où il en a besoin. Si votre harness ne le fait pas, le coût initial s’applique toujours, et il vaut mieux n’activer que les serveurs réellement nécessaires au projet.

Exemple d’utilisation :

« L’agent doit lire des tickets dans Linear. »

« Configure le harness pour utiliser le serveur MCP de Linear — il expose l’API Linear sous forme d’outils que l’agent peut appeler. Cela évite d’écrire des wrappers d’outils personnalisés. »

Ce que le harness affiche à l’utilisateur avant d’exécuter un appel d’outil qui n’a pas été préapprouvé. Le modèle produit un appel d’outil, mais au lieu de l’exécuter immédiatement, le harness s’arrête et demande l’autorisation. S’il est approuvé, l’appel s’exécute ; s’il est refusé, le harness renvoie le refus au modèle sous forme de résultat d’outil. C’est le mécanisme qui permet au harness de faire intervenir un humain dans la boucle pour les actions risquées ou sensibles.

Cycle de vie d’une demande d’autorisation :

Refuser une demande permet d’orienter l’agent. Le modèle lit le refus comme n’importe quel résultat d’outil et y réagit : il essaie une autre approche ou demande ce que vous préférez. La plupart des harnesses permettent d’ajouter un message au refus ; la demande devient alors un point d’orientation : « pas comme ça, utilisez plutôt le script de migration » arrive au moment précis où le modèle décide quoi faire ensuite.

Le coût est que chaque demande vous impose une attente synchrone. L’agent reste bloqué jusqu’à votre réponse. Cela convient lorsque vous surveillez le travail, mais devient problématique lorsque vous êtes absent : un agent qui déclenche sans cesse des demandes ne peut pas travailler en AFK. Le mode d’autorisation règle quels appels s’exécutent librement et lesquels demandent une approbation ; idéalement, un bac à sable permet d’élargir sans danger l’ensemble des actions autorisées.

Exemple d’utilisation :

« Il attend une autorisation depuis dix minutes ; j’étais en réunion. »

« C’est le coût d’un humain dans la boucle. Préapprouvez les outils sûrs afin que la demande ne se déclenche que pour les appels réellement risqués. »

La partie d’un mode d’agent qui régit les autorisations : quels appels d’outil déclenchent une demande d’autorisation et lesquels s’exécutent automatiquement. C’était l’objectif initial des systèmes de modes, avant que les harnesses n’y ajoutent des instructions de comportement.

Les harnesses proposent plusieurs niveaux de modes :

Choisir un niveau revient à arbitrer entre sécurité et interruptions, et les deux excès se font sentir. Des restrictions trop strictes font de vous un goulot d’étranglement : l’agent s’arrête toutes les quelques secondes pour des lectures inoffensives, vous approuvez machinalement et les approbations perdent tout leur sens. Valider sans réfléchir est le pire des deux mondes : toutes les interruptions, sans aucune protection. Des restrictions trop lâches laissent l’agent modifier des fichiers et exécuter des commandes que vous auriez voulu examiner d’abord.

Le mode permissif se défend surtout dans un bac à sable, où l’impact d’un mauvais appel d’outil est limité. En dehors d’un bac à sable, la plupart des gens autorisent automatiquement les lectures tout en gardant un humain dans la boucle pour toute action irréversible.

Exemple d’utilisation :

« Il s’est arrêté à chaque grep : l’exécution AFK a été complètement gâchée. »

« Assouplissez le mode d’autorisation pour les outils en lecture seule, mais gardez une demande d’autorisation pour les écritures et le shell. La plupart des demandes d’autorisation pendant une session de recherche ne sont que du bruit. »

Un préréglage qui détermine le comportement de l’agent à l’exécution : il associe un mode d’autorisation à des consignes de comportement injectées dans l’invite système. Exemples : réglage par défaut qui demande confirmation pour les appels risqués, mode planification qui bloque les modifications et oriente l’agent vers la recherche, mode acceptation des modifications qui les approuve automatiquement, mode contournement des autorisations (familièrement mode YOLO) qui approuve tout automatiquement. Le mode peut changer en cours de session.

C’est cette association qui distingue un mode d’un simple réglage d’autorisation. Le mode d’autorisation n’est qu’un filtre : il décide quels appels d’outil sont autorisés. À lui seul, ce filtre produit un agent qui veut modifier mais n’y arrive pas — il propose une écriture, est bloqué puis essaie autrement. Les consignes injectées font disparaître cette envie : le mode planification ne se contente pas de bloquer les modifications, il indique à l’agent qu’il est en phase de planification, afin qu’il lise, pose des questions et formule des propositions au lieu de lutter contre le filtre. Filtre et orientation vont dans le même sens.

En pratique, vous changez de mode à mesure que votre confiance évolue au fil d’une tâche. Une même tâche peut passer par plusieurs modes : planification pendant l’élaboration de l’approche, réglage par défaut avec confirmation pour les premières modifications délicates, acceptation des modifications lorsque l’agent a montré qu’il comprend le changement, contournement pour une exécution hors clavier dans un bac à sable. Changer de mode ne coûte rien : la conversation reprend exactement là où elle en était, avec de nouvelles autorisations et consignes. Si vous approuvez chaque demande sans la lire, le mode est plus strict que votre niveau réel de confiance ; si vous rejetez sans cesse les modifications, il est trop permissif.

Termes propres aux fournisseurs : Claude Code appelle ces réglages « modes d’autorisation », Codex les appelle « modes d’approbation » — les deux noms sont antérieurs à l’association avec des consignes de comportement.

Exemple d’utilisation :

« Il continue à modifier des fichiers alors que je veux seulement un plan. »

« Passe en mode planification — les écritures seront bloquées et il restera en phase de recherche. »

« Et pour l’exécution hors clavier plus tard ? »

« Mode contournement, mais uniquement dans le bac à sable. »

Un environnement isolé dans lequel l’agent s’exécute — conteneur, machine virtuelle, système de fichiers éphémère ou shell à permissions restreintes. Il limite le rayon d’impact des actions de l’agent : même si celui-ci exécute des commandes destructrices ou récupère quelque chose de malveillant, les dégâts restent circonscrits. C’est la base de sécurité qui rend le travail hors clavier possible.

Le bac à sable et le mode d’autorisation résolvent le même problème par des approches opposées. Les autorisations demandent confirmation avant l’exécution d’une action ; le bac à sable limite ce que l’action peut atteindre si elle s’exécute. Les autorisations exigent que vous restiez dans la boucle — chaque demande est une interruption — et une session qui demande sans cesse est à peine autonome. Le bac à sable dépense des ressources d’infrastructure plutôt que de l’attention : plus l’isolation est forte, moins il faut poser de questions.

Il existe plusieurs degrés d’isolation :

Ce qu’aucun bac à sable ne contient : les actions qui en sortent légitimement. Un agent disposant de vos identifiants git peut pousser des changements ; avec un accès réseau, il peut appeler des API de production. Décidez ce qui franchit la frontière avant de choisir l’épaisseur de l’isolation.

Exemple d’utilisation :

« Je voudrais le laisser travailler sans autorisation pendant la nuit, mais je ne suis pas encore prêt. »

« Place-le dans un bac à sable — conteneur neuf, aucun identifiant monté, pas de réseau sortant. Au pire, il détruit son propre système de fichiers et tu jettes le conteneur. »

Réponse d’un modèle complaisant avec assurance. Ce comportement vient de l’entraînement : le modèle a été façonné pour privilégier les réponses qui plaisent aux humains, lesquels préfèrent généralement qu’on leur donne raison plutôt qu’on leur dise qu’ils ont tort. Le modèle a donc appris que l’accord est récompensé, même lorsqu’il est erroné.

Manifestations :

• Céder sous la pression — revenir sur une réponse juste quand vous demandez « vous en êtes sûr ? ».
• Flatter une mauvaise idée — qualifier de brillante une stratégie défaillante avant de l’analyser.
• Biais de cadrage — une revue devient positive si vous dites l’avoir écrite, négative si vous l’attribuez à quelqu’un d’autre. Même livrable, verdict différent.
• Imitation — reprendre vos erreurs pour vous les confirmer.

Test diagnostique : le modèle aurait-il dit cela sans votre influence ? Si seul votre ton ou votre cadrage a changé, il s’agit de complaisance, pas d’un véritable changement d’analyse.

Correction : masquez vos préférences. Formulez vos demandes de façon neutre : « examine ce code » plutôt que « ce code est-il bon ? ».

À éviter : employer « complaisance » pour toute réponse erronée qui vous fait plaisir. Sans le test diagnostique, le terme ne vaut pas mieux que « faux ».

Exemple d’utilisation :

« Il a trouvé mon plan de refactorisation excellent, puis je lui ai demandé “vous en êtes sûr ?” et il a complètement changé d’avis. »

« C’est de la complaisance classique : il a d’abord approuvé parce que vous sembliez sûr de vous, puis il a cédé parce que vous sembliez douter. La qualité du plan n’a pas changé, seul votre ton a changé. Faites un effacement et reposez la question sans orienter la réponse. »

Réponse d’un modèle erronée avec assurance. Il en existe deux formes, aux causes et aux corrections différentes :

La prédiction du prochain jeton produit des réponses fluides, que le fait sous-jacent soit réel ou non : le modèle ne dispose d’aucun signal interne lui indiquant qu’il ne sait pas quelque chose. Une méthode inventée est donc formulée avec la même assurance qu’une méthode correcte. Le code halluciné est plausible par construction : c’est à quoi l’API ressemblerait si elle existait, ce qui lui permet de passer une revue rapide et de ne révéler son erreur qu’à l’exécution.

Vous devez savoir à quelle forme vous avez affaire, car la correction de l’une aggrave l’autre. Un problème d’exactitude factuelle vient d’un manque de connaissances : il faut ajouter du contexte — la documentation, les définitions de types, le fichier. Un problème de fidélité signifie que l’information est présente, mais qu’elle perd la compétition pour l’attention : il faut retirer du contexte. Si vous diagnostiquez à tort un problème de fidélité comme un manque d’exactitude, vous ajoutez encore de la documentation, ce qui augmente le contexte et aggrave la dérive. Quand l’agent se trompe, vérifiez si l’information correcte figurait déjà dans le contexte avant de décider de quel problème il s’agit.

À éviter : employer « hallucination » comme simple synonyme de « faux » — sans préciser la forme, le terme n’a aucune valeur diagnostique.

Exemple d’utilisation :

« Il a inventé une méthode `parseAsync` pour le schéma. »

« Problème d’exactitude ou de fidélité ? »

« La méthode figure dans la documentation que j’ai collée ; il a simplement cessé de la lire après le quarantième tour. »

« C’est donc un problème de fidélité. Faites une compaction et rechargez la documentation ; inutile d’en ajouter davantage. »

Ce que le modèle « sait » grâce à l’entraînement, stocké dans ses paramètres. Ces connaissances sont figées au moment de l’entraînement : le modèle ne peut ni consulter ses paramètres ni les mettre à jour. Cette compression fait perdre des détails : des milliards de faits doivent tenir dans un nombre fixe de paramètres et les faits rares deviennent flous. C’est la source de la fluidité sur les sujets courants et des inventions sur les sujets peu courants. Le contraire des connaissances contextuelles.

Les connaissances paramétriques ne sont pas stockées sous forme de faits. L’entraînement ne fournit jamais de base de données dans laquelle le modèle pourrait effectuer des recherches ; il ajuste ses paramètres jusqu’à ce que le modèle prédise correctement le texte. Un modèle qui prédit bien du texte portant sur un sujet se comporte comme s’il le connaissait. La fiabilité de ces connaissances dépend de la fréquence d’un sujet dans les données d’entraînement : le modèle reproduit précisément un sujet illustré par des millions d’exemples ; pour un sujet qui n’en compte que quelques-uns, il devine à partir de sujets similaires. Pour le modèle, reproduction et supposition reposent sur le même processus ; il ne peut pas savoir lequel il effectue. Une réponse inventée est formulée aussi aisément qu’une réponse correcte. Une hallucination est une supposition erronée du modèle.

Les connaissances paramétriques vieillissent aussi. Les paramètres cessent de changer à la date limite des connaissances : une bibliothèque publiée ou renommée après cette date n’y figure pas, et les API modifiées y sont mémorisées dans leur ancienne forme.

Pour les deux lacunes — rareté et ancienneté — le remède est le même : les connaissances ne peuvent pas être ajoutées aux paramètres ; elles doivent donc être fournies sous forme de connaissances contextuelles.

Exemple d’utilisation :

« Il écrit du React impeccable, mais invente des méthodes pour notre SDK interne. »

« React est très présent dans les connaissances paramétriques : des millions d’exemples d’entraînement. Votre SDK ne l’est pas ; le modèle comble donc les lacunes par des formes plausibles. Chargez sa documentation dans le contexte. »

La date après laquelle un modèle ne possède plus de connaissances paramétriques. Les bibliothèques, les API et les événements postérieurs à cette date sont des pièges à inventions, sauf si leur documentation est chargée comme connaissance contextuelle. Chaque version d’un modèle a sa propre date limite.

Cette limite vient du mode de fabrication des modèles : l’entraînement inscrit un instantané de textes dans les paramètres du modèle, qui sont ensuite figés. Le modèle ne sait pas que ses connaissances s’arrêtent à une certaine date. Interrogé sur un sujet ultérieur, il ne refuse pas de répondre ; il extrapole à partir de ce qu’il connaît de plus proche. Le piège est discret : le code écrit pour une ancienne version de bibliothèque paraît plausible, compile souvent, puis échoue sur les éléments qui ont changé.

La correction est toujours la même : ajouter les informations à jour au contexte. Chargez le journal des modifications, pointez vers les définitions de types de la version installée ou demandez à l’agent de lire la documentation sur le Web. Tout ce qui figure dans le contexte prime sur ce que les paramètres ne contiennent pas.

Exemple d’utilisation :

« Il écrit toujours la syntaxe du SDK v3 alors que nous sommes en v5. »

« La v5 est sortie après la date limite des connaissances. Chargez son journal des modifications comme connaissance contextuelle, sinon il continuera d’inventer à partir de la version paramétrique antérieure. »

Faits que l’agent peut lire directement dans le contexte à cet instant : la tâche de l’utilisateur, les fichiers lus par l’agent, les résultats d’outil, le contenu d’AGENTS.md chargé au début de la session. C’est le contraire des connaissances paramétriques : les connaissances paramétriques sont rappelées depuis les paramètres ; les connaissances contextuelles sont lues depuis la fenêtre. Les hallucinations sont beaucoup moins fréquentes lorsque l’agent s’appuie sur des connaissances contextuelles : la réponse est juste devant lui, il n’a pas à la tirer d’un souvenir flou.

Des deux types de connaissances, seules les connaissances contextuelles sont sous votre contrôle. Les paramètres sont figés ; pour donner au modèle des connaissances qui lui manquent — un SDK interne, une bibliothèque publiée après la date limite des connaissances, une décision prise hier — il faut les inclure dans le contexte. Une grande partie du travail pratique de codage par IA consiste à présenter les bons faits au modèle au moment où il en a besoin.

Quand les connaissances contextuelles et paramétriques se contredisent, les connaissances contextuelles l’emportent généralement. Collez la documentation actuelle de l’API et le modèle la suivra plutôt que de s’appuyer sur son souvenir périmé de l’ancienne API — même si l’ancienne version peut encore ressurgir, surtout au fond d’une longue session. Si l’agent revient sans cesse à une ancienne pratique malgré le chargement de la documentation, ce sont les connaissances paramétriques qui passent au travers des connaissances contextuelles ; répéter la correction ou la rapprocher du travail peut aider.

Contrairement aux connaissances paramétriques, les connaissances contextuelles ont un coût d’utilisation. Tout ce qui est chargé dans la fenêtre consomme des jetons et entre en concurrence pour le budget d’attention du modèle ; en charger davantage n’est donc pas automatiquement préférable. L’objectif est de mettre les faits pertinents dans la fenêtre, pas tous les faits.

Employez ce terme uniquement pour le distinguer des connaissances paramétriques ; sinon, dites simplement contexte.

À éviter : « mémoire de travail » — les connaissances contextuelles sont ce qui se trouve dans la fenêtre à cet instant ; un système de mémoire sert à y intégrer du contenu d’une session à l’autre. Ce sont des échelles différentes, à ne pas confondre.

Exemple d’utilisation :

« Pourquoi maîtrise-t-il l’API quand je colle la documentation, mais l’invente-t-il quand je ne le fais pas ? »

« Avec la documentation, il s’agit de connaissances contextuelles : il lit la page. Sans elle, les connaissances sont paramétriques et les points d’accès rares deviennent flous. »

Lorsqu’il prédit chaque jeton, le modèle tient compte de tous les autres jetons du contexte, certains fortement, d’autres à peine. La relation entre deux jetons constitue une relation d’attention ; les paires significatives (« elle » avec « Sarah », ou un appel `getUser()` avec sa définition `function getUser`) s’influencent davantage que des éléments sans rapport. Un contexte de N jetons comporte de l’ordre de N² relations.

C’est dans ces relations que réside la compréhension apparente du modèle. S’il résout un pronom, c’est parce que la relation d’attention entre « elle » et « Sarah » est forte. S’il appelle une fonction avec les bons arguments, c’est la relation entre l’endroit de l’appel et la définition lue auparavant qui agit. Rien n’est consulté dans une base : chaque relation est recalculée à chaque requête au fournisseur de modèle.

Le nombre N² mérite qu’on s’y attarde, car il augmente plus vite que l’intuition ne le laisse penser :

Chaque paire est aussi calculée plusieurs fois. Les modèles possèdent plusieurs têtes d’attention — leur nombre exact n’est pas publié pour les modèles de pointe, mais une estimation de cinquante à cent est raisonnable — et chaque tête calcule sa propre version de chaque relation. Chaque paire du tableau ci-dessus est donc reproduite pour chacune des têtes. Cela fait beaucoup de paires.

Seul un petit nombre de ces relations compte pour une tâche donnée. La relation entre votre consigne et le code qu’elle régit fait partie des rares relations importantes ; presque toutes les autres sont du bruit. Et leur évolution diffère : les relations importantes restent à peu près constantes, tandis que le nombre total de paires augmente au carré de la taille du contexte. Avec 1 000 jetons, la relation qui vous intéresse est une sur un million ; avec 100 000, une sur dix milliards. C’est l’arithmétique qui sous-tend le budget d’attention ; la dégradation de l’attention est ce que l’on ressent lorsque les relations importantes ne reçoivent plus qu’une part trop faible.

Exemple d’utilisation :

« Il confond sans cesse les deux symboles `user` dans le diff — on dirait qu’on est dans la zone bête. »

« Oui, la relation d’attention entre chaque site d’appel et sa déclaration est en concurrence avec l’autre : même forme de jeton, liaisons différentes. Renommez-en un et les correspondances seront plus nettes. »

Chaque jeton dispose d’une influence limitée à répartir sur le reste du contexte. Une forte influence sur une relation en laisse moins aux autres. Le budget est propre à chaque jeton et n’augmente pas avec la taille du contexte, ce qui explique la dilution au fil des longues sessions.

Pensez en termes de signal et de bruit. Votre consigne est un signal d’intensité fixe ; tous les autres jetons de la fenêtre de contexte constituent des sons concurrents. La consigne ne devient jamais plus faible — elle est toujours là, caractère par caractère — mais, à mesure que le contexte grandit, la pièce devient plus bruyante et le rapport signal/bruit diminue. Une consigne qui était l’élément le plus audible avec 10 000 jetons de contexte devient un bruit de fond avec 150 000 jetons. C’est le mécanisme à l’origine de la dégradation de l’attention : le modèle n’oublie pas ; le signal se perd dans le bruit.

Le symptôme ressemble à de la désobéissance : l’agent accepte une contrainte au début, puis s’en écarte ; la lui rappeler ne l’aide que brièvement. La cause n’est pas la consigne, mais tout le reste de la fenêtre qui entre en concurrence avec elle.

Vous pouvez contrôler ce qui entre dans le contexte. Un contenu qui ne sert pas la tâche n’est pas neutre : il ajoute du bruit à tout ce qui est utile. Gardez la fenêtre réduite, faites un effacement lorsque le contexte accumulé ne justifie plus sa place, et reformulez les contraintes importantes au lieu de compter sur leur mention initiale.

Exemple d’utilisation :

« Pourquoi continue-t-il d’ignorer le schéma que j’ai collé au début ? »

« Nous sommes déjà bien dans la zone bête : le budget d’attention de chaque jeton est fixe, mais le contexte a continué de grandir. Le signal associé au schéma est maintenant en concurrence avec des milliers de jetons plus récents. »

À mesure qu’une session grandit, le budget d’attention de chaque jeton se répartit entre davantage de concurrents. Le signal associé à chaque relation significative diminue ; le bruit du contexte non pertinent s’accumule. Même modèle, mêmes paramètres — simplement davantage d’éléments à nourrir dans la même assiette. C’est ce qui provoque l’effet de la zone intelligente / de la zone stupide zone effect.

On le voit lorsque le modèle semble empirer au milieu d’une session : des contraintes respectées depuis une heure commencent à lui échapper, il redemande des informations déjà fournies, écrit du code qui ignore un fichier lu précédemment. Rien n’a changé dans le modèle ; la seule variable est la quantité de contexte à laquelle il doit maintenant prêter attention.

Le phénomène est graduel, ce qui le rend difficile à remarquer depuis la session. Il n’y a ni erreur ni seuil ; chaque tour est légèrement moins bon que le précédent et, quand les dérapages deviennent évidents, vous êtes dans la zone stupide depuis un moment.

Pour y remédier, retirez du contexte au lieu d’en ajouter. Recoller la consigne ignorée ajoute un concurrent de plus à une fenêtre déjà encombrée et n’aide que brièvement. Ce qui fonctionne : effacer puis recharger uniquement ce dont la tâche a besoin, compacter ou passer le relais à une session neuve. Traitez le respect déclinant des consignes comme un signal sur la longueur du contexte, pas sur le modèle.

Exemple d’utilisation :

« Il est profondément dans la zone stupide — il invente des génériques absents du fichier de types. »

« Dégradation de l’attention. Les définitions de types sont toujours dans le contexte, mais le signal qu’elles portent est noyé sous tout ce que nous avons ajouté depuis. Efface et recharge. »

Au début d’une session, l’agent se trouve dans une « zone intelligente » : il est vif, concentré et se rappelle bien les choses. Au fil de la session, il glisse dans une « zone bête » : il devient moins rigoureux, oublieux, commet davantage d’erreurs et produit plus d’hallucinations liées à la fidélité. Même modèle, même harness — simplement davantage de contexte. C’est l’effet ressenti de la dégradation de l’attention. Avec les modèles de pointe, la zone bête commence souvent vers 125 000 à 150 000 jetons, même si ce seuil fait débat. Faites un effacement ou une compaction lorsque la session enfle ; ne forcez pas la poursuite.

La baisse est progressive, donc facile à manquer. Aucun message d’erreur ni seuil visible ne l’annonce : l’agent commence simplement à moins bien travailler, puis de plus en plus mal. Signes fréquents : il oublie une consigne donnée vingt tours plus tôt, répète une erreur déjà corrigée ou affirme avec assurance quelque chose que le contexte contredit. Comme la dégradation est graduelle, on a tendance à insister et à réexpliquer — ce qui ajoute du contexte et aggrave le problème.

Ces zones ne correspondent pas à la limite de la fenêtre de contexte. Une session peut être profondément dans la zone bête alors que la majeure partie de la fenêtre est encore libre : la limite est le point où le harness refuse de continuer, mais la qualité baisse bien avant. Organisez le travail en fonction de la zone intelligente, pas de la fenêtre : le budget pratique d’une tâche correspond au nombre de jetons avec lequel l’agent travaille bien, et non à la quantité qu’il peut techniquement contenir.

La zone intelligente est un budget que les tâches sans rapport consomment. Chaque tâche effectuée dans une session utilise des jetons ; en commencer une deuxième dans la même session revient donc à s’approcher davantage de la zone bête. Une tâche par session permet à chacune de profiter de la partie la plus efficace de la session. Si une tâche dépasse cette zone, découpez-la : faites un transfert ou une compaction à une étape naturelle, puis confiez la suite à une session fraîche.

Exemple d’utilisation :

« Il a réussi les trois premiers composants et a complètement raté le quatrième. »

« Vous avez dépassé la zone intelligente : même modèle, mais vous êtes maintenant loin dans la zone bête. Faites une compaction et rechargez le plan ; le prochain composant sera mieux traité. »

Mettre fin à la session en cours et en commencer une nouvelle. Le message suivant démarre dans une session vide, avec une fenêtre de contexte vide. Cette action est généralement déclenchée par l’utilisateur.

L’effacement remédie à un contexte pollué. Une session accumule tout : tentatives échouées, fausses pistes, résultats d’outil périmés, plans abandonnés. Le modèle relit tout cela à chaque tour, et un historique encombré pèse sur les nouveaux travaux. Au bout d’une longue session, l’agent devient plus vague et moins docile : il ignore des consignes pourtant claires, la qualité baisse, et le pousser à faire mieux n’aide pas, car il patauge toujours dans le bruit de son contexte. L’effacement élimine ce bruit.

L’effacement ne supprime pas la conversation. La plupart des harnesses conservent l’historique de la session sur votre ordinateur ; vous pouvez donc toujours le lire ou le reprendre. C’est l’état de travail de l’agent qui disparaît : le modèle est stateless, la nouvelle session ne sait donc rien de ce que l’ancienne savait. Si la session contient des décisions ou de l’avancement dont la suivante aura besoin, demandez d’abord à l’agent de créer un artefact de transfert, puis démarrez la nouvelle session en lui indiquant cet artefact.

Comparez avec la compaction, qui résume la session dans le nouveau contexte au lieu de repartir de zéro. L’effacement est l’outil le plus radical : rien ne subsiste, y compris les éléments inutiles.

Exemple d’utilisation :

« Il tourne en boucle sur le test qui échoue. »

« Faites simplement un effacement : démarrez une nouvelle session avec le document de plan et le fichier de test. Inutile de lutter contre le contexte actuel. »

Transférer le contexte d’un agent d’une session à une autre. Le mécanisme de transfert varie : artefact de transfert écrit sur disque, résumé gardé en mémoire (compaction, entre autres). À distinguer de l’effacement, qui ne transfère rien. Les raisons varient : changer de rôle (planificateur → exécutant), lancer une exécution AFK, répartir le travail entre des sessions parallèles ou libérer de l’espace dans la fenêtre de contexte.

La session qui reçoit le transfert commence sans contexte : le modèle est stateless et ne voit rien de l’ancienne session. Il faut transmettre explicitement tout ce dont la suivante aura besoin ; le reste disparaît. L’absence de voie de retour est la contrainte qui façonne le transfert : la nouvelle session ne peut pas demander à l’ancienne ce qu’elle voulait dire. Le contenu transmis doit donc se suffire à lui-même.

Le signe visible d’un mauvais transfert est la reprise du débat : la nouvelle session remet en question des décisions déjà tranchées, car le transfert indique ce qui a été décidé, mais pas pourquoi. Évaluez le transfert à l’aune de ce qu’une session sans aucun contexte pourrait en faire.

Exemple d’utilisation :

« La session de planification devient lourde ; devrais-je simplement continuer ? »

« Faites un transfert. Consignez les décisions dans un document, effacez la session et commencez l’implémentation dans une nouvelle session qui le lira. »

Une source de vérité dans sa forme originale — le code, la transcription d’une conversation, le journal brut, la véritable réponse d’API. Ce n’est pas un compte rendu de la chose : c’est la chose elle-même. Le pendant de la source secondaire.

Pour savoir ce que fait votre codebase, le code est la source primaire. La documentation, le diagramme d’architecture et le README en sont des descriptions — exactes au moment de leur rédaction, puis maintenues à leur propre rythme. Quand un agent affirme avec assurance quelque chose d’erroné sur votre projet, demandez-vous à partir de quelle source il a travaillé : un agent qui a lu un document hérite de son obsolescence ; un agent qui a lu le code consulte la vérité actuelle.

Le coût empêche les sources primaires d’être le choix par défaut. Charger une source dans la fenêtre de contexte coûte cher — fichier complet, transcription complète, chaque jeton facturé comme entrée et en concurrence pour le budget d’attention. En échange, vous obtenez l’exhaustivité : rien n’a été présélectionné selon le jugement de quelqu’un d’autre sur ce qui comptait. Un résumé rédigé le mois dernier ne peut pas contenir le détail qui s’avère important aujourd’hui ; la source primaire, elle, le contient toujours.

Consultez la source primaire quand la précision compte — signature exacte, véritable erreur, ligne qui déclenche l’exception. Une grande partie de la gestion du contexte consiste à décider quand payer le coût d’une source primaire et quand une source secondaire suffit.

Exemple d’utilisation :

« L’agent dit que les tentatives recommencent avec un délai exponentiel, mais je le vois marteler l’endpoint. »

« Il a lu cela dans le document de conception. Oriente-le vers le véritable module de nouvelle tentative — travaille à partir de la source primaire quand le comportement compte. »

Le compte rendu d’une source primaire, à un niveau de distance — documentation décrivant du code, résumé d’une transcription, rapport de résultats de recherche. Plus économique à charger dans la fenêtre de contexte que la source décrite, mais intrinsèquement incomplet : son auteur a décidé ce qui comptait et tout ce qu’il a écarté reste invisible au lecteur qui ne dispose que du résumé.

Une grande part de l’ingénierie du contexte consiste à fabriquer des sources secondaires. La compaction transforme l’historique de la session en résumé qui amorce la suivante. Un sous-agent dépense son propre contexte dans une recherche bruyante puis renvoie un bref rapport. Un artefact de passation condense les décisions d’une session dans un document destiné à la prochaine. Les systèmes de mémoire distillent les apprentissages d’une session sous forme de notes. Chacun fait le même compromis : fidélité contre marge disponible.

Les sources secondaires échouent de deux façons. Elles perdent de l’information — résumé de compaction qui omet la décision de schéma, rapport qui ne mentionne pas le cas limite. Et elles dérivent — la source primaire change, mais pas son compte rendu, si bien que la documentation décrit l’architecture du trimestre dernier avec l’assurance de celle du trimestre actuel. Quand un agent s’appuie sur une source secondaire défaillante de l’une ou l’autre manière, il agit avec confiance à partir d’informations erronées ; il faut le renvoyer à la source primaire.

Aucun de ces échecs ne rend les sources secondaires inutiles. La fenêtre de contexte est finie et les sources primaires sont coûteuses ; sans résumés, rapports et documents de passation, rien de volumineux ne pourrait y tenir. Tout l’art consiste à savoir quels détails peuvent survivre à cette perte — et à vérifier auprès de la source primaire ceux qui ne le peuvent pas. Une source secondaire bien faite comporte un pointeur de contexte vers son origine — le résumé qui nomme la transcription utilisée, le document qui nomme le fichier décrit — afin que le lecteur puisse suivre le pointeur plutôt que de s’en tenir à un compte rendu insuffisant.

Exemple d’utilisation :

« Le document de passation affirme que l’authentification est terminée, mais la nouvelle session trouve toujours des problèmes de renouvellement de jeton. »

« Le document est une source secondaire — la session précédente a noté ce qu’elle croyait, pas ce qui est vrai. Demande à la nouvelle session d’exécuter les tests d’authentification et de faire confiance à la source primaire. »

Un document qui sert de support à une passation : une session l’écrit dans l’environnement afin qu’une autre puisse le lire. Les spécifications, les tickets et les documents de plan sont tous des artefacts de passation.

Pourquoi en rédiger un ? Le modèle est sans état, donc rien d’une session ne survit à son effacement. Décisions, contraintes, plans inachevés : tout disparaît avec le contexte qui les contenait. L’environnement, lui, persiste. En consignant les informations importantes dans un fichier, vous les placez là où la session suivante pourra les relire.

L’artefact est une source secondaire — le compte rendu du travail de la session, pas le travail lui-même. C’est ce qui le rend assez compact pour présenter le contexte à une nouvelle session, mais aussi ce qui peut l’induire en erreur : il consigne ce que la session rédactrice croyait, et tout oubli ou toute erreur lui échappe. Lorsqu’une affirmation est importante, la session suivante doit la vérifier dans la source primaire — le code, les tests — plutôt que de l’accepter telle quelle.

Un bon artefact est conçu pour une session qui ne dispose d’aucun contexte. Indiquez des chemins de fichiers précis plutôt que « le fichier dont nous avons parlé ». Expliquez les décisions et leurs raisons pour que la prochaine session ne relance pas le débat. Précisez ce qui est fait et ce qui reste à faire. Il est utile de préciser à la session rédactrice la destination de l’artefact : « rédige un document de passation pour une nouvelle session qui ne sait rien de ce travail ».

L’autre mécanisme de transmission est la compaction, qui résume les informations en mémoire. L’artefact a deux avantages : il réside sur le disque, où vous pouvez le lire et le corriger avant que quoi que ce soit n’en dépende, et il est réutilisable — la même spécification peut informer cinq sessions parallèles.

Exemple d’utilisation :

« Comment répartir ce travail entre l’agent de planification et celui qui l’implémente ? »

« Demande à l’agent de planification de rédiger un artefact de passation — chemins de fichiers, décisions, contraintes. La session de l’agent chargé de l’implémentation commence par un pointeur vers cet artefact et s’en sert comme consigne. »

Un artefact de passation qui décrit un travail réparti sur plusieurs sessions : ce qui est en cours de construction, et non la manière dont chaque session contribue. Il évolue au fil du travail. Il est constitué de tickets.

La spécification existe parce que les sessions sont jetables alors que les gros travaux ne le sont pas. Tout travail qui exige plus d’une fenêtre de contexte doit avoir un emplacement en dehors du contexte, dans l’environnement de l’agent, qui survive à l’effacement : fichier dans le dépôt, ticket GitHub ou outil de suivi accessible à l’agent. La spécification est cet emplacement : l’objectif, les contraintes, les décisions prises et la liste des tickets avec leur état. Toute nouvelle session peut la lire et savoir où en est le travail sans hériter du bruit accumulé par la session précédente.

Les spécifications prennent des formes reconnaissables, souvent héritées des habitudes de documentation des équipes. Un document de spécification des exigences produit (PRD) s’attache plutôt au quoi et au pourquoi côté utilisateur : fonctionnalités, comportement, critères d’acceptation. Un document de conception ou une RFC met l’accent sur les aspects techniques : approche retenue, solutions écartées et compromis. Pour les petits travaux, un simple `plan.md` avec une liste de contrôle des tickets fait le même travail pour une fonctionnalité répartie sur plusieurs sessions. La forme compte moins que le rôle : pour l’agent, chacun de ces documents remplit la même fonction — une déclaration durable de l’intention qu’il lit au début de chaque session.

Exemple d’utilisation :

« Est-ce que tout cela doit tenir dans une seule session ? »

« Non, rédige une spécification — découpe le travail en tickets et traite chacun dans sa propre session. Essayer de tout faire dans un seul contexte vous fera atteindre la zone stupide avant d’en être à la moitié. »

Un artefact de passation qui délimite le travail d’une session. Il peut exister seul ou dépendre d’une spécification comme l’un de ses éléments enfants. Les tickets peuvent bloquer des tickets frères ou être bloqués par eux ; l’ordre du travail découle donc de leur graphe de dépendances plutôt que d’un plan linéaire.

La contrainte fondamentale est la taille : une session. Un ticket devrait pouvoir être terminé avant que la session ne sorte de la zone intelligente — et cela peut être vérifié. Si les sessions consacrées à vos tickets se dégradent régulièrement avant la fin du travail, les tickets sont trop gros : découpez-les. Si chaque session passe l’essentiel de son contexte à la configuration avant d’accomplir cinq minutes de travail, les tickets sont trop petits : regroupez-les.

Un bon ticket est rédigé pour quelqu’un qui ne dispose d’aucun autre contexte. L’objectif, les critères d’acceptation et des pointeurs de contexte vers les fichiers et décisions concernés — assez d’éléments pour que la session puisse démarrer sans devoir reconstituer ce que la précédente savait.

Le graphe de dépendances est aussi ce qui rend le travail parallèle possible. Les tickets indépendants — les feuilles du graphe — peuvent chacun être exécutés dans leur propre session au même moment. C’est une manière efficace de faire travailler plusieurs agents simultanément. Dans une usine logicielle, le fait qu’un ticket soit marqué prêt déclenche lui-même le démarrage de sa session.

Exemple d’utilisation :

« Par où commencer dans la spécification de migration ? »

« Regarde le graphe des tickets : la modification du schéma bloque le remplissage rétroactif, qui bloque le changement d’API. Choisis une feuille et démarre une session. »

Une passation effectuée en mémoire : l’historique de la session précédente est résumé, et ce résumé sert d’amorce à une nouvelle session. La perte d’information est intentionnelle : la transcription est une source primaire, le résumé une source secondaire — on échange des détails contre de la marge disponible. Le processus est déclenché manuellement par l’utilisateur ou automatiquement par autocompact.

Voici le mécanisme : la fenêtre de contexte est finie, et une longue session la remplit — chaque résultat d’outil, chaque fichier lu et chaque fausse piste restent dans l’historique. Lorsqu’il devient trop lourd, le harness demande au modèle de résumer la session, abandonne l’historique d’origine et démarre une nouvelle session à partir du résumé. Tout ce qui n’a pas été conservé dans le résumé disparaît du contexte. Certains harnesses atténuent cette perte en gardant l’ancienne transcription sur le disque et en laissant dans le résumé un pointeur de contexte qui y renvoie : la source secondaire renvoie à sa source primaire, de sorte qu’un détail oublié dans le résumé peut être retrouvé en relisant l’original.

Le résumé est rédigé par le modèle et peut donc être guidé par une consigne. « Préserve les décisions de schéma » rend l’artefact généré plus intentionnel. Le moment compte également : lancez la compaction à la fin d’une étape, une fois le plan établi, et non au milieu d’une tâche.

À distinguer de l’effacement, qui abandonne tout et repart à froid : la compaction tente de transmettre l’essentiel, tandis que l’effacement part du principe que tout est déjà noté quelque part de plus approprié.

Exemple d’utilisation :

« Le contexte devient lourd et je dois encore exécuter les tests. »

« Fais une compaction avant de commencer — indique dans la consigne du résumé ce qui doit absolument survivre, pour que la nouvelle session garde les décisions de schéma et laisse de côté l’exploration. »

Compaction déclenchée automatiquement par le harness lorsque la fenêtre de contexte approche de sa limite.

Le harness surveille le remplissage de la fenêtre de contexte. Lorsqu’un seuil est dépassé — souvent autour de 80 % —, il s’arrête, demande au modèle de résumer la session jusque-là et amorce une nouvelle session avec ce résumé. Le travail reprend alors comme si rien ne s’était passé.

Or quelque chose s’est bien passé. La compaction entraîne une perte d’information, et la compaction automatique survient à un moment que vous n’avez pas choisi. Une compaction manuelle a lieu à une étape charnière, lorsque vous pouvez indiquer au modèle ce qu’il doit préserver. La compaction automatique se déclenche en plein travail dès que le seuil est atteint — peut-être au milieu d’une refactorisation — et le résumé décide lui-même quelles décisions méritent d’être conservées. Symptôme classique : l’agent poursuit son travail avec assurance, mais a oublié discrètement une contrainte donnée une heure plus tôt ; vous ne le remarquez que lorsque son travail la contredit.

Le mieux est d’éviter son déclenchement. Surveillez l’indicateur de contexte et faites une compaction manuelle à une étape naturelle, ou consignez les décisions dans un document de planification ou un artefact de transfert sur disque, où aucun résumé ne peut les perdre. La plupart des harnesses permettent aussi de personnaliser la marge : vous pouvez avancer ou retarder le seuil, ou désactiver complètement la compaction automatique, afin de choisir la réserve à garder avant son déclenchement.

Exemple d’utilisation :

« Il ne semble pas se souvenir de ce que nous avions décidé au sujet du schéma. »

« La compaction automatique s’est déclenchée entre deux tours : les décisions du début ont été résumées et quelque chose a dû se perdre. Rechargez le document de planification ou faites une compaction manuelle la prochaine fois afin de décider vous-même ce qui sera conservé. »

Un système qui tente de rendre un agent à état persistant entre plusieurs sessions. Pendant une session, il enregistre des informations dans l’environnement, puis les recharge dans la fenêtre de contexte au début des sessions suivantes : l’agent conserve ainsi une continuité au-delà de l’effacement de la session par l’utilisateur.

Un système de mémoire comporte deux parties. Le chemin d’écriture : pendant une session, l’agent consigne ce qu’il a appris — une préférence que vous avez exprimée, un fait concernant le projet — dans des fichiers de l’environnement. Le chemin de lecture : au début d’une session, le harness recharge ces fichiers, ou leur index, dans la fenêtre de contexte. De nombreux harnesses fournissent leur propre système de mémoire — `/memory` dans Claude Code en est un — mais vous pouvez également en créer un : un répertoire de notes accompagné d’une consigne dans AGENTS.md lui demandant de le consulter.

Les mêmes compromis que pour tout contenu toujours chargé s’appliquent. Les souvenirs s’accumulent ; la plupart des systèmes chargent donc un index d’une ligne et placent les détails derrière des pointeurs de contexte au lieu de tout intégrer. Les souvenirs sont aussi des sources secondaires et deviennent obsolètes : un fait consigné en mars est chargé avec la même assurance en juin, alors que le projet a changé. Comme AGENTS.md, un système de mémoire doit être élagué.

Exemple d’utilisation :

« Je dois sans cesse lui rappeler que j’utilise Postgres, pas MySQL. »

« Configure un système de mémoire : enregistre ce qu’il apprend dans le système de fichiers au premier tour, puis recharge-le au début des sessions. Le modèle lui-même est sans état ; c’est la couche de mémoire qui simule la continuité. »

Un fichier de l’environnement que le harness charge dans la fenêtre de contexte au début d’une session : le brief permanent du projet destiné à l’agent. Convention commune aux harnesses ; certains ont aussi leur propre variante (celle de Claude Code est CLAUDE.md).

Comme il est chargé automatiquement, c’est un moyen d’éviter de se répéter d’une session à l’autre. Le modèle est sans état : une correction donnée pendant une session disparaît à la suivante, et vous finissez par répéter à chaque nouvelle session que le projet utilise pnpm, que les tests s’exécutent avec un indicateur particulier ou qu’un répertoire est généré et ne doit pas être modifié. Après avoir corrigé deux fois l’agent sur le même point, cette correction peut mériter une ligne dans AGENTS.md.

Le contenu adapté est ce que l’agent ne peut pas déduire du code : commandes de compilation et de test, conventions qui ne sont pas évidentes dans le dépôt, contraintes strictes (« ne jamais modifier le client généré »). Il doit être bref et déclaratif : c’est un brief, pas de la documentation.

Le compromis, c’est que tout son contenu est chargé en permanence. Les consignes s’accumulent, la plupart étant inutiles pour une tâche donnée ; un long AGENTS.md consomme des jetons et dilue son propre effet — plus il y a de consignes dans le contexte, moins le modèle suit chacune d’elles de façon fiable.

À éviter : utiliser AGENTS.md pour du contenu qui devrait être divulgué progressivement — tout ce qu’il contient coûte des jetons à chaque tour, dans chaque session, même lorsqu’elle n’en a pas besoin. Un guide de style peut être placé derrière une compétence ou un pointeur de contexte ; réservez AGENTS.md aux consignes applicables partout.

Exemple d’utilisation :

« Pourquoi chaque session commence-t-elle avec déjà 4 000 jetons consommés ? »

« Vérifie AGENTS.md — quelqu’un y a collé tout le guide de style au lieu de le placer derrière une compétence. »

Ne charger que le contexte dont l’agent a besoin maintenant, en utilisant des pointeurs de contexte pour le reste. L’idée vient de la conception d’interfaces, où elle consiste à ne montrer aux utilisateurs que les commandes utiles à leur tâche actuelle et à dissimuler les autres derrière un clic.

Cette technique existe parce que le contexte a un double coût. Chaque jeton chargé dès le départ est facturé comme jeton d’entrée à chaque tour, et chaque jeton consomme le budget d’attention, que l’agent en ait besoin ou non. Un fichier AGENTS.md rempli du guide de style complet, du manuel de déploiement et des conventions de base de données rend l’agent moins efficace sur chacun de ces sujets : les consignes pertinentes pour la tâche sont diluées par celles qui ne le sont pas. Le signe révélateur est un agent qui ignore des règles que vous savez présentes dans son contexte : elles y sont, mais enfouies.

La divulgation progressive renverse cette logique. Gardez la couche toujours chargée réduite — une phrase par sujet et un pointeur vers les détails. L’agent consulte le guide de style quand il écrit un composant, le manuel de déploiement quand il déploie et aucun des deux lorsqu’il corrige un test. Les compétences sont le modèle intégré au harness : une brève description chargée à chaque session, puis les instructions complètes uniquement lorsque la compétence est déclenchée.

Exemple d’utilisation :

« Devrais-je mettre tout le guide de style dans AGENTS.md ? »

« Non : utilisez la divulgation progressive. Référencez le guide de style comme une compétence que l’agent charge lorsqu’il doit réellement écrire un composant. AGENTS.md impose le coût de ses jetons à chaque tour. »

Une mention dans un document qui en désigne un autre, afin que l’agent puisse ne le charger dans la fenêtre de contexte que lorsque la tâche l’exige. C’est l’unité de base de la divulgation progressive.

On utilise un pointeur plutôt que d’intégrer directement le contenu pour une question de coût. Un pointeur n’occupe qu’une ligne dans la fenêtre de contexte. Le document vers lequel il mène peut compter des milliers de jetons, mais ceux-ci ne coûtent rien tant que l’agent ne suit pas le pointeur. Intégrez dans AGENTS.md un guide de déploiement de 2 000 jetons et chaque session en paiera le prix ; remplacez-le par « déploiement : voir `internal/deploy.md` » et seules les sessions qui déploient le chargeront. L’agent suit le pointeur par un appel d’outil lorsque la tâche s’y prête.

Un pointeur doit comporter deux éléments pour être utile : un chemin stable et une description suffisante pour que l’agent sache quand il vaut la peine de le suivre. Un chemin seul ne donne à l’agent aucune raison d’y aller ; « voir `internal/deploy.md` » sans indication de son contenu sera ignoré par une session qui en aurait besoin. Rédigez la ligne en fonction de la manière dont les tâches se présentent : « livraison, déploiement ou retour arrière — lire `internal/deploy.md` d’abord ».

On trouve des pointeurs partout dès qu’on les cherche : lignes d’AGENTS.md, descriptions de compétences (le harness charge la description ; le corps de la compétence reste derrière), noms de fichiers dans une liste de répertoire et liens entre documents.

Un pointeur peut également relier une source secondaire à la source primaire dont elle découle : le résumé de compaction qui désigne la transcription d’origine, le document qui nomme le fichier source qu’il décrit. Cela permet de récupérer les informations perdues par la source secondaire : lorsque le résumé ne suffit pas, l’agent suit le pointeur et lit l’original au lieu de s’en tenir à ce qu’il a conservé.

À éviter : « référence » — trop sec, n’évoque pas le fait que suivre le pointeur apporte davantage de contexte. « Portail » — trop emphatique.

Exemple d’utilisation :

« AGENTS.md devient énorme. »

« La plupart de son contenu devrait être des pointeurs de contexte, pas du contenu. Garde les règles permanentes en ligne ; transforme le guide de déploiement et le guide de style en compétences et laisse un pointeur de contexte. »

Une capacité qui peut être enseignée et qui regroupe, en une unité, les consignes et ressources nécessaires pour bien accomplir une tâche. Elle reste dans l’environnement jusqu’à ce qu’un pointeur de contexte la charge dans la fenêtre de contexte pour la tâche en cours. C’est l’unité de divulgation progressive d’un harness.

Les compétences sont une norme ouverte définie sur agentskills.io — conçue à l’origine par Anthropic, puis adoptée par la plupart des grands harnesses, de sorte qu’une compétence rédigée une fois fonctionne dans chacun d’eux. Le format consiste en un dossier contenant :

• Un fichier `SKILL.md` — des métadonnées (au minimum un nom et une description) ainsi que les consignes elles-mêmes
• Éventuellement, des scripts que l’agent peut exécuter
• Éventuellement, des modèles et documents de référence auxquels renvoient les consignes

Par défaut, seuls le nom et la description occupent le contexte. Lorsque la tâche de l’agent correspond, il charge le reste. D’ici là, la compétence prend très peu de place — une ou deux phrases de jetons, quelle que soit la longueur de ses consignes complètes.

C’est ce qui distingue les compétences de AGENTS.md, chargé à chaque session quelle que soit la tâche. Une compétence est lue quand un type de travail particulier se présente — livraison, création de service ou rédaction d’une migration — et ignorée le reste du temps.

À éviter : confondre avec un « outil » — l’agent appelle un outil ; il lit les consignes d’une compétence.

Exemple d’utilisation :

« Où mettre le guide de déploiement ? »

« Dans une compétence : l’agent ne la charge que lorsque la tâche concerne un déploiement. Dans AGENTS.md, elle consommerait des jetons à chaque tour pour quelque chose que nous utilisons chaque semaine. »

Un agent lancé par un autre agent via un appel d’outil. Il s’exécute dans sa propre session, avec sa propre fenêtre de contexte, puis renvoie un unique résultat d’outil. À distinguer d’une passation : le parent attend explicitement un retour ; une passation n’a aucun chemin de retour. Ne peut pas lancer d’autres sous-agents — l’arbre n’a qu’un seul niveau. Les sous-agents servent à isoler le contexte, pas à composer des hiérarchies.

L’objectif est de garder le travail bruyant hors du contexte du parent. Une recherche large ou une longue exploration de fichiers produit des pages de résultats d’outil, dont la plupart ne sont utiles que le temps de trouver la réponse. Exécutée dans le parent, toute cette matière reste dans son contexte pour le reste de la session. Exécutée dans un sous-agent, elle remplit une fenêtre jetable ; seul le rapport final arrive dans le contexte du parent. Ce rapport est une source secondaire : le parent reçoit le compte rendu du sous-agent, pas les résultats bruts ; tout élément omis du rapport lui reste donc invisible.

Les sous-agents peuvent aussi travailler simultanément : un parent peut en lancer plusieurs à la fois sur des tâches indépendantes.

Exemple d’utilisation :

« Les résultats de grep saturent mon contexte. »

« Lance un sous-agent pour faire la recherche — il remplira sa propre fenêtre de contexte avec le bruit et ne te renverra que les deux chemins de fichier dont tu as besoin. »

Un mode de travail où un ou plusieurs humains travaillent en binôme avec l’agent pendant une session : ils examinent, réorientent ou collaborent en temps réel. L’humain est présent et impliqué ; il ne se contente pas de filtrer chaque action.

L’opposé est le travail hors clavier, où l’agent travaille sans surveillance et où vous évaluez le résultat après coup. Avec un humain dans la boucle, les problèmes sont détectés tant qu’ils sont encore faciles à corriger : vous voyez l’agent choisir le mauvais fichier, mal interpréter l’exigence ou s’engager dans une impasse, puis le réorientez en une phrase — au lieu de découvrir vingt minutes de travail assuré fondé sur cette erreur. Les agents ne savent pas toujours reconnaître qu’ils s’égarent ; laissés seuls, ils ont tendance à continuer plutôt qu’à s’arrêter pour demander.

Le mode qui convient dépend du travail. Les tâches bien spécifiées, peu risquées et faciles à vérifier se prêtent au mode hors clavier. Les tâches ambiguës, irréversibles ou dont le résultat final serait difficile à examiner — migration de schéma, décision de conception délicate, tout ce qui touche à la production — justifient de rester dans la boucle. La question revient essentiellement à ceci : quel serait le coût d’une mauvaise direction et à quel moment la découvririez-vous ?

Certains travaux sont par nature réalisés dans la boucle parce que vos réactions en sont la matière première. L’entretien socratique ne fonctionne que si vous êtes là pour répondre ; le prototypage exige que vous puissiez réagir à l’artefact.

Rester dans la boucle consomme votre attention, qui est la ressource rare. Mieux travailler avec les agents consiste notamment à sortir davantage de tâches de la boucle sans risque, à l’aide de plans, de vérifications automatisées et d’une revue humaine à la fin plutôt que d’une supervision permanente. Une usine logicielle va plus loin en déclenchant les sessions, de sorte que même le lancement du travail ne dépend plus de vous.

Exemple d’utilisation :

« Je peux lancer ça hors clavier pendant la nuit ? »

« Non, c’est une migration de schéma — garde un humain dans la boucle. Je veux voir chaque étape et réorienter le travail s’il choisit la mauvaise colonne pour le remplissage rétroactif. »

Away from keyboard, c’est-à-dire « loin du clavier ». Un mode de travail où l’utilisateur lance une session puis laisse l’agent travailler sans surveillance. C’est le multiplicateur de débit du codage IA : plusieurs sessions AFK peuvent s’exécuter en parallèle pendant que vous dormez, mangez ou travaillez à autre chose. Il faut généralement un mode d’autorisation permissif et du sandboxing pour que cela soit sûr.

En votre absence, l’agent traite différemment les ambiguïtés. Lorsque vous le surveillez, une décision ambiguë se présente sous forme de question et vous y répondez ; une fois parti, l’agent choisit une valeur par défaut et poursuit, et chaque décision ultérieure s’appuie sur cette supposition. L’échec typique consiste à revenir après plusieurs heures sur un travail terminé et assuré, fondé sur une mauvaise décision prise dans les dix premières minutes. Le travail n’est pas bâclé : il est cohérent, mais cohérent autour d’une mauvaise hypothèse.

Puisque vous ne pouvez pas intervenir pendant l’exécution, faites-le avant et après. Avant : résolvez les ambiguïtés à l’avance — au moyen d’une session d’entretien socratique ou d’une spécification écrite — pour réduire les lacunes que l’agent devra combler seul. Pendant : les vérifications automatisées et la revue automatisée remplacent l’attention que vous n’accordez pas, en détectant rapidement ce qui peut l’être mécaniquement. Après : l’exécution doit se terminer par un résultat vérifiable — une PR, pas des changements déjà fusionnés. Le travail AFK ne supprime pas la revue humaine ; il la reporte entièrement à la fin, d’où l’importance que le résultat final mérite cette revue. C’est également pourquoi l’expérience agent compte autant dans les exécutions AFK : sans surveillance, l’environnement est le seul soutien dont dispose l’agent.

À éviter : « agent d’arrière-plan » — l’expression met l’accent sur la machine (« s’exécute en arrière-plan ») plutôt que sur le mode de travail humain (« l’utilisateur s’est éloigné »). AFK désigne le fait important : l’utilisateur ne surveille pas.

Exemple d’utilisation :

« Je lance ça AFK — trois agents dans des bacs à sable sur la refonte, je relis les PR demain matin. »

« Contournement des autorisations ? »

« Oui, système de fichiers en lecture seule, aucun accès réseau. »

Une vérification déterministe exécutée dans l’environnement — tests, vérifications de types, lint, compilation, hooks pre-commit. Réussite ou échec, sans jugement. C’est le signal à partir duquel un agent peut se corriger lui-même sans impliquer qui que ce soit. Un test instable est un contrôle défectueux, pas une absence de contrôle ; les vérifications automatisées sont conçues pour être déterministes.

L’autocorrection fonctionne comme une boucle. L’agent apporte une modification, lance le contrôle sous forme d’appel d’outil, puis la sortie d’échec arrive dans sa fenêtre de contexte : erreur de type avec fichier et ligne, assertion échouée avec valeurs attendue et réelle. Cela suffit à l’agent pour corriger le problème et relancer le contrôle, encore et encore jusqu’à sa réussite, sans humain dans la boucle. Le déterminisme rend cette boucle fiable : le même code produit toujours le même verdict, donc une réussite signifie quelque chose. Un contrôle instable empoisonne le processus : l’agent « corrige » du code qui était bon ou réessaie au-delà d’un échec réel.

C’est pourquoi de bons contrôles constituent une grande partie de l’expérience agent d’un dépôt de code. Dans un dépôt doté de types stricts, d’une suite de tests rapide et d’un linter, un agent détecte la plupart de ses propres erreurs avant que vous ne les voyiez ; dans un dépôt qui n’en a aucun, il livre tout ce qu’il produit. La différence est particulièrement importante pour les exécutions hors clavier, où les contrôles sont les seules vérifications effectuées pendant le travail. Mais un contrôle ne détecte que ce qu’il affirme : des contrôles au vert signifient que les propriétés vérifiées sont respectées, pas que le code est correct. Les lacunes nécessitant du jugement relèvent de la revue automatisée et de la revue humaine.

À éviter : « boucle de rétroaction » / « rétropression » — ces deux termes mélangent les contrôles et la revue. À éviter : « test » — les tests sont des vérifications automatisées, mais toutes les vérifications automatisées ne sont pas des tests.

Exemple d’utilisation :

« L’agent livre sans cesse du code cassé lors des exécutions hors clavier. »

« Quelles vérifications automatisées sont configurées dans le bac à sable ? »

« Seulement les tests unitaires. »

« Ajoute la vérification de types et le lint — l’agent pourra s’autocorriger à partir de ces résultats avant même que la PR arrive. »

Un agent qui examine le travail d’un autre agent, souvent à l’aide d’un modèle ou d’une invite système différent. Non déterministe : il forme un jugement. Il peut s’exécuter partout — avant fusion sur une PR, après coup dans l’historique des commits ou au milieu d’une session comme sous-agent. Un LLM utilisé comme juge en CI constitue une revue automatisée, pas une vérification automatisée ; c’est la nature de l’assertion qui détermine la catégorie, pas l’endroit où elle s’exécute.

La séparation d’avec l’agent qui travaille est ce qui rend cette méthode efficace. Demander à l’agent qui a écrit le code de relire son propre travail apporte peu : la session qui a produit le bug contient aussi le raisonnement qui l’a produit, et l’agent relit ses propres conclusions comme une confirmation. Un réviseur doté d’une fenêtre de contexte neuve n’a pas cet attachement : il voit le diff comme le ferait un inconnu, condition nécessaire à la revue. Un autre modèle ou une invite système conçue pour la revue accentue encore cette différence — angles morts différents et consigne ciblée sur ce qui compte réellement (sécurité, contrats d’API, performances) au lieu d’un vague « cherche des problèmes ».

Cette approche se place entre les autres niveaux de revue. Les vérifications automatisées sont déterministes et détectent ce qui peut être affirmé mécaniquement ; la revue humaine est coûteuse et passe le moins bien à l’échelle. La revue automatisée se situe entre les deux : au coût d’une machine, elle détecte les problèmes qui exigent du jugement — nom de fonction trompeur, cas limite oublié. Comme elle n’est pas déterministe, elle peut manquer des problèmes ou signaler des non-problèmes ; traitez-la comme un filtre qui relève le niveau avant l’examen humain, pas comme un garde-fou qui le remplace.

À éviter : « revue IA » / « revue par agent » — trop vague pour distinguer le réviseur de l’agent qui réalise le travail.

Exemple d’utilisation :

« Nous recevons trop de mauvaises PR provenant des exécutions hors clavier. »

« Ajoute une étape de revue automatisée avant la fusion — autre modèle, invite système distincte, ciblée sur la sécurité et les changements de contrat. »

L’utilisateur qui lit le code produit par l’agent et se fait un avis à son sujet. Lire le diff ou les fichiers modifiés compte ; lire la description de l’agent ne compte pas — un récit n’est pas le livrable. Cette description est une source secondaire, rédigée par la partie examinée ; le diff est la source primaire, et une revue consiste à le lire.

Les agents augmentent le volume de code produit ; la revue devient donc le goulot d’étranglement. Une approche utile consiste à combiner plusieurs stratégies. Les vérifications automatisées détectent les erreurs mécaniques, la revue automatisée repère celles qui peuvent être décrites, et la revue humaine se concentre sur ce que vous seul pouvez juger : le changement est-il le bon, l’approche convient-elle à la codebase, ce changement devrait-il même exister ?

La revue coûte aussi moins cher lorsqu’elle a lieu tôt. Lire un plan avant le début du travail ou un petit diff en cours de route prend quelques minutes ; examiner une branche terminée après une exécution AFK prend plus de temps. Le moment choisi pour le point de contrôle est une décision avec un humain dans la boucle, pas une réflexion après coup.

À éviter : « revue de code » sans précision — l’expression peut désigner une revue humaine ou automatisée.

Exemple d’utilisation :

« J’ai examiné humainement le résultat de l’exécution AFK. »

« Vous avez lu le diff ou seulement le résumé ? »

« Le diff. Le résumé disait que le code mort avait été supprimé ; en réalité, la fonction était appelée depuis un fichier généré. »

Un mode de travail où l’utilisateur accepte le code de l’agent sans revue humaine. Le diff est traité comme une boîte noire : seul compte le comportement du programme, pas son contenu. Une revue automatisée et des vérifications automatisées peuvent toujours être exécutées ; le codage au feeling ne se prononce ni sur l’une ni sur les autres.

Le terme vient d’Andrej Karpathy, qui l’a forgé au début de 2025 : vous « vous abandonnez complètement aux vibes » et « oubliez même que le code existe » — décrivez ce que vous voulez, acceptez le résultat et évaluez-le en l’exécutant.

Le codage au feeling échange l’inspection contre la vitesse. La lecture des diffs est généralement l’étape la plus lente du travail piloté par un agent ; la supprimer élimine donc le principal goulot d’étranglement. Pour du code dont les défaillances coûtent peu — prototypes, scripts ponctuels, outils internes — c’est un compromis raisonnable. Le risque augmente avec la durée de vie et les enjeux du code.

Le coût apparaît plus tard. Les changements réalisés au feeling s’accumulent dans une codebase que personne n’a lue, et seul le comportement a été vérifié : tout ce qu’il ne révèle pas — secret écrit dans les journaux, cas limite oublié ou traitement des données discrètement erroné — est livré sans être vu. La première fois que quelqu’un débogue le système est aussi la première fois que quiconque lit le code. Sans revue humaine, seules les vérifications automatisées encore exécutées — tests, types, revue automatisée — filtrent le code. Appliqué à toute une codebase, ou à une partie dont les modifications viennent d’une usine logicielle, le même mode de travail constitue une usine obscure.

À éviter : utiliser « codage au feeling » comme synonyme de « codage IA de mauvaise qualité » — le terme désigne la posture de revue, pas la qualité du code obtenu.

Exemple d’utilisation :

« As-tu lu les modifications apportées au flux d’authentification ? »

« Je l’ai fait au feeling — la connexion fonctionne toujours, c’est tout ce que j’ai vérifié. »

« Lis le diff avant de pousser ; improviser sur l’authentification, c’est comme ça que des secrets finissent dans les journaux. »

La compréhension commune de ce qui est en cours de construction, partagée par l’utilisateur et l’agent, mais distincte de tout livrable. Le terme vient de Brooks (The Design of Design) : la conversation, les artefacts de transfert et le code sont tous des livrables qui tentent de saisir ou d’atteindre le concept de conception, mais aucun ne l’est. La qualité de ce concept se ressent dans la qualité de la conversation qui l’a construit.

Le terme nomme l’écart à l’origine d’une frustration familière : l’agent écrit exactement ce que vous avez demandé et le résultat est pourtant mauvais. La cause habituelle est que vous n’aviez pas encore entièrement défini ce que vous vouliez. Le concept de conception n’était pas achevé dans votre esprit : votre invite exprimait les éléments que vous aviez clarifiés et ne disait rien de ceux qui ne l’étaient pas. L’agent a comblé ces silences par ses propres hypothèses, faute de repères communs. Rien n’a dysfonctionné. Aucun concept de conception n’était partagé, car aucun n’était encore assez complet pour l’être.

Vous pouvez reconnaître un concept de conception partagé comme avec un collègue : l’autre commence à répondre aux questions que vous n’avez pas encore posées, comme vous l’auriez fait. Jusque-là, le travail relève de la conversation — le grillage en est la version délibérée — et rédiger trop tôt une spécification ne ferait qu’inscrire le désaccord dans un livrable plus durable. Le concept de conception évolue aussi avec vos apprentissages ; les livrables prennent du retard. Une spécification fidèle à la compréhension de la semaine passée peut donc induire en erreur la session de cette semaine.

Exemple d’utilisation :

« Il écrit exactement ce que j’ai demandé et le résultat est quand même mauvais. »

« Vous ne partagez pas encore le même concept de conception : l’agent comble les lacunes par des suppositions. Continuez à en discuter jusqu’à ce que vous soyez d’accord sur les annulations, les remboursements et les commandes partiellement exécutées avant de lui faire rédiger une spécification. »

Une technique de conception d’un concept de conception avec un agent : l’agent interroge l’utilisateur de manière socratique, une décision à la fois, en proposant une réponse recommandée pour chacune. Elle ralentit la précipitation vers un plan terminé — aucun artefact de passation n’est rédigé tant que le concept n’est pas stabilisé.

Cette technique existe parce que les agents comblent silencieusement les lacunes. Si on leur demande de rédiger une spécification à partir d’une consigne de deux lignes, ils ne s’arrêtent pas aux décisions que vous n’avez pas prises : ils choisissent des valeurs par défaut et les inscrivent. Le résultat paraît complet, et les suppositions sont impossibles à distinguer des choix ; vous les découvrez donc tard, lors de la revue ou lorsque la fonctionnalité construite traite un cas limite d’une manière que vous n’aviez jamais choisie. L’entretien socratique inverse la démarche : au lieu de deviner, l’agent doit poser des questions.

C’est une technique avec humain dans la boucle : vos réponses constituent les entrées. Lorsqu’une question ne peut pas être résolue en conversation — il faudrait voir le résultat — passez au prototypage.

Exemple d’utilisation :

« Il s’est lancé directement dans la rédaction de la spécification et a mal compris la logique d’annulation. »

« Fais-le d’abord préciser ses hypothèses — demande-lui de m’interroger une décision à la fois avant d’écrire quoi que ce soit. »

Faire construire rapidement par l’agent une version sommaire de quelque chose, lorsque la conversation manque de fidélité et qu’il faut un véritable livrable pour en discuter.

Le grillage permet de trancher des choix de conception au cours d’une conversation. La conversation ne coûte pas cher, mais elle manque de fidélité : certaines questions ne trouvent pas de réponse en mots — comment une interaction se ressent, si la forme d’une API est pratique dans le code qui l’appelle réellement, si la mise en page tient avec des volumes de données réalistes. L’entretien bute sur une question et votre réponse honnête est : « Je ne sais pas, il faudrait que je le voie. » À partir de là, la discussion tourne en rond. Demandez plutôt à l’agent de construire l’objet, examinez-le et revenez à la conversation avec une réponse.

Les agents réduisent le coût de construction, ce qui rend cette démarche pratique. Un prototype sommaire qui demandait autrefois une journée de maquette peut désormais prendre quelques minutes ; cela vaut donc la peine d’en faire régulièrement. C’est une technique avec un humain dans la boucle : le prototype est là pour que vous puissiez réagir.

On ne s’arrête généralement pas à un seul examen. Itérez avec le prototype : réagissez, demandez une modification, réagissez de nouveau. Chaque cycle tranche une autre décision à partir du véritable livrable, avec une fidélité supérieure à celle qu’autorise une conversation.

Un prototype n’a pas nécessairement à être entièrement sommaire. Vous pouvez réaliser les éléments que vous évaluez à un niveau de qualité prêt pour la production ; une fois la décision prise, le composant ou l’API auquel vous avez réagi peut alors rejoindre la véritable codebase. Le prototypage fournit ainsi une matière essentielle à laquelle la spécification peut se référer.

Exemple d’utilisation :

« Nous débattons depuis une demi-heure pour savoir si l’assistant de configuration doit tenir sur une page ou comporter trois étapes. »

« Les mots ne suffiront pas à trancher : demandez à l’agent de prototyper les deux options. Nous les essaierons et nous saurons en cinq minutes. »

L’expérience développeur — la facilité avec laquelle une codebase et sa chaîne d’outils permettent aux humains de bien travailler. Une bonne DX se traduit par des retours rapides, des messages d’erreur clairs, une documentation qui répond à la question que vous vous posez réellement et une configuration qui fonctionne du premier coup. Le terme est bien antérieur au codage par IA ; il figure surtout dans ce dictionnaire pour servir de point de comparaison avec l’AX.

La DX désigne uniquement l’interaction entre l’humain et la codebase. La principale différence entre les deux publics est que les humains sont stateful, tandis que les agents sont stateless. Un humain apprend la codebase une fois et conserve ce savoir par la suite. C’est pourquoi une DX médiocre reste supportable : il contourne une CI lente en regroupant ses pushs, compense l’absence de documentation en posant une fois la question sur Slack et s’adapte à une structure confuse en mémorisant l’emplacement des éléments. Ces solutions de contournement s’accumulent, et l’équipe finit par être productive dans une codebase qui lui résiste.

Les agents doivent travailler dans la même codebase sans bénéficier de ces acquis. Sans état d’une session à l’autre, un agent réapprend la codebase depuis le début à chaque fois. Il profite d’une suite de tests rapide et de messages d’erreur clairs, mais tout ce qu’il a compris la veille disparaît si cela n’a pas été consigné dans l’environnement, que l’agent ne perçoit qu’au moyen des résultats d’outil. C’est ce que désigne l’AX : les aspects de la DX qui subsistent lorsque le développeur est un agent, auxquels s’ajoutent des préoccupations propres aux agents, comme préserver de l’espace dans la fenêtre de contexte.

Le chevauchement signifie qu’un investissement dans la DX améliore souvent l’AX sans effort supplémentaire : des types stricts, des tests rapides et une structure prévisible aident les deux publics. Mais les besoins divergent parfois : une excellente documentation d’intégration aide un humain pendant une semaine, mais pas du tout un agent si elle n’est pas accessible depuis AGENTS.md.

Exemple d’utilisation :

« Notre DX est correcte : les nouvelles recrues sont productives en une semaine. »

« Elles sont productives parce que quelqu’un les accompagne pendant cette semaine. L’agent ne dispose pas de cette semaine ; évaluez l’AX séparément. »

L’expérience agent — la qualité de la configuration de l’environnement pour permettre à un agent de bien travailler dans une codebase. C’est le pendant côté agent de l’expérience développeur (DX). Quand le même agent réussit dans un dépôt et échoue dans un autre — avec le même modèle et le même harness — la différence tient généralement à l’AX. Le premier réflexe est d’accuser le modèle ou de réécrire l’invite ; la solution se trouve plus souvent dans le dépôt.

Une bonne AX repose sur trois dimensions principales :

AX et DX se recoupent — de bons contrôles et une architecture claire aident les deux publics — mais elles divergent aussi. Les humains tolèrent les connaissances tribales, une CI lente et « demande à Sarah pour le module de facturation » ; les agents ne le peuvent pas. Les info-bulles d’un IDE et les jolis tableaux de bord ne leur servent pas ; ils ont besoin que les échecs leur parviennent sous forme de texte dans un résultat d’outil. Une codebase peut offrir une bonne DX et une AX médiocre.

À éviter : traiter AX comme un synonyme de DX — les deux publics nécessitent des investissements différents.

Exemple d’utilisation :

« L’agent écrit du bon code dans le dépôt API et n’importe quoi dans le front-end. »

« Le dépôt API a des types stricts et une suite de tests rapide ; le front-end n’a ni l’un ni l’autre et charge quarante compétences en permanence. C’est un déficit d’AX, pas un problème de modèle. »

Un système de travail où les sessions d’agent démarrent à partir de déclencheurs — création d’un ticket, planification, échec CI, fin d’une autre session — plutôt qu’à l’initiative d’un humain. Une plus grande part du travail s’exécute ainsi hors clavier, et l’attention humaine se concentre sur les décisions avec humain dans la boucle qui restent à prendre.

Sans usine, chaque session commence parce que quelqu’un l’a lancée. Même un travail entièrement hors clavier attend qu’une personne ouvre la session, l’oriente vers le ticket et la mette en marche. Les équipes veulent livrer davantage que cela ne le permet. Une usine retire l’humain du démarrage des sessions, sans nécessairement le retirer du reste.

Déclencheurs courants et sessions qu’ils lancent :

Une usine n’a pas à couvrir tout le processus logiciel. Un seul cron qui lance un type de session et ouvre une PR vérifiable constitue déjà une usine. Commencer petit est utile : une boucle étroite produit de petites PR similaires, et leur revue montre jusqu’où on peut faire confiance à la boucle avant de l’élargir.

Les humains peuvent intervenir à n’importe quelle étape d’une usine : rédiger et étiqueter les tickets déclencheurs, approuver un plan avant le début de l’implémentation, effectuer une revue humaine avant la fusion. La principale question de conception consiste à décider lesquelles de ces décisions restent humaines. Une codebase, ou une partie de celle-ci, dont aucun humain n’examine les résultats de l’usine est une usine obscure.

Exemple d’utilisation :

« Qui a corrigé toutes les violations `no-floating-promises` ? »

« L’usine. Le cron prend une règle de lint par nuit et ouvre une PR. Je la relis le matin. »

Un dépôt de code, ou une partie de celui-ci, dans lequel une usine logicielle écrit le code sans qu’aucun humain ne le lise. Il n’y a pas de revue humaine. Les humains peuvent toujours rédiger les tickets qui lancent le travail, mais personne ne lit le code produit. Le nom vient des usines « lights-out », qui fabriquent des produits sans personne sur place.

Une usine obscure applique le codage au feeling à un domaine du code, et non à une seule modification. Quand vous codez au feeling, vous choisissez de ne pas lire une modification que vous avez demandée. Mais vous savez qu’elle existe. Dans une usine obscure, l’équipe fait ce choix une fois pour tout le domaine. Ensuite, personne ne demande chaque modification ni ne la voit. Les changements arrivent aussi vite que les déclencheurs lancent de nouvelles tâches.

Le problème apparaît quand quelque chose casse. Vous ne savez pas ce qui a changé, puisque personne n’a lu les changements. Vous devez déboguer du code que personne dans l’équipe n’a lu. La cause peut se trouver dans n’importe laquelle des nombreuses modifications, et chacune a passé les contrôles.

Les vérifications automatisées et la revue automatisée sont les seuls garde-fous. Si elles ne trouvent aucun problème, celui-ci entre dans le code.

À éviter : qualifier un dépôt de code d’« obscur » uniquement parce que son usine fonctionne sans surveillance. Si les sessions d’agent s’exécutent hors clavier et qu’un humain examine leurs PR, il s’agit d’une usine logicielle, pas d’une usine obscure.

Exemple d’utilisation :

« Qui a modifié la logique de nouvelle tentative dans le service de facturation ? Personne dans l’équipe ne s’en souvient. »

« Le service de facturation est une usine obscure. Les agents fusionnent tous les changements qui passent CI. Personne n’a lu cette modification. »