Shadow IT : définition, risques et comment l'encadrer

Le shadow IT, ou informatique fantôme, désigne les logiciels, services en ligne et équipements utilisés pour le travail sans validation du service informatique. Il est rarement malveillant : le plus souvent, un salarié cherche simplement à faire son travail plus vite qu'avec les outils fournis. Mais chaque outil inconnu est une donnée qui sort du cadre, un compte que personne ne fermera et une faille que personne ne corrigera. On ne le supprime pas par décret : on le détecte, on comprend le besoin et on l'encadre. Sa forme la plus récente, le shadow AI, suit la même logique.

Le terme recouvre tout moyen informatique utilisé dans un cadre professionnel en dehors des circuits de validation. On parle aussi d'informatique parallèle. Quelques exemples courants :

• un service de partage ou de stockage de fichiers ouvert avec un compte personnel pour échanger avec un client ;
• une messagerie instantanée grand public devenue le canal de travail d'une équipe ;
• un abonnement en ligne (gestion de projet, signature électronique, formulaires, visioconférence) payé par carte bancaire et passé en note de frais ;
• une extension de navigateur ou une application tierce à laquelle on a donné accès à sa messagerie ou à ses documents ;
• un équipement personnel (ordinateur, téléphone, clé USB) connecté au réseau ou utilisé pour des données professionnelles ;
• un tableur à macros devenu application métier, ou une base de données montée par une équipe dans son coin ;
• un serveur ou un environnement cloud créé pour un test, jamais déclaré, toujours exposé sur internet.

Le dernier cas rappelle que le shadow IT n'est pas qu'une affaire d'utilisateurs : le guide du centre national de cybersécurité britannique (NCSC) parle plus largement d'« actifs inconnus », y compris ceux que la DSI elle-même a perdus de vue.

Le NCSC est net : le shadow IT est rarement malveillant, il vient le plus souvent de salariés qui n'arrivent pas à accomplir une tâche avec les outils ou les processus autorisés. Les causes qu'il cite se retrouvent partout :

• un espace de stockage insuffisant ;
• l'impossibilité de partager des données avec un tiers (client, partenaire, prestataire) ;
• l'absence d'accès aux services nécessaires au travail ;
• des demandes trop lentes ou trop lourdes pour obtenir un nouvel outil ;
• des applications verrouillées « par sécurité » au point de frustrer les utilisateurs, et une culture de sécurité faible, qui fait que personne ne signale ses contournements.

S'y ajoute la facilité d'accès : la plupart des services en ligne s'ouvrent en quelques minutes avec une adresse électronique et une carte bancaire, sans passer par les achats ni par la DSI.

Sécurité

• Fuite de données : les données confiées à un service non validé échappent à vos règles de partage, de chiffrement et de conservation.
• Comptes non maîtrisés : pas d'authentification unique, pas d'authentification multifacteur imposée, et surtout pas de fermeture au départ du salarié, qui garde l'accès aux données depuis chez lui.
• Vulnérabilités ignorées : un outil inconnu n'est ni mis à jour, ni supervisé, ni pris en compte dans la gestion des correctifs.
• Continuité : les données qui vivent dans un compte individuel disparaissent avec lui, et l'outil n'est dans aucun plan de reprise.

Conformité

• RGPD : dès qu'il traite des données personnelles, le fournisseur devient un sous-traitant, qui doit offrir des garanties suffisantes et être lié par un contrat (article 28). Le traitement doit figurer au registre (article 30), et un transfert hors de l'Union européenne doit être encadré (articles 44 et suivants). Rien de cela n'existe pour un outil que personne n'a déclaré.
• NIS 2 : l'article 21 attend des entités qu'elles maîtrisent la sécurité de leur chaîne d'approvisionnement et la gestion de leurs actifs. En France, le recensement des systèmes d'information est le premier objectif du ReCyF, le référentiel de l'ANSSI.
• DORA : les entités financières doivent identifier leurs actifs informatiques (article 8) et tenir un registre d'information de tous les accords contractuels portant sur des services fournis par des prestataires tiers de services TIC (article 28). Un abonnement ouvert hors des achats y manque forcément.
• Souveraineté : un outil choisi sans évaluation peut héberger des données sensibles chez un fournisseur soumis à une loi étrangère ; voir notre article sur la souveraineté numérique.

