Glossaire

Développement logiciel assisté par IA générative

Ce glossaire s'adresse à ceux qui conçoivent, produisent et de fait gèrent du logiciel ou des produits digitaux en utilisant l'IA générative.

Général

Agentic SDLC

Cycle de vie logiciel réorganisé autour d'agents comme exécutants de premier rang plutôt que comme assistants ponctuels : tickets structurés comme intrants d'agent, spécifications versionnées comme source de vérité, intégration continue comme oracle de vérification, revue humaine comme point de contrôle principal. Le terme circule largement depuis 2025 ; son contenu exact varie selon les auteurs.

Agentic PDLC

Extension de la logique agentique au cycle produit complet, en amont et en aval de la construction : processus de bout en bout, rôles, systèmes de vérification et instruments de mesure réorganisés autour d'agents. Se distingue de l'agentic SDLC, qui ne couvre que la phase de construction. Terme émergent, encore peu répandu hors du conseil.

Spec-Driven Development (SDD)

Méthode dans laquelle un artefact écrit et versionné, et non l'historique de conversation, fait office de source de vérité pilotant l'implémentation. Se distingue d'un prompting bien documenté par le statut de cet artefact, relu, versionné et modifié comme du code. Les critères de qualité en découlent : testable plutôt qu'exhaustif, versionné avec le code plutôt que gelé en amont. Chaîne d'artefacts usuelle : constitution ou steering (règles permanentes), spec (quoi), plan (comment), tasks (étapes). Outils de référence : Spec Kit (GitHub), Kiro (AWS), OpenSpec, BMAD-METHOD.

Spec drift / living spec

Écart entre la spécification servant de source de vérité et le code livré, qui se creuse lorsque les modifications de l'un ne sont pas reportées dans l'autre. Risque propre au Spec-Driven Development : une spec non tenue redevient un prompt daté, et l'agent qui la relit reproduit des décisions pourtant abandonnées. La bonne pratique consiste à modifier la spec dans la même revue que le code. Terme descriptif, usage non stabilisé. Connexe : living documentation.

Artifact status : statut de l'artefact généré

Convention d'équipe déterminant si un artefact produit par IA est une exploration jetable, une spécification vivante ou du code à reprendre et maintenir. Question devenue nécessaire dès lors que produire un artefact fonctionnel coûte des minutes plutôt que des jours ; sans réponse explicite, un prototype devient l'architecture par défaut en transportant des décisions implicites que personne n'a prises. Terme descriptif.

Ownership of generated code : propriété du code généré

Attribution explicite de la responsabilité du code produit par IA : qui en répond, qui le maintient, qui le signe en revue. Question distincte du statut de l'artefact, qui porte sur ce qu'est l'objet ; celle-ci porte sur qui en hérite. Devient un objet de négociation dès lors que du code est généré hors de l'équipe qui le maintiendra. Terme descriptif.

Le modèle comme contrainte matérielle

Token / Tokenization : tokenisation

Découpage du texte en unités sous-lexicales traitées par le modèle, qui détermine à la fois la facturation et l'occupation de la fenêtre de contexte. Un token vaut environ 0,75 mot en anglais et sensiblement moins en français. Les tokens de sortie sont typiquement facturés plusieurs fois plus cher que ceux d'entrée.

Context window : fenêtre de contexte

Quantité maximale de tokens traitée en une passe d'inférence. À distinguer de l'effective context length, portion de cette fenêtre sur laquelle le modèle reste réellement performant : la limite affichée n'est pas la limite utile, comme le décrit l'entrée context rot.

Non-determinism : non-déterminisme

Absence de garantie qu'une même entrée produise une même sortie, y compris à température nulle, du fait du batching côté serveur, de la non-associativité du calcul flottant sur GPU et du routage des modèles à experts. Interdit de fonder une chaîne de production sur la reproductibilité exacte des sorties. Connexes : reproducibility, seed, batch invariance.

Knowledge cutoff : date de coupure des connaissances

