Doit-on inventer un nouvel OS pour les agents IA ?

Les agents IA ont besoin d'un nouvel "OS" : une couche d'orchestration, sécurité, mémoire, identité et gouvernance pour passer du prototype à une exploitation fiable en entreprise.

Pendant des décennies, l’informatique d’entreprise a été structurée autour d’un principe simple : les applications exécutent des fonctions, les utilisateurs déclenchent des actions, les systèmes d’exploitation gèrent les ressources.

Mais l’arrivée des agents IA bouscule cette logique.

Un agent ne se contente pas de répondre à une question. Il peut interpréter une intention, planifier plusieurs étapes, appeler des outils, interroger des données, produire un livrable, solliciter un humain, corriger sa trajectoire et parfois agir directement dans le système d’information.

Autrement dit, l’agent IA n’est plus seulement une interface conversationnelle.

Il devient une forme d’acteur logiciel.

Et dès lors, une question devient centrale :

Avons-nous besoin d’un nouvel OS pour les agents IA ?

La réponse courte serait : oui, mais pas au sens classique du terme.

Nous n’avons probablement pas besoin d’un nouveau Windows, Linux ou macOS pour agents.

Nous avons besoin d’une nouvelle couche d’exécution, de gouvernance et d’orchestration capable de rendre les agents fiables, observables, sécurisés et industrialisables.

Un Agent OS, en somme.

Pas un système d’exploitation de machines.

Un système d’exploitation de l’intention, du contexte, des actions et de la confiance.

Le problème : les agents ne se comportent pas comme les logiciels classiques

Un logiciel traditionnel est relativement prévisible.

Il reçoit une entrée, exécute une logique déterministe, produit une sortie. Même lorsqu’il est complexe, son comportement repose sur du code écrit, testé, versionné, audité.

Un agent IA fonctionne différemment.

Il combine du raisonnement probabiliste, du contexte dynamique, des appels à des outils, de la mémoire, des permissions, des objectifs, des contraintes et parfois une forme d’autonomie opérationnelle.

Cela change tout.

Dans un système classique, on supervise des applications.

Dans un système agentique, il faut superviser des décisions.

Dans un système classique, on donne des droits à des utilisateurs ou à des services.

Dans un système agentique, il faut donner des droits à des entités capables d’interpréter une intention et d’agir sur plusieurs systèmes.

Dans un système classique, on trace des appels API.

Dans un système agentique, il faut tracer des chaînes de raisonnement, des sources utilisées, des outils appelés, des validations humaines, des erreurs de contexte et des décisions intermédiaires.

C’est précisément pour cela que les agents IA ne peuvent pas être traités comme de simples scripts améliorés.

Ils nécessitent une nouvelle couche d’exploitation.

Pourquoi l’idée d’un “Agent OS” devient crédible

Le marché commence déjà à converger vers cette idée, même si les acteurs n’utilisent pas toujours le terme “OS”.

Microsoft positionne par exemple Azure AI Foundry et son Agent Service comme une plateforme permettant de concevoir, déployer, orchestrer et superviser des agents IA en entreprise, avec des connexions à des sources comme SharePoint, Microsoft Fabric, Azure AI Search et des connecteurs d’action via Azure Logic Apps. (Microsoft Learn)

OpenAI pousse aussi cette logique avec son Agents SDK, qui couvre l’orchestration, les outils, les validations, l’état et les handoffs entre agents. Sa documentation distingue notamment les approches où le LLM décide dynamiquement du flux et celles où l’orchestration reste contrôlée par le code. (OpenAI Développeurs)

Anthropic, de son côté, a popularisé le Model Context Protocol, un standard ouvert permettant de connecter des agents à des outils et des sources de données externes. MCP vise à réduire la fragmentation des intégrations, en évitant de devoir créer un connecteur spécifique pour chaque combinaison modèle-outil-donnée. (Anthropic)

Enfin, le protocole A2A, initialement développé par Google puis donné à la Linux Foundation selon sa documentation officielle, vise à permettre à des agents issus de frameworks différents de communiquer, échanger des informations et collaborer de manière sécurisée. (a2a-protocol.org)

