Les agents IA, expliqués pas à pas

Qu'est-ce qu'un agent IA ?

Un agent IA est un système dans lequel un modèle de langage choisit sa prochaine action, appelle un outil (une recherche, une commande shell, une API), lit le résultat et recommence jusqu'à ce que le but soit atteint ou qu'une condition d'arrêt survienne. Un chatbot vous répond ; un agent agit en boucle et vérifie ce qui s'est passé [1] [2].

À la fin de cette section, vous saurez distinguer un agent d'un modèle seul, et dire si ChatGPT ou Claude « est un agent ».

Cette formulation condense ce que publient les deux éditeurs. Le guide d'OpenAI définit les agents en une ligne, comme « des systèmes qui accomplissent des tâches de façon autonome, pour votre compte » (notre traduction) [1]. Anthropic les décrit comme des « systèmes où les LLM dirigent dynamiquement leurs propres processus et leur usage des outils, et gardent la maîtrise de leur façon d'accomplir les tâches » (notre traduction) [2]. La documentation du Claude Agent SDK en donne une version concrète : un agent y est « une application qui accomplit une tâche en planifiant ses propres étapes » (notre traduction), et qui appelle pour cela des outils capables de lire des fichiers, de lancer des commandes ou de modifier du code [18].

Selon le guide d'OpenAI, un agent repose sur trois composants essentiels : un modèle, des outils et des instructions [1]. Le guide dit aussi ce qui n'est pas un agent : une application qui intègre un modèle de langage sans s'en servir pour piloter l'exécution du workflow, comme un simple chatbot, un LLM à un seul tour ou un classifieur de sentiment [1].

Ce sont les outils qui font la différence. La documentation de Claude Code le dit en deux phrases : « Sans outils, Claude ne peut répondre que par du texte. Avec des outils, Claude peut agir » (notre traduction) [5].

La figure 1.1 place les composants d'un agent autour du modèle : le « harness », l'environnement d'exécution autour du modèle, qui contient le contexte, l'exécuteur d'outils, la barrière de permission et le journal de session ; le bac à sable ; les outils et les serveurs MCP ; les fichiers d'instructions ; et vous. Chaque repère numéroté renvoie à la section de cette page qui explique ce composant, et le modèle n'y apparaît que comme un bloc parmi d'autres.

ChatGPT est-il un agent IA ? Et Claude ?

Au regard de ces définitions, la question porte sur le produit, pas sur le modèle. Anthropic trace la frontière dans sa propre documentation, en opposant Claude Code à « un chatbot qui répond aux questions et attend » (notre traduction) : Claude Code, lui, peut lire vos fichiers, lancer des commandes, faire des modifications et venir à bout de problèmes de façon autonome [20].

Côté OpenAI, ChatGPT Work, lancé le 9 juillet 2026, est présenté comme « un agent dans ChatGPT » (notre traduction) bâti sur la technologie de Codex : vous suivez sa progression et vous validez les actions importantes [21]. Le centre d'aide d'OpenAI indique désormais que « ChatGPT agent n'est plus disponible » (notre traduction) et renvoie vers ChatGPT Work [22].

Les deux éditeurs gardent une application de chat et proposent, en parallèle, des produits agentiques distincts : Claude Code, Claude Cowork et Claude Managed Agents chez Anthropic ; Codex, ChatGPT Work, les workspace agents et dots chez OpenAI [5] [23] [11] [21] [24] [25]. La réponse courte est donc que Claude est un modèle et Claude Code le harness qui en fait un agent de code [19], tandis que ChatGPT est une application de chat dans laquelle OpenAI propose un agent, ChatGPT Work [21]. Les noms de produits et les dates de lancement changent plus vite que le mécanisme : la page les range donc dans l'annexe A.

Sources du §1 : [1] [2] [18] [5] [19] [20] [21] [22] [23] [11] [24] [25], vérifiées le 4 octobre 2026. Retour au sommaire.

Comment fonctionne un agent IA ? La boucle, pas à pas

Un agent IA fonctionne en boucle. Le modèle recueille du contexte, agit par un outil, vérifie le résultat et choisit l'étape suivante, souvent des dizaines de fois de suite. L'exécution s'arrête sur une condition de sortie : une réponse finale, une sortie structurée, une erreur ou un nombre maximal de tours. Vous pouvez l'interrompre et la réorienter à tout moment [5] [1].

À la fin de cette section, vous saurez suivre une exécution, nommer ses conditions de sortie et la lire comme une trace.

La documentation de Claude Code décrit la boucle en trois phases : « recueillir le contexte, agir et vérifier les résultats. Ces phases se fondent les unes dans les autres » (notre traduction) [5]. La même page explique comment l'étape suivante est choisie : Claude décide de ce que demande chaque étape « d'après ce qu'il a appris à l'étape précédente » (notre traduction), enchaîne des dizaines d'actions et corrige sa trajectoire en chemin [5].

Pour la tâche « réparer les tests qui échouent », la documentation énumère six étapes : lancer la suite de tests, lire la sortie d'erreur, chercher les fichiers source concernés, lire ces fichiers, les modifier, puis relancer les tests pour vérifier. « Chaque utilisation d'outil donne à Claude une information nouvelle qui oriente l'étape suivante » (notre traduction) [5].

La figure 2.1 fait passer la tâche T dans la boucle. Avancez pas à pas : le modèle se marque quand il choisit un appel d'outil, puis quand le résultat revient ; un arc s'allume quand l'agent recueille le contexte, agit ou vérifie les résultats ; une pull request attend à la barrière d'approbation ; et l'exécution s'arrête sur l'une des quatre conditions de sortie. La seconde vue dessine la même exécution sous forme de trace.

Dans la tâche T, le premier contrôle échoue, et pourtant l'exécution continue : un contrôle en échec est un résultat que le modèle lit, comme dans l'exemple de la documentation, qui lit la sortie d'erreur avant de chercher dans les fichiers source [5].

Le guide d'OpenAI décrit la même forme. Toute orchestration a besoin d'une « exécution » (run), une boucle qui continue jusqu'à ce qu'une condition de sortie soit atteinte ; le guide cite « des appels d'outil, une sortie structurée donnée, des erreurs, ou l'atteinte d'un nombre maximal de tours » (notre traduction) [1]. Dans l'Agents SDK, le seul appel d'outil qui termine l'exécution est un outil de sortie finale : Runner.run() boucle jusqu'à ce qu'un tel outil soit invoqué ou que le modèle réponde sans appeler d'outil [1]. La tâche T se termine de la seconde façon, sur une réponse finale sans appel d'outil.

Interrompre et réorienter. Dans Claude Code, vous pouvez interrompre à tout moment : Esc arrête l'appel d'outil en cours, et un message que vous tapez est mis en file d'attente et lu dès que les appels d'outil en cours se terminent, dans le même tour [5]. La Responses API d'OpenAI met elle aussi en file d'attente les consignes données en cours de tour : une mise à jour n'annule ni les outils en cours, ni les actions déjà faites [30].

Lire l'exécution comme une trace. Claude Code écrit chaque message, chaque utilisation d'outil et chaque résultat dans un transcript JSONL en texte brut, sous ~/.claude/projects/ [5] [19]. La même exécution peut aussi être exportée en télémétrie : Claude Code exporte des métriques et des événements OpenTelemetry, avec des spans en bêta et désactivés par défaut [31], et Codex a des réglages d'export otel, dont un exportateur de traces [29].

Un en-tête W3C traceparent porte quatre champs : version, trace-id, parent-id et trace-flags (tableau 2.1) [26]. La révision 2026-07-28 de MCP documente le transport de traceparent, tracestate et baggage dans le _meta d'une requête, si bien qu'un appel d'outil passé par un serveur MCP peut rejoindre la même trace [15].

Tant que le comportement d'un agent est encore en cours de mise au point, OpenAI conseille de partir de ces traces pour l'évaluer et de les noter avec des correcteurs de traces (trace graders) [32]. Sur sa plateforme Evals, les évaluations existantes passent en lecture seule le 31 octobre, et la fermeture est prévue le 30 novembre 2026 ; la page des dépréciations précise que « les correcteurs documentés pour les workflows d'évaluation font partie de cette transition » (notre traduction) [16].

Sources du §2 : [5] [1] [26] [15] [19] [27] [28] [29] [10] [30] [31] [32] [16], vérifiées le 4 octobre 2026. Retour au sommaire.

Agent IA, chatbot, assistant, workflow, LLM : quelles différences ?

Un LLM est le modèle lui-même. Un chatbot ou un assistant s'en sert pour vous répondre, tour après tour. Un workflow enchaîne des appels au modèle sur un chemin qu'un développeur a écrit dans le code. Un agent laisse le modèle choisir son chemin et ses outils, et continue jusqu'à ce que la tâche soit faite ou qu'une limite soit atteinte [2] [1].

À la fin de cette section, vous saurez placer n'importe quel produit d'IA sur l'échelle qui va d'un chemin fixé d'avance à un chemin que choisit le modèle.

Ces quatre mots désignent quatre degrés de contrôle, et la question utile reste toujours la même : qui choisit l'étape suivante ? Le tableau 3.1 les met côte à côte, du modèle seul au modèle qui choisit son propre chemin.

La figure 3.1 adresse la même demande à un chatbot et à un agent. Le chatbot répond par une hypothèse plausible, et son tour s'arrête ; l'agent lance le contrôle, lit le résultat et répond avec la ligne d'où vient l'erreur. Ce qui les sépare n'est pas la qualité de la réponse, mais la maîtrise du workflow et l'accès aux outils, les deux traits par lesquels le guide d'OpenAI décrit un agent [1].

