Le shadow IT n'a pas disparu : il a changé d'échelle

Se souvenir de la manière dont naissait une application Access

Microsoft a lancé Access en novembre 1992, et pendant les quinze années qui ont suivi, cette base de données de bureau est devenue, avec Excel, l'outil par lequel une grande partie des métiers a fabriqué ses propres applications. Le scénario est familier à toutes les DSI qui ont tenté de faire l'inventaire de leur parc au milieu des années 2000. Prenons un service de gestion des sinistres dans une compagnie d'assurance. Un gestionnaire suit ses dossiers dans un tableur, le volume augmente, la demande d'évolution du logiciel central attend dans le backlog de la DSI depuis deux ans, et il finit par monter une base Access avec quelques formulaires, deux ou trois requêtes et une macro qui génère les courriers de relance. L'outil fonctionne, ses collègues le lui demandent, il le copie sur le partage réseau du service, et en quelques mois tout le plateau l'utilise chaque matin. Personne n'a décidé que cette application existerait, aucun comité ne l'a financée, et pourtant le service ne saurait plus travailler sans elle.

Ce gestionnaire n'a rien fait de travers. Il avait un problème local que personne ne traitait, il disposait d'un outil installé sur son poste qui lui permettait de le résoudre, et il l'a résolu. C'est d'ailleurs pour cette raison que le phénomène a toujours été si difficile à combattre, puisque chaque application de ce type répond à un besoin réel que l'organisation officielle n'avait pas su servir à temps.

Comprendre pourquoi le risque tient à la propriété

En construisant sa base, le gestionnaire a aussi créé un usage que lui seul maîtrise. Il est le seul à connaître la logique des requêtes, les exceptions codées en dur et la raison pour laquelle telle colonne est remplie à la main, et il est aussi le seul à pouvoir faire évoluer l'outil quand la réglementation ou l'organisation du service change. Tant qu'il est là, le dispositif tient. Quand il change de poste, part à la retraite ou quitte l'entreprise, le service découvre qu'il dépend d'une application que personne ne possède, qu'aucun contrat de service ne couvre, et que la DSI ne connaissait pas toujours. La DSI hérite alors d'un outil critique qu'elle n'a pas conçu, et doit choisir entre le maintenir en l'état sans le comprendre ou le réécrire dans l'urgence.

Les DSI ont longtemps rangé ce sujet sous l'étiquette end user computing, et les incidents les plus documentés viennent de la finance. Selon le rapport de la task force interne publié par JPMorgan en janvier 2013, après les pertes de la « baleine de Londres », le modèle de VaR utilisé par le Chief Investment Office reposait sur une série de classeurs Excel alimentés par copier-coller manuel. L'équipe de revue des modèles avait validé ce modèle en demandant qu'il soit automatisé, et cette automatisation n'avait jamais été réalisée. Une formule y divisait les variations de taux par leur somme au lieu de leur moyenne, ce qui a contribué à sous-estimer le risque. Excel a fait exactement ce qu'on lui demandait, et la défaillance se situait dans l'absence de quelqu'un chargé de répondre de l'outil une fois celui-ci devenu critique.

Mesurer ce que le vibe coding accélère

Les outils de génération de code par agents rejouent ce mécanisme avec deux différences importantes. La première porte sur le coût de fabrication. Là où la base Access demandait des semaines de tâtonnement à un utilisateur motivé, un salarié sans formation technique peut aujourd'hui obtenir en un après-midi une application web avec une base de données, une authentification et une interface soignée, qu'il partage ensuite par un simple lien. La seconde porte sur la nature de ce qui est livré, puisqu'il s'agit désormais de logiciel déployé, connecté à des données de l'entreprise et utilisé par d'autres que son auteur, ce qui le rend à la fois plus utile et plus difficile à repérer qu'un fichier posé sur un partage réseau.

On voit ainsi des salariés sans mandat technique mettre en service des outils que leurs collègues utilisent chaque jour, sans qu'aucune équipe n'en porte officiellement la responsabilité. La question que posait la base Access se repose à l'identique, avec une aggravation, car l'auteur d'une application générée par un agent connaît souvent moins bien le code qu'il a fait produire que le gestionnaire de 2005 ne connaissait ses propres requêtes. Les éditeurs eux-mêmes ont identifié le problème. Lors de la conférence TDX de Salesforce, le 15 avril 2026, Madhav Thattai, qui dirige Salesforce AI, faisait remarquer, selon The Register, qu'on pouvait peut-être se « vibe-coder » une application SaaS, en demandant aussitôt qui allait la maintenir.