Ces initiatives racontent toutes la même histoire :

les agents ont besoin d’un environnement d’exécution commun.

Pas seulement d’un modèle.

Pas seulement d’un prompt.

Pas seulement d’un framework.

Ils ont besoin d’un socle.

Ce qu’un Agent OS devrait réellement faire

Un Agent OS ne serait pas un produit unique. Ce serait plutôt une architecture de contrôle.

Il devrait répondre à une question fondamentale :

Comment permettre à des agents IA d’agir dans l’entreprise sans perdre le contrôle ?

Pour cela, il devrait couvrir plusieurs fonctions essentielles.

1. Gérer l’identité des agents

Dans le monde actuel, l’identité est principalement pensée pour les humains, les applications et les services.

Mais demain, une entreprise pourra avoir des dizaines, centaines ou milliers d’agents spécialisés : agent juridique, agent support, agent DevOps, agent RH, agent commercial, agent FinOps, agent sécurité, agent achat, agent conformité.

Chacun devra avoir une identité propre.

Qui est cet agent ?

Qui l’a créé ?

Quel est son propriétaire métier ?

Quels systèmes peut-il consulter ?

Quelles actions peut-il exécuter ?

Au nom de qui agit-il ?

Peut-il envoyer un email ? Modifier un ticket ? Créer une commande ? Déployer une infrastructure ? Accéder à des données sensibles ?

Sans identité agentique claire, l’entreprise créera un angle mort majeur.

Un agent ne doit jamais être un simple “super utilisateur IA”.

Il doit être une entité gouvernée, limitée, traçable et révocable.

2. Gérer les permissions et les politiques d’action

La vraie difficulté des agents n’est pas qu’ils parlent.

C’est qu’ils agissent.

Un chatbot peut se tromper dans une réponse.

Un agent connecté à des outils peut se tromper dans une action.

La différence est considérable.

Un Agent OS devrait donc intégrer une couche de policy engine : une capacité à définir ce qu’un agent peut faire, dans quelles conditions, avec quel niveau de validation, sur quels systèmes et avec quelles limites.

Par exemple :

Un agent peut lire une base documentaire, mais pas modifier les documents.

Un agent peut proposer une réponse client, mais pas l’envoyer sans validation humaine.

Un agent peut analyser un incident de production, mais pas redémarrer un service critique sans approbation.

Un agent peut générer du code, mais pas merger directement en production.

Un agent peut recommander une optimisation FinOps, mais pas supprimer une ressource sans contrôle.

Ce point est fondamental :

l’autonomie ne doit jamais être binaire.

Entre “l’agent ne fait rien” et “l’agent fait tout”, il existe une infinité de niveaux de délégation.

L’Agent OS devra gérer ces niveaux.

3. Orchestrer plusieurs agents

Un agent unique peut être utile.

Mais la vraie rupture viendra probablement des systèmes multi-agents.

Un agent comprend l’intention.

Un autre recherche l’information.

Un autre vérifie la conformité.

Un autre prépare une action.

Un autre valide la cohérence.

Un autre produit le livrable final.

Cette logique crée une nouvelle forme de chaîne de valeur logicielle.

Mais elle pose aussi de nouvelles questions :

Qui pilote le workflow ?

Comment éviter les boucles infinies ?

Comment arbitrer entre agents en désaccord ?

Comment transmettre le contexte sans exposer trop de données ?

Comment éviter qu’un agent faible contamine le raisonnement d’un agent critique ?

Comment documenter les décisions prises par une chaîne d’agents ?

C’est là que l’idée d’OS devient pertinente.

Un OS classique orchestre des processus.

Un Agent OS orchestrera des intentions, des tâches, des outils, des validations et des responsabilités.

4. Gérer la mémoire et le contexte

Un agent sans mémoire est limité.

Un agent avec trop de mémoire devient dangereux.

La mémoire agentique est l’un des sujets les plus sensibles.

Il faut distinguer plusieurs formes de mémoire :

La mémoire de session : ce qui se passe dans l’interaction en cours.

