Le Shadow IT à l’ère de l’IA

Le faux problème, le vrai diagnostic

Le Shadow IT existe depuis qu’il existe des départements informatiques. Ce qui a changé, en 2024-2025, n’est pas son existence — c’est son échelle. Les chiffres ci-dessous, agrégés depuis les baromètres Productiv, BetterCloud et le CESIN, racontent la même histoire : la DSI moderne pilote en moyenne un tiers à un quart du SI réel de son organisation.

Lire ces trois chiffres ensemble est plus instructif que les lire un par un. Une entreprise type a vu son parc applicatif quadrupler en six ans, sa visibilité diminuer en proportion, et un nouveau vecteur d’adoption — l’IA générative — venir se superposer à l’ancien. Le Shadow IT n’est pas un échec de gouvernance : c’est la manifestation visible d’un écart entre les besoins métier et la cadence de la DSI. Tant que cet écart n’est pas réduit, le Shadow IT ne disparaît pas — il change simplement de visage.

Un Shadow IT élevé ne signale pas une indiscipline des équipes. Il signale une DSI qui n’a pas trouvé le rythme de ses utilisateurs.

L’accélération SaaS, puis la rupture IA

Pour comprendre ce qui se joue depuis dix-huit mois, il faut regarder la trajectoire longue de l’adoption applicative.

Multiplication par seize en six ans. Ce qui n’apparaît pas dans cette courbe — et qui constitue la rupture de 2024 — c’est l’arrivée d’une nouvelle classe d’outils, l’IA générative, qui n’obéit à aucune des règles d’adoption précédentes. Trois caractéristiques rendent le Shadow IA structurellement différent du Shadow IT classique.

La vitesse d’adoption ne se mesure plus en mois mais en jours. Un nouveau modèle sort, un collaborateur l’essaye le lendemain, l’intègre à son flux la semaine suivante. Le cycle traditionnel d’évaluation IT — pilote, validation, déploiement — est un ordre de grandeur trop lent.

L’exposition des données est inversée. Un SaaS classique consomme des données via des connecteurs documentés. Un outil d’IA générative ingère ce que le collaborateur lui colle dans le prompt — extraits de contrats, données financières, code source, notes RH — sans contrôle technique possible côté entreprise.

L’invisibilité comptable est totale. Les usages gratuits, les abonnements personnels, les versions intégrées d’assistants IA dans des outils déjà présents : aucune trace dans le contrôle de gestion. Les méthodes de cartographie financière, qui fonctionnaient pour le SaaS payant, deviennent aveugles.

Pourquoi la cartographie classique échoue

Quand un DSI lance une démarche de cartographie du Shadow IT, il s’y prend presque toujours par une des trois portes — et chacune comporte un angle mort majeur que l’organisation découvre trop tard.

La porte financière consiste à exploiter les flux comptables : notes de frais, abonnements récurrents, paiements carte d’achat. Elle capture remarquablement bien le SaaS payant institutionnel. Elle est totalement aveugle aux usages gratuits, aux comptes personnels et — point critique aujourd’hui — à la majorité du Shadow IA.

La porte technique exploite les logs réseau, les passerelles cloud et le SSO. Elle capture les usages effectifs sur le périmètre maîtrisé. Elle est aveugle dès qu’un collaborateur utilise un outil sur son téléphone personnel ou depuis un café — c’est-à-dire la majorité du temps pour les outils d’IA.

La porte déclarative mise sur les remontées des équipes via questionnaires, canal Slack dédié, entretiens. Elle capture le pourquoi — le besoin métier sous-jacent — mais sous-évalue systématiquement le réel : personne ne déclare spontanément un outil dont il craint qu’on le lui retire.

La triangulation comme méthode

Aucune des trois portes ne suffit. Une cartographie fiable n’est pas l’une ou l’autre — c’est l’intersection des trois, traitée comme un système et non comme trois projets parallèles.

L’ordre dans lequel on construit les trois sources compte. En commençant par la trace déclarative — avant tout outillage technique — on installe le réflexe culturel qui rendra les deux autres exploitables. Si la première découverte que les équipes font de la démarche se traduit par la suspension de leurs outils préférés, la trace déclarative est morte pour les dix-huit mois suivants.

Cartographier pour quoi faire

Une cartographie qui ne mène à aucune décision est un rapport. Une fois que vous tenez une vision fidèle, trois réponses sont possibles pour chaque outil identifié — et le travail de la DSI consiste précisément à choisir, pour chaque cas, laquelle.

Intégrer — l’outil répond à un vrai besoin, la DSI le reprend en charge officiellement, l’encadre, mutualise les contrats. C’est le scénario le plus fréquent et le plus rentable. Le coût caché d’une absorption est presque toujours inférieur au coût d’un remplacement.

Encadrer sans intégrer — l’outil reste utilisé mais avec des règles : catégories de données interdites, formation obligatoire, audit annuel. Approprié pour les outils utiles mais risqués que la DSI ne veut pas opérer.

Interdire — réservé aux cas où le risque (fuite de données, conformité, sécurité) est supérieur à la valeur métier. À utiliser avec parcimonie : chaque interdiction non substituée nourrit le Shadow IT de demain.

Ce qu’il faut retenir

• Le Shadow IT est un signal, pas un défaut. Un Shadow IT élevé révèle un écart entre cadence métier et cadence DSI — pas une indiscipline.
• La GenAI a changé la nature du problème. Le Shadow IA n’est ni payant, ni traçable financièrement, ni captable par le SSO. Il exige une nouvelle méthode de cartographie.
• Aucune des trois portes (financière, technique, déclarative) ne suffit seule. Construisez les trois, mais commencez par la déclarative — sinon vous tuez la confiance qui rend l’ensemble possible.
• Cartographier sert à décider. Pour chaque outil identifié : intégrer, encadrer, interdire. Trois choix, jamais le statu quo.