Confidentialité et RGPD : ce que change l'IA locale

Utiliser un service cloud pour l'IA n'est pas seulement une question de commodité : pour quiconque traite des données personnelles ou professionnelles, c'est une question d'obligations légales. Le RGPD n'interdit pas d'envoyer des données dans le cloud, mais il pose des exigences que tout transfert hors UE doit satisfaire. L'IA locale change l'équation : pas de transfert, pas de sous-traitant étranger, pas de dépendance à des clauses contractuelles. Voici ce que dit la réglementation, point par point.

Le problème des services cloud, en termes RGPD

Quand vous utilisez ChatGPT, Claude, Gemini ou similaires, trois choses se produisent qui contiennent des obligations :

1. Transfert vers un pays tiers. Vos données quittent l'espace économique européen et vont sur des serveurs de pays sans adéquation pleine et stable. Le transfert n'est légitime que s'il passe par une base juridique : décision d'adéquation (art. 45), clauses contractuelles types (CCT), règles d'entreprise contraignantes (BCR) ou les dérogations de l'art. 49. Pour les services américains, la base en vigueur est la décision d'adéquation EU-US Data Privacy Framework, approuvée en juillet 2023 après la chute du Privacy Shield dans l'affaire Schrems II (C-311/18). Un cadre qu'un tribunal peut renverser à tout moment : quand c'est arrivé en 2020, les transferts en cours se sont retrouvés sans base juridique du jour au lendemain.
2. Traitement de vos données par le fournisseur. Les conditions de service décident si vos prompts sont conservés, utilisés pour améliorer les modèles, ou non. Les réglages « off » existent, mais ce sont des promesses contractuelles, pas des garanties techniques : vous n'avez ni visibilité ni contrôle sur ce qui reste dans les logs, les systèmes de sécurité ou les sauvegardes.
3. Sous-responsabilité. Le fournisseur est sous-traitant (art. 28) et pèse sur lui des obligations que vous devriez surveiller : mesures de sécurité, notifications de violation, suppression en fin de contrat. En pratique, pour la plupart des entreprises, cette surveillance n'existe pas.

Ce que dit le RGPD, et ce qui change avec l'IA locale

Les articles pertinents pour le choix cloud vs local :

Article	Obligation	Cloud	Local
Art. 5(1)(c) — minimisation	Données adéquates et limitées à ce qui est nécessaire	Chaque prompt contient plus de données que le fournisseur n'en a besoin : contexte, métadonnées, logs	Le modèle ne voit que ce que vous lui passez ; le reste reste à vous
Art. 25 — protection par la conception	Protection intégrée dès la conception	Vous la protégez par contrat, pas par architecture	L'architecture elle-même n'expose pas les données à des tiers
Art. 28 — sous-traitants	Contrat et surveillance du fournisseur	Sous-traitant hors UE à surveiller	Aucun sous-traitant : le modèle tourne chez vous
Art. 32 — sécurité du traitement	Mesures techniques adéquates (chiffrement inclus)	Dépend des mesures du fournisseur	Les vôtres : chiffrement, réseau, accès — et l'air-gap si besoin
Art. 44 — transferts vers pays tiers	Base juridique valable pour chaque transfert hors UE	Exige adéquation ou garanties, à réexaminer après chaque décision	Aucun transfert : l'article ne s'applique pas

Le point n'est pas que le cloud soit illégal — il est légal, avec les bons documents. C'est que la compliance demande un travail continu : DPIA, registre des traitements à jour, surveillance du sous-traitant, réexamen à la prochaine décision sur les transferts. Avec le local, ce travail se réduit à gérer une application en interne, avec un périmètre de sécurité que vous contrôlez.

Les trois bénéfices, dits avec précision

Pas de transfert, pas de base juridique à défendre. C'est le avantage technique-juridique le plus grand : l'art. 44 ne s'applique simplement pas. Vous ne dépendez plus de décisions d'adéquation que les tribunaux UE ont déjà renversées deux fois.

