Lancer la gouvernance de l’IA en partant d’un problème d’approvisionnement

Avant que Diabsolut puisse mettre des agents d’IA au travail au sein de la Livraison (Delivery), il fallait d’abord répondre à une question plus difficile : jusqu’où un agent devrait-il pouvoir accéder aux propres données de l’entreprise ? Voici l’histoire de ce qui s’est passé lorsque l’expérimentation de l’IA a dépassé une politique que personne n’appliquait — et les six mois qu’il a fallu à l’équipe IT de Citadelis et au groupe Delivery Intelligence de Diabsolut pour transformer cela en un flux de travail agentique gouverné, avec MuleSoft, de véritables propriétaires de dépôts, et une réelle visibilité sur les coûts.

Auteur: Alberto Navas Roch

Au commencement, il n’y avait pas d’IA. Il n’y avait que l’approvisionnement.

Pas glamour, peut-être, mais essentiel : la machinerie discrète de la civilisation d’entreprise moderne. Les demandes affluaient pour de nouveaux services cloud, des applications, des prestations professionnelles, et d’autres créatures numériques qui promettaient de rendre la vie plus facile, plus rapide, moins chère, et parfois plus compliquée d’une façon que personne n’avait budgétée.

Le rituel était familier. Quelqu’un dans l’entreprise voulait donner à un fournisseur l’accès aux données de la société. Nous voulions savoir ce qu’il comptait en faire, où il comptait les stocker, qui pourrait y toucher, combien de temps il les conserverait, et si sa posture de sécurité était faite d’acier, de carton, ou de diapositives PowerPoint optimistes.

Nous examinions les certifications de sécurité, l’historique des violations de données, les incidents de sécurité passés, les termes contractuels, les pratiques de gestion des vulnérabilités, et la maturité globale de chaque fournisseur. La mission était claire : permettre à l’entreprise d’avancer tout en la protégeant. Ce n’était pas toujours simple, mais au moins le champ de bataille était cartographié. Les risques avaient des noms. Les contrôles avaient des propriétaires. Les circuits d’approbation, sans être exactement poétiques, étaient connus.

Puis l’IA est arrivée

Non pas comme une catégorie technologique proprement emballée, attendant poliment son tour dans la file d’approvisionnement, mais comme un tsunami. Et comme la plupart des tsunamis, elle n’a pas commencé par demander une invitation à une réunion.

La première vague fut la curiosité. L’IA était la disruption annoncée, le sujet dont tout le monde parlait, qu’on observait, dont on se transmettait les articles, et qu’on testait dans l’intimité de son navigateur. C’était excitant, étrange, et un peu théâtral. Beaucoup d’organisations essayaient encore de décider s’il s’agissait d’une mode passagère, d’un booster de productivité, ou de la scène d’ouverture d’une transformation bien plus vaste.

À ce stade, les gens étaient intéressés, mais pas encore paniqués. L’IA était encore quelque chose que l’on observait à distance respectueuse, comme un volcan dans un documentaire.

Puis vint la deuxième vague.

Celle-ci portait l’urgence en elle.

L’entreprise a commencé à ressentir la pression. L’IA n’était plus un sujet futuriste réservé aux webinaires et aux présentations stratégiques. Elle devenait quelque chose qu’il fallait apprendre, adopter et utiliser rapidement. Le message adressé au personnel était subtil, de la même façon qu’une alarme incendie est subtile : bougez vite, ou risquez de perdre du terrain sur le marché.

À mesure que le marché s’échauffait, des solutions dopées à l’IA apparaissaient partout. Chaque fournisseur, plateforme, outil et module semblait avoir découvert l’intelligence artificielle du jour au lendemain, généralement avec un slogan suggérant qu’elle pouvait transformer le travail, accélérer les décisions, automatiser l’effort, générer des insights, réduire les coûts, et éventuellement faire le café si le niveau de licence était suffisant.

Naturellement, les utilisateurs sont devenus curieux.

Et la curiosité s’est transformée en expérimentation.

L’expérimentation a dépassé les règles

Les gens ont commencé à essayer des outils d’IA, des versions d’essai, des extensions de navigateur, des services en ligne, et tout ce qui portait les lettres « IA », souvent avant même de demander l’approbation de l’IT ou des achats. Le processus traditionnel, avec ses contrôles, ses revues et son insistance charmante à vouloir savoir où allaient les données de l’entreprise, a soudain semblé, aux yeux de beaucoup, être un vieux péage sur une autoroute de l’hyperespace.

Pendant un moment, les choses ont semblé échapper à tout contrôle.

