IA et RGPD : où partent vraiment les données de votre entreprise ?

C’est toujours la même question, et c’est la bonne. Un dirigeant nous décrit la fonctionnalité qu’il veut construire, un assistant qui lit les dossiers clients ou un moteur qui trie les candidatures, puis il s’arrête net : « et mes données, elles partent où exactement ? ». Le sujet IA et RGPD tient presque entièrement dans cette interrogation. Pas un débat théorique sur la régulation, un trajet concret : ce que contient la requête envoyée au modèle, chez qui elle atterrit, combien de temps elle y reste, ce que le fournisseur a le droit d’en faire.

Chez Squirrel, nous concevons des applications sur mesure depuis 2014 et nous intégrons de l’IA dans des produits qui tournent vraiment. Notre position est simple : la conformité n’est pas un frein au projet, c’est une contrainte d’architecture, qui se pose au cadrage au même titre que le budget. Posée à ce moment-là, elle coûte quelques discussions. Découverte six mois plus tard, elle coûte une refonte.

IA et RGPD : la première distinction à faire avant tout le reste

Utiliser une API de modèle n’est pas entraîner un modèle

Beaucoup de crispations viennent d’une confusion. Entraîner un modèle, c’est constituer un jeu de données, souvent massif, et s’en servir pour ajuster les paramètres du système. Traitement lourd, questions de base légale redoutables : c’est précisément le terrain sur lequel la CNIL a publié l’essentiel de sa doctrine, en admettant l’intérêt légitime comme base légale possible, sous réserve de garanties fortes. Utiliser une API de modèle, c’est autre chose. Vous envoyez un texte, le fournisseur le fait passer dans un modèle déjà entraîné, il vous renvoie une réponse. Aucun apprentissage n’a lieu au passage.

La grande majorité des projets qu’on nous soumet relève de la seconde situation. Presque personne ne veut entraîner un modèle de langage, ce serait absurde économiquement. On veut brancher un modèle existant sur ses propres contenus. La question RGPD devient alors bien plus circonscrite : elle porte sur le flux envoyé au fournisseur, pas sur la constitution d’un corpus d’entraînement.

IA et RGPD : ce que devient une requête envoyée à un fournisseur

Nous avons relu, le 6 août 2026, les engagements publics des principaux fournisseurs d’API. Le tableau est plus rassurant qu’on ne l’imagine, à condition de lire les bonnes lignes. OpenAI indique que les données professionnelles ne servent pas par défaut à entraîner ses modèles, que les entrées et sorties de l’API peuvent être conservées jusqu’à trente jours pour la surveillance des abus, et qu’une rétention nulle est accessible sur certains points d’accès. Anthropic écrit de même que, par défaut, les entrées et sorties de ses produits commerciaux n’entraînent pas ses modèles. Microsoft précise, pour les modèles servis via Azure, que les requêtes ne servent pas à entraîner des modèles de fondation sans votre autorisation. Mistral publie un avenant qui le qualifie de sous-traitant et prévoit un retrait possible de l’entraînement.

Retenez la mécanique : le comportement par défaut est rarement le pire, presque jamais le plus protecteur. Un salarié qui colle un extrait de contrat dans une interface gratuite ne joue pas la même partition qu’une application appelant l’API sous contrat entreprise.

Le fournisseur d’IA est un sous-traitant, et cela s’écrit dans un contrat

Quand vous envoyez des données personnelles à une API de modèle pour votre propre compte, vous restez responsable de traitement et le fournisseur agit comme sous-traitant. Ce n’est pas une nuance de juriste, cela déclenche une obligation précise : un contrat écrit qui encadre ce que le sous-traitant a le droit de faire, ses obligations de sécurité, le sort des données en fin de relation et les conditions de recours à d’autres sous-traitants.

