Note de référence

Six schémas, cinq altitudes, un seul métier

Les visuels qui circulent sur l'ingénierie d'agents mélangent des choses qui ne se situent pas au même endroit : un protocole de communication, une discipline de conception, un motif d'orchestration, une architecture de production, une bibliothèque d'implémentation, une technique de récupération. Cette note les remet chacun à sa place, corrige ce qui a vieilli — et il y en a — et propose, pour chacun, le vocabulaire français correspondant.

ObjetVocabulaire et cadre de lecture
Auteuruniy — studio d'architecture de systèmes agentiques
Sources vérifiées le18 août 2026
À réviser avantdécembre 2026

00Cadre

Ces schémas ne parlent pas de la même chose

La confusion la plus coûteuse, dans les discussions sur l'IA agentique, consiste à traiter comme concurrents des objets qui vivent à des altitudes différentes. On entend débattre de « MCP ou multi-agents » comme on débattrait de « prise électrique ou plan de maison ».

Les six visuels rassemblés ici forment, sans le dire, un empilement assez propre. Tout en bas, la question de la prise : par quel protocole une pièce du système parle-t-elle à une autre — c'est MCP, c'est A2A. Juste au-dessus, la question de la méthode : que met-on devant le modèle, et selon quelle discipline — l'axe qui va du prompt au contexte puis au harness. Ensuite la question du motif : un seul agent, ou un orchestrateur qui délègue. Puis celle de l'architecture : tout ce qu'il faut ajouter autour pour qu'un système tienne en production et se gouverne. Enfin celle de l'implémentation : le code qui fait réellement tourner la boucle. Et traversant tous ces niveaux, une technique particulière qui mérite son propre traitement, la récupération d'information — le RAG.

Poser cet empilement change la manière de conduire un atelier. On ne choisit pas entre ces niveaux ; on les traverse tous, dans cet ordre, et une décision prise à un niveau contraint ceux du dessus sans jamais les remplacer.

