---
title: Bases de la sécurité de l’IA : ce qui déraille vraiment et comment l’éviter
description: Un guide pratique des risques de sécurité liés à l’IA pour les équipes métier. Fuite de données, injection de prompts, évaluation des fournisseurs, et vraies différences entre sécurité personnelle et sécurité en entreprise.
date: February 5, 2026
author: Robert Soares
category: ai-strategy
---

En avril 2023, des ingénieurs de Samsung ont fait ce que des milliers d’employés font tous les jours. Ils ont collé du code dans ChatGPT. L’un déboguait un bug. Un autre a transcrit une réunion et l’a donnée à l’IA pour obtenir des notes de synthèse. Un troisième optimisait une séquence de test.

Quelques semaines plus tard, Samsung a interdit ChatGPT dans toute l’entreprise.

Le code contenait des informations propriétaires sur des semi-conducteurs. Une fois soumis, il est devenu une partie des données d’entraînement d’OpenAI. Samsung n’a pas pu le récupérer. Les dégâts étaient permanents, invisibles et entièrement évitables.

Cet incident résume tout ce qui rend la sécurité de l’IA compliquée. L’outil a fonctionné exactement comme prévu. Les employés l’ont utilisé pour résoudre de vrais problèmes. Personne ne voulait nuire. Pourtant, des données sensibles ont quitté l’entreprise et ne pourront jamais revenir.

## À quoi ressemble vraiment l’exposition des données

La fuite chez Samsung est célèbre parce qu’elle concerne un grand groupe. Mais une étude de fin 2025 a montré que 34,8 % de toutes les saisies d’employés dans ChatGPT contiennent des données sensibles. Plus d’un tiers de chaque requête. Ce n’est pas un cas limite. C’est la norme.

L’IA de l’ombre alimente une grande partie de cette exposition. Quand l’informatique ne fournit pas d’outils IA approuvés, les employés trouvent les leurs. Une enquête récente a révélé que plus de 60 % des salariés s’appuient sur des outils d’IA personnels, non gérés, plutôt que sur des alternatives approuvées par l’entreprise. Ces outils fonctionnent en dehors de la surveillance de l’organisation. Pas de journaux. Pas de contrôle. Pas de prévention des fuites de données.

Les données qui fuient suivent des schémas prévisibles :

**Code source et fichiers de configuration.** Les développeurs collent du code pour obtenir de l’aide au débogage. Ces fichiers contiennent souvent des clés d’API, des identifiants de bases de données et des détails internes sur les systèmes.

**Informations clients.** Les équipes support résument des tickets. Les commerciaux analysent des données d’un prospect. Le marketing génère du contenu personnalisé. Tout cela peut contenir des noms, des e-mails, des historiques d’achat ou des informations financières.

**Communications internes.** Des transcriptions de réunions, des messages Slack et des fils d’e-mail sont donnés à l’IA pour en faire des résumés. Ces conversations révèlent la stratégie, des sujets RH et des renseignements concurrentiels.

**Données financières.** Des tableurs, des prévisions et des enregistrements de transactions sont analysés par des outils d’IA qui n’ont jamais été validés pour la conformité.

La plupart des employés n’ont aucune idée que c’est risqué. Ils voient un outil utile, pas un vecteur d’exfiltration de données. C’est dans cet écart de perception que les programmes de sécurité échouent.

## Injection de prompts : le vecteur d’attaque auquel personne n’était préparé

La sécurité traditionnelle se concentre sur les périmètres réseau et les contrôles d’accès. L’IA introduit quelque chose de différent. Les attaques par injection de prompts manipulent les systèmes d’IA en dissimulant des instructions dans les données qu’ils traitent.

L’attaque fonctionne parce que l’IA ne peut pas distinguer de manière fiable des instructions légitimes de consignes malveillantes intégrées au contenu. Un attaquant insère du texte caché dans un document, un site web ou un e-mail. Quand l’IA traite ce contenu, elle exécute les instructions de l’attaquant à la place de celles de l’utilisateur, ou en plus.

