RGPD et IA générative en startup : ce que vous devez verrouiller dès le MVP

Temps de lecture estimé : 11 minutes | Article de blog Willaw — Volet entreprises, n°1

Vous lancez un produit qui embarque un LLM. Que vous appeliez l'API d'Anthropic, que vous hébergiez un Mistral chez Scaleway ou que vous combiniez les deux, vos utilisateurs vont envoyer des prompts, votre application va stocker des logs, vos équipes vont peut-être finir par fine-tuner un modèle sur les données accumulées. Chacune de ces étapes touche à des données personnelles au sens du RGPD.

La plupart des startups que nous accompagnons découvrent les implications RGPD au moment de la première due diligence d'un fonds, ou pire, à l'occasion d'une plainte. À ce stade, reprendre l'architecture coûte plusieurs semaines d'ingénierie et expose à des risques contractuels avec les premiers clients. Pourtant, la majorité des décisions structurantes peuvent et doivent être prises dès le MVP, sans ralentir le go-to-market.

Cet article est destiné aux fondateurs, CTO et product managers qui construisent un produit IA en France ou en Europe. Il liste les six chantiers à verrouiller avant la première levée, avec à chaque fois la décision technique, la décision contractuelle et la décision documentaire à prendre.

📌 Ce que vous allez retrouver dans cet article

• Comment cartographier les flux de données personnelles dans une architecture LLM
• Comment choisir entre API tierce et modèle hébergé sans se tromper sur les implications RGPD
• Quelles bases légales mobiliser pour quels usages
• Comment rédiger une politique de confidentialité qui couvre vraiment l'IA
• Comment encadrer les transferts hors UE
• Trois clauses contractuelles à vérifier avec votre fournisseur de LLM

1. Cartographier les flux de données personnelles dans une architecture LLM

Premier réflexe, identifier où circulent les données personnelles dans votre application. Dans une architecture LLM classique, cinq points de contact sont à considérer.

• Les prompts utilisateurs, qui contiennent presque toujours des données personnelles dès lors que l'utilisateur s'identifie ou décrit une situation concrète
• Les logs de conversation, conservés côté application pour le debug, l'amélioration du produit ou la facturation
• Les embeddings, ces représentations vectorielles utilisées pour le retrieval, qui restent rattachables à des contenus personnels
• Les jeux de données de fine-tuning, lorsque vous décidez d'entraîner un modèle sur vos données métier
• Les métadonnées techniques, adresses IP, identifiants de session, horodatage des requêtes

Beaucoup d'équipes oublient les logs et les embeddings. C'est pourtant souvent là que se cache le risque le plus concret, parce que ces données sont conservées longtemps, partagées entre environnements et rarement documentées dans le registre des traitements. La règle est simple, tout flux qui contient ou permet de retrouver une donnée personnelle doit être tracé.

🚩 Le piège fréquent

• Un prompt qui ne contient pas de nom propre peut quand même être personnel
• Un utilisateur qui demande « rédige un mail à mon manager Sophie pour lui expliquer mon projet de congé parental » fournit en quelques mots des données personnelles, parfois sensibles (vie familiale, santé)
• Le LLM ne fait pas la différence, votre application doit la faire à sa place

Décision à prendre dès le MVP. Produire une cartographie minimale au format tableur, listant chaque flux, sa nature (prompt, log, embedding, fine-tuning, métadonnée), sa durée de conservation, son lieu de stockage et sa base légale. Ce document devient le socle du futur registre des traitements et accélère significativement la due diligence d'une levée.

2. API tierce ou modèle hébergé, choisir en connaissance de cause

Le choix entre une API propriétaire (Anthropic, OpenAI, Google) et un modèle auto-hébergé (Mistral via Scaleway, Llama sur infra dédiée) est souvent présenté comme un arbitrage coût/performance. Du point de vue RGPD, c'est aussi un arbitrage de gouvernance.

L'API tierce, simplicité au prix d'un sous-traitant supplémentaire

Quand vous appelez une API, le fournisseur devient sous-traitant au sens de l'article 28 du RGPD. Cela impose de signer un Data Processing Agreement, de vérifier les engagements sur les transferts internationaux, et de documenter ce sous-traitant dans votre registre. Pour les fournisseurs américains (Anthropic, OpenAI), il faut s'appuyer sur l'EU-US Data Privacy Framework ou sur des clauses contractuelles types complétées par des mesures techniques supplémentaires.

Le modèle auto-hébergé, contrôle au prix de l'effort

Héberger Mistral chez Scaleway, c'est garder la donnée en Europe et simplifier la chaîne de sous-traitance. Mais vous devenez de facto responsable de la sécurité du modèle, des logs, du fine-tuning éventuel et des accès internes. Le RGPD ne disparaît pas, il change de mains.