Date au-delà de laquelle le modèle ignore l'état du monde, et donc les versions récentes de bibliothèques, API et frameworks. Un modèle qui code contre une API obsolète n'hallucine pas : il applique ce qu'il a appris. Le remède est de fournir la documentation à jour dans le contexte, non de changer de modèle.

Hallucination

Génération d'un contenu plausible mais faux : API inexistante, signature de méthode inventée, dépendance fictive. Une partie de la communauté de recherche emploie confabulation, jugé moins anthropomorphique. Terme fréquemment employé comme explication générique là où la cause réelle est un contexte insuffisant ou une date de coupure dépassée.

Local inference / open-weights : inférence locale

Exécution d'un modèle sur son propre matériel ou sa propre infrastructure, pour des motifs de confidentialité, de coût ou de souveraineté. Trois notions distinctes et couramment confondues : on-device (poste du développeur), self-hosted / on-prem (infrastructure maîtrisée), open-weights (poids distribués, ce qui n'implique pas une licence libre).

Multimodality : multimodalité

Capacité d'un modèle à traiter image et texte dans un même contexte. Ouvre des usages concrets en développement : capture d'interface à reproduire, capture d'erreur, schéma d'architecture. Une image reste toutefois opaque à la recherche textuelle de l'agent et ne se versionne pas comme du texte : ce qui doit être retrouvé ou relu plus tard se transcrit.

Ingénierie du contexte

Context engineering : ingénierie du contexte

Discipline consistant à concevoir l'ensemble de l'environnement informationnel du modèle : instructions persistantes, contexte récupéré, définitions d'outils, historique. Ombrelle qui englobe le prompt engineering, lequel en est un sous-ensemble et non l'inverse. Terme popularisé par Andrej Karpathy à partir de juin 2025.

Context rot / context degradation

Dégradation de la qualité des réponses à mesure que le contexte se remplit, bien avant la limite affichée. Sur des tâches de code, une récupération ciblée de quelques milliers de tokens peut battre un résumé exhaustif de plusieurs dizaines de milliers : la question opérante n'est pas quoi fournir, mais quoi évincer. Connexes : lost in the middle, needle-in-a-haystack, positional bias, context poisoning.

System prompt : prompt système

Instruction racine définissant de manière persistante le rôle, les règles et le comportement du modèle. N'est jamais une frontière de sécurité : ce qui doit être empêché doit l'être hors du modèle. La nomenclature OpenAI parle de developer message.

Reasoning models / extended thinking

Modèles produisant une chaîne de raisonnement avant de répondre. La chain-of-thought (CoT) reste la notion conceptuelle de référence mais est désormais intégrée au modèle plutôt qu'induite par le prompt : la variable de pilotage est devenue le thinking budget (vocabulaire Anthropic et Google, reasoning effort chez OpenAI), ou budget de calcul alloué à l'inférence. Connexe : test-time compute.

RAG (Retrieval-Augmented Generation) / agentic search

Augmentation de la génération par récupération d'information externe au modèle. Sur du code, l'agentic search, où l'agent explore le dépôt par recherche textuelle et lecture ciblée, concurrence sérieusement l'indexation vectorielle préconstruite. Plomberie associée : chunking, hybrid search, reranking, contextual retrieval.

Compaction / context offloading

Gestion active du contexte sur une session longue : résumé de l'historique, éviction des tours anciens, externalisation vers le système de fichiers. Notion sœur, la progressive disclosure consiste à ne charger l'information qu'au moment où elle devient nécessaire, c'est-à-dire à donner à l'agent les moyens d'aller chercher plutôt que le contenu lui-même.

Prompt caching : mise en cache du contexte

Réutilisation par le fournisseur du préfixe stable d'un contexte déjà traité, facturée à tarif réduit et servie plus rapidement. Levier de coût et de latence majeur en usage agentique, où le même contexte de départ est renvoyé à chaque tour. Suppose de placer en tête du contexte ce qui ne change pas. Connexes : cache hit rate, KV cache.

Agent instruction files : fichiers d'instructions projet

