Shadow IT généré par l’IA : risques, gouvernance et comment régulariser les applications créées par les départements

Quand les départements métiers créent des applications avec l’IA sans passer par l’IT

L’IA a transformé la nature du shadow IT. Auparavant, un département achetait un SaaS sans en informer l’IT. Aujourd’hui, il peut construire une petite application, un workflow, un tableau de bord ou un outil interne en quelques jours, le connecter à des feuilles de calcul, des CRM, des e-mails, des tickets, des documents ou des bases de données, et commencer à l’utiliser comme s’il s’agissait d’un système d’entreprise officiel.

Le problème n’est pas que le métier veuille résoudre ses propres problèmes : c’est qu’une solution utile peut devenir invisible. Aucun inventaire, aucun responsable technique, des accès non gouvernés, des données chargées hors périmètre, des clés API personnelles, des liens publics, une absence de politique de rétention et aucun plan de secours en cas de panne.

Pour les DSI, RSSI, responsables IT et responsables métiers, la question concrète est : quelles applications créées avec l’IA existent déjà, quelles données traitent-elles et lesquelles doivent être régularisées avant qu’elles ne deviennent critiques ?

Pourquoi l’IA accélère la prolifération du shadow IT

Les générateurs d’applications IA et les outils de “vibe coding” abaissent considérablement la barrière technique. Une équipe marketing peut créer un outil pour segmenter des leads, la finance peut automatiser des rapprochements, les RH peuvent construire un formulaire avec un workflow d’approbation et les opérations peuvent connecter des feuilles de calcul, des e-mails et des tickets en quelques jours. Beaucoup de ces initiatives naissent pour des raisons légitimes : backlog IT trop long, urgence opérationnelle, budget limité, besoin de prototyper rapidement.

Le point critique est que dès que l’application traite des données réelles, des utilisateurs, des intégrations ou des décisions opérationnelles, ce n’est plus seulement une expérience. Contrairement au shadow IT traditionnel, l’application est construite sur mesure et non achetée comme un produit fini : cela la rend plus difficile à recenser et rend d’autant plus important de comprendre comment elle est conçue — code, configurations, stockage, workflow, API, identifiants, domaines, logs et données inclus.

Le premier contrôle : l’application figure-t-elle dans l’inventaire ?

La première étape consiste à savoir que l’application existe. Si l’IT ne la voit pas, elle ne peut pas appliquer le SSO, les sauvegardes, le logging, la gestion des vulnérabilités, les politiques de données, la réponse aux incidents ou la mise hors service. Un inventaire utile doit inclure au moins ces éléments :

Nom de l’application et département responsable
Objectif opérationnel
Outil utilisé pour la créer
Utilisateurs internes ou externes
Données traitées
Intégrations et API
URL, domaines, prévisualisations et environnements
Identifiants et comptes utilisés
Criticité pour le processus métier

Il n’est pas nécessaire de commencer par un recensement parfait. Il faut un processus reproductible : enquêtes auprès des départements, découverte sur les domaines et SaaS, révision des applications OAuth, contrôle des dépôts de code, analyse des coûts cloud et un canal simple pour déclarer les applications existantes sans crainte d’un blocage immédiat.

Classer les données et évaluer l’impact

Toutes les applications de shadow IT ne présentent pas le même niveau de risque. Un outil qui reformate des textes publics est très différent d’un tableau de bord contenant des données clients, des factures, des tickets, des données RH ou des informations de santé. La classification doit répondre à quelques questions essentielles :

Traite-t-elle des données personnelles ou des données clients ?
Contient-elle des données confidentielles, commerciales, financières, RH ou contractuelles ?
Lit-elle ou écrit-elle sur des systèmes d’entreprise ?
Envoie-t-elle des données à des fournisseurs externes ou à des modèles d’IA ?
Produit-elle des décisions opérationnelles ou seulement des rapports ?
Est-elle utilisée par plusieurs personnes, départements ou entités externes ?
Que se passe-t-il si elle s’arrête, perd des données ou expose des informations ?

Les réponses déterminent le parcours : tolérer avec des contrôles minimaux, régulariser, tester, migrer vers une plateforme approuvée ou mettre hors service.

Accès : liens partagés, comptes personnels et rôles manquants