Pas de sous-traitant. Pas d'art. 28 à négocier, pas de clauses à mettre à jour quand le fournisseur change ses conditions. La chaîne de responsabilité est courte : vous, votre machine, vos données.

Contrôle du cycle de vie. Les données ne finissent pas dans les logs, ne vont pas dans les sauvegardes du fournisseur, n'entrent pas dans le training (si vous ne le décidez pas). Cela compte surtout pour les données que vous ne pouvez pas révéler : dossiers cliniques, contrats en négociation, documents de clients.

Les cas d'usage où ça fait vraiment la différence

Secteur	Usage typique	Ce qu'on évite
Cabinets juridiques	Révision et synthèse de contrats	Exposition des données des clients à un sous-traitant hors UE
Santé	Analyse de dossiers cliniques	Transfert de données de santé (art. 9 : catégorie spéciale)
Finance	Synthèse de documents de clients	Violation des devoirs de confidentialité envers les clients
Presse	Analyse de documents d'enquête	Risque que les sources soient exposées à des tiers
Administration	Assistants pour citoyens	Transfert de données de citoyens vers des pays tiers

Aucun de ces usages n'est interdit dans le cloud — mais dans chacun d'eux, le risque d'une perte de confidentialité, ou d'un changement de conditions du fournisseur, a un coût qu'on ne peut pas demander au client.

Et les limites ? Dites honnêtement

L'IA locale n'est pas une déclaration de conformité : le RGPD continue de s'appliquer au traitement, qu'il se fasse en interne ou dans le cloud. La base juridique (art. 6), le registre des traitements (art. 30), l'analyse d'impact (art. 35) où nécessaire, et les mesures de sécurité (art. 32) restent dus. Un modèle local qui lit des dossiers cliniques est encore un traitement de données de santé.

En plus, le local a deux limites pratiques qu'un DPO devrait savoir : les modèles open-weight n'ont pas la même qualité que les frontier pour les tâches complexes, et la responsabilité des mesures de sécurité reste la vôtre — pas de fournisseur à mettre en cause en cas de perte, et cela rend les mesures techniques encore plus importantes.

Comment bouger, en pratique

1. Inventaire : quels flux de données personnelles toucheront l'IA, et où ils finissent aujourd'hui.
2. Classification : les données sont-elles sensibles (art. 9) ou professionnelles ? Celles-ci vont en local d'abord.
3. Matériel : pour les cas d'usage ci-dessus, 16 à 24 Go de VRAM ou de mémoire unifiée suffisent, un modèle 8B à 32B quantisé, une interface. Le guide Matériel pour l'IA locale dimensionne la machine par budget ; Comment exécuter des modèles LLM localement mène de la première installation au modèle qui répond.
4. Documents : mettez à jour le registre des traitements, faites la DPIA où nécessaire, définissez les mesures de sécurité locales (accès, chiffrement au repos, réseau).
5. Évaluez : pour les tâches qu'un modèle local ne couvre pas bien, reste le cloud — mais seulement là, avec les documents de transfert en ordre.

En synthèse

L'IA locale ne rend pas le RGPD invisible : les obligations restent. Ce qu'elle fait, c'est supprimer le transfert hors UE et le sous-traitant étranger, les deux points les plus fragiles de la compliance cloud. Pour qui traite des données sensibles ou professionnelles, c'est le moyen le plus direct de réduire le périmètre de risque à celui qu'on contrôle vraiment.

Sources

• RGPD — art. 5 (principes, y compris la minimisation au 5(1)(c))
• RGPD — art. 32 (sécurité du traitement)
• RGPD — art. 44 (principe général sur les transferts vers pays tiers)
• EDPB — Opinion 28/2024 sur les aspects de protection des données dans le développement et le déploiement de modèles d'IA
• Cour de justice de l'UE — arrêt Schrems II (C-311/18)

Article généré par IA