Contexte persistant versionné dans le dépôt : conventions, architecture, commandes de vérification, pièges connus. Point d'entrée le plus immédiat pour outiller une équipe, puisqu'il s'applique à toutes les sessions sans intervention et suit le code dans son historique. Formats de référence : AGENTS.md, CLAUDE.md, .cursor/rules (anciennement .cursorrules), copilot-instructions.md.

Agent Skills (SKILL.md)

Format de packaging d'expertise réutilisable, sous forme d'un dossier contenant instructions, scripts et ressources, qu'un agent découvre et charge à la demande. Apparu fin 2025, diffusé en 2026 comme standard portable entre outils. À distinguer de trois voisins : un skill encapsule une méthode, un serveur MCP expose des outils, un fichier d'instructions fixe des règles permanentes.

Architecture agentique

Tool use / Function calling : appel d'outils

Mécanisme par lequel le modèle émet un appel structuré qu'un exécuteur externe réalise, avant de lui retourner le résultat. Brique fondamentale de toute architecture agentique, dont la standardisation par protocole n'est qu'une couche supérieure. Tool use est le vocabulaire Anthropic, function calling celui d'OpenAI.

MCP (Model Context Protocol)

Protocole ouvert standardisant l'exposition d'outils, de ressources et de prompts à un modèle, quel que soit le client. Standardisation de l'appel d'outils, non substitut : ce qui est exposé par un serveur MCP reste un outil au sens de l'entrée Tool use. Notions internes : serveur / client, transport (stdio, HTTP), tools vs resources vs prompts.

Agentic loop / harness : boucle agentique

Cycle raisonnement, appel d'outil, observation, itération, jusqu'à un critère d'arrêt. Le pattern fondateur est ReAct (Reasoning and Acting), formalisé en 2022. Le harness désigne l'enveloppe logicielle qui exécute cette boucle ; à modèle égal, il est souvent plus déterminant que le modèle lui-même. Se distingue du workflow, où l'enchaînement des appels est fixé par du code et non décidé par le modèle, et qui reste préférable dès que le chemin est prévisible. Distinction workflow / agent : Anthropic, « Building effective agents », décembre 2024. Connexe : harness engineering.

Harness engineering

Discipline consistant à concevoir l'enveloppe logicielle qui entoure un modèle pour en faire un agent : outils, permissions, instructions persistantes, bac à sable, points de contrôle et capteurs de retour sur l'effet de ses actions. Se distingue du prompt engineering, qui agit sur le texte envoyé au modèle, et de l'ingénierie du contexte, qui porte sur l'information fournie : l'objet est ici ce que l'agent peut faire et percevoir. Explique, à modèle égal, l'essentiel des écarts de résultat entre outils. Connexes : agentic loop / harness, feedback sensors, hooks, context engineering.

Plan mode / task decomposition : planification

Décomposition explicite d'un objectif en étapes vérifiables avant exécution, matérialisée par un mode distinct de l'exécution. Le plan constitue le point de contrôle humain le moins coûteux de la chaîne, très en amont de la revue de code.

Autonomy levels / Human-in-the-loop (HITL) : niveaux d'autonomie

Degré de liberté laissé à l'agent et placement des portes d'approbation dans son parcours d'exécution. La grille de décision utile classe les actions en réversibles, coûteusement réversibles et irréversibles, seule la dernière catégorie justifiant une validation systématique. Connexes : permission modes, approval gates, allowlist, checkpointing / rollback.

Subagents / orchestration

Délégation d'une sous-tâche à un agent au contexte isolé, dont seul le résultat est rapatrié dans le contexte principal. Principal mécanisme de passage à l'échelle actuel, l'isolation protégeant le contexte principal de la saturation. Patterns nommés : orchestrator-workers, evaluator-optimizer, context isolation.

Headless agents / long-horizon execution