De nombreuses applications nées dans les départements métiers commencent avec des accès simples — lien partagé, mot de passe commun, compte personnel, liste d’e-mails manuelle, permissions “éditeur” pour tout le monde. Tant que l’utilisation est restreinte, cela semble fonctionner, mais lorsqu’une nouvelle équipe, un consultant ou un utilisateur externe arrive, le modèle s’effondre. Les contrôles minimaux à appliquer sont :

Comptes nominatifs
SSO et MFA lorsque cela est possible
Suppression des comptes partagés
Révocation des accès lorsqu’une personne change de rôle ou quitte l’entreprise
Rôles cohérents avec la lecture, la modification, l’exportation et l’administration
Logs sur les accès et les actions critiques

Pour les applications traitant des données clients ou multi-départements, il est utile de tester également l’accès direct : un utilisateur peut-il changer d’ID, d’URL, de filtre, d’espace de travail ou de paramètre et voir des données qui ne lui appartiennent pas ?

Intégrations et clés API : le risque caché

Pour être utile, une application de shadow IT se connecte souvent à quelque chose : Google Workspace, Microsoft 365, CRM, ticketing, e-mail, stockage, ERP, base de données, Slack, webhooks ou services de paiement. La connexion s’effectue généralement avec des jetons personnels, des clés API copiées, des applications OAuth non approuvées ou des comptes de service avec des permissions excessives. C’est l’un des points les plus critiques : une petite application peut avoir un accès étendu aux données de l’entreprise et, si elle est compromise, les dommages ne restent pas confinés à l’application elle-même.

Les contrôles pratiques à appliquer incluent :

Inventaire des jetons, applications OAuth, comptes de service et webhooks
Périmètres (scopes) minimaux pour chaque intégration
Identifiants d’entreprise, et non personnels
Rotation périodique des clés
Ségrégation par environnement
Logs d’audit sur les appels les plus sensibles
Révocation des intégrations inutilisées

Exposition publique, prévisualisations et domaines temporaires

Les constructeurs d’applications facilitent la publication d’une prévisualisation ou d’un domaine temporaire. Le département métier peut le partager avec des collègues, des partenaires ou des clients sans percevoir cela comme une exposition sur Internet. Les éléments à contrôler sont :

URL publiques et prévisualisations encore actives
Domaines personnalisés et sous-domaines temporaires
Indexation par les moteurs de recherche
Webhooks accessibles sans authentification
Endpoints d’administration ou de débogage
Stockage public
CORS et callbacks trop larges

Lorsque l’application est accessible en ligne et gère des connexions, des API, des données réelles ou des rôles, l’inventaire ne suffit pas : un test technique est nécessaire. Dans ces cas, le Web Application Penetration Testing vérifie le comportement réel de l’application, et non seulement la configuration déclarée.

Logs, exportations, rétention et suppression

Les applications créées par le métier tournent souvent autour d’exportations et de feuilles de calcul : CSV depuis le CRM, rapports financiers, listes clients, tickets, pièces jointes, fichiers chargés. Le risque n’est pas seulement l’accès abusif, mais l’accumulation non gouvernée de données sensibles. Il est nécessaire de savoir où sont enregistrés les logs et les sorties, qui peut exporter des données, combien de temps les fichiers et transcriptions sont conservés, s’il existe des sauvegardes, comment supprimer une donnée et ce qui se passe lorsque le projet est abandonné.

Une application qui n’est plus utilisée mais toujours connectée aux données de l’entreprise est un risque silencieux : elle continue d’avoir des identifiants, des liens et un stockage actifs, mais ne reçoit plus aucune attention opérationnelle.

Régulariser sans bloquer la valeur

Si l’IT n’intervient que pour interdire, le shadow IT se cache. Un parcours efficace doit classer et régulariser, en produisant une décision claire pour chaque application : maintenir, corriger, migrer, tester ou éteindre. Il ne suffit pas de “réparer ça plus tard”.

Classe	Exemple	Action
Risque faible	Outil sans données réelles, usage individuel	Enregistrer le responsable et la date d’expiration
Risque moyen	Tableau de bord interne avec données non critiques	SSO, accès, rétention, sauvegarde
Risque élevé	Application avec données clients, API ou workflow opérationnel	Évaluation des risques, revue technique, test
Critique	Application publique, multi-utilisateurs, données sensibles	WAPT/VA, remédiation avant usage étendu
Inacceptable	Identifiants partagés, données interdites, fournisseur non approuvé	Mise hors service ou migration

