API d'IA et fuites de données : sécuriser vos prompts et flux d'entreprise

Amazon promet, noir sur blanc, qu'Amazon Bedrock « ne stocke ni n'utilise jamais vos données pour entraîner des modèles » (citation reprise et sourcée plus loin). Rien n'empêche pourtant un salarié de la même entreprise cliente de coller le même document confidentiel dans l'interface grand public gratuite d'un tout autre éditeur, dont les conditions d'utilisation générales autorisent la réutilisation des conversations. Ce n'est pas une contradiction entre fournisseurs : ce sont deux contrats différents, avec des garanties opposées, selon la porte d'entrée utilisée. La plupart des dirigeants de PME qui intègrent une IA à leurs outils métier ne connaissent pas cette distinction — et c'est précisément elle qui détermine si un devis, un contrat ou une fiche client transmis à un modèle reste confidentiel ou non.

Cet article est informatif : il ne constitue pas un conseil juridique. Pratiques et offres constatées début septembre 2026, susceptibles d'évoluer selon les fournisseurs.

À retenir

• La confidentialité d'une donnée envoyée à une IA dépend du contrat signé avec le fournisseur, pas du modèle utilisé : une offre API d'entreprise et l'interface grand public du même éditeur n'offrent pas les mêmes garanties.
• 40 % des fichiers téléchargés dans des outils d'IA non sécurisés contiennent des données personnelles ou sensibles, et 45 % des salariés utilisent déjà un outil d'IA générative (LayerX, rapport 2025 sur la sécurité des données IA et SaaS en entreprise).
• Trois garde-fous se cumulent : un contrat de sous-traitance qui exclut l'entraînement sur vos données, une architecture d'hébergement adaptée (UE quand c'est possible), et un filtrage automatisé des données sensibles avant leur envoi au modèle.
• La CNIL exige un contrat de sous-traitance dès qu'une API d'IA traite des données personnelles, quel que soit la taille de l'entreprise utilisatrice.

Interface grand public ou accès API : la distinction qui change tout

Le point de départ n'est pas le modèle d'IA que vous utilisez, mais le contrat sous lequel vous l'utilisez. Une interface grand public — la version gratuite de ChatGPT, de Gemini ou de Copilot que n'importe qui ouvre dans un navigateur — fonctionne sous des conditions d'utilisation qui, pour beaucoup de fournisseurs, autorisent la réutilisation des conversations pour améliorer les modèles, sauf désactivation explicite dans les paramètres du compte. Un accès API d'entreprise fonctionne sous un contrat commercial distinct, qui exclut cette réutilisation par défaut.

C'est cette différence, et non la puissance du modèle, qui détermine si un extrait de contrat collé dans l'outil ressort un jour, sous une forme ou une autre, dans la réponse donnée à un autre utilisateur. Un prestataire qui développe un chatbot ou un assistant interne pour un client doit vérifier sous quel contrat l'API qu'il intègre fonctionne réellement — le nom du modèle affiché à l'écran ne le dit pas.

Le shadow AI, premier vecteur de fuite dans les entreprises françaises

Avant même la question contractuelle, le risque le plus fréquent ne vient pas d'une intégration technique mal conçue : il vient d'un usage que personne dans l'entreprise n'a validé ni même repéré. Ce phénomène, baptisé shadow AI par analogie avec le shadow IT, désigne l'ensemble des outils d'intelligence artificielle utilisés par les salariés en dehors de tout cadre défini par leur employeur.

Son ampleur est documentée par la télémétrie directe de navigateurs professionnels que LayerX a collectée pour son rapport 2025 sur la sécurité des données IA et SaaS en entreprise (LayerX) : 40 % des fichiers téléchargés dans des outils d'IA non sécurisés contiennent des données personnelles ou sensibles (PII/PCI), et 45 % des salariés utilisent déjà un outil d'IA générative dans leur travail. Le canal principal de fuite n'est pas une faille technique mais le geste le plus banal qui soit : le copier-coller. La même étude mesure que 77 % des salariés collent des données dans un outil d'IA générative, et que 82 % de ces collages proviennent d'un compte personnel non géré par l'entreprise, hors de portée de toute politique de sécurité.

Trois questions simples permettent à un dirigeant de mesurer son exposition sans outil ni audit externe :

1. Quels outils d'IA vos équipes utilisent-elles réellement ? Pas seulement ceux que vous avez déployés, mais ceux qu'un salarié ouvre de sa propre initiative pour gagner du temps sur une tâche.
2. Avec quel type de compte ? Un compte professionnel géré par l'entreprise (avec des garanties contractuelles vérifiées) ou un compte personnel gratuit, dont les conditions d'utilisation n'ont jamais été lues ?
3. Sur quel type de contenu ? Un brouillon d'e-mail générique n'a pas la même portée qu'un extrait de contrat client, un identifiant, ou un tableau de rémunérations.

Une réponse honnête à ces trois questions, posée en réunion d'équipe, révèle en général plus de fuites potentielles qu'un audit technique formel — parce que le problème est avant tout organisationnel, pas informatique.

Le contrat de sous-traitance (DPA), premier garde-fou

Dès qu'une donnée personnelle transite par une API d'IA, le RGPD s'applique, et le fournisseur agit comme sous-traitant au sens de ce règlement. La CNIL est explicite sur ce point dans ses recommandations sur le développement des systèmes d'IA : un sous-traitant doit garantir qu'un contrat de sous-traitance a bien été conclu, qu'il suit les instructions du responsable de traitement, et qu'il ne réutilise pas les données au-delà de ce qui a été convenu (CNIL, 22 juillet 2025). Sans ce contrat, c'est l'entreprise utilisatrice — pas le fournisseur d'IA — qui reste seule responsable en cas de fuite ou de contrôle.

Avant de signer un contrat avec un fournisseur d'API d'IA, quatre questions doivent obtenir une réponse écrite, et chacune doit correspondre à une clause précise dans le contrat de sous-traitance (DPA) :

1. Le fournisseur agit-il bien comme sous-traitant au sens du RGPD sur cette offre précise ? La clause à exiger : une mention explicite du rôle de sous-traitant dans le DPA, distincte des conditions d'utilisation générales du produit.
2. Vos contenus servent-ils à l'entraînement des modèles ? La clause à exiger : un engagement écrit de non-réutilisation des données clientes à des fins d'entraînement, daté et signé — une promesse orale ou une simple page marketing ne suffit pas en cas de contrôle.
3. Où les données sont-elles hébergées ? La clause à exiger : la liste des régions de traitement et de stockage, avec un engagement contractuel si un hébergement dans l'Union européenne est requis.
4. Combien de temps les données sont-elles conservées ? La clause à exiger : une durée de conservation chiffrée et une procédure de suppression sur demande, pas une formule vague du type « durée nécessaire au service ».

Un fournisseur sérieux répond à ces quatre points sans détour. Une réponse évasive ou un refus de fournir le DPA doit suffire à écarter l'offre, quelle que soit la qualité du modèle proposé.

Choisir une architecture d'hébergement adaptée

Une fois le cadre contractuel posé, le choix de l'architecture technique détermine où circulent réellement les données. Les trois grandes offres d'IA d'entreprise documentent des garanties comparables sur le papier, mais avec des mécanismes différents :

Ce tableau ne dispense pas de lire le contrat réel proposé par chaque fournisseur : les garanties évoluent, varient parfois selon le modèle précis choisi au sein d'une même offre, et les conditions doivent être vérifiées à la date de signature, pas supposées à partir d'un comparatif publié à un instant donné.

Pour une PME qui ne dispose pas de compétence technique en interne pour évaluer ces options, la question à trancher en amont est simple : quelle proportion des données envoyées à l'IA est-elle personnelle ou confidentielle ? Si la réponse est « une part significative », l'architecture d'hébergement doit être un critère de sélection au même titre que le prix, pas un détail technique délégué au prestataire sans validation.

Filtrer les données avant qu'elles n'atteignent le modèle

Même avec un contrat solide et un hébergement adapté, une couche de filtrage automatisé en amont reste utile, car elle protège contre l'erreur humaine — le scénario le plus fréquent de fuite, comme le montrent les chiffres du shadow AI. Le principe : avant qu'un texte parte vers l'API, un filtre repère et masque automatiquement les motifs sensibles (adresses e-mail, IBAN, numéros de téléphone, identifiants), sans bloquer l'usage légitime de l'outil.

Exemple chiffré : une PME de 20 salariés qui déploie un filtre regex open source

Prenons une PME de services qui vient d'intégrer une API d'IA à son outil de gestion des tickets clients, avec un volume d'environ 400 messages traités par semaine. Sans filtrage, chaque message part tel quel vers l'API, avec le risque qu'un identifiant client, un numéro de commande ou une adresse e-mail personnelle transite sans contrôle.

La mise en place d'un filtre par expressions régulières (motifs pour IBAN, e-mails, numéros de téléphone français, numéros de sécurité sociale) en amont de l'appel API représente, pour un développeur qui maîtrise déjà l'intégration existante, une demi-journée de travail : écrire les motifs, les tester sur un échantillon de messages réels, et vérifier qu'aucun faux positif ne bloque un message légitime. Sur cette même PME, un tel filtre bloquerait ou masquerait typiquement l'équivalent de quelques dizaines de motifs sensibles par semaine — la proportion exacte dépend du secteur d'activité et du type de messages traités, et doit être mesurée sur un échantillon réel avant généralisation plutôt que supposée.

Ce filtrage ne remplace ni le contrat de sous-traitance ni le choix d'hébergement : il constitue une troisième couche, la seule des trois à intercepter une erreur humaine avant qu'elle ne quitte l'entreprise. Pour les entreprises qui traitent un volume important de données très sensibles, une architecture plus poussée combine un modèle local léger chargé uniquement de ce filtrage en amont, et un modèle distant plus puissant pour le raisonnement final — une approche proche de celle décrite dans notre article sur le RAG en entreprise sans exposer ses données.

Ce que dit la réglementation (RGPD, AI Act)

Le RGPD s'applique à toute donnée personnelle envoyée à une API d'IA, que le traitement ait lieu sur un serveur en France ou aux États-Unis, et indépendamment de la taille de l'entreprise. Au-delà du contrat de sous-traitance déjà évoqué, deux obligations concrètes s'ajoutent pour l'entreprise utilisatrice : informer les personnes concernées lorsque leurs données personnelles sont traitées via un outil d'IA, et réaliser une analyse d'impact relative à la protection des données (AIPD) lorsque le traitement présente un risque élevé — par exemple un profilage automatisé de clients ou de candidats à l'embauche.

Ce cadre rejoint une question déjà traitée sur ce blog pour l'hébergement local : notre article sur le LLM local pour protéger les données de votre PME détaille pourquoi le Cloud Act américain reste un risque structurel distinct du seul RGPD, même quand un hébergement européen est contractuellement garanti. Une intégration d'API d'IA mal encadrée — sans DPA, sans authentification robuste sur les accès, sans filtrage des données sensibles — expose l'entreprise aux mêmes manquements que la CNIL sanctionne déjà chez des PME par la voie de sa procédure simplifiée (défaut de sécurité, absence de contrat de sous-traitance).

Arbre de décision : quelle architecture pour votre prochaine intégration ?

Face à un nouveau projet d'intégration d'API d'IA, voici la séquence de décision à suivre avant tout développement :

1. Les données traitées incluent-elles des informations personnelles ou confidentielles ? Non → une API grand public standard, avec un DPA de base, suffit généralement. Oui → passez à l'étape 2.
2. Un contrat de sous-traitance excluant explicitement l'entraînement est-il disponible chez le fournisseur envisagé ? Non → écartez l'offre ou négociez cette clause avant signature. Oui → passez à l'étape 3.
3. L'hébergement dans l'Union européenne est-il exigé par votre secteur ou vos clients ? Oui → orientez-vous vers une offre garantissant la résidence UE (AWS Bedrock avec EU Inference Profile, Azure OpenAI en région européenne, Google Vertex AI en région européenne). Non → toute offre respectant l'étape 2 convient.
4. Le volume de données sensibles est-il élevé et récurrent (plusieurs centaines de messages par semaine) ? Oui → ajoutez une couche de filtrage automatisé en amont de l'appel API. Non → le contrat et l'hébergement suffisent, avec une sensibilisation des équipes au risque de shadow AI.

Plan d'action

Pour sécuriser une intégration d'API d'IA existante ou à venir, dans cet ordre :

1. Listez les usages réels de l'IA dans votre entreprise en posant directement les trois questions du shadow AI à vos équipes (quels outils, quels comptes, quel type de contenu) — pas seulement les outils que vous avez officiellement déployés.
2. Demandez le contrat de sous-traitance (DPA) à chaque fournisseur d'IA déjà utilisé, et vérifiez qu'il répond explicitement aux quatre questions détaillées plus haut ; en l'absence de réponse écrite, considérez l'offre comme non conforme.
3. Vérifiez l'architecture d'hébergement de vos intégrations existantes face au tableau comparatif ci-dessus, en particulier si vos clients ou votre secteur imposent une résidence des données dans l'Union européenne.
4. Si le volume de données sensibles transitant par une API dépasse quelques dizaines de messages par jour, budgétez la mise en place d'un filtrage automatisé avant l'envoi, plutôt que de compter uniquement sur la vigilance individuelle des salariés.
5. Programmez une revue de ces quatre points au moins une fois par an, ou dès qu'un nouvel outil d'IA est adopté par une équipe, pour éviter que le shadow AI ne redevienne le point d'entrée principal des fuites.

Un doute sur la conformité de vos intégrations d'IA actuelles ? Un audit de cybersécurité et de conformité RGPD permet de vérifier ces points en une fois, ou parlons-en directement si vous voulez cibler uniquement vos flux liés à l'IA.