Agents s'exécutant sans interface interactive, déclenchés par un ticket, un webhook ou la chaîne d'intégration, travaillant plusieurs dizaines de minutes voire plusieurs heures, et rendant un résultat sous forme de pull request. Déplacent le contrôle humain de la session vers la revue du résultat. Connexes : background agents, agent in CI.

Model routing : routage de modèles

Sélection du modèle selon la complexité, le coût, la latence ou la confidentialité de la tâche. Devient un levier d'arbitrage dès lors que ces quatre paramètres varient fortement d'une tâche à l'autre au sein d'une même session. Connexes : cascading, fallback, cost-aware routing.

Sandboxing : bac à sable

Isolation de l'environnement d'exécution de l'agent : conteneur, machine virtuelle, droits restreints, filtrage des sorties réseau. Conditionne le degré d'autonomie accordable sans revue préalable, puisqu'une action confinée et réversible n'appelle pas de porte d'approbation.

Non-human identity (NHI) : identité non humaine

Identité propre attribuée à un agent qui agit avec des identifiants (jetons Git, clés d'API, accès aux bases), assortie de droits minimaux, d'une traçabilité et d'une révocabilité distinctes de celles de son opérateur humain. L'identité machine préexiste, mais un acteur qui décide de ses actions et peut être détourné par les données qu'il lit pose un problème sans précédent exact.

Code completion vs agentic coding

Distinction entre deux régimes d'usage de l'IA sur du code : la complétion inline, qui suggère au fil de la frappe avec une revue implicite et continue, et l'agentic coding, qui planifie, édite plusieurs fichiers et exécute des commandes. Le second déplace la revue vers un contrôle explicite en fin de tâche, ce qui change le régime de responsabilité.

Risques, effets et contrôle

Verification loop : boucle de vérification

Ensemble formé par les tests, les types, les linters et l'intégration continue, considéré comme l'oracle par lequel un agent constate ses propres erreurs et se corrige. La durée de la chaîne d'intégration devient de ce fait une caractéristique de performance de l'agent, et non un simple confort d'équipe. Connexes : Test-Driven Development in the agentic loop, verification tax.

Test-Driven Development (TDD) in the agentic loop / tests as specification

Pratique consistant à écrire ou valider les tests avant l'implémentation, puis à laisser l'agent itérer jusqu'à ce qu'ils passent, les tests jouant le rôle de spécification exécutable. Se distingue de la boucle de vérification, qui contrôle après coup : ici le test précède et contraint la génération. Si l'agent produit à la fois le test et le code qui le satisfait, le test perd sa valeur de contrôle ; la relecture humaine se déplace donc vers les tests plutôt que vers l'implémentation. Terme descriptif, usage non stabilisé. Connexes : verification loop, reward hacking, Spec-Driven Development.

Reward hacking / specification gaming

Optimisation par l'agent du critère mesuré plutôt que de l'intention : supprimer un test qui échoue, commenter une assertion, encoder en dur la valeur attendue. Contrepartie directe de la boucle de vérification, puisque donner un oracle à un agent crée une incitation à le contourner. Connexes : goal drift, thrashing, sycophancy.

Evals : évaluation

Mesure systématique et reproductible de la qualité des sorties d'un système non déterministe. Sans elle, tout arbitrage sur les prompts, les modèles ou les workflows relève de l'anecdote. Connexes : LLM-as-a-judge, golden dataset, regression evals, rubric.

Benchmarks & contamination

Jeux de tâches standardisés servant à comparer les modèles sur du développement : SWE-bench et sa variante filtrée SWE-bench Verified, Terminal-Bench, Aider polyglot. Deux limites structurelles les affectent, la contamination, les jeux de test finissant dans les données d'entraînement, et l'écart entre tâche de benchmark et travail réel sur une base de code propriétaire.

Prompt injection : injection de prompt

Détournement d'un agent par des instructions dissimulées dans le contenu qu'il lit : ticket, page web, docstring, dépendance, sortie d'outil. Cadrage de référence, la lethal trifecta de Simon Willison réunit accès à des données sensibles, exposition à du contenu non fiable et capacité d'exfiltration : leur conjonction est un risque structurel qu'aucune amélioration de prompt ne corrige. À ne pas confondre avec le jailbreak, qui vise le modèle là où l'injection passe par les données.

Slopsquatting / package hallucination

Enregistrement par des attaquants, sur npm ou PyPI, de noms de bibliothèques que les modèles hallucinent de façon reproductible. L'hallucination devient ainsi une faille de chaîne d'approvisionnement, et rend nécessaire la vérification de l'existence et de la provenance de toute dépendance suggérée avant installation.

Vibe coding

Acceptation du code généré sans le lire. Terme d'Andrej Karpathy (février 2025), à conserver tel quel. Nomme par contraste ce que la pratique professionnelle n'est pas, et sert de repère pour fixer le statut de ce qui est produit ainsi. Connexe : augmented coding.

Augmented coding

Usage de l'IA générative dans lequel le développeur conserve la responsabilité du design, lit le code produit et maintient les propriétés du système (lisibilité, couverture de tests, cohérence de l'architecture) au même niveau d'exigence que sans assistance. Terme de Kent Beck (2025), proposé en contrepoint du vibe coding : la différence ne tient pas à la quantité de code généré, mais à ce que le développeur accepte de ne pas lire. Connexes : vibe coding, ownership of generated code, comprehension debt.

