IA agentique en entreprise : la plateforme

TL;DR

L’IA agentique est un modèle qui appelle des outils de façon autonome sur plusieurs étapes, au lieu d’écrire une réponse. En entreprise, cela exige quatre briques : un harnais pour la boucle d’agent, une passerelle pour l’identité et la résidence, une couche d’outils sur vos systèmes et de l’observabilité. Anthropic livre désormais les deux premières.

Qu’est-ce qui distingue l’IA agentique d’un chatbot ?

L’IA agentique diffère sur trois points : le modèle décide lui-même des étapes suivantes, il appelle des outils et lit leurs résultats, et il tourne sur des minutes ou des heures au lieu d’une réponse. Un chatbot reçoit un prompt et rend du texte. Un agent reçoit un objectif et y travaille jusqu’à l’atteindre ou abandonner.

Ces trois différences créent les exigences d’exploitation. Une boucle qui appelle des outils a besoin d’un endroit où tourner. Des outils qui touchent vos systèmes ont besoin d’une autorisation. Des exécutions longues ont besoin d’état, d’interruptibilité et de maîtrise des coûts. Aucun prompt ne résout cela.

Caractéristique	Chatbot	Agent
Pilotage	L’utilisateur dicte chaque étape	Le modèle décide des étapes
Outils	Aucun ou un appel de recherche	Système de fichiers, shell, API, serveurs MCP
Durée	Secondes	Minutes à heures
État	Historique de conversation	Historique, système de fichiers, résultats intermédiaires
Comportement de coût	Prévisible par message	Croît avec les étapes et le parallélisme
Risque	Mauvaise réponse	Mauvaise réponse et mauvaise action

La dernière ligne explique pourquoi les agents exigent une plateforme et non un projet. Une phrase fausse est gênante. Une écriture erronée dans un système de référence est un incident.

Que doit fournir une plateforme pour l’IA agentique ?

Une plateforme fournit quatre choses qu’une équipe applicative ne peut pas reconstruire à chaque fois : un endroit pour les boucles d’agent longues, une couche d’identité et de routage qui impose qui peut appeler quel modèle et où, une couche d’outils et de connecteurs gouvernée, et de l’observabilité par utilisateur. Le reste est du code applicatif.

La raison de centraliser n’est pas l’élégance. Chacune des quatre briques a une conséquence de conformité, et laisser dix équipes les résoudre séparément produit dix réponses à la question de savoir où les prompts sont traités. Centralisez la surface de conformité et laissez les équipes posséder leurs agents.

Brique	Ce qu’elle possède	Construire, acheter ou configurer
Harnais	Boucle d’agent, exécution d’outils, bacs à sable, état de session	Acheter ou configurer, Anthropic en livre un
Passerelle	Identité, accès modèle par groupe, routage, résidence	Configurer, un composant pris en charge existe
Couche d’outils	Accès à vos systèmes via MCP et API	Construire, personne d’autre ne peut
Observabilité	Tokens, coûts, traces, évaluation par utilisateur	Configurer, utiliser votre stack existant

Harnais : construire la boucle ou utiliser Claude Managed Agents ?

Utilisez le harnais managé sauf si vous devez contrôler la boucle elle-même ou tenir une posture de protection des données qu’il ne satisfait pas. Claude Managed Agents fournit le harnais et le runtime, donc la question n’est plus « construire une boucle ou utiliser l’API Messages directement ».

Le harnais managé repose sur quatre notions : un agent (modèle, prompt système, outils, serveurs MCP, skills), un environnement (où les sessions tournent), une session (une instance en cours sur une tâche) et des événements (messages entre votre application et l’agent). Les sessions sont conçues avec état, reprennent après une pause et conservent historique de conversation et état du bac à sable côté serveur. Les outils intégrés couvrent Bash, les opérations de fichiers, la recherche et la récupération web avec liste d’autorisation ou de blocage de domaines, et les serveurs MCP. Les déploiements planifiés exécutent les agents selon un calendrier cron.

Deux faits décident si cela convient à un déploiement européen. D’abord, l’environnement peut être un bac à sable auto-hébergé sur une infrastructure que vous contrôlez, et c’est l’option qu’Anthropic nomme pour les exigences de conformité et de résidence : l’exécution des outils et le système de fichiers du bac à sable restent chez vous, tandis que les magasins de mémoire attachés restent stockés par Anthropic et sont copiés dans votre bac à sable pour la session. Ensuite, du fait de cet état persistant, Managed Agents n’est actuellement éligible ni au Zero Data Retention ni à un accord HIPAA. Vous pouvez supprimer sessions et fichiers via l’API, mais l’écart d’éligibilité est structurel et non un réglage.