Le billet d'Anthropic sur la construction d'agents efficaces trace la frontière entre workflows et agents. Il range les uns et les autres parmi les « systèmes agentiques », puis les distingue : les workflows sont des « systèmes où les LLM et les outils sont orchestrés par des chemins de code prédéfinis » (nos traductions), tandis que les agents dirigent eux-mêmes leur processus et leur usage des outils [2]. Le même billet nomme cinq motifs de workflow : l'enchaînement de prompts, le routage, la parallélisation, l'orchestrateur et ses exécutants, et l'évaluateur-optimiseur (en anglais prompt chaining, routing, parallelization, orchestrator-workers et evaluator-optimizer) [2].

La figure 3.2 dessine ces cinq motifs en vignettes, puis fait tourner un même graphe de deux façons : quand le code choisit chaque lien, le chemin reste le même à chaque exécution ; quand c'est le modèle qui choisit, le chemin change selon ce que chaque étape a renvoyé.

Les deux éditeurs conseillent de commencer simple. Anthropic recommande de « trouver la solution la plus simple possible, et de n'augmenter la complexité qu'en cas de besoin » (notre traduction) [2]. OpenAI réserve les agents aux cas où les règles ne suffisent plus : décisions qui demandent un jugement complexe, jeux de règles devenus difficiles à maintenir, forte dépendance à des données non structurées ; « sinon, une solution déterministe peut suffire » (notre traduction) [1].

Le billet d'Anthropic date de décembre 2024 et s'ouvre désormais sur un avertissement : « une grande partie de l'outillage décrit dans ce billet a changé depuis décembre 2024 » (notre traduction) [2]. L'avertissement porte sur l'outillage ; cette section ne reprend du billet que ses définitions et ses motifs.

IA agentique et IA générative : quelle différence ?

Sur cette page, « générative » décrit ce que produit un modèle, et « agentique » un système qui agit avec des outils. Le Top 10 2026 de l'OWASP pour les applications à base de LLM place la frontière au même endroit : sa liste traite le modèle comme un composant, et dès que le modèle « devient un acteur, avec des outils qu'il peut appeler, une mémoire qu'il garde d'une session à l'autre et des conséquences qu'il déclenche en aval » (notre traduction), elle renvoie au Top 10 des applications agentiques [33].

Une bonne part de la différence tient au vocabulaire, et autant le dire franchement : un agent tourne sur un modèle génératif, le modèle que le guide d'OpenAI cite en premier parmi ses trois composants essentiels [1]. Ce qui le rend agentique, c'est ce qui entoure le modèle : les outils, la boucle et les conséquences [33].

Dans l'AI Act tel que modifié, le mot « agentique » n'apparaît qu'une fois. L'annexe XIV, qui liste les codes de désignation des organismes notifiés au titre de l'article 30, contient le code AIH 0401, « Systèmes d'IA fondés sur d'autres technologies d'IA émergentes non couvertes par d'autres codes, notamment l'IA agentique », ajouté par le règlement (UE) 2026/1744 [14]. Le règlement (UE) 2024/1689 tel qu'adopté ne contient pas ce mot [34].

Sources du §3 : [2] [1] [5] [33] [14] [34], vérifiées le 4 octobre 2026. Retour au sommaire.

Qu'est-ce que le « harness » d'un agent ?

Le harness d'un agent est le logiciel qui entoure le modèle et en fait un agent : les outils qu'il peut appeler, la gestion de son contexte, ce qu'il peut faire sans demander, l'endroit où ses commandes s'exécutent et le journal de la session. La documentation d'Anthropic le dit en une ligne : « Claude Code est le harness ; Claude est le modèle qu'il contient » (notre traduction) [19] [5].

À la fin de cette section, vous saurez dire qui fait tourner la boucle dans chaque offre des deux éditeurs, et pourquoi un changement du harness peut changer l'agent.

La définition vient du glossaire de Claude Code, qui poursuit : « Claude Code est le harness ; Claude est le modèle qu'il contient » (notre traduction) [19]. La page « How Claude Code works » décrit la même couche de l'intérieur : Claude Code fournit les outils et gère le contexte que voit le modèle, et « c'est cette couche environnante que désigne le terme de harness agentique » (notre traduction) [5].

Le glossaire énumère aussi ce que fournit le harness : « l'accès aux fichiers, l'exécution shell, le contrôle des permissions, le chargement de la mémoire et la boucle qui enchaîne les actions » (notre traduction) [19]. Rien de tout cela n'est le modèle, qui « n'exécute jamais rien de lui-même » (notre traduction) : il émet une requête structurée, et le code qui l'entoure exécute l'opération [35].

La figure 4.1 construit le harness couche par couche autour d'un modèle qui, seul, ne fait que recevoir et produire du texte : l'exécuteur d'outils, puis la gestion du contexte, puis les permissions et les hooks, puis les murs du bac à sable. Sa dernière étape ajoute les surfaces d'accès et met côte à côte une ligne de chaque éditeur.

Deux éditeurs, une même architecture. Le billet d'Anthropic sur Managed Agents, daté du 8 avril 2026, découpe un agent hébergé en trois : le « cerveau » (Claude et son harness), les « mains » (les bacs à sable et les outils qui exécutent les actions) et la session, « le journal, en ajout seul, de tout ce qui s'est passé » (nos traductions) [37]. Chaque partie peut tomber en panne ou être remplacée indépendamment des autres [37]. La panne d'un conteneur remonte au modèle comme une erreur d'appel d'outil ; un harness en panne est remplacé par un nouveau, relancé avec wake(sessionId), qui reprend à partir du journal [37]. Sur les identifiants, le billet indique que la correction structurelle a consisté à « faire en sorte que les jetons ne soient jamais accessibles depuis le bac à sable où s'exécute le code généré par Claude » (notre traduction) [37].

OpenAI emploie le même mot. Sa comparaison des environnements d'exécution résume ainsi l'Agents API : « OpenAI fait tourner un harness Codex géré » (notre traduction) [36]. Lancée en bêta publique le 10 septembre 2026, l'Agents API expose le harness et l'infrastructure qui font tourner Codex : OpenAI héberge le harness, et vous choisissez où s'exécute le calcul de l'agent, dans un bac à sable hébergé par OpenAI, sur votre propre infrastructure ou chez un partenaire [13]. Elle repose sur le harness open source de Codex [13] et, depuis le 29 septembre 2026, prend aussi en charge l'utilisation de l'ordinateur (computer use) [38].

Plus tôt, le 15 avril 2026, OpenAI avait présenté son Agents SDK comme un harness natif pour le modèle : MCP, des skills (compétences) au chargement progressif, AGENTS.md, un outil shell, un outil d'application de correctifs (apply patch) et une mémoire configurable, plus une exécution native en bac à sable, d'abord en Python [28]. Le même billet donne la raison de séparer le harness du bac à sable : « séparer le harness et le calcul aide à tenir les identifiants à l'écart des environnements où s'exécute le code généré par le modèle » (notre traduction) [28]. Les deux architectures tiennent les identifiants loin du code qu'écrit le modèle [37] [28].

Chaque éditeur propose plusieurs façons de faire tourner la boucle, de votre propre code qui pilote chaque tour jusqu'au harness hébergé par l'éditeur. Le tableau 4.1 les compare sur les mêmes colonnes.

Sources du §4 : [19] [5] [35] [17] [36] [27] [3] [37] [13] [38] [28] [18] [39] [40] [6] [11] [12] [29] [10] [41] [42], vérifiées le 4 octobre 2026. Retour au sommaire.

Que se passe-t-il quand un agent appelle un outil ?

Un appel d'outil est le moyen par lequel un agent agit, mais le modèle n'exécute jamais rien lui-même : il propose un nom d'outil et des arguments. Le harness vérifie l'appel, demande l'autorisation si besoin, l'exécute et ajoute le résultat au contexte. Le modèle lit ce résultat pour choisir l'étape suivante : tout ce qu'un outil renvoie, le modèle le lit [35] [5].

À la fin de cette section, vous saurez suivre un appel de sa proposition à son résultat, et dire pourquoi la sortie d'un outil est une surface d'attaque.

