Agents IA locaux vs services agentiques cloud : pourquoi la divergence architecturale est importante

Les agents IA ne sont pas une seule et même chose. Ils se scindent en deux modèles architecturaux fondamentalement différents, et la plupart des développeurs n’en perçoivent qu’une moitié.

Le premier modèle est l’agent de codage local. Claude Code, Cursor, Windsurf, GitHub Copilot CLI — ce sont des agents IA qui s’exécutent sur la machine du développeur, accèdent au système de fichiers local et augmentent le flux de travail d’un seul utilisateur. Ils sont interactifs, basés sur des sessions et profondément personnels. Le développeur saisit une requête, l’agent travaille, le développeur examine et itère.

Le second modèle est le service agentique cloud. Codex d’OpenAI lance des bacs à sable isolés pour chaque tâche. Les Cloud Agents de Cursor, lancés en février 2026, fonctionnent sur des machines virtuelles dédiées qui construisent du logiciel, le testent et livrent des pull requests prêtes à être fusionnées avec des démonstrations vidéo. L’agent de codage de GitHub Copilot, disponible de manière générale depuis septembre 2025, opère de façon asynchrone dans des environnements cloud propulsés par GitHub Actions. Ce sont des services alimentés par l’IA, déployés dans le cloud, qui traitent des requêtes de manière programmatique — gérant des tâches de développement, analysant des documents, orchestrant des workflows. Ils sont autonomes, pilotés par API et multi-locataires.

Ces deux modèles partagent la même technologie sous-jacente — de grands modèles de langage effectuant des appels d’outils — mais presque tout le reste diffère. Les outils qu’ils utilisent, l’authentification dont ils ont besoin, l’infrastructure sur laquelle ils fonctionnent et les mécanismes d’extensibilité pertinents pour chacun sont fondamentalement différents. Comprendre cette divergence est essentiel pour quiconque construit des systèmes d’agents, car des modèles qui fonctionnent brillamment dans un contexte échouent totalement dans l’autre.

Le modèle de l’agent local

Un agent de codage local s’exécute sur la machine d’un développeur. Il a un accès direct au système de fichiers — code, documents, fichiers de configuration, scripts. Il fonctionne dans le contexte de la session d’un seul utilisateur, avec ses identifiants, permissions et son environnement.

Comment les agents locaux étendent leurs capacités

Les agents locaux s’appuient sur trois mécanismes d’extension :

Les skills (fichiers d’instructions en markdown) — Des fichiers texte locaux qui encodent des procédures, des connaissances métier et des instructions spécialisées. L’agent les lit depuis le disque et intègre leur contenu dans sa fenêtre de contexte. Une architecture à deux couches émerge dans les systèmes d’IA en production : les skills gèrent les connaissances et les directives comportementales, tandis que les protocoles d’outils gèrent l’exécution. Selon une analyse de The New Stack, cette séparation peut réduire considérablement les coûts en tokens par rapport à l’encodage de toutes les instructions sous forme de définitions d’outils. Microsoft a publié un dépôt open source de skills sur GitHub, et des registres communautaires indexent désormais des milliers de fichiers de skills réutilisables.

Les outils CLI et scripts — L’agent peut exécuter des outils en ligne de commande que le développeur a installés et authentifiés. Git, les CLI des fournisseurs cloud, les gestionnaires de paquets, les outils de build, les linters — l’ensemble de la boîte à outils de développement locale est disponible. Ces outils utilisent les identifiants existants du développeur, donc aucune authentification supplémentaire n’est à configurer. GitHub Copilot CLI, devenu disponible de manière générale en février 2026, illustre ce modèle — un agent natif du terminal qui planifie, construit, examine et mémorise d’une session à l’autre sans quitter la ligne de commande.

Les serveurs MCP (optionnel) — Les agents locaux peuvent se connecter à des serveurs Model Context Protocol pour accéder à des services distants, mais en pratique, de nombreux cas d’usage locaux sont pleinement couverts par les skills et les outils CLI. MCP devient pertinent lorsque l’agent a besoin d’un accès structuré à des sources de données distantes ou des API sans équivalent CLI.

Pourquoi ce modèle domine les flux de travail des développeurs

Le modèle local est simple et puissant parce qu’il s’appuie sur l’infrastructure existante. La machine du développeur dispose déjà d’identifiants configurés, d’outils installés et de fichiers organisés. L’agent a juste besoin de lire des fichiers et d’exécuter des commandes — des capacités que les systèmes d’exploitation supportent depuis des décennies.