Ce document existe chez tous les fournisseurs sérieux, sous le nom d’avenant de traitement des données. Le vrai travail est de le lire et de vérifier qu’il correspond à ce que votre application fait. Trois points méritent une attention particulière : la durée de conservation annoncée, la liste des sous-traitants ultérieurs, et la mention explicite de la non-utilisation de vos données pour améliorer les modèles du fournisseur. La CNIL consacre d’ailleurs une de ses fiches pratiques sur l’IA à la qualification juridique des fournisseurs, qui n’est pas toujours celle qu’on croit. Et cocher une case dans une interface web n’équivaut pas à avoir contractualisé pour un usage professionnel.

Où le traitement a-t-il lieu ? Localisation et transferts hors Union européenne

Le RGPD n’interdit pas de faire sortir des données de l’Union européenne, il encadre ces transferts. Trois voies existent : une décision d’adéquation reconnaissant qu’un pays offre un niveau de protection suffisant, des garanties appropriées comme les clauses contractuelles types ou les règles d’entreprise contraignantes, et à défaut des dérogations pour des situations limitées. Le cadre général présenté par la CNIL est stable, et les fournisseurs d’IA s’y conforment le plus souvent via les clauses contractuelles types.

Reste qu’éviter le sujet est plus confortable que le documenter. C’est là que la localisation du traitement devient un critère d’architecture. Plusieurs fournisseurs proposent désormais de traiter et de stocker les données en Europe : OpenAI ouvre cette option de résidence des données aux clients éligibles, Microsoft précise que les requêtes sont traitées dans la géographie choisie par le client, sauf pour certains types de déploiement globaux. Ce dernier point est typique du diable dans les détails : l’option existe, encore faut-il l’activer et vérifier que le déploiement retenu ne la contourne pas.

Trois architectures sont possibles, et le choix se fait sur la sensibilité de la donnée, pas sur les convictions de chacun.

Nous conseillons rarement l’auto-hébergement. Il séduit sur le papier, coûte cher en exploitation et fige la qualité au niveau du modèle ouvert déployé. Mais quand la donnée est vraiment sensible, c’est la réponse qui tient, et il faut savoir la proposer plutôt que de forcer un compromis bancal.

Minimisation : la donnée qu’on n’envoie pas est la plus facile à protéger

Envoyer au modèle ce dont il a besoin, et rien de plus

C’est la mesure la plus efficace, et de loin la moins coûteuse. Avant de brancher quoi que ce soit, posez la question dans l’autre sens : de quoi le modèle a-t-il strictement besoin pour produire la réponse attendue ? Pour résumer un échange avec le support, il n’a besoin ni du numéro de téléphone du client, ni de son adresse. Pour classer une candidature selon des compétences, il n’a besoin ni du nom, ni de la date de naissance, ni de la photo.

Dans nos projets, cela se traduit par une couche de préparation côté serveur qui construit la requête envoyée au modèle. Ce n’est pas une brique exotique, c’est du travail de back-office et d’API classique : elle sélectionne les champs utiles, retire le reste et journalise ce qui est parti. Effet secondaire agréable, les requêtes plus courtes coûtent moins cher.

Pseudonymisation et durée de conservation des historiques

Quand un identifiant reste nécessaire pour recoller la réponse au bon dossier, on l’envoie sous forme de jeton et la table de correspondance ne quitte jamais votre système. Le modèle voit « candidat 4471 », votre application sait qui c’est. La pseudonymisation ne fait pas sortir la donnée du RGPD, mais elle réduit fortement l’impact d’un incident chez le fournisseur, et la CNIL la cite systématiquement parmi les mesures d’atténuation attendues.

Le second angle mort, c’est l’historique. Une fonctionnalité conversationnelle produit des conversations, et elles vivent dans votre base bien après avoir servi. Il faut fixer une durée de conservation, l’écrire, et la faire appliquer par une purge automatique. Peu importe le chiffre tant qu’il est justifié par un usage réel. La question qui tranche : à quoi sert cet historique dans six mois ? Si la réponse est floue, la durée est trop longue. Le raisonnement rejoint ce que nous appliquons sur la sécurité d’une application mobile iOS et Android, où la donnée que l’on ne stocke pas est la seule qui ne fuitera jamais.

