La multiplication et la démocratisation des agents IA offre de nouvelles possibilités d'automatisation. Elle impose aussi un nouveau chantier au DSI : donner aux métiers les moyens d'innover dans un cadre cohérent, partagé, sécurisé et indépendant des fournisseurs de modèles.
Un commercial crée un agent pour préparer ses rendez-vous. Un controleur de gestion automatise l'analyse de documents. Le service client connecte un assistant à son CRM. Un chef de produit automatise l'enrichissement de ses données produits Chacun choisit ses outils, configure ses instructions, définit son contexte et construit ses propres connexions au système d'information.
Ces initiatives répondent à de vrais besoins. Mais leur accumulation peut faire émerger un système d'information parallèle avec de nouveaux risques pour l'entreprise : des agents dispersés, des accès difficiles à inventorier, des traitements peu documentés et une dépendance forte aux fournisseurs de modèle. Il suffit que l'entreprise change de LLM pour que tous les agents s'effondrent. Sans compter que le ROI est impossible à mesurer pour l'entreprise.
Avec des agents accessibles facilement à tous, le shadow IT prend une dimension supplémentaire. Un outil ne se contente plus de stocker ou de restituer de l'information : il peut décider d'appeler une application, transmettre des données, modifier un dossier ou déclencher une opération. Sans aucune garantie de traçabilité ni de contrôle.
Le DSI doit donc organiser une nouvelle capacité d'action dans le système d'information.
Donner de l'autonomie aux métiers dans un cadre maîtrisé
Sans architecture commune, plusieurs problèmes apparaissent.
Les connexions au SI se multiplient sans règles homogènes. Les agents reproduisent les mêmes fonctions sans pouvoir être réutilisés. Leurs échanges deviennent difficiles à maîtriser. Les processus se fragmentent entre plusieurs outils, sans responsable clairement identifié de leur exécution complète.
La sécurité dépend alors de choix locaux : quel compte utilise l'agent ? Quelles données transmet-il au modèle ? Que peut-il partager avec un autre agent ? Qui peut interrompre son travail ? Et comment comprendre, après un incident, ce qui s'est passé ?
La réponse du DSI consiste à proposer une plateforme sur laquelle les collaborateurs peuvent construire, partager et exploiter des agents, avec des exigences communes de sécurité, de traçabilité et de performance.
Cette ambition appelle une architecture de référence unique, qui peut s'appuyer sur plusieurs composants logiciels. Son unité tient aux règles appliquées, aux services partagés et à la gouvernance de l'ensemble.
Sept exigences pour structurer la plateforme agentique
1. Préserver les agents lorsque les modèles changent
L'entreprise doit pouvoir choisir ses LLM selon les usages, les coûts, les performances et les contraintes de confidentialité. Elle doit aussi pouvoir en changer sans reconstruire tout son patrimoine d'agents.
Cette indépendance suppose de séparer le modèle des instructions de l'agent, de ses outils, de sa mémoire, de son historique et de l'état des processus en cours. Ces éléments doivent rester maîtrisés par l'entreprise et être exportables.
Un catalogue proposant plusieurs modèles ne suffit donc pas. Il faut vérifier que le contexte utile peut être reconstitué avec un autre fournisseur et que les fonctions utilisées disposent d'alternatives.
Changer de modèle peut néanmoins modifier le comportement de l'agent. La portabilité doit être accompagnée de tests de qualité et de sécurité, même lorsque les données et les historiques sont conservés.
2. Unifier les accès au système d'information
Les agents doivent utiliser un catalogue de connexions et d'outils validés par la DSI : API, serveurs MCP, connecteurs applicatifs et services métiers.
L'objectif est de mutualiser les interfaces, de maîtriser les autorisations et d'éviter que chaque équipe reconstruise ses propres accès.
Un accès unifié ne signifie pas un compte technique partagé par tous. Chaque action doit être associée à une identité et à des droits adaptés à son contexte, avec des secrets protégés et des autorisations révocables.
Les MCP peuvent standardiser la manière d'exposer des outils aux agents. Leur adoption doit s'accompagner de contrôles d'accès, de validation des opérations et de journalisation.
3. Orchestrer des processus métiers complets
Une collection d'agents spécialisés ne constitue pas, à elle seule, un processus automatisé.
Prenons le traitement d'une demande client : qualifier la demande, consulter un contrat, vérifier une information dans l'ERP, préparer une réponse puis obtenir une validation. Chaque étape doit transmettre les informations nécessaires à la suivante, gérer les erreurs et respecter les responsabilités définies.
La plateforme doit coordonner les agents, les applications et les interventions humaines. Elle doit aussi permettre de reprendre un traitement interrompu et d'éviter qu'une relance exécute deux fois la même opération.
Les règles métier stables gagnent à rester explicites dans les workflows. Les agents interviennent là où l'interprétation, la recherche ou la synthèse apportent une valeur. Les agents peuvent aussi travailler sous la supervision d'un agent Manager, celui-ci ayant en charge de piloter une équipe d'agent pour éviter les dérives.
4. Construire un patrimoine partagé d'agents
La plateforme doit proposer une bibliothèque d'agents, d'outils et de modèles de processus réutilisables.
Chaque agent publié doit avoir un propriétaire, une finalité, une version, un périmètre de données autorisé et des conditions d'utilisation. Les équipes peuvent ainsi réutiliser des composants éprouvés et identifier ceux qui doivent être maintenus ou retirés.
Les outils de création doivent s'adapter aux utilisateurs : interfaces visuelles pour les métiers, environnements de développement pour les équipes techniques. Leur mise en production doit suivre des contrôles proportionnés aux risques. Enfin, les agents doivent être développés en prenant en compte les bonnes pratiques de l'entreprise et de la création d'agents : les tools à utiliser pour chaque action, des prompts clairement découpés et précis, un contexte clair, des compétences partagées...
5. Observer et piloter le travail réalisé
Le DSI doit pouvoir relier une demande à ses différentes étapes : agents sollicités, modèles utilisés, outils appelés, validations obtenues et résultats produits.
Cette traçabilité doit couvrir le processus de bout en bout. Elle doit permettre de diagnostiquer les incidents, d'attribuer les coûts et d'évaluer la qualité du service.
Les indicateurs utiles associent performance technique et résultat métier : délai de traitement, taux de réussite, coût par dossier, fréquence des reprises humaines ou taux d'erreur.
Les traces doivent elles-mêmes être protégées, filtrées et conservées selon des règles définies, car elles peuvent contenir des informations sensibles. Il est important également de prendre en compte que la responsabilité juridique d'un agent n'est pas bien claire, il est assimilé à du logiciel. Il est donc primordial de définir ce que l'Entreprise autorise ou pas, par exemple quand un agent est chargé d'interagir avec un client ou des collaborateurs.
6. Appliquer la sécurité à chaque action
La politique de sécurité doit s'appliquer aux données consultées, aux informations transmises aux modèles, aux échanges entre agents et aux opérations exécutées.
Cela implique notamment le moindre privilège, le cloisonnement des environnements, la maîtrise des destinations de données, la protection des secrets et la possibilité de suspendre un agent ou de révoquer ses accès.
Les actions sensibles doivent être soumises à des validations adaptées. Les contenus consultés doivent être traités comme potentiellement non fiables : un document ou un message ne doit pas pouvoir modifier les autorisations de l'agent.
Une consigne donnée au modèle ne remplace jamais un contrôle d'autorisation appliqué par le système.
7. Pilotage et maitrise des coûts
L'aspect économique est également important, sa centralisation est indispensable pour permettre à l'Entreprise de les maîtriser et de les baisser par leur mutualisation. Il est évident que un abonnement par collaborateur coute plus cher qu'un abonnement négocié d'entreprise. La plate-forme agentique doit donc permettre, non seulement, de suivre les coûts de consommation de tokens, mais aussi de pouvoir les rationaliser. La construction des agents doit se faire avec connaissance de l'impact de consommation. Par exemple, en allouant les budgets par département ou par collaborateurs, voire par agent.
Un autre point souvent mis de côté concerne la consommation des MCPs qui assurent l'interface entre les agents et les logiciels d'entreprise. Les MCPs peuvent vite devenir très gourmands en tokens si ils n'identifient pas correctement le "tool" à utiliser pour répondre à une instruction. Certaines plates-formes permettent de préciser à un agent quel tool il doit utiliser pour ses actions, contribuant ainsi à maîtriser la dérive des budgets.
En tout état de cause, la plate-forme agentique d'entreprise doit permettre de piloter, comprendre et plafonner les consommations.
Un rapide tour d'horizon du marché
Les offres couvrent des périmètres différents : création d'agents par les métiers, infrastructure d'exécution, orchestration, intégration applicative ou gouvernance. Ce panorama constitue un point de départ pour une sélection, avec des capacités à vérifier selon les éditions, les régions et les modes de déploiement.
- Microsoft Copilot Studio et Microsoft Foundry — création visuelle d'agents avec Copilot Studio, développement et exploitation avec Foundry. À examiner : l'articulation entre les deux offres, la gouvernance des connecteurs et la portabilité au-delà de l'écosystème Microsoft.
- Google Gemini Enterprise et Agent Platform — outils de création et de déploiement d'agents (Agent Studio, ADK) et intégration d'agents externes. À examiner : la compatibilité des agents existants, la gestion du contexte et les conditions d'interopérabilité.
- Amazon Bedrock AgentCore — services d'exécution, de mémoire, d'identité, d'accès aux outils et d'observabilité, compatibles avec plusieurs modèles et frameworks. À examiner : l'assemblage des services et outils complémentaires nécessaires aux utilisateurs métiers.
- IBM watsonx Orchestrate — construction et orchestration d'agents, catalogue partagé et routage entre plusieurs modèles. À examiner : l'adéquation des mécanismes d'orchestration et des intégrations aux processus réels de l'entreprise.
- Salesforce Agentforce — agents étroitement intégrés aux données, aux actions et aux processus Salesforce. À examiner : la couverture des processus transverses qui dépassent le périmètre Salesforce.
- ServiceNow AI Agent Orchestrator et AI Control Tower — orchestration associée aux workflows et supervision de l'écosystème IA. À examiner : l'étendue effective des contrôles sur les agents hébergés dans des plateformes tierces.
- LangGraph et LangSmith — construction de workflows agentiques avec LangGraph, traçabilité, évaluation et déploiement avec LangSmith. À examiner : les compétences techniques et les composants à prévoir pour proposer une plateforme complète aux métiers.
Le choix doit porter sur la capacité à satisfaire l'architecture cible. Une offre adaptée à la création d'assistants individuels ne couvre pas nécessairement les besoins d'un processus critique traversant plusieurs applications.
Cinq étapes pour choisir et intégrer la bonne plateforme
1. Cartographier les usages et sélectionner quelques processus représentatifs. Recenser les agents existants, leurs utilisateurs, leurs connexions et les données manipulées. Retenir deux ou trois cas pilotes avec un responsable métier, un bénéfice mesurable et des risques identifiés.
2. Définir les exigences avant de comparer les produits. Formaliser les critères non négociables : identité, confidentialité, hébergement, export des historiques, changement de modèle, validation humaine, audit et intégration au SI. Distinguer les critères éliminatoires des préférences.
3. Tester les plateformes sur les mêmes scénarios. Comparer la qualité, les délais et le coût par traitement réussi. Tester aussi un changement de LLM, un accès interdit, une panne d'outil, une reprise après interruption et une tentative de détournement des instructions. Exiger des preuves sur la réversibilité.
4. Intégrer le socle commun avant de généraliser. Raccorder la plateforme à l'annuaire, aux mécanismes d'habilitation, à la gestion des secrets et à la supervision. Publier les premiers outils validés et organiser le passage du prototype à la production.
5. Installer une gouvernance durable et élargir progressivement. Définir qui construit, valide, exploite et retire les agents. Former les collaborateurs, suivre les résultats et enrichir la bibliothèque partagée à partir des usages qui ont démontré leur valeur.
Le succès se mesure à la capacité de l'entreprise à faire évoluer ses agents, à les faire coopérer et à maîtriser leurs actions dans la durée. Et enfin, s'attaquer au sujet dès maintenant alors que s'amorcent les premiers besoins en agents, c'est la certitude de la simplicité. Le faire demain quand des centaines d'agents travailleront déjà pour l'Entreprise est un risque de complexité important. Attendre, c'est laisser la dette technique s'accumuler.
Avec l'architecture Armonies de Zento, nous accompagnons les DSI dans cette démarche, du cadrage des usages et du choix de la plateforme à son intégration au SI et à la mise en œuvre d'une gouvernance commune.
