Beaucoup de collaborateurs peuvent échapper au périmètre que la DSI est supposée sécuriser dans votre entreprise : utiliser Trello parce qu’un outil de gestion des tâches interne charge trop lentement, partager des fichiers commerciaux via Google Drive plutôt que la GED validée, ou encore régler un abonnement SaaS par carte bancaire pour éviter le circuit d’achat, par exemple.

Selon Gartner, 30 à 40 % des dépenses IT d’une entreprise relèvent du Shadow IT. Cet impact ne reste pas théorique, et le baromètre CESIN-OpinionWay de janvier 2025 le prouve : il recense le Shadow IT dans 23 % des cyberattaques significatives subies par les entreprises françaises en 2024.

Pourquoi vos outils officiels perdent contre un SaaS trouvé en 2 clics

Le Shadow IT n’est pas un problème de discipline dans votre entreprise, mais plutôt un souci de délai. Concrètement, quand un utilisateur rencontre un besoin, il doit généralement attendre plusieurs semaines avant d’obtenir la réponse du catalogue applicatif validé. Un SaaS grand public, lui, se déploie en quelques minutes, sans ticket ni arbitrage budgétaire.

Le cloud a supprimé la friction technique qui limitait autrefois ce phénomène. Désormais, il ne reste que la friction organisationnelle ; mais celle-ci ne suffit plus à contenir des usages qui se lancent d’un simple « Se connecter avec Google ».

Détecter ce qui vous échappe : 4 sources de données, 4 angles morts

Aucune méthode ne couvre seule l’ensemble du périmètre Shadow IT. Chacune éclaire une partie du problème et en laisse une autre dans l’ombre : raison pour laquelle vous devez être en mesure de combiner plusieurs sources.

  • Les logs réseau (DNS, proxy, pare-feu) révèlent les connexions vers des domaines cloud non répertoriés, y compris sans agent installé sur le poste. Leur limite : un flux qui passe par un VPN personnel ou un réseau hors entreprise (télétravail sur box internet, 4G) n’y apparaît jamais.
  • Les journaux d’identité (SSO, Azure AD, Okta) : de plus en plus d’applications SaaS proposent une inscription via « Se connecter avec Microsoft » ou « Se connecter avec Google ». Quand l’utilisateur passe par son compte professionnel, l’outil laisse une trace dans les journaux de l’IdP, une source de détection qui ne demande aucun déploiement supplémentaire. Sa limite : elle ne voit que les inscriptions faites via SSO, pas les comptes créés avec un e-mail personnel.
  • L’analyse des dépenses : les relevés de cartes bancaires professionnelles et les factures fournisseurs recoupées avec le catalogue applicatif validé font remonter des abonnements que personne à la DSI n’a vus passer. Cette méthode ne nécessite aucun outil de cybersécurité : un croisement Excel avec la comptabilité suffit pour un premier diagnostic. Sa limite : elle ne détecte que les usages payants, pas les outils gratuits.
  • Les agents de poste et extensions navigateur (EDR, CASB) identifient les applications installées ou utilisées localement, indépendamment du réseau emprunté. Leur limite : elle tient à leur couverture (un poste personnel en BYOD, hors périmètre de gestion, reste invisible).

Un CASB (Cloud Access Security Broker) combine plusieurs de ces sources (trafic réseau, API cloud, parfois données de dépense) pour produire un inventaire consolidé et noter chaque service selon son niveau de risque. Véritable outil de référence en matière de détection, il ne remplace pas un premier diagnostic manuel. En effet, le croisement des factures et des journaux SSO permet souvent d’objectiver l’ampleur du phénomène avant même d’investir dans un outil dédié.

Une fois l’inventaire posé, résister au réflexe du blocage

Si vous bloquez purement et simplement un service détecté, vous avez peu de chances de produire l’effet recherché : l’usage va se déplacer vers un service équivalent, plus difficile encore à repérer, et la confiance entre les métiers et la DSI risque même de se dégrader. Finalement, cette étape de détection n’a de valeur que si elle débouche sur une décision par cas :

  • Le service répond à un vrai besoin non couvert. Il devient alors candidat à une intégration officielle, avec les garanties de sécurité et de licence associées. Souvent la meilleure réponse quand l’usage est déjà massif.
  • Un équivalent validé existe déjà. L’enjeu est alors d’accompagner la bascule, pas de la décréter : comprendre pourquoi l’outil officiel a été contourné pour éviter de reproduire le même contournement 6 mois plus tard.
  • Le service présente un risque incompatible (hébergement hors UE, absence de garanties contractuelles, exposition de données sensibles). Là seulement, le blocage se justifie. Il gagne à être expliqué, pas seulement appliqué.

Shadow IT et Shadow IA : une même racine, un risque qui change de nature

Le Shadow IT désigne des outils non approuvés (un compte cloud, une application SaaS, un service de partage de fichiers). Le Shadow IA pousse cette même logique un cran plus loin : ce n’est plus l’outil qui échappe au contrôle, mais la donnée elle-même, transmise volontairement par l’utilisateur à chaque prompt.

Par exemple, quand un chef de projet utilise son propre ChatGPT (ou n’importe quelle IA) pour reformuler un document interne, deux problématiques émergent : non seulement l’outil n’est pas validé, mais un contenu potentiellement sensible sort de votre organisation sans aucune trace exploitable.

Un inventaire fiable des usages réels transforme 3 choses à la fois : votre capacité à négocier les licences (un SaaS Shadow IT massivement adopté se négocie mieux en contrat groupe qu’en abonnements individuels dispersés), votre surface d’audit en cas de contrôle réglementaire (NIS2 impose désormais de documenter la maîtrise des dépendances numériques, y compris fournisseurs), et votre crédibilité du dialogue avec les métiers, car accompagner un usage plutôt que le découvrir après coup change la nature de la relation entre la DSI et le reste de votre entreprise.

Découvrez tous nos articles et contenus sur la thématique de l’IT, du système d’information et de la cybersécurité.