La mémoire utilisateur : préférences, habitudes, contexte personnel ou professionnel.

La mémoire métier : règles, procédures, référentiels, connaissances internes.

La mémoire opérationnelle : incidents passés, tickets, décisions, historiques.

La mémoire organisationnelle : ce que l’entreprise accepte de capitaliser dans le temps.

Un Agent OS devrait permettre de gouverner cette mémoire.

Que peut-on retenir ?

Combien de temps ?

Pour quel usage ?

Avec quel consentement ?

Avec quel chiffrement ?

Avec quelle capacité d’effacement ?

Avec quelle séparation entre utilisateurs, métiers et environnements ?

Sans gouvernance de la mémoire, les agents risquent de devenir des réservoirs opaques de contexte sensible.

Et dans une entreprise, l’opacité est rarement compatible avec la confiance.

5. Superviser le raisonnement et les actions

On ne peut pas industrialiser les agents sans observabilité.

Mais l’observabilité agentique ne se limite pas aux métriques classiques.

Bien sûr, il faut mesurer la latence, le coût, le taux d’erreur, la disponibilité, le nombre d’appels aux modèles et aux outils.

Mais il faut aussi observer autre chose :

Quels documents ont été utilisés ?

Quel outil a été appelé ?

Quelle décision intermédiaire a été prise ?

Quelle validation humaine a été demandée ?

Quelle action a été refusée par une politique ?

Quel niveau de confiance a été estimé ?

Quelle hallucination a été détectée ?

Quelle dérive comportementale apparaît dans le temps ?

Microsoft Foundry met d’ailleurs en avant des capacités liées à l’évaluation des workflows agentiques, au monitoring, au tracing et à la confiance dans son control plane. (Microsoft Learn)

Ce point deviendra critique.

Car dans les systèmes agentiques, le problème ne sera pas seulement de savoir si le système fonctionne.

Il faudra comprendre pourquoi il a agi.

6. Sécuriser l’exécution des outils

La sécurité est probablement le cœur du sujet.

Un agent connecté à des outils devient une surface d’attaque.

Prompt injection, tool poisoning, fuite de données, escalade de privilèges, appels non autorisés, manipulation de contexte, compromission de connecteurs, actions indirectes : les risques sont nombreux.

