En bref
Le Shadow IA — l’usage d’outils d’IA non validés par l’entreprise — n’est pas d’abord un problème de sécurité. C’est un révélateur : il expose une demande déjà prouvée, un cadre absent, une dépendance subie et, souvent, une erreur de posture de la DSI. Le bloquer ne règle rien ; il déplace le problème hors de vue.
Un salarié qui fait reformuler un mail client depuis son téléphone. Un manager qui colle un extrait de contrat dans un assistant grand public. Un dirigeant qui prépare sa réunion avec l’IA, sur son compte personnel. Rien de tout cela n’est nouveau : c’est du Shadow IT, cette vieille habitude de contourner les outils validés quand ils ne suffisent pas. Ce qui est nouveau, c’est l’accélérateur — il ne faut ni installation, ni budget, ni compétence particulière, et le gain est immédiat.
La réaction réflexe consiste à traiter le sujet comme un risque à contenir. C’est une erreur de lecture. Le Shadow IA ne crée pas les problèmes qu’il expose : il les rend visibles. Il révèle quatre choses, et aucune n’est technique.
Ce que disent les chiffres — et pourquoi ils se contredisent
Avant tout constat, une mise en garde. Les études sur le Shadow IA affichent des écarts spectaculaires : selon les sources, entre 31 % et plus de 90 % des salariés utiliseraient des outils d’IA non validés. Ces chiffres ne se contredisent pas vraiment — ils ne mesurent pas la même chose. Certains interrogent les salariés sur leurs déclarations, d’autres observent les flux réseau ; certains parlent d’usage occasionnel, d’autres de dépôt de données d’entreprise. Prendre le chiffre le plus spectaculaire pour argument, c’est déjà mal poser le problème.
Un constat, en revanche, mérite l’attention des dirigeants français. La France affiche l’un des taux de Shadow IA déclaré les plus bas au monde. Mais dans le même temps, une majorité d’entreprises françaises rapporte avoir connu un incident de sécurité lié à l’IA sur l’année écoulée, et une infime minorité de salariés dispose d’une charte ou d’un interlocuteur identifié sur le sujet. Peu de déclarations, beaucoup d’incidents, presque aucun cadre : la discrétion n’est pas de la conformité. Elle mesure surtout ce que les salariés osent dire.
Sources : Okta, AI Agents at Work 2026 · Microsoft / YouGov France, janvier 2026 · Observatoire de l’IA responsable, Impact AI · Gartner. Chiffres indicatifs, méthodologies non comparables entre elles.
Révélation 1 — une demande déjà prouvée
Dans la plupart des projets, la question qui tue est : « quel besoin réel adresse-t-on, et pour qui ? ». On lance des expérimentations en espérant qu’un usage émerge, et l’on découvre trop tard que personne n’attendait rien. Le Shadow IA, lui, présente la situation exactement inverse : l’usage existe avant la décision. Personne n’a eu besoin de convaincre qui que ce soit. La traction est là, massive, spontanée, et gratuite à observer.
C’est une information stratégique que la plupart des DSI laissent perdre. Chaque contournement désigne un cas d’usage à valeur immédiate. Traiter l’IA générative comme une exploration incertaine, avec pilote et critère d’arrêt, c’est se tromper de catégorie : ce n’est pas une innovation en quête d’usage, c’est un usage à industrialiser dont le besoin est déjà validé par le terrain.
Reste à comprendre d’où vient cette traction, et c’est moins réjouissant qu’il n’y paraît. Le Shadow IA n’est pas de l’enthousiasme technologique : c’est de la pression. On demande aux équipes de faire plus avec moins ; l’IA est devenue leur variable d’ajustement personnelle. Et le paradoxe mérite d’être connu : en essai contrôlé, les gains de productivité de l’IA générative sont réels et parfois spectaculaires (travaux de Noy et Zhang au MIT, étude BCG-Harvard) ; mais mesurés en conditions réelles, à l’échelle d’une organisation, les effets observés se réduisent à quelques points de pourcentage (Humlum et Vestergaard). L’écart ne vient pas de l’outil, il vient de l’organisation : le temps gagné n’est presque jamais réalloué. Autrement dit, des salariés s’épuisent en silence à courir après une productivité que l’entreprise ne récolte pas.
Révélation 2 — un cadre absent, et un cadre impossible
Face au constat, le réflexe est de dresser une liste d’outils autorisés. Cette approche est morte-née. Les organisations les plus avancées utilisent déjà plusieurs centaines d’outils intégrant de l’IA générative — et la plupart n’ont pas été achetés comme tels : l’IA s’est glissée dans la suite bureautique, le CRM, l’outil de visio, le correcteur orthographique. Une liste blanche d’outils est périmée le jour où on la publie.
Le cadre qui tient ne porte pas sur l’outil, il porte sur la donnée. La bonne question n’est pas « ai-je le droit d’utiliser cet assistant ? » mais « qu’ai-je le droit d’y mettre ? ». C’est un déplacement décisif : il produit une règle que chacun peut appliquer seul, sans attendre l’arbitrage de la DSI, et qui reste valable quel que soit l’outil du mois.
Ce déplacement n’est pas une opinion : c’est la position de l’ANSSI. Dans son guide Recommandations de sécurité pour un système d’IA générative (ANSSI-PA-102), l’agence consacre une section entière au cas le plus courant en entreprise — celui où l’on est simple client d’un service d’IA tiers. Sa recommandation R34 ne dit pas « n’utilisez pas l’IA générative ». Elle recommande de proscrire l’envoi de données sensibles vers des outils d’IA grand public sur Internet, et elle nomme précisément lesquelles : données personnelles, données contractuelles, juridiques ou financières de l’entreprise, secrets informatiques comme les mots de passe ou les clés d’API — sans parler des données relevant de la Diffusion Restreinte. L’interdiction porte sur la donnée, pas sur la technologie.
Le guide rappelle au passage une réalité que la plupart des utilisateurs ignorent : envoyer un texte, une image ou un document à un service d’IA grand public revient à le déposer sur un espace de stockage qui appartient à son éditeur. Le cloisonnement entre clients et la confidentialité ne sont pas maîtrisés par l’entreprise : ils reposent sur la seule confiance envers le prestataire, alors que dans la majorité des offres, les données envoyées servent aussi à optimiser les modèles.
Source : ANSSI, Recommandations de sécurité pour un système d’IA générative, ANSSI-PA-102, avril 2024 (section 5.7 et recommandation R34). Document publié sous Licence Ouverte v2.0.
| Sensibilité de la donnée | Exemples | Ce qu’on autorise |
|---|---|---|
| Publique | Contenus déjà publiés, documentation commerciale | Tout outil, y compris grand public |
| Interne | Notes, comptes rendus, supports sans secret ni donnée personnelle | Outils validés, avec compte d’entreprise |
| Confidentielle | Contrats, prévisions, code propriétaire, données clients, mots de passe et clés d’API | Uniquement des offres entreprise, avec garanties contractuelles |
| Personnelle ou réglementée | Données RH, santé, données nominatives, Diffusion Restreinte | Cadre juridique dédié — souvent exclusion pure et simple |
Un cadre par sensibilité suppose toutefois un préalable que beaucoup d’entreprises n’ont pas : savoir quelles données elles détiennent, où elles vivent, et lesquelles sont sensibles. Sans cartographie du SI, la règle reste une intention. Le Shadow IA, au fond, c’est la donnée qui sort de la carte — quand il y en a une.
Révélation 3 — une dépendance subie
Voilà le point le plus DSI de tous, et le moins évoqué. Le Shadow IA fabrique de la dépendance aux éditeurs par le bas : sans achat, sans contrat, sans mise en concurrence, sans la moindre évaluation. Les données et les manières de travailler s’installent chez des fournisseurs que personne n’a choisis. Le jour où l’entreprise décide enfin de consolider, elle ne découvre pas un outil à remplacer, mais des dizaines d’habitudes ancrées, des historiques de conversations partis ailleurs, et des équipes qui défendront « leur » outil.
C’est un renversement complet de la façon dont une DSI est censée engager son entreprise. Habituellement, on évalue, on négocie, on contractualise, puis on déploie. Ici, on déploie sans le savoir, et l’on négocie après — en position de faiblesse.
Cette dépendance a une face technique que peu regardent. Les outils d’IA se connectent aux applications métier — messagerie, espace documentaire, dépôts de code, visioconférence — et les droits qu’ils y obtiennent sont ceux positionnés par défaut à l’activation, rarement les plus restrictifs. L’ANSSI recommande d’ailleurs explicitement d’auditer ces droits dès l’activation du produit, puis de les revoir régulièrement : une simple mise à jour fonctionnelle peut élargir ce à quoi l’outil accède (recommandation R35 du guide cité plus haut). Autrement dit, même l’IA que vous avez choisie mérite qu’on vérifie ce qu’elle voit.
Le même angle mort touche les engagements extra-financiers. Un usage non cadré est un usage non mesurable : une entreprise soumise à un reporting de durabilité ne peut ni chiffrer, ni piloter, ni même constater l’empreinte d’outils dont elle ignore l’existence. Ce n’est pas un débat sur l’impact environnemental de l’IA — c’est un trou dans le périmètre de mesure.
Cette incapacité à voir n’est pas propre à l’IA : c’est un marqueur classique de maturité du SI. Le recours banalisé à des logiciels non validés, sans vision d’ensemble, figure depuis longtemps parmi les signaux faibles d’un SI subi plutôt que piloté. Le Shadow IA en est simplement la version accélérée. Dites-moi comment votre entreprise le traite, je vous dirai son niveau de maîtrise.
Révélation 4 — une erreur de posture
Reste la révélation la plus inconfortable, et elle concerne directement la DSI. Face au Shadow IA, la réponse spontanée est technique : bloquer les domaines, filtrer les flux, déployer du DLP, acheter une solution de détection. Cette réponse est compétente. Elle est aussi inopérante : l’usage bascule sur le téléphone personnel, et l’entreprise perd jusqu’à la visibilité qu’elle avait. Le blocage ne supprime pas le risque, il l’éloigne du radar.
Ce n’est pas un défaut de compétence, c’est un défaut de registre. Le sujet n’appelle pas la posture d’expert technique, celle qui traite un problème d’organisation avec des outils. Il appelle le stratège : monter au comité de direction, poser les termes de l’arbitrage, faire décider un cadre — et l’assumer collectivement. D’autant qu’un fait rend l’interdiction intenable : ce ne sont pas les juniors qui contournent le SI, ce sont largement les dirigeants eux-mêmes, qui utilisent l’IA depuis leurs comptes personnels. Interdire, c’est demander à sa direction de renoncer à ce qu’elle pratique déjà.
C’est aussi pour cela que le Shadow IA est un excellent test de la bascule d’une informatique technique vers une véritable DSI. Une informatique technique bloque. Une DSI arbitre. Et le simple fait qu’un usage massif se soit installé sans qu’elle en sache rien prouve, à lui seul, qu’elle n’était pas dans la boucle des décisions.
★ Mon retour d’expérience
Sur une mission d’accompagnement en PME industrielle, la direction avait bien fait les choses : plutôt que d’interdire, elle avait distribué des licences d’IA à plusieurs services. Le sujet semblait réglé. En regardant de près, la réalité était plus fine : les licences n’étaient pas du même niveau. Certaines relevaient d’offres grand public, où la protection des données doit être activée manuellement et où rien ne garantit contractuellement leur traitement ; d’autres relevaient d’offres entreprise, avec des engagements clairs. Personne ne le savait — ni les utilisateurs, ni ceux qui avaient acheté. Le cadre n’était pas absent : il était supposé. Distribuer des licences ne protège de rien si l’on ignore ce qu’elles couvrent.
💡 Le piège : croire que « payer » suffit
Un même éditeur propose souvent une offre grand public et une offre entreprise portant presque le même nom — avec des garanties de confidentialité radicalement différentes. Payer un abonnement ne fait pas d’un outil un outil d’entreprise. Avant d’autoriser quoi que ce soit sur une donnée sensible, vérifiez trois choses : ce que dit le contrat sur l’usage des données, si la protection est active par défaut ou à activer, et qui, chez vous, en porte la responsabilité.
Par où commencer
Trois gestes, dans cet ordre, suffisent à sortir du déni sans lancer un chantier de dix-huit mois. Observer d’abord : recenser les usages réels, sans sanction — c’est votre étude de marché, elle vous dit où est la valeur. Cadrer ensuite : une règle par sensibilité de donnée, tenant sur une page, compréhensible sans la DSI. Équiper enfin : fournir, pour les usages identifiés, des outils dont vous connaissez précisément le niveau de garanties. Dans cet ordre — car équiper avant d’observer, c’est acheter à l’aveugle, et cadrer avant d’observer, c’est légiférer sur ce qu’on ne connaît pas.
Questions fréquentes
Qu’est-ce que le Shadow IA ?
Le Shadow IA désigne l’usage d’outils d’intelligence artificielle par les salariés sans validation ni visibilité de l’entreprise — typiquement un assistant grand public utilisé depuis un compte personnel pour un travail professionnel. C’est le prolongement du Shadow IT, avec un accès immédiat et un gain perçu instantané.
Faut-il interdire l’IA générative en entreprise ?
L’interdiction déplace l’usage plutôt qu’elle ne le supprime : il bascule sur les équipements personnels, hors de toute visibilité. Elle est d’autant plus intenable que les dirigeants figurent parmi les premiers utilisateurs via leurs comptes personnels. Un cadre explicite protège mieux qu’une interdiction contournée.
Comment encadrer l’usage de l’IA sans liste d’outils autorisés ?
En cadrant par la sensibilité de la donnée plutôt que par l’outil : définir ce qu’on peut confier à un outil grand public, ce qui exige une offre entreprise avec garanties contractuelles, et ce qui ne sort pas. La règle reste valable quel que soit l’outil, et chacun peut l’appliquer seul.
Que dit l’ANSSI sur l’usage des IA génératives grand public ?
Dans son guide « Recommandations de sécurité pour un système d’IA générative » (ANSSI-PA-102, avril 2024), l’agence recommande de proscrire l’envoi de données sensibles vers des outils d’IA grand public sur Internet : données personnelles, contractuelles, juridiques ou financières, secrets informatiques comme les mots de passe et les clés d’API. Elle recommande aussi de revoir régulièrement les droits accordés à ces outils sur les applications métier. L’interdiction porte sur la donnée, pas sur la technologie.
Le Shadow IA est-il un problème de sécurité ou de gouvernance ?
Les deux, mais dans cet ordre : c’est d’abord un problème de gouvernance qui produit des conséquences de sécurité. Le traiter uniquement par des mesures techniques laisse intacte la cause — un usage réel qu’aucun cadre n’a jamais arbitré.
Envie de cadrer l’usage de l’IA sans l’interdire ?
Arnaud Benistant
Fondateur et président d’Askee, cabinet de conseil en management des systèmes d’information en Auvergne-Rhône-Alpes. Fort de 20 ans d’expérience en SI, il a notamment été DSI de l’Entrepôt du Bricolage (Groupe SAMSE) avant d’accompagner dirigeants et directions comme DSI de transition. Sa conviction : derrière chaque projet IT, c’est presque toujours une question d’humain.
