L’intelligence artificielle est là pour durer. Les gains de productivité, les avancées en matière d’innovation et les retombées économiques transforment tout simplement le fonctionnement des entreprises, dans toutes les équipes. Mais ces avantages s’accompagnent de risques majeurs pour les organisations qui adoptent l’IA. L’un des plus pressants est le recours à l’IA sans l’aval de l’organisation, aussi appelé « shadow AI ».
Le shadow AI désigne l’utilisation non autorisée d’outils d’IA par les employés, à l’insu ou sans l’approbation des équipes informatiques et de sécurité. Cette pratique s’impose rapidement comme une menace majeure pour la sécurité et la conformité, alors même qu’elle reste relativement nouvelle et continue d’évoluer.
“Si les pertes financières exactes liées à l’IA non autorisée sont encore en cours d’évaluation, les risques de préjudice sont clairs et ne cessent de croître.”
Le shadow AI est une ramification en plein essor du shadow IT, ce phénomène de longue date qui voit les employés déployer des logiciels, des services cloud ou des systèmes non approuvés au sein de l’entreprise. Alors que le shadow IT met déjà à rude épreuve la gouvernance et la sécurité, le shadow AI ajoute un nouveau degré de complexité dangereux. Les logiciels non approuvés placent les données hors du champ de visibilité des équipes informatiques ; les outils d’IA vont encore plus loin. Les modèles publics peuvent utiliser les données que leur fournissent les employés pour leur entraînement, rendant de fait irréversible toute divulgation d’informations propriétaires.
Quelques exemples d’IA non autorisée :
- Un ingénieur logiciel utilise un compte personnel ChatGPT, Gemini ou Copilot pour générer du code standard, traduire du code d’un langage à un autre, refactoriser du code existant ou rédiger des cas de test, et colle par inadvertance du code propriétaire dans un modèle public. Ce code pourrait être stocké, consigné dans des journaux ou exposé. Pire encore, le contenu généré par l’IA pourrait inclure une logique non sécurisée, des API fictives ou du code qui enfreint les conditions de licence.
- Un spécialiste de la communication téléverse une note stratégique confidentielle dans un outil d’IA pour en faire une synthèse ou rédiger un message destiné aux clients. Ce contenu appartenant à l’entreprise se retrouve désormais sur des serveurs tiers, hors du contrôle du service informatique.
- Un commercial installe une extension Chrome qui génère automatiquement des e-mails de prospection à l’aide de l’IA et se connecte à sa messagerie ainsi qu’à son CRM. Cela présente des risques de fuite de données, de violation des politiques internes et de non-conformité à des réglementations telles que le RGPD ou le California Consumer Privacy Act.
Ces exemples ne sont qu’un début. D’innombrables autres cas d’utilisation de l’IA non encadrée se produisent chaque jour dans tous les secteurs. Le phénomène est d’une telle ampleur que Gartner® prévoit que « d’ici 2027, 75 % des employés acquerront, modifieront ou créeront des technologies à l’insu de la direction informatique, contre 41 % en 2022. Par conséquent, les modèles opérationnels de cybersécurité descendants et fortement centralisés échoueront. Les RSSI doivent plutôt restructurer la cybersécurité pour en faire une fonction centralisée et allégée, qui accompagne un vaste réseau fédéré d’experts et d’équipes pluridisciplinaires intégrées dans toute l’entreprise. Cela permet de déployer la cybersécurité jusqu’aux périphéries de l’entreprise, au plus près des lieux où les décisions relatives aux technologies et aux risques sont prises et mises en œuvre. »1
Injection de prompt et fuite de données : les principales préoccupations
Si les pertes financières exactes liées à l’utilisation non encadrée de l’IA sont encore en cours d’évaluation, les risques sont manifestes et ne cessent de croître. Les organisations qui n’agissent pas dès maintenant s’exposent à des incidents graves, à des sanctions réglementaires et à une érosion de la confiance de leurs clients.
Parmi les vulnérabilités les plus préoccupantes figure l’injection de prompt : une attaque dans laquelle des instructions malveillantes, fournies directement par un attaquant ou dissimulées dans le contenu traité par l’IA, amènent le modèle à contourner les restrictions, à divulguer des données sensibles ou à effectuer des actions non prévues. Les modèles d’IA ont tendance à faire confiance par défaut aux données d’entrée, ce qui les rend vulnérables à ce type d’attaque. Une injection de prompt réussie pourrait ainsi pousser l’IA à révéler des données internes, à altérer des processus automatisés ou à compromettre des systèmes d’aide à la décision.
Une autre préoccupation majeure concerne les fuites de données, notamment les informations permettant d’identifier une personne (PII), les informations de santé protégées (PHI), les coordonnées bancaires et les données financières, le code source et les éléments de propriété intellectuelle exclusifs, les identifiants et les clés d’accès, ou encore les dossiers clients.
À cela s’ajoute le risque de non-conformité réglementaire. L’utilisation non autorisée de l’IA peut facilement enfreindre des réglementations et des normes telles que le RGPD, la loi HIPAA, la norme PCI DSS et la loi Sarbanes-Oxley, exposant ainsi les entreprises à des sanctions et à une atteinte à leur réputation.
Pourquoi les canaux chiffrés dissimulent l’utilisation non autorisée de l’IA
Si l’IA non autorisée est si difficile à contrôler, c’est notamment parce que ses échanges empruntent les mêmes voies que le trafic légitime : ils sont chiffrés. La quasi-totalité du trafic web transite désormais par des connexions TLS/SSL, et les outils d’IA ne font pas exception. Le chatbot ouvert dans un onglet du navigateur comme l’appel API effectué dans le cadre d’une automatisation passent tous deux par des sessions chiffrées.
Ce chiffrement protège la confidentialité, mais il crée aussi un angle mort pour les outils traditionnels de sécurité réseau. Un pare-feu qui ne peut pas inspecter les sessions chiffrées voit uniquement qu’un employé s’est connecté à un service d’IA. Il ne peut pas déterminer si cet employé a demandé une recommandation pour déjeuner ou s’il a collé une base de données clients dans un prompt. Les outils traditionnels de prévention des pertes de données se heurtent à la même limite : des informations sensibles quittent l’organisation au sein de sessions dont ils ne peuvent pas lire le contenu.
Il en résulte une faille dans la posture de sécurité de l’organisation. Les équipes de sécurité ne peuvent pas détecter de manière fiable les usages non autorisés de l’IA, et encore moins les empêcher. Pour combler cette faille, il faut disposer d’une visibilité sur le trafic chiffré lui-même et effectuer des inspections aux points où transitent réellement les prompts et les données, de manière sélective afin de préserver la confidentialité et les performances.
S’orienter dans le paysage réglementaire (règlement européen sur l’IA et coûts de mise en conformité)
Le cadre réglementaire se durcit lui aussi. Le règlement européen sur l’IA[he3.1] entre progressivement en application : les interdictions s’appliquent depuis début 2025, les obligations relatives aux modèles d’IA à usage général depuis août 2025, et d’autres dispositions, notamment les exigences de transparence, depuis août 2026. Les obligations concernant les systèmes d’IA à haut risque suivront en 2027 et 2028. Les sanctions pour les infractions les plus graves peuvent atteindre 35 millions d’euros ou 7 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. Un outil non validé qu’un salarié intègre à un processus métier est soumis aux mêmes règles, que l’on ait ou non conscience que la loi s’applique.
Aux États-Unis, le cadre de gestion des risques liés à l’IA du NIST s’impose comme la référence pour démontrer une gouvernance responsable de l’IA. Son adoption est volontaire, mais les auditeurs, les assureurs et les clients professionnels l’attendent de plus en plus. Après un incident, les autorités de régulation posent une question simple : l’organisation savait-elle quels outils d’IA étaient utilisés et en encadrait-elle l’usage ? Avec l’IA fantôme, la réponse honnête est non.
Les coûts sont quantifiables. Le rapport 2026 d’IBM sur le coût d’une violation de données révèle que l’utilisation non encadrée de l’IA était en cause dans 43 % des incidents de sécurité, contre 20 % un an auparavant. Ces violations ont coûté en moyenne 5,39 millions de dollars et environ une sur cinq a donné lieu à une amende réglementaire.
Certaines entreprises réagissent en imposant des interdictions, mais est-ce efficace ?
Face à ces risques, certaines organisations ont interdit à leurs employés d’utiliser des outils d’IA générative non approuvés. Samsung, par exemple, a été l’une des premières entreprises, en 2023, à interdire l’utilisation de ChatGPT et d’autres agents conversationnels similaires fondés sur l’IA, invoquant des craintes de fuites d’informations internes sensibles. Plusieurs banques et autres entreprises ont depuis adopté des restrictions ou émis des avertissements similaires.
Pourtant, les experts du secteur déconseillent très majoritairement les interdictions généralisées.
Pourquoi la gouvernance est préférable aux interdictions
Malgré les risques réels, les analystes du secteur recommandent des politiques préventives et des cadres de gouvernance plutôt que des interdictions pures et simples. La plupart des organisations n’en sont pas encore là. Selon l’étude menée par IBM en 2026[he5.1], 68 % des organisations victimes d’une violation de données ne disposaient pas de cadre de gouvernance de l’IA pour encadrer son utilisation ou détecter les usages non autorisés. Même parmi les organisations ayant mis en place des politiques de gouvernance, seules 29 % effectuaient régulièrement des audits pour repérer les usages non autorisés de l’IA.
Les interdictions ont tendance à être contre-productives. Difficiles à faire respecter, elles freinent souvent l’innovation et nuisent au moral des équipes. Elles peuvent aussi rendre l’utilisation de l’IA encore plus clandestine, compliquant davantage sa détection et son contrôle par les équipes de sécurité.
Comme l’a déclaré un responsable informatique lors d’une discussion au sein de la Gartner Peer Community sur l’interdiction des outils d’IA : « Les interdictions ne fonctionnent tout simplement pas. Même en l’absence de règles, cette mesure nuit à l’innovation et envoie un mauvais signal au personnel et au reste du monde sur notre organisation. »
Ce que les organisations devraient faire à la place
Voici quelques mesures concrètes de gouvernance que les organisations peuvent prendre dès maintenant :
- Établir une politique claire d’utilisation de l’IA
Définissez les outils autorisés, les modalités de gestion des données, les cas d’usage acceptables et les garde-fous en place. Indiquez très clairement ce qui est permis, et pourquoi. - Tenir à jour une liste d’outils d’IA validés
Évaluez les outils en matière de confidentialité des données, de sécurité et de conformité réglementaire. Encouragez les employés à les utiliser plutôt que des plateformes non validées. Par exemple, utilisez des versions professionnelles d’outils tels que ChatGPT, dotées de fonctionnalités de journalisation et de protection contre la perte de données, et adoptez des assistants d’IA internes intégrés aux plateformes de l’entreprise. - Former les employés et les sensibiliser
Aidez le personnel à comprendre les risques, des fuites de données aux manquements aux obligations de conformité, en passant par les contenus inventés par l’IA. La plupart des usages inappropriés sont involontaires. - Surveillez, puis adaptez-vous
Envisagez de mettre en place une surveillance respectueuse de l’éthique et de la législation pour détecter les usages non autorisés. Privilégiez la sensibilisation plutôt que la sanction. Faites évoluer vos politiques en permanence à mesure que les capacités de l’IA progressent.
Comment F5 sécurise les charges de travail d’IA et atténue les risques liés à l’IA non autorisée
La technologie peut-elle offrir une solution évolutive ? Absolument.
F5 AI Gateway s’intercale entre vos utilisateurs, vos agents et les services d’IA sur lesquels ils s’appuient. Il assure la détection et la prévention des fuites de données pour chaque requête et chaque réponse qui le traversent, en bloquant les données sensibles (code source, identifiants, informations clients) avant qu’elles n’atteignent un modèle externe. Associée aux solutions de visibilité sur le trafic chiffré de F5, qui peuvent diriger le trafic destiné à l’IA vers la passerelle pour inspection, cette protection s’étend aux outils d’IA non autorisés qui se dissimulent dans les canaux chiffrés (utilisés par défaut par la plupart des API d’IA et des plateformes SaaS).
AI Gateway répond également aux nouvelles formes d’IA non autorisée : des agents, des plugins et des serveurs MCP non validés qui fonctionnent au sein d’outils approuvés. Il contrôle les modèles et les outils auxquels les utilisateurs et les agents peuvent accéder, et conserve une piste d’audit complète de chaque interaction. Associé aux mesures de gouvernance décrites ci-dessus, il permet de rendre une politique d’utilisation de l’IA concrètement applicable.
Questions fréquentes
Quelle est la différence entre le shadow IT et le shadow AI ?
Le shadow IT désigne toute technologie utilisée par les employés sans l’approbation du service informatique, des applications non autorisées aux espaces de stockage cloud personnels. Le shadow AI en est la branche qui connaît la croissance la plus rapide : il s’agit de l’utilisation non autorisée d’outils d’IA. La différence essentielle réside dans ce qu’il advient des données. Le shadow IT classique place les données hors du champ de visibilité du service informatique ; les outils d’IA peuvent également ingérer des données dans le cadre des requêtes et de leur entraînement, rendant leur exposition pratiquement irréversible.
Comment les équipes informatiques détectent-elles l’utilisation non autorisée d’outils d’IA dans le trafic chiffré ?
Les équipes informatiques détectent les usages non autorisés de l’IA dans le trafic chiffré en obtenant une visibilité sur ce trafic. En pratique, cela consiste à déchiffrer et à inspecter de manière sélective les sessions TLS aux points de passage stratégiques du réseau, à surveiller les connexions aux services d’IA connus et à appliquer des mesures de prévention des pertes de données aux requêtes en transit. Sans cette visibilité, les équipes de sécurité peuvent constater qu’un employé s’est connecté à un service d’IA, mais pas quelles données ont été partagées. Quant aux fonctionnalités d’IA intégrées à d’autres applications SaaS, elles peuvent passer totalement inaperçues.
Pourquoi les interdictions généralisées de l’IA sont-elles inefficaces ?
Les interdictions générales de l’IA sont souvent inefficaces, car elles suffisent rarement à mettre fin aux pratiques. Les employés qui constatent de réels gains de productivité continuent à utiliser l’IA sur leurs appareils et comptes personnels, sur lesquels les équipes de sécurité n’ont aucune visibilité. Une gouvernance fondée sur des outils approuvés permet de maintenir l’utilisation de l’IA dans un cadre où elle peut être suivie et encadrée.
Comment F5 AI Gateway empêche-t-il les fuites de données dans le contenu des prompts ?
F5 AI Gateway empêche les fuites de données dans le contenu des prompts en inspectant les prompts et les réponses en temps réel, en repérant les données sensibles qu’ils contiennent (une clé d’accès, une fiche client, un bloc de code propriétaire), puis en les bloquant ou en les masquant avant qu’elles ne parviennent à un modèle externe. Des règles de contrôle définissent également, en amont, les modèles et outils d’IA auxquels les utilisateurs et les agents peuvent accéder.
GARTNER est une marque déposée et une marque de service de Gartner, Inc. et/ou de ses sociétés affiliées aux États-Unis et à l’international, et est utilisée ici avec leur autorisation. Tous droits réservés.
1Gartner, Maverick Research : Les RSSI doivent transformer leur rôle sous peine de devenir obsolètes, 19 juin 2025
À propos de l’auteur
Articles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.