Notre recommandation :

Votre contrainte	Choix de harnais
Tâches longues, pas d’exigence ZDR	Claude Managed Agents avec bac à sable cloud
L’exécution des outils doit rester sur votre infrastructure	Claude Managed Agents avec bac à sable auto-hébergé
Le Zero Data Retention est contractuellement requis	Construire sur l’API Messages, garder l’état chez vous
Vous devez contrôler la boucle, les reprises et la distribution d’outils	API Messages ou Agent SDK
Les agents servent les développeurs, dans l’IDE et le CLI	Claude Code avec sous-agents, pas un harnais séparé

La bêta passe par l’en-tête managed-agents-2026-04-01, est active par défaut pour les comptes API, et les tunnels MCP ainsi que le dreaming restent dans un aperçu de recherche plus restreint. Prévoyez que l’interface bouge. Notre guide du Claude Agent SDK en Europe traite la voie de la construction maison sur Bedrock et Google Cloud.

Passerelle : qu’exige la couche d’identité et de résidence ?

C’est à la passerelle que résidence et identité cessent d’être une politique pour devenir une configuration. Pour les organisations qui doivent faire passer l’inférence par leur propre fournisseur cloud, le Claude apps gateway est le motif pris en charge, et ses prérequis sont assez précis pour appartenir à la conception avant tout le reste.

Ce que c’est : un binaire Linux unique auto-hébergé placé devant Amazon Bedrock, Claude Platform on AWS, Google Cloud ou Microsoft Foundry, qui authentifie les développeurs contre votre fournisseur d’identité, impose l’accès aux modèles par groupe et émet des métriques OpenTelemetry portant comptes de tokens, modèle, identité de l’utilisateur et latence, avec logs et traces en option par destination.

Ce qu’il exige, et chaque ligne a déjà bloqué un déploiement quelque part :

1. Claude Code v2.1.195 ou plus récent sur le serveur et sur chaque poste de développeur. L’upstream Claude Platform on AWS exige v2.1.198 ou plus récent sur le serveur, et la connexion Claude Desktop v2.1.203 ou plus récent.
2. Un fournisseur d’identité OIDC. Okta, Microsoft Entra ID, Google Workspace, Keycloak, Dex ou tout autre fournisseur conforme OIDC. SAML et LDAP ne sont pas pris en charge, ce qui écarte un nombre surprenant de parcs d’identité historiques sans passerelle intermédiaire.
3. PostgreSQL 11 ou plus récent, qui porte le flux d’authentification device et les compteurs de limites de débit, et contient les tables durables de dépense, d’audit et d’identité dès que les plafonds de dépense sont actifs. Sauvegardez la base.
4. Une adresse de réseau privé. À l’authentification, Claude Code exige que le nom d’hôte de la passerelle ne résolve que vers des adresses privées : RFC 1918, link-local, CGNAT 100.64.0.0/10, ULA IPv6 fc00::/7 ou loopback. Les organisations qui numérotent leur réseau interne depuis un bloc public qu’elles possèdent doivent déclarer ces blocs explicitement.

Deux conséquences de conception suivent immédiatement. Le démarrage est fail-closed pour la configuration, la connexion Postgres, la découverte OIDC et la construction des clients upstream, donc la passerelle s’arrête plutôt que de servir en mode dégradé. C’est le bon comportement, et cela fait de la passerelle une dépendance de production avec les exigences de disponibilité correspondantes. Et il n’existe aucun flux de jeton de service pour les pipelines non supervisés : l’authentification passe toujours par le flux device du navigateur, donc les jobs de CI s’authentifient directement auprès du fournisseur cloud et les réglages de la passerelle restent hors des runners.

La propriété de la couche de données à montrer au CSE et au DPO : la passerelle n’envoie rien depuis sa propre couche de données à l’infrastructure Anthropic tant que l’API Anthropic n’est pas configurée en upstream. Télémétrie, journaux d’audit, réglages managés et identité des développeurs restent où vous les placez.

Un compromis se décide consciemment : les sessions passerelle ne récupèrent pas les réglages managés côté serveur configurés dans la console d’administration claude.ai, donc la politique provient du bloc managé de la passerelle. Vous gagnez le contrôle de la résidence et du fournisseur, et vous cédez une partie des fonctions Enterprise. Notre guide de la passerelle LiteLLM pour l’UE traite l’alternative multi-éditeurs.

Où la résidence se décide-t-elle réellement ?

