L’essentiel en 30 secondes
- Le shadow IT passe d’abord par le navigateur : service non validé, formulaire web, copier-coller ou extension suffisent à faire sortir une donnée sans alerte DLP.
- Aucun contrôle ne couvre seul ces quatre chemins ; exclusions TLS et règles pensées pour des fichiers créent les angles morts.
- Il faut cartographier les usages, puis rejouer des sorties factices et noter ce qui est bloqué, alerté ou ignoré.
Le shadow IT désigne les applications, comptes et services utilisés en entreprise sans validation de la DSI. Côté fuite de données, son principal vecteur est le navigateur : un formulaire web, un copier-coller dans un outil en ligne ou une extension installée en deux clics suffisent à faire sortir une information sensible sans qu’aucune règle DLP ne se déclenche. Pour réduire ce risque, il faut découvrir ces usages, puis tester activement si vos contrôles voient réellement ces chemins.
Pourquoi le navigateur est devenu le premier canal du shadow IT
Il y a quinze ans, le shadow IT, c’était un logiciel installé sur un poste ou un serveur caché sous un bureau. Aujourd’hui, presque tout passe par un onglet. Convertisseur PDF, outil de traduction, tableau partagé, service de transfert de fichiers, assistant d’écriture : aucune installation, aucun droit d’administrateur, aucune demande à la DSI.
Le problème n’est pas la mauvaise foi des utilisateurs. Ils veulent aller vite. Le problème, c’est que la plupart des dispositifs DLP ont été conçus autour de canaux connus : messagerie, périphériques USB, partages réseau, quelques applications SaaS sanctionnées. Le navigateur, lui, ouvre une infinité de destinations, chiffrées, souvent hébergées sur des infrastructures cloud parfaitement légitimes.
Les quatre chemins d’exfiltration que vous ne voyez pas
Schéma · quatre chemins de sortie
1. Les applications non validées
Un compte personnel sur un service de stockage, un outil de gestion de projet grand public, une plateforme de signature électronique choisie par un service métier. Chacun est une destination de sortie. Si votre CASB ou votre proxy ne connaît pas l’application, ou la classe dans une catégorie autorisée (« productivité », « hébergement »), le flux passe. Le sujet des outils collaboratifs du quotidien est détaillé dans notre article sur le cloud personnel, Teams et Slack.
2. Les formulaires web
C’est le chemin le plus sous-estimé. Un champ de texte dans un formulaire de contact, de support, de ticket ou d’enquête accepte souvent plusieurs milliers de caractères. Un utilisateur qui colle un extrait de base clients dans un formulaire de demande de devis chez un fournisseur ne fait pas de « téléversement de fichier ». Beaucoup de politiques ne surveillent que les pièces jointes et les envois de fichiers. Le texte saisi dans une requête HTTPS reste alors invisible si l’inspection n’analyse pas le contenu des formulaires.
3. Le copier-coller
Copier un tableau depuis un document interne, le coller dans un outil en ligne : c’est le geste de base de l’IA générative, des traducteurs automatiques et des outils de mise en forme. Certains agents DLP endpoint contrôlent le presse-papiers, d’autres non, et beaucoup ne le font que pour certaines applications de destination. Le cas spécifique des assistants conversationnels est traité dans IA générative et fuite de données.
4. Les extensions de navigateur
Une extension de correction orthographique, de capture d’écran ou de prise de notes peut lire le contenu des pages visitées, y compris des applications internes. Les données partent alors depuis le processus du navigateur, vers les serveurs de l’éditeur de l’extension, sans action consciente de l’utilisateur. C’est le chemin le plus silencieux des quatre : il n’y a même pas de geste humain à détecter.
Ce que chaque contrôle voit (et ne voit pas)
Aucun outil ne couvre seul ces quatre chemins. Le tableau ci-dessous donne une lecture qualitative des angles morts fréquents. Il dépend évidemment de vos produits et de leur configuration : c’est précisément ce qu’il faut vérifier par le test.
| Chemin | DLP endpoint | Proxy / passerelle web | CASB | Angle mort typique |
|---|---|---|---|---|
| Application non validée | Partiel | Selon catégorisation | Si l’application est connue | Service récent ou mal catégorisé |
| Formulaire web | Rarement | Si inspection TLS et analyse du corps | Rarement hors SaaS sanctionnés | Texte saisi plutôt que fichier |
| Copier-coller | Si contrôle du presse-papiers activé | Indirectement, à l’envoi | Non | Navigateur exclu de la règle |
| Extension | Rarement | Si le domaine de l’éditeur est filtré | Non | Flux émis sans action utilisateur |
Deux points reviennent souvent : les exclusions d’inspection TLS (posées pour des raisons de performance ou de confidentialité) et les règles écrites pour des fichiers alors que la donnée sort sous forme de texte. Sur le premier sujet, voir les angles morts de l’inspection TLS.
Découvrir le shadow IT avant de le tester
On ne teste bien que ce qu’on a cartographié. La découverte n’a pas besoin d’être parfaite, elle doit être suffisante pour choisir des scénarios réalistes.
- Journaux du proxy et du DNS : listez les domaines les plus contactés hors applications sanctionnées, en particulier ceux qui reçoivent des volumes montants (POST) importants.
- Inventaire des extensions : la plupart des navigateurs gérés permettent d’exporter la liste des extensions installées. Repérez celles qui demandent l’accès à toutes les pages.
- Découverte CASB : si vous avez un CASB, son module de découverte donne une première liste d’applications non validées.
- Entretiens métiers : demandez aux équipes quels outils en ligne elles utilisent « pour dépanner ». Vous apprendrez plus en une heure qu’avec bien des rapports.
- Notes de frais et cartes d’achat : les abonnements payés hors achats informatiques révèlent souvent des applications SaaS non référencées.
Scénario concret : le service RH et le convertisseur en ligne
Une chargée RH doit transmettre un tableau de rémunérations au format PDF. Le logiciel installé ne fait pas l’export voulu. Elle cherche « convertir Excel en PDF », tombe sur un service en ligne, téléverse le fichier, récupère le PDF. Trente secondes.
Ce que votre DLP aurait dû faire : reconnaître un fichier classé confidentiel, identifier une destination non autorisée, bloquer ou au moins alerter. Ce qui se passe souvent : le domaine du convertisseur est catégorisé « outils en ligne », autorisé ; la règle DLP endpoint ne surveille que la messagerie et l’USB ; l’étiquette de classification n’est pas posée sur ce fichier. Personne ne le saura, sauf si vous rejouez ce scénario vous-même. L’importance de l’étiquetage est développée dans pourquoi la DLP dépend de la classification des données.
Et chez vous ?
Vos contrôles voient-ils les chemins du navigateur ?
Une démo guidée de 30 minutes, sur des jeux de résultats préétablis, pour voir comment une campagne restitue ce qui sort par chaque chemin de sortie.
Plan de test : les chemins du navigateur
Le principe est celui du test d’exfiltration de données : rejouer des sorties réalistes avec des données factices, depuis un poste de production représentatif, et constater ce qui est bloqué, alerté ou ignoré.
- Préparez des leurres réalistes : faux numéros de sécurité sociale au bon format, faux IBAN, faux extraits de contrats, fichiers étiquetés confidentiels.
- Téléversez un fichier leurre vers une application non validée, puis vers une application sanctionnée mais avec un compte personnel.
- Collez un extrait leurre dans un champ de formulaire web, sans fichier joint.
- Copiez un contenu leurre depuis une application interne et collez-le dans un outil en ligne, dans chacun des navigateurs autorisés.
- Vérifiez le comportement avec et sans inspection TLS sur la destination, notamment pour les domaines exclus.
- Contrôlez ce qu’une extension autorisée peut lire sur une page interne contenant des leurres (inventaire des permissions plutôt que tentative de contournement).
- Pour chaque scénario, notez trois résultats distincts : bloqué, alerté (et l’alerte est-elle arrivée au SOC ?), ignoré.
- Rejouez après chaque changement : nouvelle version du navigateur, nouvelle règle, nouvelle exclusion. Un résultat vrai en janvier ne l’est plus forcément en mars.
Que faire des constats ?
Bloquer tout le shadow IT est illusoire, et souvent contre-productif : les usages se déplacent vers des outils encore moins visibles. L’approche réaliste consiste à proposer une alternative validée pour les besoins récurrents (conversion, traduction, transfert), à restreindre les extensions par liste d’autorisation, à étendre les règles DLP au texte saisi et au presse-papiers sur les navigateurs, et à hiérarchiser selon la sensibilité des données réellement exposées. Un constat sur des données de santé ne se traite pas au même rythme qu’un constat sur des plaquettes commerciales.
FAQ
Le shadow IT est-il forcément une fuite de données ?
Non. C’est un risque, pas un incident. Il devient une fuite quand des données sensibles sortent vers une destination que l’entreprise ne maîtrise pas, sans contrat ni garanties sur leur traitement.
Faut-il bloquer toutes les extensions de navigateur ?
Une liste d’autorisation est plus tenable qu’un blocage total. Autorisez les extensions utiles après revue de leurs permissions, et refusez par défaut celles qui demandent l’accès à toutes les pages.
Un CASB suffit-il à couvrir le shadow IT ?
Il aide beaucoup pour la découverte et les applications connues. Il couvre mal les formulaires web génériques, le copier-coller et les extensions. Seul un test permet de savoir où s’arrête sa couverture dans votre environnement.
Peut-on tester ces chemins sans exposer de vraies données ?
Oui, c’est même indispensable : des données factices au bon format déclenchent les mêmes règles que des données réelles, sans exposer de donnée réelle si elles sortent.