Cette simplicité explique l’adoption rapide des agents de codage locaux. Le moteur Cascade de Windsurf indexe l’ensemble du code source local et maintient une mémoire persistante de l’architecture du projet et des conventions de codage. Claude Code lit les fichiers du projet et exécute les commandes directement. Il n’y a pas d’étape de déploiement, pas d’infrastructure à provisionner, pas d’authentification à configurer au-delà de ce que le développeur possède déjà.

La sécurité favorise également la préférence pour le local. Confier un code professionnel à un service cloud tiers est un risque stratégique que de nombreuses organisations ne sont pas prêtes à accepter. L’exécution locale garde le code sur la machine du développeur, seuls les appels API vers le fournisseur de LLM franchissant la frontière du réseau.

Le modèle de l’agent cloud

Un service agentique cloud est un animal entièrement différent. Il fonctionne sur un serveur — un conteneur, une fonction serverless, une VM dans le cloud. Il n’a pas de système de fichiers local au sens propre. Il traite des requêtes provenant de nombreux utilisateurs, chacun avec ses propres permissions et données. Il fonctionne de manière autonome, sans qu’un humain guide chaque étape.

Le modèle cloud mûrit rapidement. Les Cloud Agents de Cursor fonctionnent sur des machines virtuelles isolées et, selon l’entreprise, 30 % des pull requests fusionnées de Cursor sont désormais créées par ces agents. Codex d’OpenAI opère dans des conteneurs sécurisés et isolés avec l’accès à Internet désactivé pendant l’exécution, limitant l’interaction au seul code fourni via les dépôts. L’agent de codage de GitHub Copilot gère des tâches de complexité faible à moyenne de manière asynchrone dans des environnements de développement cloud.

Comment les agents cloud étendent leurs capacités

Les agents cloud nécessitent des mécanismes d’extension fondamentalement différents :

Les serveurs MCP — Le principal moyen pour les agents cloud d’accéder à des outils et données externes. Le Model Context Protocol fournit une découverte et une invocation standardisées de services externes sur le réseau. Contrairement aux agents locaux, les agents cloud ne peuvent pas exécuter de commandes shell — ils ont besoin de services accessibles par le réseau avec une authentification appropriée et des interfaces structurées.

L’authentification OAuth 2.1 — Les agents cloud servent plusieurs utilisateurs, chacun avec ses propres comptes et permissions. La spécification MCP, mise à jour dans sa version stable du 25 novembre 2025, classe les serveurs MCP comme des serveurs de ressources OAuth 2.1. Cela impose une authentification par utilisateur avec PKCE pour tous les clients, de sorte que les requêtes de chaque utilisateur soient traitées avec ses propres identifiants. Les clients doivent implémenter les Resource Indicators (RFC 8707) pour prévenir le vol de tokens par des serveurs malveillants.

La gestion d’état avec session — Les agents cloud doivent souvent maintenir un état à travers plusieurs interactions. Un agent de support client a besoin du contexte de conversation. Un agent d’analyse de documents doit suivre l’état du traitement. Cela nécessite une infrastructure d’état explicite — bases de données, caches, workflows en file d’attente — que les agents locaux gèrent implicitement via leurs sessions terminales interactives.

Pourquoi le modèle local échoue ici

Considérez ce qui se passe lorsque vous essayez d’appliquer les modèles d’agents locaux à un service cloud :

Des skills en fichiers locaux ? Il n’y a pas de système de fichiers local persistant. L’agent cloud fonctionne dans un conteneur qui peut être détruit et recréé à tout moment. Les skills doivent être intégrés au déploiement ou chargés depuis un registre — pas lus depuis le disque d’un développeur.

Des outils CLI avec des identifiants ambiants ? Il n’y a pas d’identifiants ambiants. L’agent cloud sert de nombreux utilisateurs, chacun nécessitant sa propre authentification. Un compte de service partagé avec des permissions étendues est un risque de sécurité. L’OAuth par utilisateur est la seule approche responsable.

Des sessions terminales interactives ? Il n’y a pas de terminal. L’agent cloud reçoit des requêtes API et retourne des réponses API. Il n’y a pas d’humain dans la boucle pour chaque décision. L’agent doit être suffisamment autonome pour traiter les requêtes sans aide, avec des tentatives automatiques, des solutions de repli et une gestion des erreurs.

Cinq dimensions de divergence

1. Authentification