La résidence se décide par la route, non par un réglage de la plateforme. Sur l’API de première partie, inference_geo n’accepte que "global" et "us", et le workspace geo n’offre que "us" et ne change plus après la création. Sur Amazon Bedrock et les modèles Claude gérés par Google, inference_geo ne s’applique pas du tout : c’est l’URL du point de terminaison ou le profil d’inférence qui détermine la région.

Cette asymétrie gouverne la plupart des architectures européennes. Si l’exigence est un traitement en région européenne, la plateforme passe par un point de terminaison régional sur une plateforme partenaire, et la passerelle ou l’application le sélectionne. La page data residency donne le reste : l’inférence limitée aux États-Unis coûte 1,1 fois le tarif standard sur Claude 4.6 et les modèles suivants, allowed_inference_geos et default_inference_geo imposent une politique sur toutes les clés d’un workspace, et les limites de débit sont partagées entre les geos.

Quatre vérifications appartiennent au runbook de la plateforme, non à un document :

1. Vérifier le geo configuré par workspace après chaque changement, car un nouveau workspace n’en hérite pas.
2. Vérifier le point de terminaison ou le profil d’inférence par région sur les routes cloud, car c’est cela qui décide où l’inférence tourne.
3. Consigner le champ de réponse usage.inference_geo dans votre télémétrie, pour pouvoir prouver après coup où une requête a tourné.
4. Revérifier après chaque changement de génération, puisque inference_geo n’est pris en charge qu’à partir de Claude 4.6 et que les modèles antérieurs répondent 400.

Notre guide de la résidence des données Claude détaille les réglages par route.

Combien coûte l’exploitation ?

Trois lignes de coût : les tokens, le multiplicateur de parallélisme et l’infrastructure de la plateforme elle-même. Les tokens suivent des tarifs publiés. Le parallélisme est la ligne qui surprend. L’infrastructure est petite en comparaison, et souvent la seule qui figure au plan.

Tarifs de tokens depuis la page des prix : Sonnet 5.5 à 2 USD en entrée et 10 USD en sortie par million avec lectures de cache à 0,10 USD, Opus 5.5 à 4 USD et 20 USD avec lectures de cache à 0,20 USD, et 10 pour cent de surcoût pour les points régionaux ou multirégionaux. Les charges agentiques sont par nature gourmandes en cache, car le prompt système, les définitions d’outils et le contenu des skills se répètent, donc le tarif de cache compte ici plus que dans une charge de chat.

Le parallélisme distingue les plateformes agentiques de tout le reste. Les équipes d’agents dans Claude Code consomment environ 7 fois plus de tokens qu’une session standard en mode plan, car chaque coéquipier porte sa propre fenêtre de contexte. La même arithmétique vaut pour tout motif de fan-out que vous construisez : la simultanéité multiplie le contexte, et le contexte est le coût. Concevez le fan-out avec un budget au lieu de le découvrir.

Ligne de coût	Moteur	Levier
Tokens en régime normal	Taille de contexte par étape, nombre d’étapes	Cache de prompts, modèles plus petits pour les sous-étapes
Tokens en fan-out	Nombre d’agents parallèles	Plafonner la simultanéité, Haiku ou Sonnet pour les workers
Surcoût de résidence	Points de terminaison régionaux	N’y router que les charges qui l’exigent
Infrastructure de la passerelle	Un hôte Linux et un PostgreSQL managé	La plus petite offre de base suffit
Observabilité	Volume OTLP	Échantillonner les traces, garder les métriques complètes

Notre guide des prix de l’API Claude en Europe porte les grilles par route, et notre guide de Langfuse auto-hébergé traite la couche d’observabilité dans l’UE.

Construire en interne ou externaliser ?

Construisez la couche d’outils vous-même et configurez le reste. Le harnais et la passerelle sont désormais des produits avec des prérequis documentés, donc la valeur d’ingénierie se trouve dans les serveurs MCP et les API qui exposent vos propres systèmes de façon sûre. C’est aussi ce qu’une partie externe fait mal, car cela dépend de savoir quels champs de vos systèmes sont dangereux.

Chantier	Effort	Construire ou acheter
Choix du harnais et premier agent	10 à 15 jours	Configurer
Mise en production de la passerelle avec le fournisseur d’identité	10 à 20 jours	Bon candidat à l’externalisation
Serveurs MCP sur les systèmes internes	15 à 30 jours par système	Construire en interne
Chaîne d’observabilité et cadre d’évaluation	15 à 25 jours	Mixte
Runbook de vérification de résidence	5 jours	Construire en interne
Changement de modèle et tests de régression	5 jours par génération	En interne, régulièrement