Aucune source ne suffit seule. On croise en général :

• les journaux réseau (proxy, DNS, pare-feu), qui montrent les services en ligne réellement contactés depuis le réseau et les postes ; les outils de découverte des services cloud automatisent cette analyse ;
• les achats et les notes de frais, où apparaissent les abonnements payés par carte bancaire ;
• la gestion des terminaux et les scans réseau : le NCSC recommande de croiser l'inventaire avec ces outils, et de considérer comme shadow IT tout appareil qui se connecte au réseau sans appartenir à l'organisation ;
• la suite collaborative : les applications tierces auxquelles les utilisateurs ont accordé l'accès à leur messagerie ou à leurs documents ;
• les équipes elles-mêmes : une enquête simple, sans reproche, sur les outils qu'elles utilisent et pourquoi. C'est souvent la source la plus riche.

Le résultat alimente un inventaire des applications, rattaché à la cartographie du système d'information : qui utilise l'outil, pour quelles données, depuis quand, avec quel contrat.

1. Inventorier les outils découverts et les rattacher à un responsable métier.
2. Trier selon le risque : quelles données l'outil traite-t-il, et quelle serait la gravité de leur fuite ou de leur perte ? La méthode DICP aide à classer, et les cas sensibles relèvent d'une analyse de risques.
3. Décider outil par outil : autoriser tel quel ce qui ne touche pas de données sensibles ; encadrer ce qui est utile mais exposé (contrat, évaluation du fournisseur, configuration, comptes rattachés à l'authentification unique) ; remplacer par l'outil validé quand il existe ; interdire ce qui est dangereux, en expliquant pourquoi.
4. Ouvrir une voie rapide pour les nouveaux besoins. Le NCSC recommande des circuits rapides et contrôlés pour obtenir un service hors catalogue, et des processus pour ramener sous contrôle un service non autorisé, par exemple en migrant ses données vers une plateforme prise en charge. Une évaluation du fournisseur proportionnée à l'enjeu, appuyée sur un questionnaire de sécurité fournisseur, s'intègre à votre démarche de gestion des risques tiers.
5. Fixer la règle et l'expliquer : la charte informatique dit ce qu'on peut installer ou ouvrir, et la sensibilisation en donne les raisons.
6. Outiller sans tout verrouiller : authentification unique pour les services validés, blocage des catégories les plus risquées, contrôle d'accès au réseau fondé sur des certificats émis aux appareils (que le NCSC juge le plus efficace), et vérification de l'état des terminaux, qui rejoint la logique du zero trust.

Une condition traverse les six étapes : ne pas punir. Le NCSC le souligne, si l'on blâme ou sanctionne les salariés, leurs collègues hésiteront à signaler leurs propres pratiques, et le shadow IT redeviendra invisible.

Les outils d'intelligence artificielle générative ont donné au phénomène une nouvelle ampleur : ils sont gratuits ou presque, s'utilisent dans un navigateur et rendent un service immédiat. Le shadow AI ajoute deux risques propres : les données saisies dans les requêtes, qui peuvent être conservées par le fournisseur, et les agents qui agissent avec les droits de l'utilisateur sur sa messagerie ou ses documents. Le NCSC, dans sa publication sur les risques cachés du shadow AI, retient la même ligne que pour le shadow IT : chercher à réduire le risque plutôt que de prétendre l'éliminer.

La démarche est la même, avec un point d'attention réglementaire : un déployeur au sens de l'AI Act doit savoir quels systèmes d'IA il utilise pour remplir ses obligations, ce que détaille notre article sur les obligations des déployeurs.