L’urgence venant de l’entreprise avait été interprétée par beaucoup comme une invitation ouverte à tester tout ce qui mentionnait l’IA. La gouvernance est devenue optionnelle dans l’esprit de certains utilisateurs, ce qui est une façon polie de dire qu’elle a été temporairement ignorée par des gens allant très vite et se sentant très innovants.

Des données pouvaient être copiées dans des outils sans une compréhension complète de leur destination, de la façon dont elles seraient stockées, de qui pourrait y accéder, ou de si elles seraient utilisées pour entraîner des modèles externes. Les anciennes questions de risque fournisseur s’appliquaient toujours, mais l’IA en ajoutait une nouvelle : l’outil pouvait-il apprendre des données, en déduire des choses, les reproduire, les exposer, ou les transformer discrètement en le futur miracle de productivité de quelqu’un d’autre ?

Nous avions déjà publié notre première politique IA en 2024 (c’était un an plus tôt, durant la première vague).

Elle existait. Elle était réelle. Elle avait des mots, une structure, un objectif, et vraisemblablement un emplacement de fichier.

Mais le timing a joué contre nous. Dans la précipitation à explorer et adopter l’IA, la politique a été largement oubliée, rejoignant cette noble archive de documents d’entreprise dont tout le monde s’accorde à dire qu’ils sont importants, juste après que quelque chose a mal tourné. L’expérimentation avançait plus vite que la prise de conscience, et la prise de conscience avançait plus vite que la gouvernance.

Remettre la gouvernance de l’IA en place

À ce stade, l’IT a dû taper du poing sur la table et lever un drapeau urgent.

L’objectif n’a jamais été d’arrêter l’innovation. Cela aurait été à la fois impopulaire et impossible, un peu comme essayer d’arrêter la marée avec un tableur. Il s’agissait de mettre en place des limites, une structure et une responsabilisation avant que l’enthousiasme ne dépasse complètement le jugement.

Comme toujours, les achats sont devenus un point de contrôle clé pour l’examen des nouveaux outils et services. Mais l’IA ne rentrait pas dans le moule habituel des fournisseurs. Une simple liste de contrôle ne suffisait plus. L’IA exigeait une propriété plus claire, une gouvernance plus forte, et de nouveaux rôles capables de guider l’organisation à travers un territoire inconnu.

C’est à ce moment que l’entreprise a commencé à créer des rôles et des responsabilités spécifiques pour reprendre le contrôle des initiatives IA. L’accent est passé d’une réaction à des demandes éparses vers la construction d’un modèle de gouvernance capable de soutenir l’innovation en toute sécurité.

L’IA n’était plus simplement une autre technologie.

Elle était devenue à la fois une capacité métier, un domaine de risque, et une priorité de gouvernance. Un dragon à trois têtes, en somme, sauf que celui-ci venait avec des API, des coûts d’abonnement, et des implications juridiques.

La question qui définissait désormais tout : comment permettre à l’entreprise d’avancer vite avec l’IA sans laisser le risque, la confusion et l’expérimentation incontrôlée avancer encore plus vite.

L’équipe Delivery a fait monter les enjeux

Nous en étions encore à travailler sur tout cela lorsque l’équipe métier de Diabsolut est venue avec une idée plus ambitieuse : mettre en œuvre une stratégie de flux de travail agentique au sein du département Delivery.

Ce n’était pas une autre expérience du type « essayons ça et voyons ce qui se passe », chuchotée dans le vide avec un essai gratuit et une adresse e-mail professionnelle.

C’était une initiative métier structurée avec un objectif clair : utiliser des agents d’IA pour améliorer la façon dont les équipes de livraison recueillent des renseignements, produisent de la documentation, et accélèrent les résultats internes. La vision était de créer un environnement propice à l’IA, capable de se connecter aux connaissances de l’entreprise, aux données historiques de projets, aux playbooks de livraison et aux dépôts internes, afin que les agents puissent soutenir les équipes avec des informations pertinentes, contextuelles et réutilisables.

Autrement dit, l’idée était de donner aux équipes de livraison quelque chose de mieux que la mémoire éparpillée, l’effort manuel héroïque, et l’antique chasse au trésor d’entreprise connue sous le nom de « je crois que ce document est quelque part sur SharePoint ».

L’équipe innovation de Diabsolut a contacté notre équipe pour commencer à construire l’infrastructure nécessaire. L’objectif était de créer d’abord les fondations, puis d’évoluer vers les capacités les plus avancées requises pour une configuration IA mature. Cela impliquait de penser non seulement aux modèles d’IA eux-mêmes, mais aussi à l’accès aux données, à l’orchestration, aux permissions, à la sécurité, à la visibilité des coûts et à la gouvernance.

C’est là que la précédente conversation sur la gouvernance de l’IA a cessé d’être théorique.

Elle a chaussé ses bottes.