Local : Les identifiants existants du développeur — clés SSH, cookies de navigateur, tokens CLI, variables d’environnement — tous configurés une fois et utilisés par tout ce qui tourne sur la machine, y compris l’agent.

Cloud : OAuth 2.1 par utilisateur. Chaque requête doit être authentifiée selon les permissions spécifiques de l’utilisateur. Le support OAuth 2.1 intégré à la spécification MCP, avec PKCE obligatoire et Resource Indicators, a été conçu spécifiquement pour ce modèle multi-locataire.

2. Accès aux données

Local : Accès direct au système de fichiers. L’agent lit le code, les documents et la configuration directement depuis le disque. Zéro latence réseau. Windsurf indexe l’ensemble du projet en utilisant le RAG sur les fichiers locaux, construisant une compréhension persistante du code source.

Cloud : Accès médié par le réseau. Tout — bases de données, magasins de documents, API, stockage de fichiers — est accessible via le réseau par des appels de service authentifiés. Chaque accès aux données a de la latence, peut échouer et doit gérer les tentatives de manière élégante.

3. Gestion d’état

Local : Implicite. La session terminale maintient l’état. Le développeur voit l’historique de conversation. Les fichiers sur le disque persistent entre les sessions. Le système de mémoire de Windsurf apprend même les conventions du projet de manière autonome au fil du temps.

Cloud : Explicite. L’état doit être stocké dans des bases de données ou des caches. Les sessions doivent être suivies. L’historique de conversation doit être persisté. Rien de tout cela ne se fait automatiquement. Comme le souligne la documentation technique de Red Hat sur l’IA agentique, concevoir pour un fonctionnement sans état avec des magasins d’état externes est essentiel pour des workflows d’agents cloud fiables.

4. Extensibilité

Local : Skills (fichiers) + outils CLI (exécutables) + MCP optionnel. Le modèle d’extension est natif du système de fichiers. Un développeur peut écrire un fichier markdown avec des instructions de déploiement et l’agent les suit immédiatement.

Cloud : MCP (protocole réseau) + intégrations API personnalisées. Le modèle d’extension est natif du réseau. Le transport Streamable HTTP, introduit début 2025, permet de déployer les serveurs MCP comme des fonctions serverless, réduisant l’infrastructure à un seul endpoint HTTP.

5. Gestion des erreurs

Local : Le développeur est dans la boucle. Quand quelque chose ne va pas, l’agent peut demander de l’aide et le développeur peut intervenir immédiatement. Cela rend les agents locaux tolérants aux instructions imprécises.

Cloud : L’agent est seul. La gestion des erreurs doit être automatisée — tentatives, solutions de repli, disjoncteurs, files d’attente de messages morts. Comme le note la recherche 2026 de Deloitte sur l’IA agentique, seules 11 % des organisations utilisent activement l’IA agentique en production, en partie parce que construire une gestion d’erreurs autonome robuste reste difficile. Il n’y a pas d’humain à interroger pour une clarification quand une requête échoue à 3 heures du matin.

La zone de chevauchement : quand les skills rencontrent MCP

Il y a un domaine où les skills et MCP se chevauchent véritablement : les outils CLI locaux. Un développeur qui a besoin que son agent de codage déploie chez un fournisseur cloud peut soit écrire un skill avec un script bash qui appelle le CLI du fournisseur, soit se connecter à un serveur MCP qui encapsule l’API du fournisseur.

Pour un développeur seul sur une machine locale, les deux produisent le même résultat. L’approche par skill est plus simple — pas de serveur à exécuter, pas de surcharge protocolaire. Cette substituabilité explique pourquoi certains développeurs voient les skills comme un remplacement de MCP.

Mais étendez le scénario à une équipe de dix développeurs, chacun utilisant son propre agent, tous devant déployer avec des contrôles d’accès appropriés — et l’approche MCP devient clairement supérieure. Un serveur MCP centralisé peut appliquer des permissions, auditer les actions et gérer les identifiants en un seul endroit. L’approche script-dans-un-skill donne à chaque développeur un accès complet non délimité via ses identifiants personnels, sans gouvernance centralisée.

Le chevauchement n’existe que dans le cas local mono-agent. Dès que vous avez besoin de coordination multi-agents, d’authentification multi-utilisateurs ou de gouvernance centralisée, MCP est la seule voie viable. Les huit modèles de conception multi-agents de Google, publiés début 2026, supposent tous des interfaces d’outils accessibles par le réseau — pas des instructions basées sur des fichiers locaux.

La convergence à venir

