Excel, macros, scripts, agents IA : comment reprendre le contrôle d’une population d’outils qui grandit plus vite que vos campagnes d’inventaire, sans détruire la valeur qu’elle produit.
Depuis vingt ans, la réponse au shadow IT tient en un mot : recenser. Une campagne annuelle, un formulaire, un inventaire figé. Cette réponse était déjà fragile, et l’IA vient de la rendre absurde. La question n’est plus de savoir combien nous en avons, mais comment faire pour qu’aucun nouvel outil critique ne naisse hors de contrôle.
Récemment, sur une mission dans un grand groupe bancaire, j’ai vu le contrôle interne poser une question simple à la DSI : combien de fichiers Excel, de macros et de scripts alimentent aujourd’hui vos reportings critiques ?
Personne n’avait la réponse.
Le dernier recensement datait de deux ans, un formulaire jamais rafraîchi, et depuis, la population avait bougé, grandi, muté. On pilotait un risque réglementaire avec une photo périmée. Mais au delà de cet exemple spécifique, je n’ai encore jamais visité une grande organisation où cette problématique soit réellement résolue.
Qu’est-ce qu’on appelle vraiment un EUC ?
Le terme technique est EUC, pour End User Computing, et on le réduit souvent au tableau Excel du contrôleur de gestion. Cette vision est trop étroite, dans la réalité, ils recouvrent une grande variété d’outils.
Un EUC, c’est n’importe quel outil, tableur, macro, script, base Access, dashboard, robot RPA, automatisation, créé ou maintenu par un utilisateur en dehors du cycle de gouvernance IT. On les distingue ensuite par usage plutôt que par technologie : quelle donnée l’outil manipule, quelle est sa criticité, quel niveau de contrôle il subit, à quel point il est intégré dans la gouvernance.
Et vous connaissez tous les signaux qui trahissent leur présence, et on les entend dans toutes les organisations. « La dernière version est sur le poste de Untel. » « Le fichier arrive par mail. » « Si ça casse, on répare à la main. » « Il n’y a pas de doc, mais l’équipe sait faire. » « On ne sait pas exactement d’où viennent les données. »
Pas d’inventaire. Pas de sauvegarde. Pas de contrôle de version. Pas de reproductibilité.
Un outil dont dépend un processus réel, et que l’organisation ne voit pas.
Là où l’opérationnel devient réglementaire
Tant qu’un EUC calcule le budget d’un service, le risque reste interne, il coute quelques heures perdues, quelques cheveux arrachés pour reconstruire les arbitrages sur une donnée que personne n’a vérifiée. Mais, au final le risque reste limité. À partir de quand devient-il un problème de conformité ? Le jour où il entre dans la chaîne d’agrégation des données de risque, celle qui alimente les reportings adressés au régulateur.
BCBS 239, le standard du Comité de Bâle sur l’agrégation des données de risque, exige que ces données soient exactes, complètes, traçables, auditables, et produites par des processus « hautement automatisés, minimisant l’intervention manuelle ». Un tableur sans piste d’audit, sans versioning et sans traçabilité de la donnée coche méthodiquement la case inverse.
DORA, le règlement européen sur la résilience opérationnelle numérique (UE 2022/2554), applicable depuis janvier 2025, pousse dans la même direction sur la continuité et la maîtrise des actifs, et le RGPD ajoute par-dessus la couche donnée personnelle. Le résultat converge : un outil qui touche la donnée critique doit être démontrable, et pas seulement fonctionnel.
Le jour d’un audit, dire que ça marche depuis dix ans ne vaut rien. Seul compte ce qu’on peut prouver.
L’IA industrialise la production de l’ancien
La tentation, aujourd’hui, consiste à traiter l’IA comme une catégorie à part, un troisième type d’outil à côté des vieux Excel et des solutions bricolées par les power-users. Mais c’est une fausse bonne idée : elle pousse à construire une gouvernance IA séparée là où il suffirait d’étendre celle qui existe déjà.
Ce que l’IA change, c’est le volume. Hier, écrire un script demandait une compétence spécifique, et souvent rare. Aujourd’hui, un copilote génère une automatisation ou un agent en quelques minutes, à la demande de quelqu’un qui ne sait pas coder.
La population d’EUC ne grandit donc plus de façon linéaire, elle explose.
Et le réflexe historique s’effondre là. Recenser une population par campagne annuelle avait un sens quand elle bougeait lentement ; vouloir le faire aujourd’hui revient à compter une foule qui court, et le temps de finir l’inventaire, il est déjà faux.
Si l’inventaire déclaratif est mort, ce n’est pas parce qu’on le faisait mal. C’est parce que le rythme de création a changé d’échelle.
Pourquoi l’interdiction ne tient jamais longtemps ?
La réponse la plus courante est souvent la plus mauvaise : verrouiller, interdire, forcer tout le monde à repasser par l’IT.
Mais le métier a un vrai besoin, et celui qui crée ce script est souvent plus proche du besoin que la DSI ne l’est. Il est capable avec l’IA de produire en trois jours ce que le cycle IT livrerait en trois mois. Cette valeur est réelle, et la nier garantit le contournement plutôt qu’elle ne l’empêche.
L’objectif n’est donc pas de supprimer et d’interdire les EUC, mais de garder ce qu’ils créent en retirant le risque non maîtrisé.
Quatre leviers pour reprendre le contrôle
Le premier levier est le blocage à la source : empêcher techniquement l’export de données critiques vers un outil qui ne soit pas une application officielle. C’est le seul contrôle qui stoppe la création d’un EUC non gouverné avant même qu’il existe. Et il agit accessoirement comme révélateur, puisque qu’on peut alors identifier qui essaye de sortir de quelle donnée, et donc sortir du cadre.
Mais ce levier a une limite lourde. Bloquer suppose de savoir ce qu’on bloque, donc d’avoir cartographié toutes les entrées et sorties de données. Dans une petite structure l’exercice se fait en quelques jours, nous l’avons mis en place pour notre propre usage de l’IA et du vibe coding chez Alenia. Dans un grand groupe, ce mapping complet est quasi impossible, même en se limitant aux données critiques : les flux se comptent par milliers, ils se croisent, ils changent tous les mois. Le blocage à la source est une cible vers laquelle on tend, pas un interrupteur qu’on actionne du jour au lendemain.
Comment retrouver, alors, ce que personne n’a jamais déclaré ? C’est l’objet du deuxième levier, la détection automatique. Des outils spécialisés, comme ClusterSeven de Mitratech ou CIMCON EUC Insight, scannent les serveurs de fichiers, les partages réseau et le stockage cloud, SharePoint et OneDrive compris, pour repérer les tableurs, bases et scripts qui tournent sous le radar. La mécanique est un entonnoir : un scan léger sur les métadonnées d’abord, puis la détection des chaînes de versions, parce qu’un fichier ré-enregistré en boucle est probablement embarqué dans un vrai processus, puis une analyse de contenu poussée, formules, macros, liens entre fichiers, droits d’accès, réservée au sous-ensemble qui a survécu au tri.
C’est efficace, avec deux réserves. Le scoring technique est automatique, mais pas le scoring de criticité métier : il suppose que l’organisation ait défini au préalable ce qui est critique chez elle, et le vrai travail se trouve là bien plus que dans la technologie de scan. Quant au fichier qui vit uniquement sur le poste d’un utilisateur, jamais synchronisé, il reste hors d’atteinte. La détection réduit l’angle mort sans le refermer.
Le troisième levier tient dans un principe simple : un régime, une exception. Un régime général, piloté par la criticité de l’usage et assorti de garde-fous spécifiques à l’IA, outils validés, aucune donnée sensible envoyée à des modèles externes, exigence d’explicabilité. Et une seule dérogation encadrée, les power-users : des profils compétents, nommés, certifiés, autorisés à relâcher certaines contraintes sur la façon de construire. La latitude porte sur les outils, l’accès et la mise en production, jamais sur les fondamentaux, puisque sauvegarde, documentation, contrôle de version et confidentialité restent non négociables. L’exception se mérite, et elle se retire.
Le quatrième levier remplace l’interdit binaire par une matrice, où l’autorisation suit le cas d’usage plutôt que l’outil. Un même tableur peut être parfaitement acceptable pour un usage local et interdit dès qu’il touche une donnée réglementaire. On croise donc deux axes, la criticité de l’usage et l’origine de l’outil. Un usage critique avec exigence de continuité reste un candidat à la migration vers une application gouvernée, quelle que soit son origine, jamais un état permanent. À l’autre bout, un usage non critique construit sur une plateforme validée est non seulement toléré, mais encouragé.
Aucun de ces leviers ne suffit seul, et les grandes organisations les associent pour construire un cadre qui tienne.
Le levier le plus efficace : ouvrir une voie rapide
Si je devais n’en garder qu’un, ce ne serait aucun des quatre.
Le contrôle qui produit le plus d’effet n’est pas un contrôle. C’est une offre.
Donner aux équipes métier des outils pour développer vite, dans un environnement déjà validé : des plateformes en libre-service, un catalogue d’outils avancés pour les power-users, un espace de travail géré où l’on peut scripter, versionner et déployer sans jamais sortir du cadre.
Pourquoi les gens contournent-ils ? La logique est humaine avant d’être technique. Un EUC non contrôlé naît presque toujours d’un besoin légitime qui n’a pas trouvé de réponse officielle assez rapide, et tant que le chemin conforme reste plus lent que le contournement, les gens contournent. Si le responsable financier, frustré par son équipe IT, peut développer son propre outil sur la base des briques partagées par l’IT, il ne s’amusera pas à monter une nouvelle infrastructure ou des connecteurs non sécurisés.
Rendons le cycle de construction IT plus simple et plus rapide, et les utilisateurs métiers n’auront plus de raison d’en sortir.
Ce levier a un revers, qui peut devenir sérieux. Ouvrir des plateformes rapides au métier provoque mécaniquement une explosion de la création d’applications côté utilisateurs, et sans garde-fous on remplace un problème par un autre : des centaines d’applications fragiles, mal maintenues, qui font trois fois la même chose, et plus aucune vision d’architecture d’entreprise. La facilité de création devient alors une dette de résilience et de maintenabilité, ce qui n’enlève rien au besoin de référencer, de rationaliser et de tenir une cohérence d’ensemble.
Où placer la ligne entre ouvrir assez et ouvrir trop ? Je ne sais pas la tracer à l’avance, et je ne pense pas qu’elle existe dans l’absolu. Elle dépend de la maturité de l’organisation, de sa tolérance au risque par rapport à sa vélocité souhaitée.
L’IT monte d’un niveau, qu’elle le veuille ou non
Le centre de gravité se déplace. Le développement logiciel se démocratise, et la valeur de l’IT glisse vers la cohérence, l’architecture et le contrôle, pendant que la capacité à produire du code cesse d’être ce qui la distingue.
Le métier n’attendra pas. S’il estime qu’il est plus rapide de construire sans l’IT, il construira sans l’IT, et les organisations qui auront su canaliser cette énergie avanceront plus vite que celles qui auront passé leur temps à l’interdire.
Passer de gardien à fournisseur de voies rapides, de contrôleur a posteriori à architecte du cadre : c’est la condition pour ne pas se faire doubler, par son propre métier comme par ses concurrents.
Reste une ligne qui ne bouge pas. Dans un secteur régulé, cette montée en puissance n’est possible que si elle respecte la régulation et la sécurité. La vitesse qui ignore la conformité ne crée aucun avantage : elle augmente le risque, et la facture arrive plus tard.
Et chez vous, est-ce que l’IT court encore après son shadow IT, ou est-ce qu’elle a commencé à s’en servir pour monter d’un cran ?