AI-readiness

Aptitude d'une base de code à être travaillée par un agent : documentation à jour, commandes de build et de test simples et rapides, conventions explicites, arborescence lisible, absence d'étapes manuelles non documentées. Levier au moins aussi déterminant que le choix du modèle ou de l'outil, et le plus souvent sous-estimé par rapport à eux. Terme descriptif. Connexe : agent instruction files.

Agent observability : observabilité agentique

Instrumentation d'une exécution d'agent, où chaque appel de modèle et d'outil devient un span horodaté rattaché à une trace. Sans elle, un échec d'agent est indébogable et la consommation intraçable. Prérequis de gestion d'incident et d'audit. Les conventions sémantiques OpenTelemetry GenAI tendent à s'imposer comme socle commun.

Cost per completed task : coût par tâche accomplie

Coût complet d'une tâche réellement terminée, réessais et revue humaine inclus. Seule base d'arbitrage sérieuse, là où le coût par million de tokens n'en est pas une. Indicateurs associés : taux de succès au premier essai, cache hit rate, part des tokens dépensés en réessais. Terme descriptif.

AI code review / LLM-as-reviewer : revue de code par IA

Relecture de changements de code confiée à un modèle, en complément ou en amont de la revue humaine. Efficace sur les défauts locaux (style, erreur manifeste, test manquant), elle ne vaut pas validation : un modèle relisant du code généré par un modèle partage ses angles morts, et l'accord de deux modèles n'est pas une preuve. La question d'équipe porte sur ce qu'une revue IA autorise à alléger, non sur ce qu'elle remplace.

Review bottleneck : goulot de la revue

Concentration de la contrainte de flux sur la revue humaine, l'implémentation s'étant compressée sans que la vérification et la validation suivent. Rend déterminantes des pratiques auparavant considérées comme de confort : taille des changements, commits atomiques, messages explicites. Terme descriptif. Connexe : verification tax / J-curve.

Verification tax / J-curve : taxe de vérification

Surcoût de relecture, de test et de validation induit par l'augmentation du volume de code généré, qui absorbe une part du temps gagné à la production. La courbe en J désigne la trajectoire correspondante à l'échelle de l'organisation : une baisse initiale de performance, le temps que vérification et livraison se réorganisent, avant un gain net. Un gain de vélocité brut n'est pas un gain de productivité tant que ce surcoût reste non mesuré. Vocabulaire issu des rapports DORA. Connexes : review bottleneck, cost per completed task, perceived vs actual velocity.

DORA metrics / SPACE : métriques DORA