La documentation de la plateforme d'Anthropic présente l'usage des outils comme « un contrat entre votre application et le modèle » (notre traduction) : l'application déclare quelles opérations existent et la forme de leurs entrées et de leurs sorties, et le modèle décide quand et comment les appeler [35]. La même page pose la règle qui compte le plus pour la sécurité : « Le modèle n'exécute jamais rien de lui-même. Il émet une requête structurée, votre code (ou les serveurs d'Anthropic) exécute l'opération » (notre traduction), puis le résultat revient dans la conversation [35].

La documentation de Claude Code décrit la même boucle du côté de l'agent : « chaque usage d'un outil rapporte des informations qui réalimentent la boucle et éclairent la décision suivante de Claude » (notre traduction) [5]. Ses outils intégrés se rangent en cinq catégories : les opérations sur les fichiers, la recherche, l'exécution, le web et l'intelligence du code [5].

Autour de l'appel. Entre la proposition et le résultat se trouve un logiciel qui peut refuser, vérifier et consigner. Le Model Context Protocol, le standard commun pour brancher des outils, détaille avec ses mots normatifs (DOIT pour MUST, DEVRAIT pour SHOULD, PEUT pour MAY) ce que fait un client prudent autour de chaque appel : il DEVRAIT montrer à l'utilisateur les entrées de l'outil avant d'appeler le serveur, valider les résultats avant de les transmettre au modèle, fixer un délai d'expiration aux appels et journaliser l'usage des outils pour l'audit [43]. De l'autre côté, les serveurs DOIVENT valider toutes les entrées des outils et assainir leurs sorties [43].

Les outils coûtent du contexte avant même de servir. Anthropic indique qu'une configuration typique à plusieurs serveurs « peut consommer environ 55 000 jetons de définitions avant que Claude ne fasse le moindre travail »^†, et que la recherche d'outils « réduit généralement ce volume de plus de 85 % »^† (nos traductions), en ne chargeant que les trois à cinq outils dont une requête a besoin [44]. La même page indique que la précision avec laquelle Claude choisit le bon outil se dégrade au-delà de 30 à 50 outils disponibles^† [44].

Les harness chargent donc les définitions au dernier moment. Dans Claude Code, les définitions des outils MCP sont différées par défaut et chargées à la demande par la recherche d'outils : tant qu'aucun outil ne sert, seuls les noms des outils et les instructions des serveurs occupent le contexte [5]. L'Agents API d'OpenAI, qui fait tourner le harness de Codex comme un service géré par OpenAI, propose la recherche d'outils, qui « charge les définitions d'outils pertinentes au besoin » (notre traduction), et l'appel programmatique d'outils (programmatic tool calling), qui permet aux agents de filtrer ou de combiner des résultats dans du code et de ne ramener dans le contexte que ceux qui comptent [13]. Le guide de Claude Code note aussi que les outils en ligne de commande sont « la manière la plus économe en contexte d'interagir avec des services externes » (notre traduction) [20].

Pourquoi la sortie d'un outil est une surface d'attaque. Un journal de tests, un résultat de recherche et une page web récupérée reviennent tous de la même façon : comme un résultat que le modèle lit avant de choisir son étape suivante [5]. Le même protocole demande aux clients de valider les résultats des outils avant qu'ils n'atteignent le modèle [43]. La partie III, sur le contrôle, part de là.

Sources du §5 : [35] [5] [43] [44] [13] [20], vérifiées le 4 octobre 2026. Retour au sommaire.

Pourquoi un agent oublie-t-il ? La fenêtre de contexte

Un agent ne voit que sa fenêtre de contexte, où chaque instruction, définition d'outil, fichier et sortie de commande prend de la place. Plus elle se remplit, plus la qualité baisse, et les détails anciens finissent résumés. L'ingénierie du contexte décide de ce qui entre : outils et skills chargés à la demande, anciens tours compactés, travail annexe confié à des sous-agents, texte stable en tête [20] [45].

À la fin de cette section, vous saurez expliquer pourquoi une longue session se dégrade, ce que perd le compactage, et pourquoi l'ordre d'un prompt change ce qu'il coûte.

Le guide des bonnes pratiques de Claude Code repose sur une seule contrainte : « la fenêtre de contexte de Claude se remplit vite, et les performances se dégradent à mesure qu'elle se remplit » (notre traduction) [20]. Le billet d'ingénierie qu'Anthropic consacre au sujet nomme l'effet : plus la fenêtre contient de jetons, moins le modèle parvient à y retrouver une information, ce que le billet appelle « context rot », le pourrissement du contexte ; un modèle dispose en outre d'un « budget d'attention » (notre traduction) limité, dans lequel puise chaque nouveau jeton [45].

Dans Claude Code, la fenêtre contient l'historique de la conversation, le contenu des fichiers, les sorties de commandes, CLAUDE.md, la mémoire automatique, les skills chargés et les instructions système [5]. Deux fonctions en tiennent une partie à l'écart. Les skills (compétences) se chargent à la demande : Claude voit leurs descriptions au démarrage de la session, et leur contenu complet seulement quand un skill sert [5]. Les sous-agents travaillent dans leur propre fenêtre : leurs appels d'outils restent hors de la vôtre, et un résumé revient quand ils ont fini [5].

La figure 6.1 suit la tâche T dans ce budget, de la charge fixe de T.01 jusqu'à une session assez longue pour être compactée, puis un nouveau départ. Sa bascule fait tourner la recherche de T.05 dans la session ou dans un sous-agent.

Quand la fenêtre se remplit. Près de la limite, Claude Code efface d'abord les anciennes sorties d'outils, puis résume la conversation ; vos demandes et les extraits de code importants sont gardés, mais « des instructions détaillées données tôt dans la conversation peuvent se perdre » (notre traduction), si bien que les règles durables ont leur place dans CLAUDE.md [5]. Un CLAUDE.md à la racine du projet et la mémoire automatique survivent au compactage et sont rechargés depuis le disque [19]. Si un fichier ou une sortie d'outil est si volumineux que la fenêtre se remplit de nouveau après chaque résumé, Claude Code « cesse de compacter automatiquement après quelques tentatives et affiche une erreur au lieu de tourner en boucle » (notre traduction) [5].

Les API proposent le même compromis. Le compactage de l'API d'Anthropic, en bêta, « remplace les tours les plus anciens d'une conversation par un résumé » (notre traduction), que Claude rédige côté serveur [48]. L'Agents API d'OpenAI compacte automatiquement le contexte antérieur quand une session approche de sa limite [13], et le guide GPT-6 d'OpenAI décrit le compactage comme une réduction de la taille du contexte qui préserve l'état nécessaire pour continuer [30].

D'une session à l'autre. Un résumé perd du détail, et une nouvelle session part de zéro. Le billet d'Anthropic sur les harness pour agents de longue durée le dit sans détour : « chaque nouvelle session commence sans aucun souvenir de ce qui a précédé » (notre traduction) [49]. Son harness laisse donc derrière lui un fichier de progression, une liste de fonctionnalités et des commits git, que la session suivante lit en premier [49].

L'ordre change le coût. La mise en cache des prompts fonctionne par préfixes : la documentation d'Anthropic la décrit comme le fait de « reprendre à partir de préfixes précis de vos prompts » (notre traduction) [50]. Sur l'API d'Anthropic, le cache suit l'ordre outils, système, messages, et un changement à un niveau invalide ce niveau et tous ceux qui suivent [50]. Le guide d'OpenAI donne le conseil symétrique : « placez les instructions stables et les documents de référence avant les détails de la tâche qui changent » (notre traduction) [30]. Le même guide indique que « les jetons d'entrée en cache coûtent jusqu'à 95 % de moins que les jetons d'entrée hors cache, selon le modèle »^† (notre traduction) [30].

Le protocole suit la même logique : la spécification MCP demande aux serveurs de renvoyer tools/list dans un ordre déterministe, ce qui permet aux clients de mettre la liste en cache et améliore le taux de succès du cache de prompts quand les outils figurent dans le contexte du modèle [15] [43].

Quelle taille fait la fenêtre ? Vérification faite le 4 octobre 2026, les modèles phares actuels des deux éditeurs acceptent environ un million de jetons : 1 million sur les modèles Claude 5.x dans la vue d'ensemble des modèles d'Anthropic [51], et 1 050 000 sur les quatre pages de modèles GPT-6 d'OpenAI [52]. La taille repousse la limite ; elle ne lève pas la contrainte de départ.

Sources du §6 : [20] [45] [5] [44] [46] [19] [47] [48] [13] [30] [49] [50] [15] [43] [51] [52], vérifiées le 4 octobre 2026. Retour au sommaire.

CLAUDE.md, AGENTS.md, skills, sous-agents : qui se charge quand ?

AGENTS.md et CLAUDE.md sont de simples fichiers Markdown de règles de projet, lus par un agent de code au démarrage d'une session. Les skills sont des dossiers d'instructions chargés seulement quand une tâche en a besoin. Les sous-agents mènent une tâche annexe dans leur propre contexte et renvoient un résumé. Aucun d'eux n'impose rien : ce rôle revient aux hooks, aux règles de permission et au bac à sable [17] [53] [19].

À la fin de cette section, vous saurez prévoir quels fichiers d'instructions un agent lit, et choisir entre une règle, un skill, un sous-agent et un hook.

Claude Code charge ses fichiers CLAUDE.md, des fichiers Markdown d'instructions de projet, et sa mémoire automatique au début de chaque conversation [17]. AGENTS.md est un format ouvert du même genre, qui se présente comme « un README pour les agents » (notre traduction) et dont la gestion revient à l'Agentic AI Foundation, rattachée à la Linux Foundation [53].

Les fichiers courts fonctionnent mieux. La page de Claude Code sur la mémoire fixe un objectif de moins de 200 lignes par CLAUDE.md [17]. Son guide des bonnes pratiques propose de demander, pour chaque ligne : « la supprimer amènerait-elle Claude à faire des erreurs ? » (notre traduction), et prévient que des fichiers trop chargés poussent Claude à ignorer vos véritables instructions [20]. La mémoire automatique contient les notes que Claude écrit lui-même à partir de vos corrections et de vos préférences ; les 200 premières lignes ou les 25 premiers Ko de MEMORY.md, selon la limite atteinte en premier, se chargent à chaque session [17].

Quel fichier l'emporte. Chaque éditeur documente sa propre règle. Depuis la v2.1.277, publiée le 18 septembre 2026 [6], Claude Code lit AGENTS.md quand il n'y a ni CLAUDE.md, ni .claude/CLAUDE.md, ni CLAUDE.local.md dans le répertoire de travail ou au-dessus ; quand les deux sortes de fichiers sont présentes, il ne lit par défaut que les CLAUDE.md, et un réglage permet de charger les deux [17]. Il ne lit jamais AGENTS.local.md, AGENTS.override.md, ni rien de ce qui se trouve dans un répertoire .agents/ [17].

Codex construit une chaîne d'instructions à son démarrage : dans son répertoire personnel, il lit AGENTS.override.md s'il existe, sinon AGENTS.md, et ne garde que le premier fichier non vide ; il parcourt ensuite le projet depuis sa racine, en général la racine Git, jusqu'au répertoire courant, en prenant au plus un fichier par répertoire [54]. Les fichiers sont concaténés de la racine vers le bas, si bien que « les fichiers plus proches de votre répertoire courant l'emportent sur les consignes précédentes » (notre traduction), et Codex cesse d'ajouter des fichiers à project_doc_max_bytes, soit 32 Kio par défaut [54].

Le site d'AGENTS.md donne la règle générale : « l'AGENTS.md le plus proche du fichier modifié l'emporte ; les demandes explicites de l'utilisateur dans le chat priment sur tout le reste » (notre traduction) [53]. Le guide GPT-6 d'OpenAI précise ce qu'un tel fichier doit dire : quand certains documents et certains tests comptent, et une autorisation explicite pour les tâches courantes sans risque, comme lancer des tests locaux sur des données jetables, sans aucun accès à la production [30].

Ce qui impose une règle. Aucun de ces fichiers ne peut empêcher une action. La page de Claude Code sur la mémoire est explicite : pour bloquer une action quoi que décide Claude, il faut un hook PreToolUse [17]. Un hook est un gestionnaire défini par l'utilisateur, qui s'exécute à un point fixe du cycle de vie de la session, par exemple avant l'exécution d'un outil, après la modification d'un fichier ou au démarrage de la session [19]. Le guide de Claude Code pour bâtir sa configuration au fil du temps donne une règle simple : une convention ou une commande sur laquelle Claude se trompe deux fois va dans CLAUDE.md ; ce qui doit se produire à chaque fois, sans demander, devient un hook [55].

Les skills : des instructions chargées à la demande

Un skill, ou compétence, est un dossier qui contient un fichier SKILL.md, avec un nom, une description et des instructions pour une tâche précise, et qui peut embarquer des scripts, des références et d'autres fichiers [56]. Les agents chargent les skills par étapes, en trois temps (progressive disclosure) : au démarrage, seulement le nom et la description de chaque skill ; le SKILL.md complet quand une tâche correspond à la description ; les fichiers joints seulement au besoin [56] [9]. La documentation de Claude Code en dit l'effet sur le contexte : « Claude voit les descriptions des skills au démarrage de la session, mais leur contenu complet ne se charge que lorsqu'un skill sert » (notre traduction) [5].

Anthropic a présenté Agent Skills le 16 octobre 2025, puis publié le format comme standard ouvert le 18 décembre 2025 [9]. Codex a ajouté les skills d'agent dès le lendemain, le 19 décembre 2025, en suivant la spécification ouverte des skills d'agent [10], et agentskills.io cite, parmi les outils qui ont adopté le format, Claude Code, ChatGPT et Codex, GitHub Copilot, Cursor et Gemini CLI [56].

Les sous-agents : une tâche annexe dans son propre contexte

Un sous-agent est une seconde boucle d'agent, pour une tâche déléguée. Dans Claude Code, il tourne dans sa propre fenêtre de contexte, avec son prompt système, ses accès aux outils et ses permissions, et renvoie un résumé ; les sous-agents intégrés comprennent Explore, Plan et general-purpose [19]. Le guide de configuration de Claude Code dit quand y recourir : quand une tâche annexe noie votre conversation sous une sortie que vous ne consulterez plus, faites-la passer par un sous-agent [55].

Codex définit ses agents personnalisés dans des fichiers TOML rangés dans ~/.codex/agents/ ou .codex/agents/, chacun avec un name, une description et des developer_instructions [47]. Les versions locales de Codex lancent des sous-agents sur demande directe ou quand une instruction du projet ou d'un skill s'y prête, et la documentation les conseille pour les tâches qui lisent beaucoup, comme l'exploration, les tests, le tri des problèmes ou les résumés, avec plus de prudence pour celles qui écrivent beaucoup [47].

Déléguer coûte des jetons, chez les deux éditeurs. La documentation de Claude Code prévient : « lancer plusieurs sessions ou sous-agents à la fois multiplie la consommation de jetons » (notre traduction) [57]. La Responses API d'OpenAI propose un mode multi-agent, en bêta, qui donne à chaque sous-agent son propre contexte et fixe par défaut à trois le nombre de sous-agents actifs (max_concurrent_subagents) ; sa documentation ajoute que les sous-agents peuvent augmenter la consommation de jetons et n'aident pas forcément les tâches qui reposent sur une seule chaîne de raisonnement ordonnée ou qui écrivent souvent dans un état partagé modifiable [46].

La figure 7.1 parcourt une session dans une seule colonne de contexte : ce qui est toujours chargé, ce qui se charge à la demande, ce qui tourne à part, et ce qui se tient hors de la colonne et impose. Le tableau 7.1 reprend les mêmes mécanismes ligne par ligne.

Sources du §7 : [17] [53] [19] [20] [6] [54] [30] [55] [56] [9] [5] [10] [47] [57] [46] [58] [27], vérifiées le 4 octobre 2026. Retour au sommaire.

MCP, c'est quoi ? Et quelle différence avec une API ?

MCP, le Model Context Protocol, est un standard ouvert qui permet à un agent de découvrir et d'appeler les outils et les données qu'exposent des serveurs, de la même façon pour tous les serveurs. Une API est l'interface propre à un service ; un serveur MCP enveloppe en général des API pour que n'importe quel agent conforme puisse s'en servir. La révision 2026-07-28 a rendu le protocole sans état [59] [15].

À la fin de cette section, vous saurez expliquer MCP dans sa révision actuelle, et le distinguer d'une API comme d'A2A.

Les versions de MCP sont des dates : chaque chaîne de version marque la dernière date à laquelle des changements incompatibles avec les versions antérieures ont été apportés [61]. Vérification faite le 4 octobre 2026, la page sur le versionnage désigne 2026-07-28 comme version actuelle [61]. Le tableau 8.1 reprend les principaux changements de chaque révision depuis mars 2025.

Ce que 2026-07-28 a changé. La révision a réécrit la façon dont un client parle à un serveur [15] :

• Les sessions au niveau du protocole et l'en-tête Mcp-Session-Id disparaissent, tout comme la négociation initiale initialize puis notifications/initialized ; chaque requête porte sa version du protocole et les capacités du client dans _meta [15].
• Les serveurs DOIVENT implémenter server/discover, qui annonce les versions qu'ils prennent en charge, leurs capacités et leur identité ; les clients PEUVENT l'appeler avant toute autre requête [15].
• Les requêtes à allers-retours multiples (Multi Round-Trip Requests) remplacent les requêtes émises par le serveur : un serveur à qui il manque une information renvoie resultType: "input_required" avec inputRequests, et le client relance la requête d'origine avec inputResponses [15].
• Chaque résultat porte un resultType, "complete" ou "input_required" [15].
• La reprise des flux SSE disparaît : un flux interrompu perd la requête en cours, que le client renvoie comme une nouvelle requête [15].
• Les tâches (tasks) quittent le cœur du protocole pour une extension officielle [15].

Le billet de migration de l'Agentic AI Foundation, écrit une semaine avant la sortie et qui parle donc encore de propositions, en donne le but : une répartition de charge en round-robin ordinaire, sans sessions persistantes (sticky sessions) ni état de session partagé [62]. La figure 8.1 déroule le même appel d'outil sous les deux révisions.

Ce qu'elle retire. La même révision rend obsolètes Roots, Sampling et Logging, avec ce conseil : « journalisez vers stderr (stdio) ou utilisez OpenTelemetry plutôt que Logging » (notre traduction) ; elle rend aussi obsolètes le transport HTTP+SSE, deux valeurs de includeContext, et l'enregistrement dynamique des clients (Dynamic Client Registration) au profit des Client ID Metadata Documents [15]. Une fonction rendue obsolète reste dans la spécification au moins douze mois, ou au moins quatre-vingt-dix jours au titre de l'exception de retrait accéléré que prévoit la politique de cycle de vie et de dépréciation des fonctionnalités, avant de pouvoir être supprimée [61] ; le billet de migration fixe au 28 juillet 2027 la date de retrait la plus précoce pour cet ensemble [62].

Les règles pour qui fait tourner l'agent. Sur les outils, la spécification dit qu'« il DEVRAIT toujours y avoir un humain dans la boucle, capable de refuser les invocations d'outils », et que les clients « DOIVENT considérer les annotations d'outils comme non fiables, sauf si elles viennent de serveurs de confiance » (nos traductions) [43]. Sur l'autorisation, les bonnes pratiques de sécurité de la même révision disent que les serveurs NE DOIVENT PAS tenir la possession d'un identifiant d'état (state handle) pour une authentification, et NE DOIVENT PAS accepter des jetons d'accès qui n'ont pas été émis pour eux [66].

MCP ou API

Une API est l'interface propre à un service, avec ses points d'accès, son authentification et ses conventions. MCP est un protocole unique : tout client conforme liste les outils d'un serveur avec tools/list et les appelle avec tools/call, quoi que fasse le serveur derrière [43]. Un serveur MCP est donc en général un adaptateur placé devant une ou plusieurs API ; la spécification elle-même dit des outils qu'ils permettent aux modèles d'interagir avec des systèmes externes, « par exemple interroger des bases de données, appeler des API ou effectuer des calculs » (notre traduction) [43]. Le journal des modifications de la révision actuelle est la meilleure page à lire ensuite [15].

MCP ou A2A

A2A, le protocole Agent2Agent, répond à une autre question. Sa spécification, en version 1.0.0, présente les deux comme des « protocoles complémentaires » (notre traduction) : MCP normalise la façon dont les agents se connectent aux outils, aux API, aux sources de données et à d'autres ressources, tandis qu'A2A normalise la façon dont des agents indépendants communiquent et collaborent entre eux, d'égal à égal [67]. Son propre exemple associe les deux : un agent serveur A2A peut se servir de MCP pour atteindre les outils dont il a besoin afin d'achever une tâche qu'un agent client A2A lui a confiée [67].

Sources du §8 : [59] [15] [60] [61] [62] [43] [26] [63] [64] [65] [66] [20] [55] [67] [68], vérifiées le 4 octobre 2026. Retour au sommaire.

Les agents IA sont-ils dangereux ? Injection de prompt et « trifecta létale »

Un agent IA est dangereux de deux façons documentées : il peut obéir à des instructions cachées dans une page web, un e-mail ou un fichier et se servir de ses accès pour faire fuir des données, et il peut contourner les contrôles qu'on lui a imposés [69] [70]. Les parades sont structurelles : ne jamais réunir contenu non fiable, données privées et communication vers l'extérieur sans validation humaine [71].

À la fin de cette section, vous saurez expliquer l'injection de prompt, reconnaître la combinaison de capacités qui la rend dangereuse et citer des parades qui donnent des garanties plutôt que des probabilités.

Repartons de la tâche T et changeons une seule ligne de ce que lit l'agent.

L'instruction cachée arrive par le même chemin que n'importe quel résultat d'outil. Le harness exécute la lecture et verse ce qu'elle renvoie dans le contexte, sous forme de texte, puis le modèle lit ce texte pour choisir sa prochaine étape : tout ce qu'un outil renvoie, le modèle le lit [35] [5].

L'attaque porte un nom depuis le 12 septembre 2022, quand Simon Willison a décrit des attaques par injection de prompt contre GPT-3 [72]. L'injection indirecte, où le texte hostile n'arrive pas par l'utilisateur mais à l'intérieur de données que l'application va chercher, a été décrite dans un article du 23 février 2023 [73]. Cette page reprend la définition du glossaire de Claude Code, en mettant l'agent à la place de Claude :

La « trifecta létale ». Le 16 juin 2025, Simon Willison a nommé la combinaison qui transforme une injection en fuite : l'accès à des données privées, l'exposition à du contenu non fiable et la capacité de communiquer vers l'extérieur [69]. L'exécution piégée réunit les trois : une clé d'API se trouve dans l'environnement, la ligne aspirée n'est pas fiable, et l'agent peut faire sortir des requêtes. Sur les garde-fous qui se targuent d'arrêter la plupart des attaques, il est sans appel : « 95 %, c'est bel et bien une note éliminatoire » (notre traduction) [69].

La Rule of Two. Publiée par Meta le 31 octobre 2025, la règle dite « Agents Rule of Two » fait de la même idée une règle de conception : au sein d'une même session, un agent ne devrait réunir, au plus, que deux des trois propriétés suivantes [71].

• [A] Il traite des entrées non fiables.
• [B] Il a accès à des systèmes sensibles ou à des données privées.
• [C] Il peut modifier un état ou communiquer vers l'extérieur.

Si une tâche exige les trois, l'agent ne devrait pas tourner en autonomie mais sous supervision, par exemple avec une validation humaine dans la boucle ; Meta présente la règle comme un complément au principe du moindre privilège, non comme un substitut [71].

La figure 9.1 met les trois branches sur des interrupteurs. Lancez l'attaque avec les trois activés et la clé part ; coupez une branche, n'importe laquelle, et le chemin s'interrompt à cet endroit ; ou gardez les trois et placez un accord humain sur l'appel sortant, qui met la requête en pause là où une personne voit ce qu'elle enverrait. Les légendes sous les interrupteurs donnent trois noms à une même structure : la trifecta, la Rule of Two, et les sources et puits de l'analyse d'OpenAI [69] [71] [74].

Ce que font les éditeurs. Les deux éditeurs traitent le contenu venu de l'extérieur comme non fiable dans leurs propres outils [4] [76]. Dans Claude Code, le classifieur du mode auto voit les messages de l'utilisateur et les appels d'outils de l'agent, mais pas leurs résultats, qui lui sont retirés : un contenu hostile logé dans un fichier ou une page web ne peut donc pas s'adresser à lui directement [4] [19]. La page de sécurité de Codex le dit en une phrase, « Traitez les résultats web comme non fiables » (notre traduction) [76], et le guide d'OpenAI sur l'utilisation de l'ordinateur (computer use) demande la même prudence pour ce qui s'affiche à l'écran [77].

Le billet d'OpenAI du 11 mars 2026 ajoute que les injections les plus efficaces en conditions réelles ressemblent de plus en plus à de l'ingénierie sociale, et que la défense ne peut pas reposer sur le seul filtrage des entrées : il faut concevoir les systèmes pour limiter l'impact même quand certaines attaques réussissent [74]. OpenAI indique qu'un e-mail d'attaque de 2025, pris en exemple, a fonctionné dans 50 % de ses tests avec un prompt donné ^† [74]. OpenAI y associe l'analyse source-puits et une parade qu'il nomme Safe Url [74].

Les listes de la communauté. L'OWASP GenAI Security Project a publié en décembre 2025 son Top 10 des applications agentiques (tableau 9.1) [75]. Le document pose le principe de « Least-Agency », le moins d'autonomie possible, et juge l'observabilité « non négociable » (notre traduction) [75]. Dans le Top 10 distinct que le même projet consacre aux applications LLM, daté du 3 août 2026, l'Excessive Agency, l'autonomie excessive, « est montée à la troisième place » (LLM03:2026, notre traduction) [33].

Des défenses par conception. Des chercheurs ont proposé des défenses qui tiennent par construction plutôt que par détection [78] [79]. Un article de 2025 décrit six patrons de conception contre l'injection : Action-Selector, Plan-Then-Execute, LLM Map-Reduce, Dual LLM, Code-Then-Execute et Context-Minimization [78]. CaMeL, issu d'un autre article de 2025, sépare le flux de contrôle d'une tâche des données non fiables qu'elle manipule ; ses auteurs indiquent 77 % des tâches d'AgentDojo résolues avec une sécurité prouvable, contre 84 % pour un système sans défense [79].

Sources du §9 : [69] [70] [71] [35] [5] [72] [73] [19] [74] [75] [4] [76] [77] [33] [78] [79] [23] [80], vérifiées le 4 octobre 2026. Retour au sommaire.

Que peut faire un agent sans demander ? Bacs à sable et permissions

Deux couches décident de ce qu'un agent peut faire sans demander. Un bac à sable, imposé par le système d'exploitation, limite les fichiers et les hôtes réseau que ses commandes peuvent atteindre [3] [76]. Les réglages de permission fixent ce qui s'exécute, ce qui attend l'accord d'une personne et ce qui est refusé. Anthropic comme OpenAI laissent désormais un relecteur IA approuver les actions courantes, et en publient les limites [4] [7].

À la fin de cette section, vous saurez expliquer les deux murs, lire côte à côte les deux modèles de permission et lire sans illusion le taux d'erreur d'un relecteur IA.

L'exécution piégée veut la clé d'API, et une requête sortante pour l'emporter. Deux couches lui barrent la route avant qu'on ne demande quoi que ce soit à une personne : des murs autour des commandes de l'agent, et des réglages qui décident de ce qui s'exécute tout seul.

Deux murs. Le billet d'Anthropic sur le bac à sable explique pourquoi un seul mur ne suffit pas : « Sans isolation du réseau, un agent compromis pourrait exfiltrer des fichiers sensibles comme des clés SSH », et « sans isolation du système de fichiers, un agent compromis pourrait facilement s'échapper du bac à sable et obtenir un accès au réseau » (nos traductions) [3]. Claude Code bâtit ces murs sur bubblewrap sous Linux et sur Seatbelt sous macOS, et Anthropic a publié le runtime du bac à sable en open source, sous forme d'aperçu de recherche [3]. Dans son usage interne, Anthropic a constaté que « le bac à sable réduit sans risque les demandes d'autorisation de 84 % » (notre traduction) ^† [3].

Le bac à sable de Claude Code ne couvre que les commandes shell, et ses domaines réseau autorisés sont « vides au départ » (notre traduction) ; les outils de fichiers de Claude, les serveurs MCP locaux et les hooks de commande tournent en dehors [58]. Codex nomme trois modes de bac à sable : read-only, workspace-write (le mode par défaut dans un dossier sous contrôle de version) et danger-full-access [76]. Ses politiques d'approbation comprennent on-request, par défaut, never et une politique granulaire qui garde certaines catégories de demandes et refuse les autres ; l'ancienne politique untrusted a été retirée [76]. Le réseau est coupé par défaut, et c'est le système d'exploitation qui fait respecter la limite : Seatbelt par sandbox-exec sous macOS, bwrap et seccomp sous Linux, un bac à sable natif ou WSL2 sous Windows [76].

La figure 10.1 dessine les deux murs autour d'un même shell. Avec les deux en place, le contrôle de la tâche T tourne dans le projet, une écriture hors du projet s'arrête au mur des fichiers, une lecture de ~/.ssh/ passe ce mur, qui par défaut bloque les écritures et non les lectures, et une requête vers un hôte inconnu s'arrête au mur du réseau : c'est lui qui garde la clé. Retirez un mur et regardez ce que l'autre ne couvre plus.

Les réglages de permission. À l'intérieur des murs, des réglages décident de ce qui s'exécute sans personne : six modes de permission dans Claude Code, quatre dans Codex, bâtis sur ses modes de bac à sable et ses politiques d'approbation (tableau 10.1) [19] [81]. Depuis la v2.1.283, publiée le 25 septembre 2026, le mode auto est le mode de départ intégré des sessions interactives dans le terminal et dans VS Code ; sur les versions antérieures, il ne l'était que sur les offres Pro, Max et Team [82] [6]. Le mode auto exige un modèle compatible, et une organisation peut le désactiver [82].

Des règles se superposent aux modes. L'Agent SDK évalue un appel d'outil dans un ordre fixe : les hooks, les règles de refus (deny), les règles de demande (ask), le mode de permission, les règles d'autorisation (allow), puis le callback canUseTool ; une règle de refus qui correspond bloque l'outil « même en mode bypassPermissions » (notre traduction) [27]. Les règles s'évaluent dans l'ordre refus, demande, autorisation, et la première qui correspond l'emporte [19]. Les points de restauration ne rattrapent pas tout : « Les actions qui touchent des systèmes distants (bases de données, API, déploiements) ne peuvent pas faire l'objet d'un point de restauration » (notre traduction) [5].

OpenAI documente les mêmes barrières dans ses propres outils. Dans l'Agents SDK, avec un outil marqué needs_approval, l'exécution renvoie des interruptions et un état qu'on peut reprendre : vous approuvez ou refusez, puis vous reprenez l'exécution [83]. Le guide pratique d'OpenAI conseille de classer chaque outil en risque faible, moyen ou élevé, et de faire intervenir un humain quand des seuils d'échec sont dépassés et avant les actions à haut risque [1]. Le guide de prompting de Codex demande une approbation avant que l'agent n'envoie, ne publie ou ne modifie des informations dont d'autres dépendent [84]. La pull request de la tâche T, à l'étape T.11, est une action de ce genre.

Les relecteurs IA. Les deux éditeurs laissent un second modèle trancher les demandes d'approbation à la place de l'utilisateur [4] [7]. Le classifieur du mode auto d'Anthropic ne voit que les messages de l'utilisateur et les appels d'outils de l'agent, une fois retirés les messages de Claude et les sorties d'outils, « ce qui le rend aveugle au raisonnement, par conception » (notre traduction) ; il travaille en deux étapes [4]. Pour le pipeline déployé, Anthropic indique 0,4 % de faux positifs sur le trafic réel (n = 10 000), 17 % de faux négatifs sur des actions réelles trop zélées (n = 52) et 5,7 % de faux négatifs sur des tentatives d'exfiltration synthétiques (n = 1 000) ^† [4]. Le billet ajoute : « Le taux de 17 % de faux négatifs sur les actions réelles trop zélées est le chiffre honnête » (notre traduction) ^† [4].

Dans Codex, le réglage approvals_reviewer = "auto_review" confie les demandes d'approbation éligibles à un agent relecteur [76]. Auto-review n'examine que les actions qui demandent déjà une approbation, si bien que les actions menées à l'intérieur du bac à sable échappent à son examen, et il n'élargit ni le bac à sable ni l'accès au réseau [7]. Là où le classifieur d'Anthropic ne reçoit pas les résultats d'outils, le relecteur de Codex voit « une transcription condensée, plus la demande d'approbation exacte » (notre traduction), en général avec les appels et les sorties d'outils, mais sans le raisonnement caché de l'assistant [7]. Il est conçu pour bloquer l'envoi de données privées, de secrets ou d'identifiants vers des destinations non fiables, la recherche d'identifiants, l'affaiblissement large ou durable de la sécurité, et les actions destructrices qui risquent sérieusement de causer des dommages irréversibles ; la politique elle-même est open source [7]. Dans l'implémentation open source actuelle, un disjoncteur interrompt le tour après « 3 refus consécutifs ou 10 refus dans une fenêtre glissante des 50 derniers examens du même tour » (notre traduction), et /approve autorise une nouvelle tentative d'une action refusée, qui repasse malgré tout par Auto-review [7].

La figure 10.2 rassemble les chiffres publiés : les approbations sous forme de points, la baisse des demandes due au bac à sable sous forme de barre, les erreurs du classifieur sur son petit échantillon, et le disjoncteur de Codex sous forme de compteur [4] [3] [7].

Le confinement. Anthropic décrit son confinement produit par produit : claude.ai exécute le code dans un conteneur gVisor, Claude Code est un « bac à sable avec un humain dans la boucle » (notre traduction), soit des demandes d'approbation plus un bac à sable du système d'exploitation, Seatbelt ou bubblewrap, et Cowork exécute son code dans une machine virtuelle locale [23]. Le même billet affirme que « la couche la plus faible est celle que vous avez construite vous-même » (notre traduction) [23].

Lors d'un exercice interne et contrôlé de red team, en février 2026, un chercheur a piégé un employé par hameçonnage pour qu'il lance Claude Code avec un prompt malveillant [23]. « Sur 25 nouvelles tentatives avec ce prompt, Claude a mené l'exfiltration à son terme 24 fois » (notre traduction) ^† [23]. Le billet y voit une injection directe, puisque les instructions sont arrivées par l'utilisateur, et conclut que, dans ce cas, la seule défense qui tienne est l'environnement : le contrôle des flux sortants et les limites du système de fichiers [23].

La surveillance du désalignement d'OpenAI est asynchrone. Quand elle se déclenche, l'API renvoie une erreur HTTP 403 avec invalid_request_error et misalignment_policy_violation ; la consigne est de cesser d'envoyer des actions et de ne pas relancer automatiquement [85]. La page prévient : « Comme la surveillance est asynchrone, une action peut déjà être terminée avant que la surveillance ne détecte un problème » (notre traduction) [85].

Sources du §10 : [3] [76] [4] [7] [19] [58] [81] [82] [6] [27] [5] [83] [1] [84] [23] [85], vérifiées le 4 octobre 2026. Retour au sommaire.

Comment évaluer un agent IA ? Vérification, pass@k et pass^k

Un agent a fait le travail quand un contrôle qu'il ne peut pas contester passe : un test, un build [20]. Pour mesurer sa fiabilité, on lance chaque tâche plusieurs fois : pass@k est la probabilité qu'au moins un des k essais réussisse, pass^k celle que tous réussissent [86]. À 75 % de réussite par essai, la probabilité calculée que trois essais réussissent tous est d'environ 42 % [86].

À la fin de cette section, vous saurez définir une évaluation, distinguer pass@k de pass^k et lire un score de benchmark avec méfiance.

La tâche T se referme sur une preuve : le contrôle échoue en T.04, passe en T.10, et c'est seulement alors que l'agent demande à ouvrir la pull request. Les bonnes pratiques de Claude Code en font la première règle : « Donnez à Claude un contrôle qu'il peut lancer : des tests, un build, une capture d'écran à comparer » (notre traduction) [20]. Sans contrôle, « a l'air fini » reste le seul signal, et « c'est vous qui devenez la boucle de vérification » (nos traductions) [20].

La page des bonnes pratiques énumère des verrous de plus en plus solides [20] :

1. demander le contrôle dans le prompt ;
2. en faire une condition /goal, qu'un évaluateur distinct revérifie après chaque tour ;
3. ajouter un hook Stop qui lance le contrôle sous forme de script et empêche le tour de se terminer tant qu'il ne passe pas ;
4. confier le résultat à un sous-agent de vérification, un modèle neuf qui cherche à le réfuter.

Le guide des modèles GPT-6 qu'OpenAI a publié le 2 octobre 2026 donne la même consigne avec ses propres mots : définir à quoi se reconnaît un travail terminé (implémenter, lancer, examiner le résultat, corriger les échecs) et lister les décisions qui vous reviennent [30].

Le vocabulaire des évaluations. Le billet d'Anthropic sur les évaluations d'agents fixe les termes, cités ici dans notre traduction [86] :

• une tâche (task) est « un test unique, avec des entrées et des critères de réussite définis » ;
• un essai (trial) est une tentative de mener une tâche à bien ;
• un correcteur (grader) est la logique qui note un aspect de la performance de l'agent ;
• une transcription (transcript) est « l'enregistrement complet d'un essai » ;
• l'issue (outcome) est « l'état final de l'environnement » au terme de l'essai.

Dans la tâche T, la transcription, ce sont les douze étapes. La réponse finale peut affirmer que le contrôle passe ; l'issue, c'est un dépôt dans lequel il passe vraiment.

Deux mesures de la fiabilité. Un essai ne prouve pas grand-chose, car la sortie d'un modèle varie d'une exécution à l'autre [86]. Deux mesures résument plusieurs essais d'une même tâche : pass@k, « la probabilité qu'un agent obtienne au moins une solution correcte en k tentatives », et pass^k, « la probabilité que les k essais réussissent tous » (nos traductions) [86]. Si les essais sont indépendants et que chacun réussit avec une probabilité p, les deux mesures suivent les équations (1) et (2).

Avec p = 0,75 et k = 3, l'équation (2) donne 0,75 × 0,75 × 0,75 = 0,421875, soit environ 42 %, calculé comme dans l'exemple chiffré d'Anthropic [86]. Pour les mêmes valeurs, l'équation (1) donne 1 − 0,25 × 0,25 × 0,25 = 0,984375, soit environ 98 % (calculé). Le billet le dit sans détour : à k = 10, les deux mesures « racontent des histoires opposées » (notre traduction) [86].

La figure 11.1 trace les deux courbes. Parcourez ses préréglages, puis déplacez les curseurs : a marché une fois et marche à chaque fois se séparent en quelques essais. Le tableau 11.1 donne les mêmes valeurs, sans le dessin.

Construire une évaluation. Anthropic en distingue deux sortes : les évaluations de capacité « devraient partir d'un faible taux de réussite » (notre traduction), tandis que les évaluations de non-régression, qui vérifient que l'agent réussit toujours les tâches qu'il savait mener, devraient passer presque à chaque fois [86]. Pour un premier jeu, Anthropic conseille 20 à 50 tâches simples tirées d'échecs réels [86]. La mesure pass^k elle-même vient de tau-bench, un benchmark de l'interaction entre outil, agent et utilisateur publié le 17 juin 2024 [87].

Tant que le comportement d'un agent est encore en cours de mise au point, OpenAI conseille de partir des traces, notées par des correcteurs de traces (trace graders) [32]. Une réserve datée s'impose : la page qu'OpenAI consacre aux retraits (Deprecations) indique que les évaluations existantes passent en lecture seule le 31 octobre 2026, prévoit la fermeture du tableau de bord et de l'API Evals le 30 novembre 2026, et range dans cette transition les correcteurs documentés pour les workflows d'évaluation [16]. Les pages sur la notation des traces ne portent aucun avertissement de ce genre [32].

Séparer le correcteur de l'exécutant. Anthropic constate que des agents à qui l'on demande d'évaluer un travail qu'ils ont produit « ont tendance à répondre en faisant l'éloge du travail avec assurance » (notre traduction) [88]. Son harness pour le développement d'applications au long cours répartit le travail entre un planificateur, un générateur et un évaluateur [88]. Dans la tâche T, c'est le contrôle qui joue l'évaluateur : il échoue, quoi que l'agent pense de sa propre modification.

Les benchmarks publics vieillissent eux aussi : le cas 3 qui suit cette section en retrace un qui a cessé de mesurer ce pour quoi il avait été construit.

Sources du §11 : [20] [86] [19] [30] [87] [32] [16] [88], vérifiées le 4 octobre 2026. Retour au sommaire.

Bonnes pratiques : ce sur quoi Anthropic et OpenAI s'accordent

Les bonnes pratiques qu'Anthropic et OpenAI documentent tous deux tiennent en une courte liste : donner à l'agent un contrôle qu'il peut lancer, explorer et planifier avant de modifier, garder des fichiers d'instructions courts et charger le détail à la demande, dire ce qu'il peut faire seul, gérer la fenêtre de contexte, recourir à un relecteur distinct et tenir pour non fiable le contenu du web et des outils [20] [30].

À la fin de cette section, vous saurez appliquer les pratiques que documentent les deux éditeurs, avec la source de chaque côté.

Chaque éditeur publie ses propres conseils. Anthropic tient une page de bonnes pratiques dans la documentation de Claude Code [20] ; OpenAI a publié le 2 octobre 2026 un guide des modèles de la famille GPT-6 [30] et tient une page consacrée aux prompts dans sa documentation de Codex [84]. Le tableau 12.1 les met en regard, une pratique par ligne, avec la source de chaque côté.

Sur la première ligne, les deux pages disent la même chose avec d'autres mots. Celle d'Anthropic décrit ce qu'un contrôle apporte à la boucle : « Claude fait le travail, lance le contrôle, lit le résultat et recommence jusqu'à ce que le contrôle passe » (notre traduction) [20]. Le guide d'OpenAI demande une définition de « terminé » qui inclut l'exécution du travail et l'inspection du résultat [30].

Comment une session dérape. Anthropic nomme aussi cinq motifs d'échec, chacun avec son remède (tableau 12.2) [20]. OpenAI en documente un dans ses propres termes, la surspécification [30] [92]. La réorientation de l'agent en cours d'exécution, qu'OpenAI documente comme une fonctionnalité [84], n'est pas le même conseil que le redémarrage qu'Anthropic préconise après deux corrections infructueuses [20].

Sources du §12 : [20] [30] [84] [17] [5] [47] [88] [32] [16] [91] [76] [77] [50] [86] [92] [53] [54], vérifiées le 4 octobre 2026. Retour au sommaire.

Claude Code et Codex : quelles différences ?

Claude Code (Anthropic) et Codex (OpenAI), agents de code, reposent sur une même idée : un harness lit votre dépôt, lance des commandes dans un bac à sable du système d'exploitation, modifie les fichiers et vérifie son travail, depuis un terminal, un éditeur, une application de bureau ou le cloud [5] [76]. Tous deux peuvent lire AGENTS.md et confier les approbations courantes à un relecteur IA [17] [54] [4] [7]. Noms et réglages par défaut diffèrent.

À la fin de cette section, vous saurez comparer Claude Code et Codex sur des faits documentés, et dire ce qui passe de l'un à l'autre.

Les deux éditeurs décrivent leur agent de code comme une couche autour d'un modèle. La documentation de Claude Code le présente comme « la couche autour du modèle qui fournit les outils et gère le contexte que voit le modèle » (notre traduction) [5]. Côté OpenAI, l'Agents API, en bêta publique depuis le 10 septembre 2026, expose le harness et l'infrastructure qui font tourner Codex [13].

Le tableau 13.1 les met côte à côte sur ce que documente chaque éditeur : Claude Code d'abord, par ordre alphabétique, les mêmes lignes pour les deux, et aucune ligne qui les classe. Les noms de produits et les réglages par défaut changent vite ; le cas 4 qui suit cette section rassemble les retraits que les deux éditeurs ont datés.

Ce qui les distingue tient surtout à la forme du contrôle. Les deux entourent les commandes d'un bac à sable et d'une couche d'approbation. Claude Code exprime la couche d'approbation par un seul mode de permission, avec des règles de refus qui valent dans tous les modes, et garde son bac à sable comme une couche distincte [19] [27] ; Codex associe une politique d'approbation, le moment où il faut demander, à un mode de bac à sable, ce que les commandes peuvent atteindre [76]. Les deux relecteurs IA ne lisent pas non plus les mêmes entrées, et chaque éditeur dit ce que son choix coûte. Anthropic retire les sorties des outils pour qu'un contenu injecté ne puisse pas atteindre son classifieur, et accepte que, lorsque l'utilisateur n'a jamais nommé un identifiant, le classifieur ne puisse pas savoir si l'agent l'a trouvé ou inventé [4]. Le relecteur de Codex voit « une transcription condensée, plus la demande d'approbation exacte » (notre traduction), qui contient en général les sorties des outils ; il peut, rarement, faire des vérifications en lecture seule pour réunir le contexte qui manque, et le raisonnement caché n'en fait pas partie [7].

Quelle différence entre Claude et Claude Code ?

Claude est le modèle ; Claude Code est le harness qui l'entoure, comme le dit en une ligne le glossaire de Claude Code : « Claude Code est le harness ; Claude est le modèle qu'il contient » (notre traduction) [19]. Le harness fournit « l'accès aux fichiers, l'exécution shell, le contrôle des permissions, le chargement de la mémoire et la boucle qui enchaîne les actions » (notre traduction) [19]. Le tableau 4.1 situe Claude Code parmi les autres façons dont chaque éditeur fait tourner un modèle en agent.

Peut-on utiliser les deux ?

Oui, et une bonne partie de la configuration passe de l'un à l'autre. Claude Code lit AGENTS.md quand un dépôt n'a pas de CLAUDE.md, depuis la v2.1.277 [17]. Depuis le 11 août 2026, l'application de bureau ChatGPT importe les instructions, les réglages, les skills, les plugins, les projets et le travail récent depuis Claude Code, Claude Cowork et Cursor, et la CLI de Codex importe la configuration et les conversations récentes depuis Claude Code et Cursor avec /import [10].

Les skills partagent un même format ouvert [56]. Les deux outils se connectent à des serveurs MCP : Claude Code par sa configuration MCP [5], Codex par des entrées mcp_servers.<id> dans son fichier de configuration [29].

Sources du §13 : [5] [76] [17] [54] [4] [7] [13] [38] [56] [10] [19] [47] [3] [27] [82] [81] [20] [29] [93] [94] [31] [18] [11] [36] [95] [96] [42] [86] [89] [1], vérifiées le 4 octobre 2026. Retour au sommaire.

Combien coûte un agent IA ?

Un agent IA coûte des jetons (tokens), et il en consomme beaucoup : chaque tour de boucle renvoie le contexte, les sorties des outils s'accumulent et les agents qui travaillent en parallèle multiplient la consommation. La mise en cache des prompts, le chargement des outils à la demande et le compactage font baisser la facture. L'unité utile est le coût d'une tâche réussie, pas celui d'un appel [98] [30].

À la fin de cette section, vous saurez raisonner sur le coût d'un agent sans liste de prix, en coût par tâche réussie.

Où partent les jetons. Anthropic indique que, dans ses données, les agents « utilisent en général environ 4 fois plus de jetons que les échanges de chat, et les systèmes multi-agents environ 15 fois plus que les chats »^† (notre traduction) [98]. Dans le même billet, à propos de son évaluation BrowseComp, Anthropic constate que « l'usage des jetons explique à lui seul 80 % de la variance » (notre traduction) des performances^† [98].

Le travail en parallèle multiplie la facture des deux côtés. La documentation de Claude Code prévient : « faire tourner plusieurs sessions ou sous-agents à la fois multiplie la consommation de jetons » (notre traduction) [57]. Celle de Codex indique que les workflows à sous-agents « consomment plus de jetons que des exécutions comparables à agent unique » (notre traduction) [47].

Ce qui fait baisser la facture. Trois mécanismes figurent dans la documentation des deux éditeurs. La mise en cache des prompts réutilise le début d'un prompt qui se répète : le cache d'Anthropic couvre le préfixe du prompt, dans l'ordre tools, system, puis messages [50], et le guide d'OpenAI recommande de « placer les instructions stables et les documents de référence avant les détails de la tâche qui changent » (notre traduction) [30]. Charger les outils à la demande tient leurs définitions hors du contexte : Anthropic indique qu'une configuration courante à plusieurs serveurs peut dépenser environ 55 000 jetons en définitions d'outils avant tout travail, et que la recherche d'outils réduit en général ce volume de plus de 85 %^† [44]. L'Agents API d'OpenAI propose elle aussi la recherche d'outils [13]. Le compactage remplace les tours les plus anciens par un résumé : en bêta sur l'API d'Anthropic [48], automatique dans l'Agents API d'OpenAI [13] [41].

Les deux éditeurs facturent l'entrée mise en cache à une fraction du prix normal de l'entrée, à des taux qui dépendent du modèle [51] [30]. Les prix changent, et cette page n'en imprime donc aucun : les taux figurent sur les pages citées, chacune listée dans les Références avec le jour où elle a été lue.

L'effort. L'effort arbitre entre profondeur et coût. Le glossaire de Claude Code le résume : « plus d'effort signifie plus de jetons de réflexion et un raisonnement plus approfondi ; moins d'effort est plus rapide et moins cher » (notre traduction) [19]. Le guide d'OpenAI conseille de commencer par l'effort par défaut, de n'essayer les niveaux les plus élevés que si le niveau élevé (high) ne suffit pas, et de ne les garder que si le gain justifie le temps et le coût [30].

L'unité. Le guide d'OpenAI demande de mesurer la réussite des tâches, la latence et le coût par tâche réussie avant de déployer un agent [30]. Écrit en toutes lettres, le coût par tâche réussie donne l'équation (3) :

Les tentatives échouées restent au numérateur : elles dépensent des jetons et ne terminent rien. Si toutes les tentatives coûtent autant et réussissent avec la même probabilité p, le coût attendu par tâche réussie est le coût d'une tentative divisé par p (calculé). Les jetons ne sont pas le seul coût : le cas 5 qui suit cette section y ajoute la disponibilité.

Sources du §14 : [98] [30] [57] [47] [50] [44] [13] [48] [41] [51] [19], vérifiées le 4 octobre 2026. Retour au sommaire.

Qui fixe les standards des agents IA ?

Plusieurs standards communs des agents IA relèvent désormais de l'Agentic AI Foundation, un fonds de la Linux Foundation créé le 9 décembre 2025 autour de MCP (Anthropic), de goose (Block) et d'AGENTS.md (OpenAI). A2A, qui porte les échanges entre agents, l'a rejointe le 17 août 2026. Agent Skills reste un format ouvert distinct, adopté par les outils des deux éditeurs [8] [100] [56].

À la fin de cette section, vous saurez situer AGENTS.md, Agent Skills, MCP et A2A dans une même pile, et dire qui a la charge de chacun.

Le 9 décembre 2025, la Linux Foundation a annoncé la création de l'Agentic AI Foundation (AAIF) avec trois projets fondateurs : le Model Context Protocol (MCP) d'Anthropic, goose de Block et AGENTS.md d'OpenAI [8]. L'annonce nomme huit membres Platinum : AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft et OpenAI [8].

Anthropic présente l'AAIF comme un fonds dédié (directed fund) de la Linux Foundation, et précise que la gouvernance de MCP reste entre les mains de ses mainteneurs [101]. OpenAI, qui annonçait sa participation le même jour, dit avoir publié AGENTS.md en août 2025 [102].

A2A, le protocole des échanges entre agents, a rejoint l'AAIF le 17 août 2026 ; le billet de la fondation qualifie la version 1.0 de « première spécification stable » (notre traduction), livrée en mars 2026 [100]. Le site de la spécification présente la version 1.0.0 comme sa « Latest Released Version », la dernière version publiée [67], tandis que la page GitHub des versions du projet indique la 1.0.0, sortie le 12 mars 2026, et la 1.0.1, publiée le 28 mai 2026 [103].

La page des projets de l'AAIF en compte six : MCP, goose, AGENTS.md, agentgateway, A2A et Agent Router [104]. Le tableau 15.1 empile les formats communs selon ce qu'ils transportent, des instructions qu'un dépôt donne à un agent jusqu'à la couche du trafic, et indique pour chacun qui en a la charge et quelle version ou quelle date donnent ses sources.

Agent Skills reste hors de la fondation. Son site présente le format comme « développé à l'origine par Anthropic, publié comme standard ouvert » (notre traduction) [56] ; la note d'Anthropic sur le standard ouvert est datée du 18 décembre 2025 [9], et la page des projets de l'AAIF ne le mentionne pas [104]. Le même site cite, parmi les outils qui l'ont adopté, Claude Code, ChatGPT et Codex, GitHub Copilot, Cursor et Gemini CLI [56].

Les pouvoirs publics avancent sur une voie à part : le 17 février 2026, l'institut américain des normes et de la technologie (NIST) a annoncé l'AI Agent Standards Initiative de son Center for AI Standards and Innovation (CAISI) [105].

Sources du §15 : [8] [100] [56] [101] [102] [67] [103] [104] [9] [15] [105] [59] [53], vérifiées le 4 octobre 2026. Retour au sommaire.

Que dit l'AI Act européen sur les agents ?

L'AI Act européen ne connaît pas la notion d'agent : il encadre les systèmes d'IA selon leur risque. Les obligations visant les modèles d'IA à usage général s'appliquent depuis le 2 août 2025, celles de transparence de l'article 50 depuis le 2 août 2026. Depuis le 27 juillet 2026, l'omnibus numérique reporte les obligations du haut risque au 2 décembre 2027 ou au 2 août 2028, selon les systèmes [34] [14].

À la fin de cette section, vous saurez quelles dates de l'AI Act s'appliquent après l'omnibus, et où en est le projet de loi luxembourgeois qui doit l'appliquer.

Tel qu'adopté. Le règlement (UE) 2024/1689, l'AI Act, est entré en vigueur le 1er août 2024 [34]. Ses interdictions et son obligation de maîtrise de l'IA s'appliquent depuis le 2 février 2025, et son chapitre V, consacré aux modèles d'IA à usage général, depuis le 2 août 2025 ; sa date d'application générale était fixée au 2 août 2026 [34].

Pas de catégorie « agent ». Le règlement ne réserve aucune catégorie aux agents, et sa définition d'un système d'IA vise déjà un système « conçu pour fonctionner à différents niveaux d'autonomie » (article 3, point 1) [34]. Un agent relève donc des mêmes règles fondées sur le risque que n'importe quel autre système d'IA [34].

L'article 50. Son paragraphe 1 impose d'informer les personnes qu'elles interagissent avec un système d'IA, sauf si cela ressort clairement des circonstances, ce qui concerne tout agent qui parle à des clients [34]. Son paragraphe 2 impose de marquer les contenus de synthèse dans un format lisible par machine [34].

L'omnibus numérique. Le règlement (UE) 2026/1744, l'omnibus numérique sur l'IA, a été adopté le 8 juillet 2026, publié au Journal officiel le 24 juillet 2026, et il est entré en vigueur le troisième jour suivant sa publication, soit le 27 juillet 2026 [14]. Dans l'acte tel qu'adopté, les obligations du haut risque devaient s'appliquer le 2 août 2026 pour les usages listés à l'annexe III et le 2 août 2027 pour les produits de l'annexe I [34] ; l'omnibus les reporte au 2 décembre 2027 pour les systèmes de l'annexe III et au 2 août 2028 pour ceux de l'annexe I [14]. Il change aussi quatre points qui comptent pour quiconque construit ou déploie des agents :

• Marquage. Les systèmes génératifs mis sur le marché avant le 2 août 2026 disposent d'une transition de quatre mois pour l'obligation de marquage de l'article 50, paragraphe 2, jusqu'au 2 décembre 2026 [14].
• Nouvelles interdictions. Le point b bis) de l'article 5, paragraphe 1, premier alinéa, interdit les systèmes d'IA qui génèrent ou manipulent des images, des vidéos ou des contenus audio intimes et réalistes d'une personne identifiable sans son consentement explicite ; le point b ter) vise les contenus d'abus sexuels sur enfants au sens de l'article 2, points c) et e), de la directive 2011/93/UE. Avec les nouveaux paragraphes 1 bis et 1 ter de l'article 5, ces interdictions s'appliquent à partir du 2 décembre 2026, selon le point a) modifié de l'article 113 [14].
• Maîtrise de l'IA. L'article 4 est réécrit : les fournisseurs et les déployeurs « prennent des mesures pour favoriser le développement de la maîtrise de l'IA par leur personnel » et par les autres personnes qui font fonctionner ou utilisent des systèmes d'IA pour leur compte [14].
• Contrôle. L'article 75, paragraphe 1, tel que remplacé, rend le Bureau de l'IA « seul compétent » pour les systèmes d'IA fondés sur un modèle d'IA à usage général quand le modèle et le système viennent du même fournisseur ou de la même entreprise, avec quatre exceptions listées (produits de l'annexe I ; annexe III, point 2 ; systèmes relevant de l'article 74, paragraphe 6 ; annexe III, point 8, pour l'administration de la justice), ainsi que pour les systèmes d'IA qui constituent une très grande plateforme en ligne ou un très grand moteur de recherche en ligne au sens du règlement (UE) 2022/2065, ou qui y sont intégrés [14]. Lu à la lettre, le premier cas couvre un produit agentique qu'un fournisseur de modèles bâtit sur son propre modèle, sauf exception [14].

Lignes directrices et codes. Selon les lignes directrices de la Commission, un acteur en aval qui modifie un modèle ne devient fournisseur d'un modèle d'IA à usage général que si la modification mobilise plus d'un tiers du calcul qui a servi à entraîner le modèle d'origine [106]. En pratique, construire un agent sur l'API d'un éditeur ne fait normalement pas de vous un tel fournisseur [106].

Le code de bonnes pratiques sur la transparence des contenus générés par l'IA (Code of Practice on Transparency of AI-generated Content), dans sa version finale depuis le 10 juin 2026, donne le 2 août 2026 comme date d'application des obligations de l'article 50 [107]. La Commission indiquait le 31 juillet 2026 qu'environ 190 organisations avaient signé à la fin du mois, dont Anthropic et OpenAI, tous deux inscrits à la section 1 [108]. Anthropic déclare marquer d'un filigrane les textes produits par ses modèles sortis après le 2 août 2026 [109].

La page de la Commission consacrée à l'AI Act, mise à jour le 3 août 2026, tient la chronologie consolidée [110]. La figure 16.1 place sur une même frise les dates de l'acte tel qu'adopté et tel que modifié, et le tableau 16.1 reprend les mêmes étapes.

Qui contrôlerait au Luxembourg ?

Projet de loi 8476, en commission. Tout ce qui suit sous ce titre décrit un projet de loi, pas une loi en vigueur. Le projet de loi 8476 a été déposé le 23 décembre 2024 par Elisabeth Margue ; la page de la Chambre des députés lui donne le statut « En commission », avec Félix Eischen pour rapporteur [111].

Le Conseil d'État a adopté son avis le 10 juillet 2026, avec des oppositions formelles, par exemple sur la compétence de la CSSF au titre de l'article 74, paragraphe 6, de l'AI Act et sur la sécurité juridique [112].

L'article 7 du projet ferait de la CNPD l'autorité de surveillance du marché par défaut, avec des exceptions au profit d'autres autorités ; l'article 13 en ferait le point de contact unique ; l'article 12 permettrait à toute autorité compétente de mettre en place un bac à sable réglementaire [113]. Le tableau 16.2 détaille qui ferait quoi.

Pour les lecteurs en France, la CNIL a publié avec le Conseil de l'IA et du Numérique (CIANum) une note exploratoire, « IA agentique et données personnelles », le 20 juillet 2026 [115]. Seule sa page d'actualité a été lue pour cette révision : la note elle-même n'est donc pas citée ici.

Sources du §16 : [34] [14] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115], vérifiées le 4 octobre 2026. Retour au sommaire.