Informer les utilisateurs et mettre à jour la politique de confidentialité

Ajouter une fonctionnalité d’IA modifie votre traitement. La politique de confidentialité doit donc le refléter : quelles données, pour quelle finalité, vers quel destinataire, pendant combien de temps, et si un transfert hors Union européenne a lieu, sur quelle base il est encadré. Cette mise à jour prend une demi-journée au bon moment, et devient pénible à rattraper quand la fonctionnalité est en ligne depuis un an. Nous détaillons le contenu attendu dans notre article sur les mentions légales d’une application mobile.

L’information ne se limite pas au document juridique, elle se joue aussi dans l’interface. Dire clairement qu’une réponse est générée par une IA relève du bon sens produit et des obligations de transparence portées par le règlement européen sur l’intelligence artificielle, que nous traitons dans notre article dédié aux obligations concrètes de l’IA Act pour une application. Les deux textes ne se remplacent pas : le RGPD encadre la donnée personnelle, l’IA Act encadre le système d’IA en tant que produit. Un projet sérieux les traite dans le même cadrage, pas dans deux chantiers séparés.

Analyse d’impact : quand le traitement mérite un examen approfondi

Une analyse d’impact devient obligatoire lorsque le traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes. La CNIL retient une grille de neuf critères, dont le croisement d’au moins deux déclenche l’obligation : évaluation ou notation, décision automatisée avec effet juridique, surveillance systématique, données sensibles, collecte à grande échelle, croisement de données, personnes vulnérables, usage innovant, exclusion du bénéfice d’un droit ou d’un contrat.

Relisez cette liste avec votre projet en tête. Un moteur qui trie des candidatures coche l’évaluation et l’usage innovant. Un outil qui analyse des dossiers de santé coche les données sensibles et souvent la grande échelle. Là, l’analyse d’impact n’est pas une formalité : c’est l’exercice qui vous force à écrire ce que vous faites et à identifier les mesures de réduction du risque. Nous préférons le mener au cadrage, quand les décisions d’architecture sont encore ouvertes.

Questions fréquentes sur l’IA et le RGPD

Peut-on utiliser ChatGPT ou un autre assistant avec des données clients ?

Pas dans une offre grand public, sans contrat et sans encadrement. Dans une offre professionnelle, avec un avenant de traitement signé, une durée de conservation connue et l’assurance que vos contenus n’entraînent pas les modèles du fournisseur, c’est envisageable. La différence n’est pas technique, elle est contractuelle.

Mes données servent-elles à entraîner le modèle du fournisseur ?

Sur les offres professionnelles des grands fournisseurs, la réponse publiée est non par défaut, avec parfois une exception si vous envoyez volontairement un retour qualitatif. Sur les offres gratuites, les règles diffèrent et sont souvent plus permissives. Vérifiez la documentation de l’offre exacte que vous utilisez, pas celle de l’éditeur en général.

Faut-il un modèle hébergé en France pour être conforme au RGPD ?

Non. La conformité ne dépend pas du drapeau mais de l’encadrement des transferts, du contrat, de la minimisation et de l’information des personnes. Un traitement en Europe simplifie beaucoup de choses et nous le recommandons souvent, mais il ne dispense d’aucune des autres obligations.

Combien de temps faut-il pour cadrer le volet RGPD d’un projet d’IA ?

Quelques ateliers suffisent pour trancher le flux de données, le choix du fournisseur, la durée de conservation et les mentions à ajouter. Ce n’est pas ce qui allonge un planning. Ce qui l’allonge, c’est de découvrir en recette que la fonctionnalité envoie des données de santé vers une API dont personne n’a lu les conditions. Nous abordons ces arbitrages dès la première réunion, comme sur tous les projets d’intelligence artificielle dans une application mobile.