Cadres de référence pour mesurer la performance de livraison logicielle et la productivité des développeurs, le premier par quatre indicateurs de débit et de stabilité, le second par cinq dimensions allant de la satisfaction à l'efficience. Aucun des deux ne compte le code produit, ce qui les rend utilisables là où ce volume cesse d'être la contrainte. Leur emploi suppose une mesure antérieure à l'introduction des outils, faute de quoi aucun effet n'est attribuable. Connexes : DORA AI Capabilities Model, developer experience (DevEx), perceived vs actual velocity.

Perceived vs actual velocity : vélocité perçue et vélocité réelle

Écart entre le gain de productivité ressenti et le gain mesuré. Les études disponibles le trouvent favorable au ressenti, avec des amplitudes très variables selon le contexte, et convergent sur un point : le gain n'est ni automatique ni uniforme, la dispersion entre équipes étant plus forte que l'effet moyen. Références : étude METR (2025) sur des développeurs expérimentés et sa révision de protocole (2026), rapports DORA. Connexe : code churn. Terme descriptif.

Code churn / duplication / AI slop

Dégradation mesurable d'une base de code sous l'effet d'une génération rapide et peu relue. Trois signaux la caractérisent : le churn, code réécrit ou supprimé peu après sa création ; la duplication, blocs copiés plutôt que factorisés ; le slop, contenu verbeux et approximatif accepté faute de lecture. Tous trois se lisent dans l'historique du dépôt, ce qui en fait les premiers indicateurs disponibles pour arbitrer l'usage d'un outil. Références : rapports GitClear sur la qualité du code assisté (2024 à 2026). Connexes : perceived vs actual velocity, maintainability gap.

Maintainability gap / refactoring budget

Écart croissant entre le volume de code produit et l'effort consacré à le restructurer, à en supprimer les doublons et à entretenir le code existant, observé dans les dépôts fortement assistés par IA. Se distingue du churn, qui mesure le code réécrit peu après sa création : ici le code reste, mais la maintenance qui le rendrait durable n'est pas faite. La réponse opérationnelle consiste à réserver une part de capacité au refactoring et à fixer un seuil d'alerte sur la duplication. Terme émergent, issu des rapports GitClear. Connexes : code churn / duplication / AI slop, comprehension debt.

Comprehension debt / cognitive debt

Perte de compréhension d'une base de code par l'équipe qui la maintient, à mesure qu'augmente la part de code qu'elle n'a ni écrit ni lu. Se distingue de la dette technique, qui porte sur la qualité du code : ici le code peut être correct et néanmoins inintelligible pour ceux qui en répondent, ce qui renchérit chaque évolution ultérieure. Termes en circulation, usage non stabilisé. Connexe : ownership of generated code.

Conditions d'usage de l'IA générative

Data retention / no-training clause : rétention des données

Régime contractuel définissant ce que le fournisseur conserve, réutilise ou emploie pour entraîner ses modèles. Le zero data retention (ZDR) désigne l'absence de conservation au-delà du traitement, la no-training clause l'engagement de ne pas réutiliser les données soumises pour l'entraînement. Détermine ce qui peut être soumis à quel outil, et motive la plupart des projets d'inférence locale.

Sovereign AI : souveraineté

Maîtrise de la localisation des traitements, de la juridiction applicable et de la dépendance à un fournisseur. Se décline en trois questions distinctes : où le calcul s'exécute, quel droit s'applique aux données traitées, et quelle est la capacité de substitution en cas de rupture d'accès. Arbitre des choix d'architecture, non seulement des choix contractuels.

EU AI Act

Règlement européen sur l'intelligence artificielle, structuré par niveaux de risque et assorti d'obligations spécifiques pour les modèles à usage général. Concerne le développement à deux titres : lorsque le logiciel produit intègre lui-même de l'IA, ce qui déclenche des exigences de documentation, de transparence et de gestion des risques, et lorsque l'outillage utilisé relève d'un fournisseur soumis à ces obligations. Calendrier d'application échelonné et sujet à ajustements : à vérifier à date.

Inference footprint : empreinte de l'inférence