Voir comment les éditeurs SaaS en font la norme

Ce même jour, Salesforce présentait Headless 360, avec l'objectif que tout ce que fait sa plateforme puisse être appelé par un agent, via une API, un serveur MCP ou une commande en ligne, et que l'utilisateur puisse travailler depuis Slack, Teams, ChatGPT, Claude ou une application React de son choix plutôt que depuis l'interface de Salesforce. Lors de la présentation de ses résultats trimestriels fin mai, l'éditeur a cité l'exemple d'Anthropic, dont l'usage de Sales Cloud aurait été multiplié par cinq en un trimestre parce que ses salariés y accèdent depuis Claude Cowork et Slack, un chiffre déclaré par Salesforce lui-même. Le 26 août 2026, Salesforce et Anthropic ont annoncé Claudeforce et un plugin qui permet d'interroger les données commerciales, de mettre à jour le pipeline et de construire des applications sur mesure à travers une interface générée par Claude, Marc Benioff résumant l'annonce par la formule « the UI is the AI ». Le produit était alors réservé à des clients pilotes, avec une bêta ouverte annoncée pour septembre.

Pour la question de la propriété, ce mouvement change l'échelle du phénomène. Le parcours utilisateur standardisé, que l'éditeur dessinait et que la DSI paramétrait, protégeait l'entreprise contre la multiplication des variantes, au prix d'une rigidité que les métiers contournaient justement avec Excel et Access. Quand chaque commercial peut se composer un tableau de bord ou une petite application adaptée à sa façon de travailler, simplement en le demandant à un assistant, la production hors mandat devient le mode d'usage prévu par l'éditeur, alors qu'elle était jusqu'ici un contournement toléré. Il faut noter que Salesforce garde la main sur les données, les permissions et les règles métier, et que c'est sur ce socle que viennent s'appuyer les écrans composés par chacun. C'est aussi ce qui distingue la situation de celle de 2005, puisque l'application composite d'un commercial lit les mêmes données gouvernées que celles de ses collègues, là où la base Access en tenait une copie que personne ne contrôlait.

Organiser la propriété plutôt que l'interdire

Interdire n'a jamais fonctionné avec Access, et ce sera encore moins réaliste quand l'outil de fabrication est intégré au CRM que l'entreprise paie déjà. La DSI qui voudrait rester productrice exclusive des applications se retrouverait en concurrence avec ses propres éditeurs, et perdrait. En revanche, elle reste la seule à pouvoir définir ce qu'une application doit garantir dès qu'elle sert à d'autres que son auteur. Quatre décisions permettent de passer de la tolérance subie à une propriété organisée.

- Inventorier les usages plutôt que les applications, c'est-à-dire repérer ce dont un collectif dépend chaque jour, quel que soit l'outil qui le porte, une conversation récurrente avec un assistant comprise. - Placer la gouvernance au niveau des données, des permissions et des règles métier, là où les éditeurs la placent eux-mêmes, de façon que n'importe quelle interface composée par un utilisateur hérite des mêmes droits et des mêmes contrôles. - Exiger un propriétaire déclaré, et un second, dès qu'un outil est partagé au-delà de son auteur, avec un critère de bascule simple, par exemple le nombre de collègues qui l'utilisent ou le fait qu'une décision métier en dépende. - Traiter le départ de l'auteur comme le test de reprise, en vérifiant régulièrement qu'une autre personne saurait expliquer, modifier ou retirer l'outil sans lui.

Cette approche rejoint deux constats déjà posés ici. Le premier tient à l'écart entre la vitesse des agents, qui progresse au rythme des versions de modèles, et le temps dont une organisation a besoin pour apprendre à absorber ce qu'ils produisent. Les outils de fabrication arrivent en quelques mois, alors que les règles de propriété demandent des années à s'installer. Le second tient à la différence entre répondre d'un usage transformé chez quelques utilisateurs et répondre d'un produit dans la durée. Le salarié qui compose son application répond du premier, et personne ne répond du second tant que l'organisation ne l'a pas désigné.

À l'automne 2026, les outils qui rendent cette production possible sont déjà disponibles, ou en bêta, chez les principaux éditeurs, alors que les règles qui permettraient de l'absorber restent largement à écrire, et c'est par ces règles qu'une DSI a intérêt à commencer, avant que le départ d'un premier auteur ne l'oblige à le faire dans l'urgence.