Nous avons commencé par explorer les solutions qui intéressaient l’entreprise, comme MuleSoft, qui est passé par le processus standard d’approvisionnement et de diligence raisonnable en matière de sécurité. Cette étape était essentielle. Même si l’initiative était innovante et pilotée par le métier, elle devait encore suivre les principes que nous avions déjà renforcés : comprendre la technologie, valider le fournisseur, évaluer le risque, et définir les bons contrôles avant d’ouvrir un accès large aux données internes.

L’innovation est importante. Tout comme le fait de ne pas donner accidentellement à un agent numérique les clés de tous les classeurs du royaume.

Décider jusqu’où les agents pouvaient aller

À partir de là, la discussion a évolué vers un territoire plus complexe. Nous avons dû explorer les limites des Model Context Protocols, ou MCP, et comprendre jusqu’où les agents devaient être autorisés à s’étendre dans les dépôts de l’entreprise.

Cela a soulevé des questions importantes. À quelles données les agents devraient-ils pouvoir accéder ? Quels dépôts devraient être inclus ? Qui devrait approuver cet accès ? Comment pouvions-nous garantir que les permissions suivaient un contrôle d’accès basé sur les rôles ? Et comment pouvions-nous équilibrer le besoin d’innovation avec la responsabilité de protéger l’organisation ?

Il y avait parfois une tension naturelle entre l’expérimentation et le contrôle. Certains scénarios de test nécessitaient un accès large, voire des droits administratifs, pour explorer pleinement les capacités de la plateforme. Dans le même temps, nous savions que donner aux agents d’IA un accès inutile aux dépôts internes pourrait créer un risque inacceptable.

Le défi consistait à éviter de bloquer l’innovation tout en évitant une exposition incontrôlée. C’est l’art délicat, propre à l’entreprise, de dire « oui » sans dire accidentellement « oui à tout ».

Cet équilibre exigeait de la collaboration.

Nous avons impliqué les propriétaires de sites SharePoint, les propriétaires Azure DevOps, et d’autres propriétaires d’outils internes pour définir les bonnes limites. Dépôt par dépôt, nous avons déterminé ce qui pouvait être exposé, ce qui devait rester restreint, et quel niveau d’accès était approprié pour les flux de travail agentiques.

Finalement, tout le monde s’est aligné autour d’un modèle mettant en place des limites tout en permettant à l’innovation d’avancer. Ce n’était pas une mince affaire. Quiconque a déjà essayé d’aligner des propriétaires de données, des exigences de sécurité, l’urgence métier, les capacités de la plateforme et les attentes en matière de gouvernance sait que cela ressemble moins à une réunion qu’à la négociation d’un traité entre cités-États technologiquement avancées.

Avec cet alignement, l’architecture a commencé à prendre forme.

Câbler le tout avec des contrôles

L’orchestration agentique de MuleSoft est devenue une partie de la solution. Ses capacités MCP ont été connectées à des dépôts internes de l’entreprise sélectionnés. Les permissions ont été revues et alignées. Les modèles d’IA ont été connectés et configurés via des abonnements Azure spécifiques, ce qui nous a permis de mesurer les dépenses et d’obtenir une visibilité sur l’ensemble de l’environnement.

Cette visibilité était essentielle.

Nous ne voulions pas que l’utilisation de l’IA devienne une boîte noire : mystérieuse, coûteuse, puissante, et défendue par des gens disant : « Ne vous inquiétez pas, ça marche, c’est tout. » Nous devions comprendre la posture de sécurité, surveiller la performance, et suivre les coûts dès le départ.

En structurant l’environnement de cette façon, nous avons créé une configuration qui permettait à l’équipe Delivery Intelligence d’expérimenter et de construire, tout en donnant à l’IT les contrôles nécessaires pour soutenir l’initiative de façon responsable.

Le résultat fut plus qu’une simple mise en œuvre technique. Il a montré comment la gouvernance de l’IA, les achats, la sécurité et l’innovation métier peuvent travailler ensemble. La chose qui nous inquiétait, l’utilisation incontrôlée de l’IA, est devenue la chose que nous gérons désormais délibérément.

Il a fallu six mois de travail d’équipe intense, parfois chaotique, entre l’équipe de support IT de Citadelis et l’équipe Delivery Intelligence de Diabsolut, à partir de la fin 2025.

À la fin, nous avions une structure là où régnait l’incertitude, et une capacité Delivery Intelligence gouvernée là où il y avait auparavant une curiosité éparpillée et des expériences en version d’essai gratuite.

Une fois les fondations en place, la véritable valeur dépend de l’intelligence avec laquelle l’organisation saura les exploiter. C’est la partie sur laquelle nous travaillons maintenant.