Beaucoup de startups choisissent une approche hybride, modèle hébergé pour les données les plus sensibles ou les workflows critiques, API tierce pour les fonctionnalités annexes. Cet arbitrage est légitime, à condition d'être documenté et tracé dans le registre des traitements.

✅ Décision à prendre dès le MVP

• Lister chaque fonctionnalité IA et le modèle utilisé
• Pour chaque modèle, identifier le fournisseur, sa localisation, la base juridique du transfert si applicable
• Privilégier les fournisseurs proposant un mode entreprise avec opt-out d'entraînement par défaut

3. Bases légales, l'erreur classique du consentement par défaut

Pour traiter des données personnelles, le RGPD impose de mobiliser une base légale parmi les six listées à l'article 6. Pour un produit IA, trois bases sont les plus fréquentes.

• L'exécution du contrat, lorsque le traitement est nécessaire à la fourniture du service que l'utilisateur a souscrit (par exemple, un assistant d'écriture qui doit traiter le texte fourni pour produire la réponse)
• L'intérêt légitime, lorsque le traitement répond à un intérêt légitime de l'entreprise et n'écrase pas les droits des personnes (par exemple, l'analyse agrégée de l'usage du produit pour l'améliorer)
• Le consentement, lorsqu'aucune autre base n'est mobilisable et que l'utilisateur peut effectivement refuser sans perdre l'accès au service principal

L'erreur classique consiste à mobiliser le consentement pour tout, parce qu'il « semble » plus protecteur. C'est l'inverse, le consentement est la base la plus fragile, parce qu'il doit être libre, spécifique, éclairé, univoque et révocable à tout moment. Si l'utilisateur refuse, vous ne pouvez plus traiter, même si le traitement est essentiel à votre service.

Pour l'usage central de votre produit (le LLM qui génère la réponse à partir du prompt), la base légale est presque toujours l'exécution du contrat. Pour les usages annexes (amélioration du produit, analyse statistique, fine-tuning sur les données clients), l'intérêt légitime est généralement plus adapté, à condition de produire une analyse d'intérêt légitime documentée.

📌 Pour aller plus loin
Sur l'analyse d'intérêt légitime, voir notre guide dédié, « L'analyse d'intérêt légitime (LIA) : méthode, pièges et automatisation par l'IA ».

4. Politique de confidentialité, ce qu'il faut vraiment écrire pour un produit IA

Une politique de confidentialité copiée d'un template SaaS classique passe à côté de la moitié des informations à fournir aux utilisateurs d'un produit IA. Les articles 13 et 14 du RGPD imposent de mentionner explicitement plusieurs éléments souvent absents.

• Le fait que des données personnelles sont traitées par un ou plusieurs systèmes d'IA, et lesquels
• La logique sous-jacente du traitement automatisé lorsqu'il produit des décisions ayant un effet juridique ou significatif sur la personne
• Les fournisseurs de modèles tiers et leur localisation
• Les durées de conservation distinctes pour les prompts, logs, embeddings et données de fine-tuning
• L'existence ou non d'un usage des données pour l'entraînement de modèles
• Les modalités d'exercice des droits, en particulier le droit à l'effacement, qui pose des questions techniques spécifiques quand des embeddings ont été produits

La politique de confidentialité n'est pas un document marketing. C'est un document opposable, qui sert de référence en cas de plainte ou de contrôle. Une politique floue ou générique sur l'IA est un facteur aggravant, pas une protection.

✅ Le réflexe à adopter

• Rédiger la politique de confidentialité après avoir cartographié les flux, pas avant
• Mettre la politique à jour à chaque ajout de fonctionnalité IA significative
• Conserver l'historique des versions, c'est exigible en cas de contrôle

5. Transferts hors UE, ne pas se cacher derrière le DPF

L'EU-US Data Privacy Framework, en vigueur depuis juillet 2023, simplifie les transferts vers les fournisseurs américains certifiés. Mais il ne dispense pas de plusieurs précautions.

• Vérifier que le fournisseur est effectivement certifié au DPF, la liste est publique sur le site du Department of Commerce américain
• Documenter le recours au DPF dans le registre des traitements et dans la politique de confidentialité
• Anticiper la possibilité d'une nouvelle invalidation, comme cela a été le cas pour le Privacy Shield en 2020 (arrêt Schrems II)
• Avoir un plan B, en pratique des clauses contractuelles types et des mesures techniques supplémentaires (chiffrement, pseudonymisation)

Pour les fournisseurs hors États-Unis et hors zone d'adéquation (UK, Suisse, Japon notamment), il faut s'appuyer sur les clauses contractuelles types adoptées par la Commission européenne en 2021, complétées par une analyse de transfert (Transfer Impact Assessment) qui vérifie que le pays de destination offre un niveau de protection essentiellement équivalent.

