La DSI doit-elle rester le gardien qui valide les usages au cas par cas, ou devenir le fournisseur de voies rapides ?
Avec l’IA agentique, l’IT ne peut plus gouverner après coup des outils qui se recomposent sans cesse. Sa crédibilité dépendra d’autre chose : sa capacité à fournir des voies rapides, plus simples que le contournement, où les données, les identités et les responsabilités restent dans le champ commun.
Fabien Dussaucy conclut son analyse du Shadow IT par un déplacement décisif : passer de gardien à fournisseur de voies rapides, de contrôleur a posteriori à architecte du cadre. C’est un changement de fonction pour les équipes IT, sécurité et plateforme.
Un gardien autorise ou refuse, au cas par cas, des demandes formulées par d’autres. Il est structurellement en retard : l’usage arrive toujours avant la règle. Un fournisseur de voies rapides inverse la séquence. Il met à disposition, avant le besoin, des capacités que les équipes peuvent mobiliser elles-mêmes, avec des protections déjà intégrées. La décision ne disparaît pas ; elle se déplace de la validation de chaque projet vers la conception de ce que tous les projets pourront utiliser.
L’IA agentique rend ce déplacement urgent. Les équipes ne choisissent plus seulement des applications. Elles composent des systèmes capables de mobiliser un modèle, des données, une identité, des outils et parfois une capacité d’action. Aucun guichet ne peut suivre ce rythme, d’autant que les usages n’attendent pas : selon le baromètre IA 2026 de l’ESSCA et de Forvis Mazars, deux tiers des professionnels de l’IT et du digital interrogés en Europe constatent déjà des pratiques de Shadow AI dans leur organisation. Une plateforme agentique le peut, à condition d’en être une.
Prenons un cas ordinaire : un agent de support client. Il lit les tickets entrants, consulte la base de connaissances et l’historique du client, puis prépare une réponse. Demain, il pourrait l’envoyer lui-même, voire déclencher un geste commercial.
Cet agent n’est pas un produit qu’on installe. C’est un assemblage : des instructions, un modèle, une mémoire éventuelle, une identité, des données accessibles, des outils appelables et des règles de décision. Le même outil d’orchestration peut produire un assistant inoffensif ou un acteur capable d’engager l’entreprise auprès de ses clients. Tout dépend de ce qu’on lui branche.
C’est là que l’approche par catalogue atteint sa limite. Approuver un fournisseur de modèles ou une solution d’agents ne dit presque rien du risque réel. Le même modèle, autorisé pour reformuler des textes, ne pose pas les mêmes questions lorsqu’il lit des données clients et peut écrire dans un système de facturation. Le risque ne loge pas dans l’outil. Il naît de la combinaison entre données, droits et actions.
La bonne unité de gouvernance devient donc l’interaction : un agent accède à une donnée, appelle un outil, reçoit une autorisation, produit une recommandation ou déclenche une action. Les outils changeront. Les combinaisons, elles, se multiplieront.
Si le risque naît des interactions, il faut un endroit où ces interactions sont décidées. C’est le cœur d’une plateforme agentique : la séparation entre plan d’exécution et plan de contrôle.
Le plan d’exécution est l’espace où l’agent travaille : il interroge un modèle, recherche une information, appelle un outil, enchaîne des tâches. Le plan de contrôle est l’espace où l’organisation définit et applique ses règles : identités, droits, politiques de données, limites budgétaires, approbations, journalisation et mécanismes d’arrêt.
Cette séparation répond à une question simple : qui décide qu’une action peut avoir lieu ? Un modèle peut proposer d’envoyer une réponse au client. Il ne doit pas être l’autorité qui s’autorise à le faire. La décision doit être évaluée au moment où l’action s’exécute, selon une identité, un contexte et une politique explicite, et non reconstituée dans un prompt ou dissimulée dans une clé API partagée.
C’est ce qui rend la plateforme supportable à grande échelle. Elle n’a pas besoin de prévoir chaque agent qui sera imaginé demain. Elle fournit les frontières qui rendent les interactions importantes visibles, gouvernables et révocables lorsqu’elles apparaissent. Les recommandations de sécurité publiées par OWASP, AWS ou Microsoft convergent sur ce point : permissions minimales, distinction entre lecture et écriture, outils limités, approbation humaine pour les actions sensibles, journalisation et possibilité d’interrompre.
Le contrôle cesse d’être une étape administrative placée avant ou après l’usage. Il devient une propriété de l’exécution.
Cet automne, l’idée est devenue un argument commercial. IBM, Boomi, Check Point et une longue liste d’éditeurs proposent désormais leur « plan de contrôle » pour agents. Gartner place la gouvernance de la plateforme d’agents autonomes parmi ses tendances stratégiques pour 2027 : les DSI, écrit le cabinet, passent de la gestion d’actifs technologiques à la gouvernance du comportement des machines.
Cette convergence valide l’architecture. Elle installe aussi une illusion : celle qu’on pourrait acheter la voie rapide. Un produit fournit des mécanismes. Il ne fixe ni les seuils d’autonomie, ni les responsables, ni ce qui se passera le jour où l’organisation voudra changer de fournisseur.
Beaucoup de ces offres commencent d’ailleurs par découvrir et recenser les agents. Le repérage est utile, mais il retrouve vite la limite de tout inventaire : il décrit ce qui existe, pas ce qui est en train d’agir. Le registre est un moyen. La gouvernance se joue au moment où l’agent agit.
Le mot « plateforme » peut tout désigner et ne rien préciser. Une plateforme agentique n’est ni un chatbot interne, ni une vitrine de cas d’usage, ni un nouveau circuit de validation. C’est l’ensemble des fondations que chaque équipe ne devrait pas avoir à reconstruire, ni à négocier, pour chaque nouvel agent.
Ces fondations tiennent en quelques capacités. Une identité de service propre à chaque agent durable, distincte de celle des personnes qui le créent, avec des droits explicites et révocables ; Microsoft, IBM et Google en font désormais une brique standard de leurs offres. Des accès aux données et aux API métier qui respectent les habilitations et la classification de l’information. Des environnements où l’on peut tester, versionner, observer et retirer un agent, avec des limites de coût, de volume et de nombre d’actions. Une traçabilité qui permet, en cas d’erreur, de retrouver les données consultées, les outils appelés, l’autorisation accordée et le résultat produit.
Deux précisions évitent que ces capacités se retournent contre leur objet. Lorsqu’un agent agit au nom d’une personne, ses droits délégués ne doivent jamais excéder ceux de cette personne, ni survivre à son départ. Et les traces servent à rendre un système exploitable et auditable, pas à surveiller le travail des salariés : elles doivent être protégées, limitées dans leur durée de conservation et accessibles selon des règles connues.
La voie rapide n’est donc pas l’absence de règles. C’est la présence de règles déjà intégrées dans ce que l’on propose aux équipes.
Le développement logiciel a déjà traversé cette tension : écrire du code va vite, exploiter un service dans la durée exige secrets, environnements, déploiement, supervision et reprise après incident.
C’est l’une des raisons d’être des Internal Developer Platforms, ou IDP : un ensemble de capacités partagées qui permet aux équipes de créer et d’exploiter des services sans reconstruire les mêmes fondations à chaque projet. Une IDP ne décide pas ce que les équipes construisent. Elle leur offre un chemin de production assez simple pour que le chemin conforme soit aussi le chemin efficace.
Ce précédent montre surtout qu’un standard bien conçu peut produire de l’autonomie plutôt que de la contrainte. Là où une IDP fonctionne, les équipes livrent sans attendre l’intervention d’un spécialiste, et l’organisation gagne en robustesse parce que les services reposent sur des mécanismes communs.
L’analogie a une limite qu’il faut garder en tête. Des fondations techniques fiables ne garantissent pas la qualité de ce qu’un agent produit : une réponse fausse peut être parfaitement tracée. L’évaluation des résultats reste un travail propre à chaque usage. Mais la leçon organisationnelle tient : mutualiser ce qu’il serait coûteux, fragile et risqué de réinventer pour chaque agent.
Tous les agents ne présentent pas le même risque. Les traiter comme équivalents condamnerait l’organisation à choisir entre deux impasses : bloquer chaque expérimentation ou banaliser des usages qui engagent déjà des clients et des systèmes critiques.
L’agent de support illustre cette gradation. Lorsqu’il consulte la base de connaissances, l’enjeu porte sur l’accès et la traçabilité. Lorsqu’il prépare une réponse qu’un conseiller relit, il entre dans un processus, mais un humain reste l’auteur de l’envoi. Lorsqu’il envoie seul, ou accorde un remboursement, il engage directement l’entreprise. À chaque palier, les exigences doivent monter : séparation entre lecture et écriture, autorisations au niveau de l’outil, approbation humaine, journalisation renforcée, coupure possible.
Le palier où l’agent écrit lui-même aux clients n’engage pas seulement des règles internes. Depuis août 2026, l’AI Act impose d’informer les personnes qu’elles échangent avec une IA ; à partir de décembre 2027, les usages classés à haut risque devront en plus garantir journalisation et supervision humaine.
Gartner chiffre le coût de l’erreur inverse : d’ici 2027, 40 % des entreprises devraient rétrograder ou retirer des agents autonomes à cause de failles de gouvernance découvertes après un incident en production. Le cabinet en désigne la cause : une gouvernance binaire, tout verrouillé ou tout permis. Trop restreindre les agents simples ralentit les équipes et pousse au développement parallèle ; trop peu encadrer les plus autonomes expose l’organisation.
La plateforme rend cette gradation praticable sans exiger de chaque équipe qu’elle invente sa propre analyse de risque. La question n’est plus « les agents sont-ils autorisés ? », mais « quel niveau d’autonomie cet usage justifie-t-il, et quelles protections doivent l’accompagner ? »
Cette logique dessine aussi une trajectoire. Commencer par la recherche, la synthèse et la préparation, qui permettent d’éprouver les fondations sans déléguer d’actions irréversibles. Industrialiser ensuite ce qui fonctionne. N’envisager les actions sensibles qu’une fois que l’organisation sait interrompre, corriger et expliquer ce qu’un agent a fait.
Une plateforme ne peut pas répondre de tous les usages qu’elle rend possibles, et l’équipe qui porte un besoin ne peut pas assumer seule la sécurité, la conformité et l’exploitation.
La responsabilité doit donc être distribuée et nommée. L’équipe plateforme porte les fondations communes. Les équipes sécurité, risques et données fixent les politiques d’accès et les seuils d’autonomie. Les équipes métier portent la valeur du cas d’usage, la qualité des résultats et leurs effets dans le processus transformé. Le management arbitre les ressources et accepte les risques lorsqu’un usage franchit un seuil d’impact.
Cette répartition répond à des questions qui deviennent inévitables : qui accepte le niveau d’autonomie de l’agent de support ? Qui peut l’arrêter ? Que se passe-t-il pour les clients et les conseillers s’il est coupé un lundi matin ? Un agent qui porte une partie du travail doit avoir un mode dégradé, faute de quoi la coupure devient elle-même un incident. Et qui déclare l’incident ? Selon une étude de Workato, 36 % des dirigeants interrogés tenteraient de régler discrètement un incident de sécurité causé par un agent. Sans responsable nommé, l’erreur ne disparaît pas ; elle est seulement tue.
Mutualiser crée aussi un risque propre : une plateforme commune concentre les dépendances. Sa disponibilité, sa sécurité et sa réversibilité vis-à-vis des fournisseurs de modèles deviennent des sujets de premier rang. Les standards ouverts aident : la fondation Agentic AI, hébergée par la Linux Foundation, réunit désormais dix projets, dont le protocole MCP, sous une gouvernance neutre. Ce n’est pas un argument contre elle. C’est une raison de la traiter comme une infrastructure critique.
Un agent sans propriétaire est une dette avant d’être une innovation.
Construire une plateforme agentique a un coût : compétences d’ingénierie, intégration avec l’identité et les données, connecteurs, observabilité, accompagnement, exploitation dans la durée. Ce coût apparaît dans un budget, avec un responsable et une ligne à défendre.
C’est précisément pourquoi le bricolage paraît plus attractif. Son coût ne figure nulle part. Il est réparti entre les équipes : intégrations réécrites, clés disséminées, comptes difficiles à révoquer, licences locales, données dupliquées, incidents impossibles à diagnostiquer, expérimentations utiles qui ne deviennent jamais réutilisables. Personne ne le paie en une fois ; tout le monde le paie, plus cher lorsqu’il devient critique.
Le véritable arbitrage n’oppose donc pas une dépense à l’absence de dépense. Il oppose un investissement explicite à une dette implicite. Il faut toutefois donner raison à l’objection : pour deux ou trois usages isolés, une plateforme complète n’est pas automatiquement le bon investissement. Sa rentabilité dépend du nombre d’équipes qui l’utiliseront réellement. D’où l’intérêt de la construire par paliers, au rythme des usages, plutôt que d’en promettre d’emblée l’exhaustivité.
Le résultat attendu doit être aussi explicite que le coût : permettre à une équipe de passer d’un besoin à une expérimentation encadrée en quelques jours, sans compte personnel, sans secret partagé, sans sortie non maîtrisée des données. Si la voie gouvernée reste plus lente que le contournement, la plateforme ne résout rien. Elle devient un guichet de plus.
Le succès ne se mesure pas au nombre d’agents publiés ou de règles écrites. Il se mesure à quelques signaux simples : le délai entre un besoin et une expérimentation encadrée, le temps nécessaire pour révoquer un accès ou arrêter un agent, la part des expérimentations devenues des composants réutilisables, et les frictions qui poussent encore les équipes hors du cadre.
Ils vérifient une seule chose : les équipes IT, sécurité et plateforme sont-elles devenues des fournisseurs de voies rapides, ou restent-elles des contrôleurs que les usages contournent ?
Le premier pas n’a rien de spectaculaire : choisir un usage comme l’agent de support, en lecture et en préparation seulement. Lui donner une identité, des accès bornés, des traces exploitables et un responsable. Mesurer combien de temps il a fallu pour l’ouvrir, et combien il en faudrait pour l’arrêter. Puis demander aux équipes si ce chemin était plus simple que celui qu’elles auraient pris seules.
Si la réponse est non, c’est la plateforme qu’il faut corriger, pas les équipes. Il ne s’agit pas d’empêcher l’initiative. Il s’agit de lui donner une infrastructure.