Malgré ces différences, les deux modèles se rapprochent l’un de l’autre :

Les agents en arrière-plan brouillent la frontière. Le mode headless de Claude Code fonctionne localement mais opère de manière autonome — pas d’humain dans la boucle à chaque étape. Les Cloud Agents de Cursor et l’agent de codage de GitHub Copilot fonctionnent dans le cloud mais sont déclenchés par des développeurs individuels. La frontière entre local et cloud devient moins une question de lieu d’exécution de l’agent et plus une question de qui il sert.

Les skills deviennent distribuables. Le concept d’instructions structurées plus des fichiers de référence n’est pas intrinsèquement local. Le dépôt open source de skills de Microsoft et les registres communautaires rendent les skills partageables entre équipes et agents. Anthropic a publié un SDK Python pour consommer des skills de manière programmatique, permettant aux agents cloud de bénéficier des connaissances basées sur les skills sans accès au système de fichiers.

MCP devient plus léger. Le transport Streamable HTTP permet de déployer les serveurs MCP comme des fonctions serverless, réduisant l’infrastructure à un seul endpoint HTTP. Cela rend MCP viable même pour des intégrations légères où l’exécution d’un serveur persistant était auparavant impraticable.

L’orchestration multi-agents émerge. Gartner a rapporté une hausse de 1 445 % des requêtes sur les systèmes multi-agents entre le T1 2024 et le T2 2025. Le modèle plan-and-execute — où un modèle performant crée une stratégie et des modèles moins coûteux exécutent les étapes individuelles — est adopté en production, certaines équipes signalant des réductions de coûts significatives. Les agents locaux comme cloud participent à ces workflows orchestrés.

Guide pratique

Construisez un agent local quand :

• Vous augmentez le flux de travail d’un seul développeur
• L’agent a besoin d’un accès direct au système de fichiers pour le code et la configuration
• Un fonctionnement interactif avec humain dans la boucle est acceptable ou souhaité
• Les outils CLI et identifiants existants peuvent être exploités
• La sécurité du code exige de garder les sources sur la machine du développeur

Construisez un agent cloud quand :

• L’agent sert plusieurs utilisateurs simultanément
• Un fonctionnement autonome, piloté par API, est requis en permanence
• L’authentification et l’autorisation par utilisateur sont nécessaires
• L’agent doit fonctionner 24h/24 et 7j/7 sans supervision humaine
• Une mise à l’échelle horizontale sur de nombreuses tâches parallèles est nécessaire

Construisez les deux quand :

• Les développeurs ont besoin d’agents de codage (local) et le produit a besoin d’agents de service autonomes (cloud)
• Les connaissances métier encodées dans les skills peuvent informer les deux modèles
• Les serveurs MCP peuvent servir à la fois les agents locaux et cloud via le même protocole
• L’organisation veut des agents locaux pour la vélocité de développement et des agents cloud pour la fiabilité en production

Conclusion

La scission entre agents IA locaux et cloud n’est pas une phase temporaire — c’est une divergence architecturale permanente, portée par des exigences fondamentalement différentes. Les agents locaux optimisent l’expérience développeur, en exploitant l’environnement riche de fichiers, d’outils et d’identifiants d’une seule machine. Les agents cloud optimisent les opérations en production, nécessitant des protocoles réseau, une authentification par utilisateur et une prise de décision autonome.

Les organisations les plus efficaces construiront les deux — des agents locaux pour la productivité des développeurs, des agents cloud pour l’automatisation en production — partageant connaissances et capacités entre eux grâce à des skills bien conçus et des serveurs MCP. Les gagnants seront ceux qui comprendront quel modèle appliquer où, plutôt que de forcer une seule architecture à répondre aux deux besoins.

Sources et lectures complémentaires

• Model Context Protocol OAuth 2.1 Authorization Specification — Anthropic
• Claude Code Skills Documentation — Anthropic
• How MCP Uses Streamable HTTP for Real-Time AI Tool Interaction — The New Stack
• Skills vs MCP: Agent Architecture — The New Stack
• Cursor Cloud Agents: Autonomous Coding on Virtual Machines — TechCrunch
• GitHub Copilot: Meet the New Coding Agent — GitHub Blog
• Introducing Codex — OpenAI
• Agentic AI: Design Reliable Workflows Across the Hybrid Cloud — Red Hat
• Google’s Eight Essential Multi-Agent Design Patterns — InfoQ
• Agentic AI Strategy — Deloitte Tech Trends 2026