Le lexique du métier

Un agent qui mène une tâche entière sans surveillance, au lieu d’avancer tour par tour sous vos yeux. Ce qui change quand personne ne regarde, c’est le modèle de sécurité : garde-fous, budgets et isolation assurent la supervision que vous ne faites plus.

Un modèle mis en boucle et équipé d’outils : il lit, agit, observe, recommence. Le passage de l’autocomplétion à l’agent : il ne se contente plus de suggérer du texte, il agit dans votre projet et réagit au résultat.

Le mécanisme par lequel le modèle pondère les tokens qui comptent pour produire le suivant. Une ressource limitée, qui se dilue à mesure que la fenêtre se remplit. Plus de contexte, ce n’est pas toujours mieux : l’attention s’étale, et chaque token en reçoit moins.

Votre biais à vous, pas celui du modèle. Une sortie fluide et bien formatée passe pour correcte. Le danger : la plausibilité baisse votre garde au moment précis où la vérification compte le plus.

Le cycle « lire, agir, observer » qui définit un agent : il inspecte l’état, agit via un outil, lit le résultat, décide de la suite. C’est la boucle qui produit le travail, pas le modèle seul.

Le pipeline où un agent prend une issue, l’implémente et ouvre une pull request à relire. L’unité de travail autonome à l’échelle d’une équipe.

Tout ce que le modèle voit dans la session : votre prompt, les fichiers, les tours précédents, la sortie des outils. Le modèle n’a pas de mémoire d’une session à l’autre. Le contexte, c’est ce que vous reconstruisez à chaque fois. Et tout s’y dispute la place, token par token.

Un test lu comme un énoncé qui engage : voici le comportement attendu. Qui écrit le test tient le contrat. C’est pour ça que sur les chemins critiques, vous l’écrivez vous-même, au lieu de laisser l’agent à la fois construire et définir ce qui est correct.

De la dette technique produite vite par un agent. Le taux d’intérêt a changé : la dette engendre la dette, parce que la facilité à générer pousse à en empiler plus qu’on ne peut rembourser à la main.

L’ensemble des changements proposés à la revue. Mais le diff ne dit pas tout : ne lire que lui, c’est rater la trajectoire, comment l’agent y est arrivé et ce qu’il a touché en chemin.

Le processus, en amont et hors ligne, qui a produit les poids du modèle à partir d’un corpus. Tout est figé au moment où vous l’utilisez. L’entraînement et l’inférence, ce sont deux moments qui ne communiquent pas.

Le plafond de tokens qu’un modèle garde en tête le temps d’une session. Une limite dure, pas une mémoire : une fois pleine, il faut couper quelque chose ou repartir de zéro. Les grandes fenêtres déplacent le plafond. Elles ne le suppriment pas.

Le contrat d’entrée du projet pour un agent (CLAUDE.md, par exemple) : le contexte permanent qu’il lit au début de chaque session. C’est par là qu’un projet explique à chaque nouveau venu, humain ou agent, comment on fait ici.

Une sortie confiante et plausible, mais fausse. Le modèle optimise la plausibilité, pas la vérité. Le résultat : une erreur fluide, bien tournée, qu’on ne repère pas au premier coup d’œil.

Le moment où le modèle tourne sur votre entrée pour produire une sortie. L’usage en direct, par opposition à l’entraînement : le modèle n’apprend rien de votre session, et votre session ne change rien au modèle.

Un environnement par agent, pour que des agents concurrents ou autonomes ne se marchent pas dessus : une sandbox ou un worktree qui contient le rayon d’explosion quand ça tourne mal.

Le vocabulaire partagé et précis d’un projet. C’est une interface : un langage du domaine cohérent fait converger humains et agents sur le même sens. Et c’est une des formes de contexte les moins chères à donner.

Un grand modèle de langage. Un système entraîné à prédire le prochain token à partir d’énormes quantités de texte. Il ne « connaît » pas des faits et n’interroge pas votre dépôt : il génère la suite la plus plausible. « Modèle », c’est le raccourci qu’on emploie au quotidien.

Le répertoire d’actions d’un agent : lire un fichier, lancer une commande, chercher, éditer. La description d’un outil est elle-même un prompt. La façon dont vous le nommez et le documentez décide si l’agent s’en sert correctement.

La responsabilité du code que vous livrez, peu importe qui l’a écrit, humain ou modèle. Le code généré a un auteur : celui qui le soumet. L’ownership ne se transfère pas au modèle, et il ne se délègue pas.

Le rayon d’action de l’agent : ce qu’il a le droit de faire sans demander. Trop serré, vous validez chaque étape. Trop large, il agit là où vous voudriez un contrôle. Les permissions, c’est là que vous tracez cette ligne.

Un dry run de l’approche de l’agent avant qu’il n’écrive du code : l’occasion d’attraper le malentendu pour pas cher. Pour les grosses tâches, le plan d’abord. C’est bien moins cher de corriger un plan qu’un diff.

Les étapes d’entraînement qui viennent après le modèle de base : le fine-tuning sur instructions, l’alignement, et le post-entraînement agentique qui rend un modèle bon à l’usage des outils et au travail en plusieurs étapes. Pas seulement à compléter du texte.

Une routine réutilisable et nommée qu’on passe à un agent à la demande (une commande, un skill) : du savoir-faire encapsulé. Le rituel devient une commande, au lieu d’un paragraphe qu’on retape à chaque fois.

L’entrée que vous donnez au modèle. Pour du vrai travail, traitez-le comme une spécification : sensible à la formulation, c’est un artefact qu’on travaille, pas un message qu’on jette.

Un relecteur IA dans le pipeline : un relecteur de plus, pas un juge. Il élargit la couverture et attrape l’évident. Mais il ne porte pas l’ownership, et il ne remplace pas le verdict humain.

Un service externe qui expose des outils à un agent via un protocole (MCP). C’est comme ça qu’on branche un agent sur le monde extérieur : une base de données, une API, un gestionnaire de tickets, au-delà du shell qu’il a déjà.

Une sortie générée de mauvaise qualité, qui a l’air correcte et ne l’est pas : du code plausible, redondant, hors conventions ou faux en douce. Une des formes de la dette générée, avec la duplication et la divergence.

Un énoncé précis de ce que vous voulez et de la façon dont ce sera vérifié, qui ferme l’espace des solutions, surtout en négatif (ce qu’il ne faut pas faire). Un artefact, pas une phrase. Plus vous déléguez, plus elle porte le poids.

La tendance du modèle à vous suivre : approuver, valider votre cadrage, produire ce que vous semblez attendre plutôt que ce qui est juste. Demandez-lui « c’est bon ? » et vous le poussez vers le oui.

Un test qui ressemble à de la couverture et ne vérifie rien : il affirme l’évident, n’exerce jamais le vrai chemin. Facile à générer en masse pour un agent. Pire qu’aucun test, parce qu’il achète une fausse confiance.

Le token, c’est l’unité que le modèle lit et facture. Un fragment de mot : plus petit qu’un mot, plus gros qu’une lettre. Tout ce que vous envoyez et tout ce que le modèle répond se compte en tokens. C’est le compteur sur lequel vous payez.

Conduire un agent au feeling, accepter sa sortie sans la lire. Pratique pour du jetable, corrosif sur ce qu’on devra maintenir : à la fin, personne ne comprend ce qui est parti en prod. Lu honnêtement, c’est un mode, pas une méthode.