Consommation énergétique et hydrique de l'exécution des modèles, distincte de celle de l'entraînement et appelée à la dépasser en cumulé à mesure que l'usage se généralise. Un usage agentique consomme davantage qu'un usage conversationnel, du fait des boucles, des réessais et du contexte renvoyé à chaque tour. Se répercute sur trois décisions : routage de modèles, budget de réessais, arbitrage local ou distant. Connexes : tokens par joule, PUE, WUE.

Output indemnification / IP du code généré

Statut juridique des sorties d'un modèle et garanties contractuelles associées. Trois points distincts : protégeabilité incertaine du code généré selon les juridictions, risque de reproduction de code sous licence contraignante, et indemnification, engagement par lequel certains fournisseurs couvrent leurs clients en cas de réclamation. Détermine ce qui peut être livré et sous quelles conditions. Connexes : license contamination, SBOM, attribution.

Shadow AI

Usage d'outils d'IA non validés par l'organisation, principalement via postes personnels et comptes gratuits. Se distingue du shadow IT classique par son ampleur, sa gratuité d'accès et le fait que la donnée sortante est du contenu de travail plutôt qu'un usage applicatif. La réponse le plus souvent recommandée est la mise à disposition d'une alternative acceptable, l'interdiction déplaçant l'usage sans le réduire.

Culture modèle

Notions natives de l'IA mais sans effet sur les décisions de développement courantes. Pour qui veut comprendre le fonctionnement.

Transformer / attention

Architecture fondée sur l'auto-attention, sous-jacente à tous les modèles de langage actuels. Explique pourquoi le coût de traitement croît plus que proportionnellement à la longueur du contexte, et pourquoi la fenêtre de contexte reste une ressource à économiser malgré son extension.

Parameters / weights : paramètres, poids

Nombre de coefficients appris par un modèle, exprimé en milliards. N'est plus un bon prédicteur de performance depuis la généralisation de la distillation et du post-entraînement ; dans les architectures à experts, le nombre de paramètres actifs par token importe davantage que le total affiché.

Mixture of Experts (MoE)

Architecture n'activant qu'une fraction des paramètres par token, via un routeur interne. Explique l'existence de modèles très volumineux mais rapides à l'inférence, l'écart entre paramètres totaux et actifs, et une part du non-déterminisme observé, le routage pouvant varier d'une exécution à l'autre.

Quantization : quantification

Réduction de la précision numérique des poids, sans réentraînement, pour diminuer l'empreinte mémoire et accélérer l'inférence. Condition pratique de l'exécution locale sur matériel courant. La perte de qualité, faible aux précisions usuelles, croît avec l'agressivité de la réduction et se manifeste d'abord sur les tâches longues, ce qui justifie un essai avant adoption.

Distillation

Transfert de capacité d'un grand modèle enseignant vers un modèle élève plus petit, entraîné à reproduire ses sorties. Explique qu'un modèle compact récent puisse dépasser un modèle plus volumineux mais plus ancien, et rend la date d'entraînement plus informative que la taille pour anticiper les capacités d'un modèle compact.

Fine-tuning

Réentraînement ciblé d'un modèle existant sur un corpus propre, pour lui transmettre un style, un format ou un domaine. Valeur opératoire faible pour une équipe de développement : le besoin identifié se résout presque toujours par du contexte.

Embeddings

Représentations vectorielles denses capturant la proximité sémantique entre textes ou fragments de code. Support technique de la recherche par similarité et de l'indexation vectorielle d'un dépôt, que la recherche textuelle agentique concurrence sur le code.

Fill-in-the-Middle (FIM)

Objectif d'entraînement propre au code, où le modèle apprend à compléter un trou en connaissant préfixe et suffixe. Mécanisme technique de la complétion inline en éditeur, qui explique que la qualité d'une suggestion dépende du code situé après le curseur autant qu'avant.

Scaling laws / test-time scaling

Relations empiriques entre calcul investi et performance obtenue. Le calcul dépensé au moment de l'inférence est devenu, avec les modèles de raisonnement, un levier de progression comparable à l'augmentation de la taille des modèles, ce qui déplace une part du coût de l'entraînement vers l'usage.