Security researcher simonw, writing on [Hacker News](https://news.ycombinator.com/item?id=35572290), identified the core problem: "for a security issue like this we need a 100 % reliable solution, or people WILL figure out how to exploit it."

Cette solution fiable n’existe pas encore.

Dans la même discussion, l’utilisateur bawolff a formulé le problème d’architecture sans détour : "Black box we don't really understand executing shell scripts in response to untrusted user input."

Quand vous connectez une IA à des outils capables d’envoyer des e-mails, de modifier des bases de données ou d’accéder à des systèmes de fichiers, vous donnez ces capacités à quiconque peut influencer ce que l’IA lit. Un PDF malveillant, une page web compromise, même un e-mail soigneusement rédigé dans la boîte de réception de quelqu’un. Tout devient un vecteur d’attaque potentiel.

De vrais exploits sont déjà apparus. Des chercheurs ont démontré une injection de prompts contre Bing Chat quelques semaines après son lancement. Des GitHub Actions utilisant des agents IA se sont révélées vulnérables à des attaques cachées dans des descriptions de pull request. Les serveurs MCP (Model Context Protocol), qui étendent les capacités des IA, ont montré des vulnérabilités critiques dans environ 10 % des implémentations analysées.

User noodletheworld captured the current state on [Hacker News](https://news.ycombinator.com/item?id=43632112): "there is no solution currently, other than only use trusted sources...this idea of arbitrary content going into your prompt...can't be safe. It's flat out impossible."

Ce n’est pas de l’alarmisme. C’est une évaluation technique exacte. Les architectures d’IA actuelles n’ont pas la capacité d’imposer des frontières strictes entre instructions et données. Tant que cela ne change pas en profondeur, tout système d’IA ayant accès à du contenu non fiable et à des outils puissants représente un risque de sécurité.

## Évaluer la sécurité des fournisseurs d’IA

Tous les services d’IA ne présentent pas le même niveau de risque. La différence entre les offres grand public et les offres entreprise est importante, mais le marketing brouille souvent les distinctions réelles.

Commencez par les politiques de données d’entraînement. Par défaut, OpenAI utilise les conversations de ChatGPT gratuit pour améliorer ses modèles. Son offre entreprise, explicitement non. "By default, we do not use your business data for training our models," states their [enterprise privacy documentation](https://openai.com/enterprise-privacy/). Les autres fournisseurs varient. Exigez toujours une confirmation écrite.

Le chiffrement compte, mais les détails comptent encore plus. Recherchez un chiffrement AES-256 au repos et TLS 1.2+ en transit. Plus important encore : comprenez qui détient les clés. Le chiffrement géré par le fournisseur est standard. Des clés gérées par le client offrent plus de contrôle, mais augmentent la complexité opérationnelle.

La résidence des données devient critique pour les secteurs réglementés. Où vos données sont-elles stockées ? Peuvent-elles franchir des frontières ? Le RGPD impose une protection adéquate pour les données quittant l’UE. La santé et les services financiers font face à des restrictions géographiques supplémentaires.

Examinez soigneusement les politiques de conservation. Combien de temps le fournisseur conserve-t-il vos prompts et ses réponses ? Pouvez-vous les supprimer ? Que devient l’historique des conversations quand vous fermez un compte ? Certains fournisseurs conservent les données indéfiniment pour de la « recherche de sûreté ». Cela peut entrer en conflit avec vos exigences de minimisation des données.

Les intégrations tierces multiplient le risque. La fuite de novembre 2025 ayant touché des utilisateurs d’OpenAI est passée par Mixpanel, un prestataire d’analytique tiers. L’incident a exposé des noms d’utilisateurs, des adresses e-mail et des données d’usage. Votre sécurité n’est jamais plus solide que le partenaire d’intégration le plus faible de votre fournisseur.

Les droits d’audit et les certifications de conformité apportent une assurance partielle. Les rapports SOC 2 Type II, la certification ISO 27001 et les attestations de conformité au RGPD indiquent des pratiques de sécurité de base. Ils ne garantissent pas que ces pratiques fonctionnent. Demandez les rapports eux-mêmes, pas seulement les arguments marketing.

## Sécurité personnelle vs sécurité en entreprise : les vraies différences

L’écart entre les niveaux grand public et entreprise compte plus que la plupart des gens ne le pensent.

Les offres grand public (gratuites ou abonnements à bas coût) :

- Utilisent vos conversations pour l’entraînement du modèle, sauf si vous refusez explicitement
- Stockent l’historique des conversations indéfiniment
- N’offrent aucune option d’authentification d’entreprise
- Manquent de contrôles d’administration et de journaux d’audit
- Offrent peu ou pas de certifications de conformité
- Font transiter les données via une infrastructure partagée, sans isolation

Les offres entreprise :

- Excluent par défaut les données de l’entreprise de l’entraînement du modèle
- Proposent une conservation configurable des données avec des capacités de suppression
- Prennent en charge le SSO, SCIM et la gestion d’identité d’entreprise
- Incluent des tableaux de bord d’administration, des analyses d’usage et des journaux d’audit
- Maintiennent des certifications de conformité (SOC 2, ISO 27001, HIPAA BAA le cas échéant)
- Offrent une infrastructure dédiée ou une isolation logique

La différence concrète apparaît dans la responsabilité. Quand un employé colle des données clients dans ChatGPT gratuit et que ces données influencent de futures sorties du modèle, votre exposition juridique est importante. Les mêmes données soumises via une offre entreprise correctement configurée restent isolées, journalisées et supprimables.

Le coût suit les capacités. Les abonnements IA entreprise vont de 20 à 60 $ par utilisateur et par mois pour les niveaux de base. Des fonctionnalités avancées comme des instances dédiées, des modèles personnalisés ou des contrôles de conformité renforcés font monter les prix. Comparez ce coût aux amendes réglementaires et aux dépenses de réponse à un incident que vous évitez.

## Mettre en place des contrôles de sécurité pratiques

Les politiques, à elles seules, n’empêchent pas les fuites de données. Samsung avait des politiques. Et des ingénieurs sous pression, avec des délais, utilisant l’outil le plus rapide disponible.

Les contrôles techniques créent une friction que les politiques ne peuvent pas créer.

**Déployer proactivement des outils IA entreprise.** Si vous ne fournissez pas d’alternatives approuvées, les employés en trouveront de non approuvées. Le problème de l’IA de l’ombre est fondamentalement un problème d’offre. Résolvez-le en offrant une meilleure alternative.

**Mettre en place une DLP pour les usages IA.** Les outils de prévention des fuites de données peuvent surveiller et bloquer du contenu sensible avant qu’il n’atteigne des services d’IA. Les solutions DLP modernes reconnaissent le trafic des principaux outils IA et peuvent appliquer des politiques spécifiques.

**Utiliser l’isolation du navigateur pour l’accès aux outils IA.** Des solutions de navigateur d’entreprise peuvent faire passer l’accès aux outils IA par des environnements contrôlés où les données de l’entreprise ne peuvent pas atteindre le presse-papiers.

**Privilégier les listes d’autorisation aux listes de blocage.** Bloquer ChatGPT par domaine est trivial à contourner. Approuver des outils IA spécifiques, avec la bonne configuration, est plus défendable.

**Tout journaliser.** Les offres IA entreprise fournissent des journaux d’usage. Collectez-les. Intégrez-les à votre SIEM. Établissez des baselines. Enquêtez sur les anomalies.

**Former spécifiquement aux risques IA.** Une sensibilisation générique ne couvre pas les risques uniques des outils d’IA. Montrez aux employés à quoi ressemble l’exposition de données. Démontrez l’injection de prompts. Rendez les risques concrets.

**Définir des procédures de réponse aux incidents pour l’exposition IA.** Si des données sensibles atteignent un outil IA, quelle est votre réponse ? Qui enquête ? Que signale-t-on ? Définissez cela avant d’en avoir besoin.

## Les limites des solutions actuelles

Une évaluation honnête implique de reconnaître ce que nous ne pouvons pas encore résoudre.

L’injection de prompts n’a pas de solution complète. Les mesures d’atténuation aident. Une architecture prudente aide davantage. Mais comme l’a noté l’utilisateur TeMPOraL sur [Hacker News](https://news.ycombinator.com/item?id=43632112) : "Prompt injection, being equivalent to social engineering, will always be a problem." L’architecture fondamentale des modèles de langage actuels rend une séparation fiable entre instructions et données extrêmement difficile.

La vérification des sorties de l’IA reste largement manuelle. Quand l’IA génère du code, des contrats ou des communications clients, des humains doivent vérifier l’exactitude et la pertinence. L’automatisation de cette vérification est, au mieux, balbutiante.

Le retrait de données d’un modèle entraîné est impraticable. Si vos données ont contribué à l’entraînement, les extraire complètement peut être techniquement impossible. Le code des ingénieurs de Samsung influencera indéfiniment le comportement du modèle.

Les cadres de conformité sont en retard sur la technologie. Le RGPD n’a pas été écrit en pensant aux grands modèles de langage. Pas plus qu’HIPAA. Les régulateurs rattrapent leur retard, mais l’ambiguïté persiste. Des « mesures de sécurité raisonnables » dans un règlement de 2016 ne signifiaient pas la même chose qu’aujourd’hui.

## Ce que cela implique pour la suite

Les équipes de sécurité font face à un vrai dilemme. Les outils d’IA apportent des gains de productivité légitimes. Les bloquer totalement pousse les employés vers des alternatives non contrôlées. Les autoriser sans contrôles crée une exposition des données. Aucun extrême ne fonctionne.

La voie pragmatique passe par une adoption contrôlée. Fournissez des outils IA sécurisés. Configurez-les correctement. Surveillez leur usage. Formez les employés aux risques. Acceptez qu’un risque résiduel subsiste.

Surveillez le paysage réglementaire. Les échéances de conformité de l’AI Act de l’UE approchent. Les nouvelles règles californiennes sur la prise de décision automatisée sont entrées en vigueur en 2026. D’autres juridictions suivront. Les programmes de sécurité qui intègrent dès maintenant des exigences spécifiques à l’IA s’adapteront plus facilement à mesure que les exigences évolueront.

Créez des relations avec vos fournisseurs d’IA. La sécurité n’est pas une fonctionnalité qu’on achète une fois. C’est une conversation continue sur les configurations, les politiques et la réponse aux incidents. Les fournisseurs qui refusent d’entrer dans les détails de sécurité ne peuvent probablement pas offrir une protection de niveau entreprise.

Les organisations qui s’en sortiront bien ne seront pas celles qui ont évité l’IA. Ce seront celles qui l’auront intégrée de manière délibérée, avec des politiques claires, des contrôles appropriés et une reconnaissance honnête de ce qu’elles pouvaient et ne pouvaient pas prévenir.

Cette reconnaissance est peut-être la partie la plus difficile. Nous sommes habitués à des problèmes de sécurité avec des solutions. Correctifs. Configurations. Formation. Le paysage de la sécurité de l’IA inclut des risques sans solution actuelle. Vivre avec cette incertitude tout en avançant exige une autre façon de penser la sécurité.

C’est peut-être le véritable changement. Pas seulement de nouveaux outils nécessitant de nouvelles politiques, mais de nouvelles catégories de risques nécessitant une nouvelle capacité à être à l’aise avec l’ambiguïté.