Checklist pour les applications shadow IT créées avec l’IA

L’application est-elle recensée dans un inventaire IT/sécurité ?
Existe-t-il un responsable métier et un responsable technique ?
Quelles données traite-t-elle et d’où proviennent-elles ?
Utilise-t-elle des données personnelles, clients, RH, financières ou contractuelles ?
Est-elle accessible depuis Internet, par des partenaires ou seulement depuis le réseau interne ?
Utilise-t-elle le SSO/MFA ou des comptes partagés ?
Quelles clés API, applications OAuth, webhooks ou intégrations utilise-t-elle ?
Quels rôles existent et qui peut exporter des données ?
Où finissent les logs, fichiers, exportations, sauvegardes et transcriptions ?
Existe-t-il des prévisualisations, domaines temporaires ou anciennes versions encore actives ?
Un test d’accès avec différents utilisateurs a-t-il été effectué ?
Est-il clair ce qu’il faut faire si l’application est compromise ou doit être mise hors service ?

Quand impliquer ISGroup

Le point de départ peut être une évaluation légère : inventaire, données, exposition, responsable, intégrations et risque. Le contrôle suivant dépend de ce qui émerge.

Scénario	Risque principal	Contrôle conseillé
Nombreuses applications non recensées créées par les départements	Gouvernance faible et absence de propriété	RSSI Virtuel (Virtual CISO)
Besoin de classer les données, impacts et priorités	Risque non compris ou non priorisé	Évaluation des risques (Risk Assessment)
Applications, hôtes, domaines, prévisualisations ou services exposés	Vulnérabilités connues et configurations ouvertes	Évaluation des vulnérabilités (Vulnerability Assessment)
Web app ou API avec connexion, données, rôles ou utilisateurs réels	Abus applicatif depuis l’extérieur	Web Application Penetration Testing

Le choix n’est pas de “faire de la sécurité sur tout”. C’est décider quelles applications sont tolérables, lesquelles doivent être régularisées, lesquelles nécessitent un test technique et lesquelles doivent être éteintes — avant qu’elles ne deviennent un problème opérationnel ou réglementaire.

Éléments utiles pour une vérification

Pour lancer une vérification structurée, il est utile de rassembler : liste des applications, responsables, URL, outil utilisé pour les créer, données traitées, utilisateurs, rôles, intégrations, clés API, applications OAuth, fournisseurs impliqués, logs, exportations, sauvegardes, domaines, prévisualisations, environnements et criticité du processus. Sont également utiles des exemples concrets comme des captures d’écran, des exportations, des workflows, des schémas de données, la configuration des accès, la liste des connecteurs, la liste des utilisateurs et une description de ce qui se passe si l’application n’est pas disponible.

Questions fréquentes

Le shadow IT généré par l’IA doit-il toujours être bloqué ?
Non. Il doit être découvert et classé. Certaines applications peuvent rester opérationnelles avec des contrôles minimaux, d’autres doivent être régularisées, testées, migrées ou mises hors service en fonction du risque qu’elles présentent.
Quel est le premier contrôle à effectuer ?
L’inventaire. Sans savoir quelles applications existent, quelles données elles traitent et qui les utilise, tout contrôle technique arrive trop tard et sans contexte.
Quand un Web Application Penetration Test est-il nécessaire ?
Lorsque l’application est accessible en ligne, expose des API, gère des connexions, des données réelles, des rôles, des téléchargements, des paiements ou des workflows utilisés par plusieurs utilisateurs.
Quand une évaluation des risques (Risk Assessment) est-elle suffisante ?
Lorsque le problème principal est de définir les priorités, les responsables, les données traitées, l’impact sur l’entreprise et le parcours de régularisation avant de lancer des tests techniques.
Qui doit être responsable de l’application ?
Il faut au moins un responsable métier pour le processus et les données, et un responsable IT/sécurité pour les accès, les contrôles, les intégrations et le parcours de régularisation.

[Callforaction-RA-Footer]

ISGroup Conseil en Cybersécurité