Notre avis : la passerelle est le meilleur candidat à l’externalisation de cette liste, car ses prérequis sont précis, ses modes d’échec fail-closed, et la configuration du fournisseur d’identité coûte deux semaines à une équipe qui la fait pour la première fois. La couche d’outils MCP est le pire, car une partie externe exposera l’API facile à appeler plutôt que celle qu’il est sûr d’appeler. Notre guide de Claude MCP en entreprise traite le modèle d’autorisation et de sécurité de cette couche.

Ce qu’il faut exiger de quiconque construit une plateforme agentique pour vous :

1. Une décision de harnais avec sa conséquence Zero Data Retention énoncée, non reportée.
2. La route de résidence nommée, avec la vérification automatisée plutôt que documentée.
3. Un budget de simultanéité pour chaque motif de fan-out, avec le multiplicateur montré.
4. L’attribution par utilisateur en place, y compris sur les routes cloud où les tableaux de bord Anthropic ne voient rien.
5. La couche d’outils livrée en tant que code dans votre dépôt, avec les opérations dangereuses explicitement hors périmètre.

Une plateforme de chat pour les salariés est un autre chantier : notre guide de la plateforme IA interne traite LibreChat et Open WebUI sur Bedrock, et notre guide LLMOps le modèle d’exploitation autour des deux.

Un agent qui atteint des clients sous votre marque pose une question qu’une plateforme interne ne pose pas : êtes-vous devenu le fournisseur de ce système au sens du règlement sur l’IA ? Notre guide du marquage des contenus IA traite les trois déclencheurs et la divulgation dès la première interaction.

FAQ

Qu’est-ce que l’IA agentique ?

L’IA agentique est un modèle qui reçoit un objectif, décide lui-même des étapes suivantes, appelle des outils et lit leurs résultats, et y travaille sur des minutes ou des heures. Un chatbot, lui, reçoit un prompt et rend une réponse. La différence crée les exigences de runtime, d’autorisation et de maîtrise des coûts.

Qu’est-ce qu’une plateforme pour l’IA agentique ?

La couche partagée qui permet à plusieurs équipes d’exploiter des agents Claude sans résoudre les mêmes problèmes chacune : un harnais pour les boucles longues, une passerelle pour l’identité et le routage des modèles, une couche d’outils gouvernée sur les systèmes internes, et de l’observabilité par utilisateur. Les équipes possèdent leurs agents, la plateforme la surface de conformité.

Claude Managed Agents ou boucle maison ?

Claude Managed Agents pour les charges longues et asynchrones, sauf si vous exigez le Zero Data Retention ou le contrôle de la boucle. Il fournit harnais, bacs à sable, état de session et déploiements planifiés, et prend en charge les bacs à sable auto-hébergés quand l’exécution des outils doit rester chez vous. Il est en bêta et n’est éligible ni au ZDR ni à HIPAA.

Qu’exige le Claude apps gateway ?

Claude Code v2.1.195 ou plus récent sur le serveur et tous les clients, un fournisseur d’identité OIDC (SAML et LDAP ne sont pas pris en charge), PostgreSQL 11 ou plus récent et un nom d’hôte résolvant uniquement vers des adresses privées. Le démarrage est fail-closed et il n’existe aucun flux de jeton de service, donc la CI s’authentifie directement auprès du fournisseur cloud.

Une plateforme agentique peut-elle garder l’inférence dans l’UE ?

Oui, via des points de terminaison régionaux sur Amazon Bedrock, Google Cloud ou Microsoft Foundry, où le point de terminaison ou le profil d’inférence détermine la région. L’API de première partie n’offre que "global" et "us" pour l’inférence et "us" pour le workspace geo, donc le traitement européen vient des plateformes partenaires.

Combien coûte l’exploitation d’une plateforme agentique ?

Les tokens dominent : Sonnet 5.5 à 2 USD en entrée et 10 USD en sortie par million, Opus 5.5 à 4 USD et 20 USD, plus 10 pour cent pour les points régionaux. La ligne à prévoir est le multiplicateur de parallélisme, car le fan-out multiplie le contexte, et les équipes d’agents dans Claude Code consomment environ 7 fois plus de tokens qu’une session standard en mode plan.

Sources

1. Anthropic : Claude Managed Agents (28 octobre 2026)
2. Claude Code : Claude apps gateway (28 octobre 2026)
3. Anthropic : data residency (28 octobre 2026)
4. Anthropic : tarifs des modèles (28 octobre 2026)
5. Claude Code : maîtriser les coûts (28 octobre 2026)
6. Support Anthropic : la formule Enterprise (28 octobre 2026)