Les cinq altitudes de l'ingénierie d'agents Cinq bandes empilées de bas en haut : le protocole (MCP, A2A), la méthode d'ingénierie (prompt, contexte, harness), le motif d'orchestration (agent unique ou orchestrateur et sous-agents), l'architecture système (les neuf couches de production), l'implémentation (la boucle d'agent du SDK). Une bande verticale transversale à droite porte la récupération d'information, le RAG, qui concerne les cinq niveaux. AltitudeCe que le niveau décideTransverse Implémentation Le code qui exécute la boucle — garde-fous, hooks, arrêts 05Le moteur Architecture système Observabilité, fiabilité, gouvernance, infrastructure 04La maison Motif d'orchestration Un agent, ou un orchestrateur qui délègue à des spécialistes 03Le plan Méthode d'ingénierie Ce qu'on met devant le modèle, et ce qu'on lui retire 02Le geste Protocole Par quelle prise les pièces se parlent — MCP, A2A 01La prise Récupération RAG, recherche hybride, agentique traverse les cinq
Une décision au niveau de la prise — choisir MCP pour exposer un outil — ne dit rien du motif d'orchestration ni de l'architecture de production. C'est en confondant ces niveaux qu'on achète un protocole en croyant acheter un système.
Ce que la note fait

Remettre à sa place

Chaque schéma est rendu à son altitude, et le vocabulaire qu'il porte est défini une fois pour toutes dans le glossaire.

Ce que la note fait

Corriger

Plusieurs de ces visuels décrivent un état du monde révolu. Onze corrections sont recensées en fin de note, avec leurs sources.

Ce que la note ne fait pas

Prescrire une pile

Aucun de ces motifs n'est bon en soi. Le choix se dérive du cas d'usage mesuré, jamais de l'élégance du schéma.

01La prise

MCP et A2A : deux prises, deux étages

Le premier schéma oppose deux protocoles comme s'il fallait trancher. Leurs auteurs respectifs disent l'inverse depuis le début : l'un branche un agent sur des outils, l'autre branche des agents entre eux. Ils s'empilent.

MCP, le Model Context Protocol, résout un problème d'intégration très concret. Avant lui, connecter un modèle à un système d'information supposait d'écrire une glu propriétaire par couple modèle-outil : autant de connecteurs que de produits, à refaire à chaque changement de fournisseur. MCP standardise la déclaration : un serveur MCP expose des outils, des ressources et des invites, un client MCP les découvre et les appelle, et le modèle décide seul lequel employer. La décision reste au modèle, l'exécution revient au client — cette séparation est le cœur du protocole et c'est aussi, on le verra en section 05, l'endroit où l'on peut poser un point de contrôle humain.

A2A, l'Agent2Agent Protocol, résout un problème d'un tout autre ordre : faire coopérer des agents qui n'appartiennent pas au même éditeur, ne tournent pas sur la même infrastructure et n'ont aucune raison de partager leur contexte interne. Un agent y publie une carte d'agent décrivant son identité et ses compétences ; un autre lui confie une tâche, objet à cycle de vie propre ; ils échangent des messages et le travail rendu prend la forme d'artefacts. On reconnaît là le vocabulaire d'une frontière contractuelle entre organisations, pas celui d'un appel de fonction.

MCP relie un agent à ses outils, A2A relie des agents entre eux À gauche, le motif MCP : une personne adresse une demande à un hôte qui contient le modèle et le client MCP ; le modèle décide de l'outil, le client l'appelle sur des serveurs MCP, les résultats remontent, la réponse est rendue. À droite, le motif A2A : une personne adresse une demande à un agent orchestrateur qui délègue des tâches à des agents spécialisés appartenant à d'autres organisations ; chacun de ces agents utilise ses propres outils par MCP et rend ses artefacts. MCPagent ↔ outil Personne Hôte Modèle décide quoi faire Client MCP exécute l'appel Serveurmétier Serveurfichiers demande réponse les résultats reviennent au client Le modèle décide, le client exécute. Accès outillé centralisé. Fait pour un agent qui travaille dans un seul périmètre. A2Aagent ↔ agent Personne Orchestrateur délègue, n'exécute pas Agent tiers A autre organisation Agent tiers B autre organisation tâche tâche ses outils par MCP ses outils par MCP artefacts Chaque agent garde son contexte. On échange des tâches et des artefacts, jamais un état interne.
La lecture juste n'est pas « MCP ou A2A » mais « MCP dans A2A » : chaque agent d'un réseau A2A utilise MCP pour atteindre ses propres outils. Le premier trace une frontière technique, le second une frontière organisationnelle.

Ce qui a changé, et que le schéma ne dit pas

Deux évolutions de gouvernance rendent ce visuel factuellement obsolète, et toutes deux comptent pour qui prépare une décision d'architecture.

01MCP n'appartient plus à Anthropic

Le protocole a été donné à la Linux Foundation le 9 décembre 2025, au sein de l'Agentic AI Foundation co-fondée par Anthropic, Block et OpenAI, avec Google, Microsoft, AWS, Cloudflare et Bloomberg parmi les soutiens. Il évolue désormais par un processus public de propositions numérotées, examinées en groupes de travail.

Ce point n'est pas cosmétique pour une direction qui se demande ce qui la protège de l'enfermement chez un éditeur. Un protocole confié à une fondation, adopté par les trois grands fournisseurs de cloud et par les principaux assistants du marché, offre une réversibilité qui ne dépend de la parole de personne.

02Le protocole est devenu sans état

La révision du 28 juillet 2026 supprime la poignée de main d'initialisation, les sessions protocolaires et l'en-tête de session. La version de protocole et les capacités du client voyagent désormais dans les métadonnées de chaque requête, un appel de découverte permet au serveur d'annoncer son identité, et les requêtes qui allaient du serveur vers le client passent par un aller-retour explicite plutôt que par une inversion de flux.

Conséquence pratique : un serveur MCP se déploie et se met à l'échelle comme un service web ordinaire, derrière une passerelle qui route sur des en-têtes HTTP sans lire le corps du message. C'est une bonne nouvelle pour une infrastructure interne que l'on veut simple à exploiter.

03Trois primitives sont dépréciées

La même révision déprécie Roots, Sampling et Logging. Les primitives actives sont désormais les outils, les ressources, les invites et l'élicitation — cette dernière étant le mécanisme par lequel un serveur redemande une information à l'utilisateur en cours de route. Une politique de cycle de vie garantit une fenêtre de dépréciation de douze mois au minimum.

Conséquence pour qui forme des équipes ou reprend un serveur existant : Sampling et Roots ne s'enseignent plus. Les répertoires de travail passent par des paramètres d'outil ou des URI de ressources ; l'appel au modèle passe directement par l'API du fournisseur.

04A2A n'est plus un projet Google, et n'est plus expérimental

Google Cloud a donné A2A à la Linux Foundation. Le protocole est piloté par un comité technique réunissant AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP et ServiceNow. La version 1.0 stable est sortie le 9 avril 2026, avec des cartes d'agent signées cryptographiquement, du multi-tenant d'entreprise et trois liaisons de transport. Plus de cent cinquante organisations le portent, et des usages en production sont déclarés en chaîne d'approvisionnement, en assurance, en services financiers et en exploitation informatique.

Autrement dit, la question « faut-il regarder A2A ? » a changé de nature en avril. Ce n'est plus un sujet de veille, c'est une architecture disponible. Cela ne signifie pas qu'elle s'impose : peu d'organisations ont aujourd'hui un besoin réel de faire coopérer des agents appartenant à des éditeurs différents, et il vaut mieux savoir le dire que de déployer un protocole pour la beauté du schéma.

Ce que cela implique en pratique

La conséquence la plus utile est un déplacement de la question de souveraineté. Elle ne se défend pas en refusant les protocoles du marché, mais en choisissant où tournent les serveurs. Un serveur MCP qui expose la base documentaire d'un industriel peut vivre entièrement dans ses murs : le protocole est public, l'implémentation lui appartient, et le jour où il change de modèle, ses outils ne bougent pas. La réversibilité cesse d'être une clause de contrat pour devenir une propriété vérifiable de l'architecture.

02Le geste

Du prompt au contexte, du contexte au harness

C'est le schéma le plus important des six, parce qu'il décrit un déplacement de la valeur. Ce qui passait pour une écriture d'invite est devenu une discipline d'ingénierie à part entière.

Le premier temps, celui du prompt, revenait à bien formuler une demande. Une invite système, un message d'utilisateur, une réponse. Le savoir-faire tenait dans la tournure. Il s'est très vite épuisé, pour une raison simple : la qualité d'une réponse dépend beaucoup moins de l'élégance de la question que de ce que le modèle a sous les yeux au moment de répondre.

Le deuxième temps, celui du contexte, part de ce constat. Anthropic en a donné la formulation de référence en septembre 2025 : l'ingénierie de contexte consiste à « entretenir l'ensemble optimal de jetons » pendant l'inférence. Le mot qui compte est optimal, pas maximal. La fenêtre de contexte n'est pas un réservoir qu'on remplit, c'est une ressource qui se dégrade : plus on y entasse, moins le modèle rappelle fidèlement ce qui s'y trouve. Le phénomène porte un nom — le context rot, l'usure du contexte — et il retourne l'intuition de tout le monde. La compétence n'est plus d'ajouter, elle est de trier, résumer et jeter.

Le troisième temps est celui du harness, et c'est là que le mot mérite une mise au point. Le harnais, c'est tout ce qui entoure le modèle : les outils qu'on lui donne, la politique de contexte, les points d'interception, le bac à sable, les boucles de retour. Le modèle décide, le harnais encadre. Concevoir un harnais, c'est accepter que la boucle tourne — que l'agent appelle un outil, lise le résultat, décide s'il a terminé, recommence — et que chaque tour de cette boucle soit observable, borné et rattrapable.

Trois âges de l'ingénierie : prompt, contexte, harness Premier temps, le prompt : une fenêtre de contexte contenant une invite système et un message utilisateur alimente le modèle, qui produit une réponse. Deuxième temps, le contexte : un ensemble de contextes disponibles — documents, outils, mémoire, instructions, historique — est curé avant d'entrer dans la fenêtre ; le modèle produit soit une réponse, soit un appel d'outil dont le résultat revient dans l'historique. Troisième temps, le harnais : la boucle se referme — le modèle décide s'il a terminé, sinon il appelle un outil dans un environnement outillé, le résultat est curé puis réinjecté, et une mémoire longue durée vit hors de la fenêtre. Premier temps Prompt bien formuler la demande Fenêtre de contexte Invite système Message utilisateur Modèle Réponse Un aller, un retour. Aucun outil, aucune mémoire, aucune boucle. Deuxième temps Contexte trier ce qui entre, jeter ce qui encombre Contexte disponible documents outils mémoire instructions savoir métier historique complet curation Fenêtre curée invite système 2 documents sur 6 outils utiles seulement historique résumé tout n'entre pas — le tri est le travail Modèle Réponse Appel d'outil le résultat revient dans l'historique — qui grossit, donc se résume Troisième temps Harnais encadrer la boucle jusqu'à ce que la tâche soit faite Fenêtre contexte curé à chaque tour de boucle Modèle Terminé ? oui Réponse non Outils & environnement recherche fichiers exécution API résultat curé, puis réinjecté Mémoire longue durée hors fenêtre
Le harnais n'est pas une couche technique supplémentaire : c'est le lieu où se prennent les décisions d'ingénierie qui font qu'un agent tient ou s'effondre — ce qui entre dans la fenêtre, quand elle se vide, ce que l'agent a le droit de faire, à quelles conditions il s'arrête.

Les cinq gestes du harnais

Ce que la littérature publiée recense de plus solide, et qui se transpose tel quel dans un projet.

Geste 01

Compacter

Résumer l'historique avant d'atteindre la limite, en préservant les décisions structurantes et en jetant les sorties redondantes. Technique de base — et Anthropic a nuancé sa portée en mars 2026 : sur les tâches très longues, vider entièrement la fenêtre et repartir d'un agent frais s'est révélé plus efficace que compacter.

Geste 02

Prendre des notes hors contexte

Écrire l'état d'avancement dans un fichier plutôt que dans la conversation. Un agent qui reprend son travail relit ses notes ; il n'a pas besoin de relire tout ce qu'il a dit. C'est aussi ce qui rend le travail auditable par un humain.

Geste 03

Déléguer à des sous-agents

Confier une exploration à un agent dédié, avec son propre contexte, et n'en récupérer qu'un résumé condensé — de l'ordre de mille à deux mille jetons. L'agent principal garde ainsi une fenêtre propre pour la planification.

Geste 04

Dessiner les outils

Un outil doit être autonome, robuste à l'erreur et sans ambiguïté sur son emploi. Deux outils qui se recouvrent créent un point de décision inutile où l'agent hésite — et donc se trompe. La qualité d'un agent se lit dans la qualité de son jeu d'outils.

Geste 05

Récupérer au dernier moment

Plutôt que de précharger tout ce qui pourrait servir, garder des identifiants légers et charger à l'exécution ce dont on a besoin. C'est un déplacement explicite depuis la récupération par plongements en amont vers une navigation outillée de l'information — voir la section 06.

Verrou

Le mot lui-même

« Harness engineering » est un terme émergent, pas établi, attribué à un praticien indépendant début 2026. Anthropic écrit abondamment sur le harnais et sa conception mais n'emploie pas cette expression. À manier avec prudence : ce n'est pas encore un mot de l'industrie, et l'employer devant une direction suppose de l'expliquer d'abord.

Ce que cela implique en pratique

Ce schéma dit où se trouve réellement la difficulté. Ni dans le modèle, qui est une commodité louée au mois et remplaçable d'un trimestre à l'autre ; ni dans l'invite, qui se copie en trois secondes. Elle est dans le harnais — c'est-à-dire dans la connaissance du travail réel qu'il faut posséder pour décider quoi mettre devant le modèle, quels outils lui donner et à quelles conditions l'arrêter. Cette connaissance, aucun éditeur ne l'a. Elle vit dans l'organisation, le plus souvent sans avoir jamais été écrite, et c'est ce qu'il faut aller chercher avant la première ligne de code.

03Le plan

L'orchestrateur et ses spécialistes

Le troisième schéma présente un coordinateur qui délègue à quatre agents spécialisés. C'est un motif réel, documenté, avec un gain mesuré — et un coût qu'on oublie systématiquement de citer avec.

Le principe est celui de la division du travail. Un agent coordinateur reçoit l'objectif, le décompose, lance en parallèle des agents dont chacun ne voit que sa part — l'un cherche sur le web, l'autre lit les documents, un troisième synthétise, un quatrième met en forme — puis rassemble. L'intérêt n'est pas la vitesse : c'est que chaque spécialiste travaille dans sa propre fenêtre de contexte, ce qui multiplie la matière que le système peut traiter au total sans qu'aucun de ses membres ne sature.

Un coordinateur et quatre agents spécialisés, puis le flux de bout en bout En haut, un agent coordinateur délègue à quatre agents spécialisés : recherche web, analyse documentaire, synthèse, mise en forme. Chacun dispose de sa propre fenêtre de contexte. En bas, le flux : objectif de l'utilisateur, coordinateur, travail en parallèle des spécialistes, synthèse, mise en forme, réponse finale. Un encart rappelle le coût : environ quinze fois plus de jetons qu'une conversation ordinaire. Le motif Coordinateur décompose et rassemble Recherche web, sources contexte propre Analyse documents contexte propre Synthèse croise, arbitre contexte propre Mise en forme livrable contexte propre Ce que le schéma omet ≈ 15 × plus de jetons qu'une conversation ordinaire + 90,2 % de performance — sur une évaluation interne de recherche, juin 2025 Le flux de bout en bout Objectifde la personne Coordinateur Spécialistesen parallèle Synthèse Mise en forme Réponse relecture humaine Rien ne sort du système sans que quelqu'un ait lu — le dernier segment du flux n'est pas automatique.
Le gain de quatre-vingt-dix pour cent et le coût de quinze fois sont deux faces du même choix. Un motif multi-agents ne se justifie que si la valeur de la tâche absorbe la facture de jetons — c'est un arbitrage économique avant d'être une décision d'architecture.

Quand ce motif est le bon, et quand il ne l'est pas

Les recommandations publiées sont précises, et elles sont plus restrictives qu'on ne le croit. Le motif convient aux tâches franchement parallélisables, à celles dont la matière excède ce qu'une seule fenêtre peut contenir, aux recherches larges qui poursuivent plusieurs pistes indépendantes. Il convient mal — et c'est explicite — aux tâches où tous les agents ont besoin du même contexte, ou dont les parties sont fortement interdépendantes. La plupart du travail de développement logiciel est nommément citée comme un mauvais candidat.

La critique la plus argumentée vient de Cognition, en juin 2025 : dès lors qu'une action porte une décision implicite, deux agents qui travaillent en parallèle sans se voir prennent des décisions incompatibles, et le rassemblage produit un livrable incohérent. Leur conclusion est de partager le contexte et la trace complète, donc de préférer un agent linéaire. Ce n'est pas une position marginale ; c'est la contradiction sérieuse à connaître.

Et Anthropic a elle-même déplacé son argumentaire. En mars 2026, la justification du multi-agents n'est plus le parallélisme mais la séparation des rôles : un agent planifie, un autre produit, un troisième évalue — parce qu'un agent qui juge son propre travail le surévalue systématiquement. Le multi-agents devient un dispositif contre le biais d'auto-évaluation avant d'être un dispositif de débit.

C'est la lecture la plus solide, et la plus transposable. Séparer celui qui produit de celui qui vérifie est une règle d'atelier avant d'être une règle d'architecture ; elle se comprend sans détour dès qu'on connaît la différence entre un opérateur et un contrôleur qualité.

04La maison

Neuf couches, dont quatre qu'on oublie toujours

Le quatrième schéma est le plus austère et le plus utile. Il ne montre pas comment un agent fonctionne, il montre tout ce qu'il faut construire autour pour qu'un agent tienne en production — et c'est cette liste-là qui sépare une démonstration d'un système.

Cinq couches vont de soi dès qu'on a bâti un prototype : les interfaces par lesquelles on parle au système, le plan d'orchestration qui décompose et route, la couche des agents proprement dits, les outils qui les relient au monde, la mémoire qui leur donne une histoire. Personne ne les oublie, parce que sans elles rien ne s'exécute.

Les quatre autres sont celles qu'on découvre à la première panne. L'observabilité : sans traces de bout en bout, un système d'agents est une boîte noire dont on ne peut pas dire ce qui s'est passé. La fiabilité : détection d'erreur, reprise, agents de repli, disjoncteur, et l'intervention humaine dans la boucle. La gouvernance : qui a le droit d'appeler quoi, quelles données sortent du périmètre, quelles traces d'audit sont conservées. L'infrastructure : passerelle de modèles, gestion des secrets, files d'attente, stockage, déploiement.

Les neuf couches d'un système d'agents en production Colonne de gauche : interfaces et systèmes existants. Colonne centrale, de haut en bas : plan d'orchestration avec décomposition de tâches, sélection d'agent, gestion du plan, état et contexte, garde-fous ; couche d'agents spécialisés ; couche des outils et intégrations ; couche de mémoire et de connaissance. Colonne de droite : observabilité, fiabilité, gouvernance et sécurité. Bande inférieure : socle d'infrastructure transversal. Les cinq couches qu'on construit d'instinct Les quatre qu'on découvre à la panne Interfaces application conversation API poste de travail Systèmes existants ERP, CRM GED, PLM bureautique Plan d'orchestration décomposerla tâche choisirl'agent conduirele plan tenir l'étatet le contexte garde-fous Couche d'agents recherched'information raisonnementet décision actionsur les outils donnéeset calcul rédactionet restitution Outils & intégrations serveurs MCP, API métier, exécution de code, fichiers, bases de données, recherche la prise de la section 01 Mémoire & connaissance contexte courant, mémoire longue durée, base de connaissance, historique la récupération, section 06 Observabilité traces de bout en bout coût, latence, jetons alertes sur anomalie journal d'audit Fiabilité détection d'erreur, reprise agent de repli, disjoncteur reprise de main humaine c'est ici que vit le dernier mot Gouvernance & sécurité qui a le droit d'appeler quoi données personnelles conformité et preuve Socle d'infrastructure passerelle de modèles · stockage · file d'événements · cache · gestion des secrets · index vectoriel · déploiement et versions · station souveraine dans les murs du client La question qui tranche un projet : sur laquelle de ces neuf couches l'organisation garde-t-elle la main le jour où le prestataire s'en va ?
Un prototype occupe les cinq couches de gauche. Un système occupe les neuf. L'écart entre les deux n'est pas une question de sophistication du modèle, c'est une question d'ingénierie ordinaire — et c'est là que se joue la possibilité d'une architecture gouvernable sans son constructeur.

Comment s'en servir

Ce schéma est une grille de diagnostic déguisée. Passer un projet couche par couche fait apparaître très vite ce qui manque, et la conversation devient concrète : personne ne sait dire ce qu'a coûté l'agent le mois dernier, personne ne sait qui l'a autorisé à écrire dans le CRM, personne ne sait ce qu'il a fait mardi entre onze heures et midi. Ces trois phrases valent mieux qu'un long discours sur la gouvernance.

Elle donne aussi deux règles qui ne coûtent presque rien à poser au début d'un projet et très cher à rattraper ensuite : rien n'entre en production sans mesure préalable, et l'architecture livrée doit rester gouvernable sans celui qui l'a construite. Les couches d'observabilité et de gouvernance sont ces deux règles, exprimées en langage d'architecte — du sérieux d'ingénieur plutôt que de la prudence morale.

05Le moteur

La boucle, et l'endroit exact où l'humain garde la main

Le cinquième schéma descend au niveau du code. Il dit une chose que tout le reste de cette note présuppose : le modèle choisit l'action, le programme qui l'héberge décide si elle a lieu. Cette séparation n'est pas une précaution ajoutée après coup, c'est l'architecture même de la boucle.

Le déroulement est simple. On envoie au modèle l'état de la conversation ; il répond soit par du texte, soit par une demande d'appel d'outil. S'il n'y a pas d'appel, la boucle se termine et le résultat est rendu. S'il y a un appel, il ne part pas directement à l'exécution : il traverse une série de points d'interception que l'application contrôle. Un premier valide ou refuse la demande avant même qu'elle existe. Un deuxième soumet l'appel à une politique de permission — autoriser, refuser, demander. L'outil s'exécute alors, et un troisième point observe le résultat, l'audite, déclenche ce qu'il faut déclencher. Le résultat retourne au modèle, qui décide de la suite. Un aller-retour d'outil équivaut à un tour de boucle.

Ces points d'interception ont un nom — les hooks — et une propriété remarquable : ils vivent hors de la fenêtre de contexte. Le modèle ne les voit pas, ne peut pas les négocier, ne consomme aucun jeton pour eux. C'est, techniquement, l'endroit le plus solide où poser une règle que l'agent ne contournera pas.

La boucle d'agent et son plan de contrôle applicatif Le modèle décide ; s'il n'y a pas d'appel d'outil, la réponse finale est rendue. S'il y a un appel, il traverse le plan de contrôle applicatif : validation avant exécution, politique de permission — une porte marquée d'une ligne jaune que le signal ne franchit pas seul —, exécution de l'outil, puis observation après exécution. Le résultat remonte au modèle pour le tour suivant. Modèle choisit l'action Appel d'outil ? non Réponse finale la boucle se termine oui Plan de contrôle applicatif — hors de la fenêtre de contexte Avant exécution valider, bloquer chemins, commandes Permission autoriser · refuser demander à quelqu'un Exécution l'outil tourne bac à sable Après exécution auditer, tracer effets de bord le chemin de l'appel porte humaine le résultat remonte au modèle et nourrit sa décision suivante un aller-retour d'outil = un tour de boucle
La scène illustre une règle que nous appliquons à tout système que nous signons : quelque part, un signal arrive à une ligne et ne la franchit pas seul. Ici cette ligne est la politique de permission, et elle n'est pas décorative — c'est un point d'interception réel, hors du contexte du modèle, que l'agent ne peut pas contourner.

Les garde-fous, et leur contrepartie

Deux familles de réglages encadrent la boucle. D'un côté ce qui la borne : un nombre maximal de tours, un plafond de dépense estimée, un périmètre d'outils réduit au strict nécessaire, une politique de permission, un identifiant de session qui permet de reprendre où l'on s'était arrêté. De l'autre ce qui explique pourquoi elle s'est arrêtée : succès, plafond de tours atteint, plafond de dépense atteint, erreur d'exécution, échecs répétés de validation de sortie. Un système d'agents sérieux distingue ces cinq fins ; un système bricolé rend « ça n'a pas marché ».

Le plafond de dépense mérite une mise en garde que la documentation donne elle-même : la vérification du budget a lieu après chaque appel au modèle, si bien que le coût final peut légèrement dépasser la valeur demandée. C'est le genre de détail qu'il vaut mieux avoir lu avant de le découvrir sur une facture.

Trois noms de ce schéma sont faux. Vérifié le 18 août 2026 sur la documentation du SDK.
Sur le schémaÉtatLe nom réel
MAX_BUDGET_USDcasse fausseLe concept existe. L'option s'écrit max_budget_usd, en minuscules, dans les options de l'agent.
ERROR_MAX_BUDGETnom fauxLa valeur réelle est error_max_budget_usd, portée par le sous-type du message de résultat.
OUTPUT_RETRIESinexistantAucune option de ce nom. L'identifiant voisin attesté concerne les échecs de validation de sortie structurée ; il n'apparaît pas dans la documentation de référence, seulement dans un ticket public.
« Claude Code SDK »nom périméClaude Agent SDK. Le nom « Claude Code » est explicitement interdit dans le branding d'un produit tiers.

Autre point à connaître avant d'arrêter une architecture : ce SDK n'existe qu'en Python et en TypeScript. Pour piloter la même boucle depuis un autre langage, on lance l'exécutable en sous-processus. Et les points d'interception ne sont pas identiques d'un langage à l'autre — plusieurs n'existent qu'en TypeScript.

Ce que cela implique en pratique

C'est le schéma qui transforme un principe en dispositif. « L'humain garde le dernier mot » cesse d'être une déclaration d'intention pour devenir une ligne de configuration : vérifiable, située hors du contexte du modèle, et que l'agent ne peut pas négocier. À la question de savoir ce qui empêche un agent d'écrire tout seul dans un ERP, la réponse n'est plus un engagement mais trois artefacts qu'on peut ouvrir et lire — une politique de permission, un journal d'audit, un plafond de dépense.

06La récupération

Le RAG, et ce qui l'a déplacé sans le remplacer

Le sixième visuel aligne douze notions de récupération augmentée. Elles sont toutes justes et toujours utiles. Ce qu'il ne dit pas, c'est qu'aucune n'est plus le premier réflexe : depuis 2026, la question se pose autrement.

Rappelons le problème d'origine. Un modèle ne connaît pas les documents d'une entreprise. Pour qu'il en parle sans inventer, il faut aller chercher les bons extraits et les lui mettre sous les yeux au moment de répondre. Le RAG est la mécanique de cette recherche : on découpe les documents, on transforme chaque morceau en une suite de nombres qui encode son sens, on les indexe, et à chaque question on récupère les morceaux dont le sens est le plus proche.

Douze notions de la récupération augmentée Douze cartes : plongements vectoriels, base vectorielle, recherche sémantique, découpage, réordonnancement, recherche hybride, filtrage par métadonnées, fenêtre de contexte, garde-fou d'hallucination, ancrage, dérive des données, graphe de connaissance. Chacune est définie en une phrase. 01Plongements mot Transforme un texte en nombres qui encodent son sens, pour que deux idées proches soient voisines. 02Base vectorielle Indexe ces nombres pour retrouver les plus proches en quelques millisecondes. 03Recherche sémantique Cherche par le sens et non par les mots exacts. Trouve « devis » quand on dit « chiffrage ». 04Découpage Taille les documents en morceaux de bonne dimension. Le choix de la coupe décide de tout. 05Réordonnancement Reclasse les extraits récupérés par pertinence réelle, avec un second modèle plus fin. 06Recherche hybride mots-clés+ sens Croise la recherche par mots et par sens, puis fusionne les deux classements. Le choix de 2026. 07Filtrage par étiquettes Restreint la recherche par service, date, confidentialité. Souvent plus efficace que le reste. 08Fenêtre de contexte Ce que le modèle peut lire d'un coup. Grande ne veut pas dire bien lue — voir section 02. 09Garde-fou d'invention Interdit au modèle de répondre au-delà de ce qu'il a récupéré. Réduit l'invention, ne l'annule pas. 10Ancrage réponse source Rattache chaque affirmation à un document citable. C'est ce qui rend une réponse auditable. 11Dérive Les documents changent, l'index reste. Sans réindexation, le système répond avec de l'ancien. 12Graphe de connaissance Relie explicitement les entités entre elles. Gagne sur les questions à plusieurs sauts — et coûte cher.
Toutes ces notions restent opératoires. Deux méritent une révision de statut : la recherche hybride est passée du raffinement au réglage par défaut, et le réordonnancement n'apporte plus le gain spectaculaire que les chiffres de 2024 laissaient croire.

Ce que 2026 a changé

Trois déplacements, tous documentés, tous contre-intuitifs par rapport à ce que ces douze cartes suggèrent.

Déplacement 01

L'hybride devient le défaut

La recommandation de production en 2026 n'est plus le vectoriel seul mais la combinaison d'une recherche par mots-clés classique et d'une recherche par sens, dont les deux classements sont fusionnés. Le vectoriel pur reste raisonnable en dessous de quelques milliers de morceaux.

Déplacement 02

Le réordonnancement s'est dégonflé

Les gains massifs souvent cités datent de septembre 2024. Des travaux de 2026 sur des jeux de référence montrent qu'aucun réordonnanceur neuronal ne dépasse significativement une bonne recherche par mots-clés. À traiter comme une option à mesurer, pas comme un acquis.

Déplacement 03

Le long contexte n'a rien remplacé

Les fenêtres à un million de jetons n'ont pas tué la récupération, pour quatre raisons tenaces : le coût, la latence, la fraîcheur — un contexte rechargé en bloc est vite périmé — et le fait qu'une information enfouie au milieu reste difficile à extraire même quand elle tient dans la fenêtre.

Le déplacement le plus profond est ailleurs, et il rejoint la section 02. Anthropic assume un passage de la récupération par plongements calculée en amont vers une récupération au dernier moment : plutôt que d'indexer tout un corpus par avance, on donne à l'agent des outils pour naviguer l'information — lister, ouvrir, chercher, suivre une référence — et il découvre progressivement ce dont il a besoin, comme le ferait une personne. C'est ce qu'on appelle la recherche agentique, et elle change la nature du chantier : moins d'infrastructure d'indexation, plus de conception d'outils.

Un repère de dimensionnement utile en atelier : en dessous d'environ deux cents mille jetons — soit à peu près cinq cents pages — mettre toute la base de connaissance dans l'invite est viable, et la mise en cache réduit la latence de plus de moitié et le coût dans des proportions considérables. Au-delà, la récupération redevient nécessaire.

Ce que cela implique en pratique

Devant une base documentaire, le premier réflexe ne devrait plus être « on monte un index vectoriel » mais une question de volume et d'usage : combien de pages, à quelle fraîcheur, pour combien de requêtes par jour, et l'agent a-t-il besoin de tout voir ou seulement de savoir où chercher ? Pour beaucoup de PME et d'ETI industrielles, la réponse honnête tient dans un dossier bien rangé, une recherche par mots-clés correcte et quelques outils de navigation — pas dans une base vectorielle. C'est moins impressionnant, et considérablement plus solide dans le temps.

07Grille de lecture

Où chacun de ces niveaux tombe dans un projet

Rien de tout cela n'a de valeur tant que ce n'est pas raccordé à la conduite d'un projet réel. Voici la correspondance, telle que nous l'employons en mission — extraire le savoir, le structurer en architecture, l'embarquer dans les équipes.

NiveauTemps du projetCe que ça donne concrètement en mission
Protocole
MCP, A2A
Embarquer Décide où tournent les serveurs, donc où vit la souveraineté. C'est la garantie de réversibilité la plus solide qu'on puisse donner à une direction, parce qu'elle repose sur un standard confié à une fondation plutôt que sur un engagement contractuel.
Méthode
harnais
Structurer Le cœur du travail de conception. Décider ce qui entre devant le modèle exige de savoir comment le travail se fait réellement — ce que l'atelier d'extraction va chercher, et que personne n'a jamais écrit.
Motif
orchestration
Structurer Se dérive du cas d'usage mesuré, jamais de l'élégance du schéma. Séparer celui qui produit de celui qui vérifie est la version machine du point de contrôle par palier.
Architecture
neuf couches
Structurer, puis embarquer Grille de diagnostic. Les couches d'observabilité et de gouvernance portent les deux règles qui décident de la suite — rien en production sans mesure, et une architecture gouvernable sans son constructeur.
Implémentation
boucle, hooks
Embarquer Rend le dernier mot humain vérifiable au lieu de promis. Une politique de permission, un journal, un plafond : trois artefacts qu'on peut montrer.
Récupération
RAG et suites
Extraire Question de dimensionnement avant d'être une question de technologie. Le bon réflexe est de compter les pages avant de dessiner un index.

Une note sur le vocabulaire

Ces mots décrivent une architecture, pas un actif. Une architecture est agentique ; un savoir-faire d'entreprise ne l'est jamais — il reste ce que l'organisation possède, la technique n'étant que ce qu'on y ajoute. La distinction paraît byzantine ; elle évite pourtant l'erreur la plus fréquente de ces projets, qui consiste à confondre l'outil avec la valeur qu'il sert.

Sur les anglicismes, notre règle est simple : on traduit quand une traduction existe et tient — récupération, plongement, découpage, point d'interception — et on garde l'anglais quand le terme désigne un objet nommé, comme MCP ou A2A. Le harnais est le cas limite : le mot français est clair, l'expression anglaise n'est pas encore un terme de l'industrie, et le plus honnête devant un public non technique est de dire « tout ce qu'on construit autour du modèle ».

Reste le mot le plus utilisé et le moins défini de tous. Agent n'a aucune définition partagée : il désigne selon l'interlocuteur une boucle outillée, un assistant spécialisé, un service autonome ou un simple appel scripté. En réunion comme en cahier des charges, mieux vaut décrire ce que la chose fait — elle lit, elle propose, elle attend une validation — que de laisser le mot faire le travail à sa place.

08Glossaire

Le vocabulaire, une fois pour toutes

Terme français retenu, équivalent anglais entre parenthèses pour reconnaître le mot dans la littérature. Filtrez sur un mot, en français ou en anglais.

Agentagent
Un modèle placé dans une boucle, doté d'outils et d'un objectif, qui décide lui-même de ses étapes. Le mot n'a aucune définition partagée dans l'industrie : préférez décrire ce que la chose fait.
Agentiqueagentic
Qualifie une architecture, une méthode ou un système fondé sur des agents. Chez nous, l'adjectif décrit toujours la technique, jamais l'actif du client.
A2AAgent2Agent Protocol
Protocole de communication entre agents appartenant à des organisations ou des éditeurs différents. Porté par la Linux Foundation, version 1.0 stable depuis avril 2026.
Ancragegrounding
Rattacher chaque affirmation d'une réponse à une source citable. Condition d'auditabilité — et souvent la seule chose qui distingue un livrable défendable d'un texte plausible.
Bac à sablesandbox
Environnement d'exécution cloisonné dans lequel un outil tourne sans pouvoir toucher au reste du système.
Base vectoriellevector database
Index qui range des plongements pour retrouver les plus proches très vite. Utile au-delà de quelques milliers de morceaux ; souvent surdimensionné en dessous.
Biais d'auto-évaluationself-preferential bias
Tendance mesurée d'un agent à surévaluer son propre travail. Justifie de séparer celui qui produit de celui qui juge.
Boucle d'agentagent loop
Le cycle décider, appeler un outil, lire le résultat, recommencer, jusqu'à une condition d'arrêt. Un aller-retour d'outil vaut un tour.
Carte d'agentAgent Card
Document A2A par lequel un agent publie son identité, ses compétences, ses points d'accès et ses exigences de sécurité. Signable cryptographiquement depuis la version 1.0.
Compactioncompaction
Résumer l'historique d'une conversation avant de saturer la fenêtre, en gardant les décisions et en jetant le redondant.
Découpagechunking
Tailler les documents en morceaux avant de les indexer. Le choix de la coupe détermine la qualité de tout ce qui suit.
Dérivedata drift
Écart croissant entre les documents réels et l'index qui les représente. Sans réindexation, le système répond juste sur des données fausses.
Élicitationelicitation
Primitive MCP par laquelle un serveur redemande une information à l'utilisateur en cours d'exécution, au lieu d'échouer ou de deviner.
Évaluationeval
Jeu de cas de référence qui mesure si un agent fait bien ce qu'on attend. Sans évaluation, une amélioration n'est qu'une impression.
Fenêtre de contextecontext window
Ce que le modèle peut lire d'un seul coup. Ressource finie qui se dégrade quand on la remplit — voir usure du contexte.
Garde-fouguardrail
Toute borne posée sur la boucle : nombre maximal de tours, plafond de dépense, périmètre d'outils, politique de permission.
Graphe de connaissanceknowledge graph
Représentation explicite des entités et de leurs liens. Gagne sur les questions à plusieurs sauts, coûte cher à construire et à tenir à jour.
Harnaisharness
Tout ce qu'on construit autour du modèle : outils, politique de contexte, points d'interception, bac à sable, boucles de retour. L'expression « harness engineering » est émergente, pas établie.
Hôte, client, serveurhost, client, server
Les trois rôles MCP. L'hôte abrite le modèle, le client exécute les appels, le serveur expose les outils et les ressources.
Humain dans la bouclehuman in the loop
Point où une personne autorise, corrige ou refuse avant qu'une action ait lieu. Techniquement : une politique de permission, hors du contexte du modèle.
Ingénierie de contextecontext engineering
Entretenir l'ensemble optimal — et non maximal — de ce que le modèle a sous les yeux pendant l'inférence. Trier, résumer, jeter.
Inviteprompt
Le texte adressé au modèle. Longtemps confondu avec le métier ; désormais un composant parmi d'autres du harnais.
Jetontoken
Unité de découpage du texte par le modèle, et unité de facturation. Compter les jetons est la première discipline économique d'un projet d'agents.
MCPModel Context Protocol
Protocole standard par lequel un agent atteint des outils, des ressources et des invites. Donné à la Linux Foundation en décembre 2025 ; révision sans état depuis juillet 2026.
Mémoire longue duréelong-term memory
Ce qu'un agent conserve hors de sa fenêtre de contexte : notes de travail, décisions, état d'avancement. Ce qui lui permet de reprendre là où il s'était arrêté.
Orchestrateurorchestrator
Agent qui décompose un objectif, délègue à des spécialistes et rassemble. Il ne touche pas aux outils lui-même.
Plongementembedding
Représentation d'un texte sous forme de nombres encodant son sens, de sorte que deux idées proches se retrouvent voisines dans l'espace.
Point d'interceptionhook
Fonction déclenchée par un moment du cycle de vie — avant l'exécution d'un outil, après, à l'arrêt, avant une compaction. Vit hors de la fenêtre de contexte : le modèle ne peut ni la voir ni la négocier.
Politique de permissionpermission policy
Règle qui décide, pour chaque appel d'outil, entre autoriser, refuser et demander. L'endroit exact où se pose le dernier mot humain.
RAGretrieval-augmented generation
Aller chercher les bons extraits dans un corpus et les placer devant le modèle avant qu'il réponde. Toujours utile, plus jamais automatique.
Recherche agentiqueagentic search
Laisser l'agent naviguer l'information avec des outils — lister, ouvrir, chercher, suivre une référence — plutôt que lui servir des extraits préindexés.
Recherche hybridehybrid search
Croiser recherche par mots-clés et recherche par sens, puis fusionner les deux classements. Réglage par défaut recommandé en 2026.
Récupération au dernier momentjust-in-time retrieval
Garder des identifiants légers et charger le contenu à l'exécution, au lieu de tout précharger « au cas où ».
Remise à zéro du contextecontext reset
Vider entièrement la fenêtre et repartir d'un agent frais, en s'appuyant sur des notes externes. S'est révélé plus efficace que la compaction sur les tâches très longues.
Réordonnancementre-ranking
Reclasser les extraits récupérés par pertinence réelle avec un second modèle. Gain à mesurer plutôt qu'à supposer.
Ressource, outil, inviteresource, tool, prompt
Trois des quatre primitives MCP actives, avec l'élicitation. Une ressource se lit, un outil s'exécute, une invite se réutilise.
Sous-agentsubagent
Agent spécialisé lancé par un autre, avec son propre contexte, qui ne rend qu'un résumé condensé. Sert autant à paralléliser qu'à protéger la fenêtre de l'agent principal.
TâcheTask
En A2A, unité de travail à état et à cycle de vie propres, confiée d'un agent à un autre et rendue sous forme d'artefacts.
Tour de boucleturn
Un aller-retour complet d'outil. C'est l'unité sur laquelle se règle le plafond de tours d'un agent.
Usure du contextecontext rot
Dégradation du rappel d'un modèle à mesure que sa fenêtre se remplit. La raison pour laquelle « tout mettre dedans » ne marche pas.

09Corrections

Ce qui est faux ou périmé dans ces visuels

Recensement des écarts entre ce que montrent les six schémas et ce qui est vérifiable au 18 août 2026. À relire avant de reprendre l'un de ces visuels dans un support.

Croyance couranteÉtatCe qui est exact
MCP est un protocole AnthropicpériméDonné à la Linux Foundation le 9 décembre 2025, au sein de l'Agentic AI Foundation co-fondée par Anthropic, Block et OpenAI.
Les primitives MCP incluent Sampling et RootspériméRoots, Sampling et Logging sont dépréciés depuis la révision du 28 juillet 2026. Actives : outils, ressources, invites, élicitation.
MCP est un protocole à sessions, avec poignée de mainpériméLe protocole est devenu sans état. Plus d'initialisation, plus d'en-tête de session ; les requêtes du serveur vers le client passent par un aller-retour explicite.
Les tâches sont une primitive du cœur de MCPfauxLes tâches ont quitté le cœur du protocole pour devenir une extension officielle.
A2A est un projet Google, encore expérimentalpériméLinux Foundation, comité technique multi-éditeurs, version 1.0 stable depuis le 9 avril 2026, plus de cent cinquante organisations, usages en production déclarés.
« Harness engineering » est un terme formalisé par AnthropicfauxTerme émergent attribué à un praticien indépendant. Anthropic écrit sur le harnais et sa conception, sans employer cette expression.
La compaction est la solution au contexte longnuancéAnthropic rapporte en mars 2026 que la remise à zéro complète de la fenêtre bat la compaction sur les tâches longues.
Le multi-agents est meilleur en généralfauxMauvais candidat quand le contexte doit être partagé ou les parties interdépendantes ; la plupart du travail de développement est nommément cité comme tel. Coût : environ quinze fois plus de jetons.
Le SDK s'appelle Claude Code SDK et existe en plusieurs langagesfauxClaude Agent SDK, en Python et TypeScript uniquement. Trois identifiants du schéma sont erronés — détail en section 05.
Le RAG vectoriel dense est la référencepériméLa recommandation de production 2026 est l'hybride mots-clés plus sens, avec fusion des classements.
Le long contexte a remplacé la récupérationfauxCoût, latence, fraîcheur et difficulté d'extraction au milieu du contexte maintiennent la récupération pertinente.

Quatre points sur lesquels aucune source primaire n'a pu être établie, et sur lesquels nous ne nous prononçons donc pas : le nombre de serveurs MCP publics en août 2026, le rattachement d'A2A à l'Agentic AI Foundation spécifiquement, toute position d'Anthropic sur les graphes de connaissance, et la confirmation documentaire de l'identifiant d'échec de validation de sortie structurée.

10Sources

Sources primaires

Vérifiées le 18 août 2026. Les affirmations datées de cette note s'appuient sur ces documents ; les chiffres de performance sont donnés avec leur date et leur périmètre, jamais seuls.

  1. Model Context Protocol — annonce de la révision 2026-07-28 et journal des changements.
  2. Anthropic — donation de MCP et création de l'Agentic AI Foundation, 9 décembre 2025.
  3. Model Context Protocol — feuille de route 2026, 9 mars 2026.
  4. A2A Protocol — présentation et gouvernance et spécification.
  5. Linux Foundation — bilan de la première année d'A2A et version 1.0, avril 2026.
  6. Google — donation d'A2A à la Linux Foundation.
  7. Anthropic — Effective context engineering for AI agents, 29 septembre 2025.
  8. Anthropic — Effective harnesses for long-running agents, 26 novembre 2025.
  9. Anthropic — Harness design for long-running application development, 24 mars 2026.
  10. Anthropic — How we built our multi-agent research system, 13 juin 2025.
  11. Cognition — Don't Build Multi-Agents, 12 juin 2025.
  12. Claude Agent SDK — présentation, référence Python, points d'interception.
  13. Anthropic — Contextual Retrieval, septembre 2024 — source des chiffres de récupération souvent cités sans leur date.
Avertissement

Note de référence publiée par uniy. Elle fixe un cadre de lecture et un vocabulaire ; elle ne constitue pas un avis juridique, fiscal ou technique, et ne préconise aucune pile technologique. Les schémas ont été redessinés à partir de visuels en circulation dont les sources primaires ont été vérifiées indépendamment ; les corrections recensées en section 09 relèvent de cette vérification et non des visuels d'origine. Les états de l'art évoluent vite : cette note porte une date de vérification et doit être revue avant tout usage au-delà de quelques mois.