Les débats récents autour de vulnérabilités et de risques liés à MCP montrent que les protocoles d’intégration agentique ne sont pas de simples sujets de productivité. Ils deviennent des sujets de sécurité d’architecture. Des articles récents ont rapporté des failles et controverses autour d’implémentations MCP, notamment sur les risques d’exécution de code à distance et d’exposition de serveurs. (Tom's Hardware)

Même si ces informations doivent être analysées avec prudence, elles rappellent une évidence :

connecter un agent à un outil, c’est lui ouvrir une porte dans le SI.

Un Agent OS devra donc intégrer nativement :

la sandbox d’exécution,

la validation des outils,

la signature des connecteurs,

la limitation des permissions,

l’audit des appels,

la séparation des environnements,

la protection contre l’injection de prompt,

la validation humaine pour les actions sensibles.

Sans cette couche, les agents deviendront des accélérateurs de risque.

7. Gérer le cycle de vie des agents

Une entreprise ne peut pas laisser ses agents proliférer sans gouvernance.

Qui crée les agents ?

Qui les valide ?

Qui les publie ?

Qui les met à jour ?

Qui les désactive ?

Qui vérifie leurs performances ?

Qui répond en cas d’erreur ?

Qui est responsable si un agent prend une mauvaise décision ?

Un Agent OS devrait intégrer un cycle de vie complet :

conception,

évaluation,

publication,

supervision,

amélioration,

retrait.

C’est exactement le passage du prototype au produit.

Beaucoup d’organisations savent créer des démonstrateurs IA.

Peu savent gérer un portefeuille d’agents en production.

La différence entre les deux sera un marqueur de maturité majeur.

L’Agent OS n’est pas un framework

Il faut éviter une confusion.

LangChain, Semantic Kernel, AutoGen, CrewAI, OpenAI Agents SDK ou d’autres frameworks permettent de construire des agents ou des workflows agentiques.

Mais un Agent OS est autre chose.

Un framework aide à développer.

Un OS aide à exploiter.

Un framework répond à la question :

comment construire un agent ?

Un Agent OS répond à la question :

comment faire vivre des agents dans une organisation réelle, avec des droits, des règles, des données, des risques, des coûts et des responsabilités ?

C’est une différence fondamentale.

Les entreprises ne manqueront pas de frameworks.

Elles manqueront de contrôle planes.

Pourquoi le terme “OS” est utile, mais aussi dangereux

Le mot “OS” est séduisant parce qu’il donne une image simple : une couche commune qui abstrait la complexité.

Mais il peut aussi induire en erreur.

Un OS classique contrôle le matériel, les processus, la mémoire, les fichiers, le réseau et les périphériques.

Un Agent OS, lui, contrôlerait des choses beaucoup moins déterministes :

des intentions,

du langage naturel,

du contexte,

des probabilités,

des décisions,

des délégations,

des interactions humaines,

des actions métier.

Il ne s’agit donc pas d’un OS au sens technique strict.

Il s’agit plutôt d’un runtime de confiance pour agents IA.

Le bon terme pourrait être :

Agent OS,

Agent Runtime,

Agent Control Plane,

Agentic Platform,

Enterprise Agent Fabric,

AI Operations Layer.

Mais peu importe le nom.

Le besoin est réel.

Le parallèle avec Kubernetes

Il existe un parallèle intéressant avec Kubernetes.

Avant Kubernetes, les conteneurs existaient déjà.

Mais leur exploitation à grande échelle posait des problèmes : scheduling, réseau, stockage, supervision, résilience, déploiement, scaling, configuration, sécurité.

Kubernetes n’a pas inventé les conteneurs.

Il a rendu leur exploitation industrielle possible.

Nous sommes peut-être dans une situation comparable avec les agents IA.

Les agents existent.

Les frameworks existent.

Les modèles existent.

Les connecteurs existent.

Mais il manque encore une couche standardisée pour les opérer à grande échelle.

L’Agent OS pourrait jouer pour les agents le rôle que Kubernetes a joué pour les conteneurs :

passer de l’expérimentation à l’industrialisation.

Avec une différence majeure : Kubernetes orchestre des workloads déterministes.

Un Agent OS devra orchestrer des comportements probabilistes.

Et cette différence change tout.

Le vrai enjeu : la confiance opérationnelle

Le sujet n’est pas uniquement technique.

Il est organisationnel.

Une entreprise n’adoptera massivement les agents IA que si elle peut répondre à quelques questions simples :

Puis-je savoir ce que fait un agent ?

Puis-je limiter ce qu’il peut faire ?

Puis-je expliquer pourquoi il l’a fait ?

Puis-je empêcher une action risquée ?

Puis-je auditer son comportement ?

Puis-je mesurer sa valeur ?

Puis-je le désactiver immédiatement ?

Puis-je prouver sa conformité ?

Le NIST AI Risk Management Framework met déjà l’accent sur la gouvernance, la mesure, la gestion et la cartographie des risques liés à l’IA. Son profil dédié à l’IA générative vise notamment à aider les organisations à intégrer la confiance dans la conception et l’exploitation des systèmes IA. (NIST)

En Europe, l’AI Act impose aussi une logique de transparence, de gestion des risques et d’identification des contenus générés par IA, avec des règles progressives selon les niveaux de risque. La Commission européenne indique notamment que les règles de transparence doivent entrer en application en août 2026. (Stratégie numérique européenne)

Cela signifie que l’Agent OS ne sera pas seulement une couche d’efficacité.

Ce sera aussi une couche de conformité.

À quoi pourrait ressembler une architecture d’Agent OS ?

On peut imaginer une architecture en plusieurs couches.

1. Couche d’identité

Elle définit les agents, leurs propriétaires, leurs rôles, leurs périmètres, leurs credentials et leurs droits.

2. Couche de contexte

Elle connecte les agents aux données internes, aux documents, aux bases, aux APIs, aux historiques et aux connaissances métier.

3. Couche mémoire

Elle gère ce qui peut être retenu, oublié, partagé, isolé ou historisé.

4. Couche outils

Elle expose les actions possibles : lire, écrire, créer, modifier, déclencher, exécuter, notifier, déployer.

5. Couche politique

Elle applique les règles : autorisations, interdictions, seuils de validation, séparation des tâches, conformité.

6. Couche orchestration

Elle coordonne les agents, les workflows, les handoffs, les validations humaines et les plans d’action.

7. Couche observabilité

Elle trace les décisions, les prompts, les sources, les outils, les coûts, les erreurs, les performances et les incidents.

8. Couche sécurité

Elle protège contre les attaques, les fuites, les injections, les actions non autorisées et les dérives.

9. Couche expérience utilisateur

Elle expose les agents dans les environnements de travail : Teams, Slack, Outlook, navigateur, IDE, portail métier, application interne.

10. Couche gouvernance

Elle pilote le portefeuille d’agents, les responsabilités, les évaluations, les versions, les risques et la valeur produite.

Ce n’est pas un simple produit.

C’est une nouvelle discipline d’architecture.

Microsoft, OpenAI, Anthropic, Google : vers une bataille du control plane

Ce qui se dessine aujourd’hui, c’est une bataille autour du control plane agentique.

Microsoft voudra naturellement intégrer les agents dans son écosystème : Microsoft 365, Copilot, Azure AI Foundry, Fabric, Entra, Defender, Purview, Power Platform, GitHub.

OpenAI pousse une approche développeur et plateforme, avec SDK, orchestration, outils et environnements d’exécution.

Anthropic pousse MCP comme standard d’intégration entre agents, outils et données.

Google pousse A2A pour l’interopérabilité entre agents et écosystèmes.

Les grands éditeurs métier comme SAP, Salesforce, ServiceNow, Workday ou Atlassian intégreront aussi leurs propres agents dans leurs processus.

La question pour les entreprises sera donc stratégique :

veut-on subir la fragmentation des agents ou construire une couche d’orchestration maîtrisée ?

C’est ici que le concept d’Agent OS prend toute sa valeur.

Faut-il vraiment l’inventer ?

Oui et non.

Non, si l’on imagine un grand OS universel, unique, centralisé, qui contrôlerait tous les agents de toutes les entreprises.

Ce scénario est peu probable.

Les environnements seront hybrides, multi-cloud, multi-modèles, multi-outils, multi-éditeurs. Les agents seront intégrés dans des SaaS, des plateformes cloud, des outils collaboratifs, des IDE, des applications métier et des portails internes.

Mais oui, il faut inventer une nouvelle couche d’exploitation agentique.

Elle ne sera peut-être pas unique.

Elle ne sera peut-être pas appelée OS.

Elle sera probablement composée de standards, de plateformes, de protocoles, de runtimes, de politiques et de services d’observabilité.

Mais sa fonction sera bien celle d’un OS :

rendre exploitable une nouvelle génération d’unités de travail logiciel.

Hier, l’unité de travail était le programme.

Puis le service.

Puis le conteneur.

Puis la fonction serverless.

Demain, ce sera peut-être l’agent.

Et chaque fois que l’unité de travail change, l’infrastructure d’exploitation doit changer avec elle.

Le risque : créer des agents sans système d’exploitation

Le pire scénario serait de multiplier les agents sans architecture commune.

Un agent dans le CRM.

Un agent dans l’ERP.

Un agent dans Teams.

Un agent dans l’IDE.

Un agent dans le support.

Un agent dans les RH.

Un agent dans la finance.

Un agent dans la sécurité.

Un agent dans les opérations IT.

Chacun avec sa mémoire.

Ses permissions.

Ses logs.

Ses connecteurs.

Ses règles.

Ses risques.

Ses coûts.

Ses comportements.

Ce serait une nouvelle forme de shadow IT.

Mais amplifiée par l’autonomie.

Le shadow IT classique créait des applications non gouvernées.

Le shadow AI créera des acteurs logiciels non gouvernés.