ChatGPT ici, Claude là, un bot support ailleurs : les agents IA prolifèrent sans architecture. Pourquoi c'est un risque, et comment une plateforme d'orchestration peut en faire un actif stratégique.
Depuis l'irruption des agents IA dans le paysage professionnel, une même scène se répète dans la plupart des grandes entreprises : un service marketing qui bricole un agent sur ChatGPT, une équipe support qui déploie son propre bot sur Claude, une DSI qui découvre après coup qu'un agent RH interroge une base de données sensible sans qu'aucune revue de sécurité n'ait été menée. Chacun avance de son côté, avec son LLM préféré, ses propres intégrations, ses propres règles — ou plutôt, l'absence de règles.
Cette prolifération anarchique n'est pas un simple désordre esthétique. Elle constitue un risque stratégique, financier et sécuritaire dont les DSI commencent à s'emparer.
Le symptôme : une multiplication sans architecture
Les agents se multiplient plus vite que les processus qui devraient les encadrer. Concrètement, cela se traduit par plusieurs soucis récurrents :
- Dépendance forte à un LLM ou une plateforme. Chaque agent est conçu, souvent dans l'urgence, sur l'outil fourni par un fournisseur unique — OpenAI, Anthropic, Google… Si ces acteurs changent leur tarif ou leur architecture, l'agent sera perdu avec la fin de l'abonnement.
- Absence de support commun. Pas de socle technique partagé, pas de bibliothèque d'outils réutilisables : chaque équipe repart de zéro, multipliant les coûts de développement et de maintenance.
- Peu de partage entre collaborateurs. Les agents vivent en silos. Un agent développé par les ventes ne profite pas aux équipes support, alors même que la logique métier sous-jacente pourrait être largement mutualisée, voire constituer le chaînon d'un process transverse.
- Intégration sauvage au système d'information. Connexions directes aux bases de données, appels API non validés, contournement des habilitations existantes : les agents s'intègrent parfois avec une méthode qu'on n'accepterait jamais pour une application classique.
- Incapacité à évaluer le ROI. Sans instrumentation ni reporting centralisé, impossible de savoir combien coûte réellement un agent, ce qu'il rapporte, ni s'il est encore utilisé six mois après son lancement.
- Failles de sécurité. Un agent qui accède à des données sensibles sans traçabilité, sans limitation de ses droits, est une porte ouverte — parfois littéralement, quand il dispose de capacités d'action sur des systèmes tiers.
Pris isolément, chacun de ces agents peut sembler anodin, voire utile à court terme. Mis bout à bout, ils dessinent un système d'information parallèle, non gouverné, que la DSI ne maîtrise plus.
Les questions à se poser avant de lancer un agent
Avant de valider un projet d'agent, cinq questions devraient être systématiquement posées :
Cet agent fonctionnera-t-il encore dans un an ? Si l'entreprise change de fournisseur de LLM — et elle le fera, tant ce marché évolue vite — l'agent doit pouvoir migrer sans réécriture complète. Un agent construit en dur sur les spécificités d'un modèle est un agent jetable.
Cet agent respecte-t-il le périmètre de droits qui lui est assigné ? Un agent capable d'agir sur le système d'information doit être soumis aux mêmes principes de moindre privilège qu'un utilisateur humain — ni plus, ni moins. Sans cadre, rien ne garantit qu'il ne dépassera pas son mandat, par erreur de conception ou par dérive du modèle sous-jacent.
Peut-on mesurer son ROI ? Sans instrumentation dès la conception, impossible de répondre à cette question a posteriori. Le reporting ne s'ajoute pas après coup : il se prévoit en amont.
Peut-on tracer ce qu'il fait ? Chaque décision, chaque appel d'outil, chaque accès à une donnée doit pouvoir être audité. C'est une condition de conformité autant qu'une condition de confiance.
Valide-t-on la connexion d'un agent avec une application ? En particulier pour les applications SaaS qui font payer l'utilisation de leurs APIs, il est indispensable de maîtriser l'accès des agents aux applications. Si on met à disposition des agents un MCP, qui va l'utiliser ? Pour faire quoi ?
Ces cinq questions ont un point commun : des agents autonomes ne peuvent pas y satisfaire. Elles appellent une réponse architecturale, transverse, portée par la DSI et plus largement par l'entreprise. Jusqu'à maintenant, le DSI était le garant du fonctionnement des applications entre elles ; maintenant, il doit également prendre en charge le travail des agents.
La réponse : une plateforme d'orchestration agentique d'entreprise
Avant de multiplier les agents, il faut donc se poser la question de la plateforme qui les portera. Une plateforme agentique d'entreprise digne de ce nom doit répondre à un cahier des charges précis :
- Être indépendante des LLMs. L'orchestration, la logique métier et les intégrations doivent être découplées du modèle sous-jacent, pour permettre de changer de LLM — ou d'en combiner plusieurs — sans tout reconstruire.
- Mutualiser les agents à l'échelle de l'entreprise. Un agent développé pour un métier doit pouvoir être réutilisé, adapté ou combiné par un autre, plutôt que d'être redéveloppé en silo.
- Proposer des mécanismes de construction d'agents. Un socle commun, des briques réutilisables, des standards de conception qui évitent à chaque équipe de réinventer sa propre façon de faire.
- Disposer d'un orchestrateur. Les cas d'usage les plus intéressants naissent souvent de la coopération entre plusieurs agents spécialisés, voire le contrôle d'agents superviseurs. Cette coopération nécessite un orchestrateur central.
- Proposer des mécanismes de reporting et de surveillance. Visibilité sur l'usage, les coûts, les performances et les anomalies — en continu, pas en audit ponctuel.
- S'intégrer au système d'information via des interfaces validées et communes — MCP ou API surveillés et maîtrisés — plutôt que par des connexions ad hoc négociées agent par agent.
- Respecter les règles de sécurité de l'entreprise concernant l'accès aux données, leur usage et les droits des utilisateurs, au même titre que n'importe quelle application du système d'information.
Ce cahier des charges n'est pas un exercice théorique : c'est la condition pour que les agents IA deviennent un actif stratégique durable, plutôt qu'une dette technique et sécuritaire qui s'accumule silencieusement.
Gouverner avant de déployer
La tentation est grande, face à la pression du marché et à la peur de prendre du retard, de déployer vite et de gouverner plus tard. C'est précisément l'inverse qu'il faut faire. Une architecture d'orchestration agentique pensée en amont coûte moins cher, à tous égards, qu'un rattrapage de gouvernance mené dans l'urgence sur des dizaines d'agents déjà en production, dispersés, non documentés et non sécurisés.
Pour les DSI, l'enjeu n'est donc pas de freiner l'adoption des agents, mais d'en reprendre la maîtrise : définir le socle avant de laisser les équipes construire dessus.
Chez Zento, nous avons formalisé cette approche à travers Armonies, une architecture d'orchestration multi-agents pensée pour répondre précisément à ces enjeux d'indépendance vis-à-vis des LLMs, de mutualisation et de gouvernance. Nous en reparlerons bientôt plus en détail.