Logprobs

Probabilités attribuées par le modèle aux tokens qu'il génère. Support de plusieurs méthodes de détection d'incertitude, étant entendu que la confiance déclarée n'est pas la fiabilité réelle. Accessibles en appel direct d'API, rarement exposées par les outils agentiques.

Temperature : température

Paramètre d'échantillonnage contrôlant le caractère aléatoire de la sélection du token suivant ; une valeur basse favorise un résultat prévisible. Fixé par l'outil dans la plupart des usages agentiques, ce qui en fait un levier accessible surtout en appel direct d'API. Connexes : top-p / nucleus sampling, greedy decoding.

Zero-shot / few-shot / In-Context Learning (ICL)

Guidage par zéro, un ou quelques exemples de sortie attendue. Le terme-ombrelle académique est l'in-context learning : capacité du modèle à s'adapter depuis le seul contexte, sans mise à jour de ses poids. Valeur pratique décroissante, les modèles récents suivant l'intention sans exemples.

Construction d'outillage agentique

Notions qui deviennent opérantes lorsqu'une équipe passe de l'usage à la construction : serveur MCP exposant le système d'information interne, agent maison sur un SDK, harness d'orchestration, skills packagés pour l'organisation.

AI engineering

Discipline de construction d'applications qui intègrent un modèle de langage comme composant, couvrant la conception des prompts, la récupération d'information, l'appel d'outils, l'évaluation et le déploiement. Se distingue du développement assisté par IA, où le modèle est un outil de production du logiciel et non une partie du logiciel livré. Les deux se recouvrent dès qu'une équipe construit son propre outillage agentique : les exigences d'évaluation et d'observabilité de la première s'appliquent alors au second. Terme popularisé par l'ouvrage éponyme de Chip Huyen. Connexes : evals, agent observability, tool design.

Tool design : conception des outils

Rédaction des descriptions d'outils exposés à un agent, lues par un modèle et non par un compilateur. Nommage, granularité et qualité des messages d'erreur y importent davantage que le typage. Connexes : namespacing, tool search / lazy loading.

Structured outputs / JSON schema

Contrainte de la sortie d'un modèle à un schéma vérifiable. Condition d'intégration fiable dans une chaîne logicielle, là où du texte libre suppose un analyseur tolérant. Connexe : constrained decoding.

Idempotence et réversibilité

Propriétés à exiger des outils confiés à un agent, garantissant qu'un appel répété ou erroné reste sans conséquence durable. Base concrète du placement des portes d'approbation : une action idempotente et réversible peut être laissée à l'agent, une action irréversible appelle une validation.

Retry management : gestion des reprises

Dispositif encadrant le comportement d'un agent en échec : reprise sur erreur, limitation des boucles, budgets d'exécution, critères d'arrêt. Détermine le coût plancher d'une tâche qui échoue, et distingue un échec franc, peu coûteux, d'une boucle qui consomme sans converger.

Runtime guardrails : garde-fous d'exécution

Filtres appliqués hors modèle aux entrées et sorties : détection de secrets, blocage de commandes destructrices, restriction réseau. Seul niveau où une interdiction est réellement opposable, le prompt système ne l'étant pas.

Agent interoperability : interopérabilité entre agents

Protocoles de communication entre agents de fournisseurs différents, dont A2A. Conditionne le risque de verrouillage sur un écosystème unique. Se distingue de MCP, qui relie un modèle à des outils et non des agents entre eux. Standard non stabilisé.

Model card / version pinning

Documentation publiée par le fournisseur sur les capacités et limites d'un modèle, et épinglage d'une version datée plutôt que d'un alias glissant. Sans épinglage, un déploiement stable peut changer de comportement sans intervention ; avec, la mise à jour redevient une décision, à accompagner d'evals de non-régression.

Cet en-tête est saisi à la main, comme toute cette page : elle est rédigée de bout en bout, et ne porte aucun bloc calculé.