Beaucoup de jeunes startups passent cette étape, considérant qu'elle relève du « legal stuff plus tard ». C'est une erreur, parce que la due diligence d'un fonds européen ou d'un acquéreur sérieux vérifie systématiquement ce point.

6. Trois clauses à vérifier, et négocier si possible, avec votre fournisseur de LLM

Au-delà du DPA standard, trois clauses méritent une attention particulière dans tout contrat avec un fournisseur de LLM. Soyons réalistes, face aux grands acteurs (Anthropic, OpenAI, Google), une early-stage startup signe le plus souvent un contrat d'adhésion, sans véritable levier de négociation. L'enjeu n'est donc pas tant de négocier ligne à ligne que de vérifier ce que le fournisseur garantit déjà, de choisir le bon palier d'offre (les versions entreprise offrent presque toujours de meilleures garanties que les offres self-service), et de ne négocier que lorsque votre volume ou votre profil le permettent.

Clause 1, opt-out d'entraînement par défaut

Vérifiez que vos données (prompts, logs, fichiers fournis) ne sont pas utilisées pour entraîner les modèles du fournisseur, ou que cet usage est désactivable et désactivé dans votre offre. Les versions entreprise de la plupart des grands acteurs (Anthropic, OpenAI, Google) intègrent cet opt-out par défaut, encore faut-il le confirmer par écrit dans le contrat. Une formulation claire est, par exemple, « le fournisseur ne traite les données du client que pour fournir le service, et n'utilise en aucun cas les données du client pour entraîner ou améliorer ses modèles ».

Clause 2, durée de conservation des prompts et logs côté fournisseur

Les grands fournisseurs conservent par défaut les requêtes de l'API pendant une période courte, généralement de l'ordre de 30 jours, à des fins de sécurité et de détection des abus, après quoi elles sont supprimées sauf obligation légale. Vérifiez cette durée dans la documentation du fournisseur et alignez-la avec votre propre politique de conservation. Pour les usages les plus sensibles (santé, RH, finance), la rétention zéro (zero data retention) supprime cette conservation par défaut, elle est proposée par certains fournisseurs pour les clients entreprise éligibles, sur demande et sous conditions.

Clause 3, sous-traitance en cascade

Votre fournisseur de LLM utilise lui-même des sous-traitants (cloud, monitoring, support). Ces sous-traitants doivent être listés, leur localisation précisée, et toute modification doit vous être notifiée à l'avance avec un droit d'opposition. C'est ce qu'on appelle l'autorisation préalable de sous-traitance ultérieure, prévue par l'article 28 du RGPD.

✅ Décision à prendre dès le MVP

• Vérifiez ces trois points avant de vous engager, et privilégiez l'offre entreprise quand ces garanties n'existent pas dans l'offre standard
• Conservez une trace écrite des garanties du fournisseur et de la version finale signée
• Réévaluez ces garanties à chaque renouvellement, les pratiques et les offres évoluent vite chez les fournisseurs

Ce qu'il faut retenir

La conformité RGPD d'un produit IA ne se règle pas en deux heures avant la première levée. Mais elle ne demande pas non plus de mobiliser un cabinet à six chiffres dès le premier jour. Six chantiers structurants, traités sérieusement au stade du MVP, suffisent pour partir avec une base saine.

1. Cartographier les flux de données personnelles dans votre architecture LLM
2. Choisir entre API tierce et modèle hébergé en documentant les implications
3. Mobiliser la bonne base légale pour chaque usage (ne pas surutiliser le consentement)
4. Rédiger une politique de confidentialité spécifiquement pensée pour l'IA
5. Encadrer les transferts hors UE avec un dispositif robuste
6. Vérifier les trois clauses critiques avec vos fournisseurs de LLM, et les négocier si votre profil le permet

Ces six chantiers se traitent en quelques jours-homme, sont valorisables en levée et évitent des semaines de remédiation post-LOI. Ils constituent aussi le socle sur lequel viendront se greffer, plus tard, les obligations issues de l'AI Act pour les startups dont les fonctionnalités basculent en haut risque.

📚 Pour aller plus loin sur willaw.ai

• « Registre des traitements RGPD : le guide pratique pour 2026 », pour formaliser la cartographie
• « AIPD et intelligence artificielle », dès qu'apparaît la nécessité d'une analyse d'impact
• « L'analyse d'intérêt légitime (LIA) : méthode, pièges et automatisation par l'IA »
• « AI Act : guide complet entreprises 2026 », pour anticiper les obligations à venir

🚀 Aller plus loin avec Willaw
Willaw automatise la conformité RGPD et AI Act des entreprises tech. Notre plateforme s'appuie sur un stack souverain (Mistral, Scaleway) et accompagne les startups dès le MVP jusqu'à la Series A et au-delà.
Auditer votre stack IA avec Willaw, démo en 20 minutes, sur willaw.ai.