L’intelligence artificielle générative s’est installée dans les organisations sans que personne ne l’ait vraiment décidé. Un collaborateur teste ChatGPT pour rédiger un compte rendu de réunion, un autre utilise Copilot pour analyser un contrat. Résultat : des données potentiellement sensibles transitent vers des serveurs américains, sans AIPD, sans clause contractuelle solide, sans que le DPO en soit informé. Ce scénario n’est pas hypothétique : il se produit chaque semaine dans des centaines d’organisations françaises.
Face à ce constat, la réponse réflexe du DPO est souvent l’interdiction. Mais l’interdiction sans alternative n’a jamais fonctionné. Ce qui change depuis quelques mois, c’est qu’une alternative sérieuse existe désormais : les modèles à poids ouverts, dont Gemma 4 de Google DeepMind est, à ce jour, l’un des représentants les plus aboutis.
« Open weights » ne signifie pas « open source » : une distinction que le DPO doit maîtriser
Le terme « open source » a été tellement galvaudé dans l’univers de l’IA qu’il convient de poser les bases clairement.
Un modèle « à poids ouverts » (open weights) est un modèle dont les paramètres, c’est‑à‑dire les données numériques qui constituent son « apprentissage », sont rendus publics et téléchargeables. Cela permet de le déployer sur une infrastructure que vous contrôlez, sans passer par une API externe. En revanche, le code d’entraînement et les données utilisées pour former le modèle ne sont généralement pas publiés. Gemma 4 entre dans cette catégorie : Google publie les poids et la description d’architecture, mais pas l’ensemble des données d’entraînement.
Ce point est important pour le DPO. Lorsqu’un fournisseur vous dit « notre IA est open source », posez la question suivante : « Puis‑je déployer votre modèle sur mes propres serveurs, sans aucune communication avec vos infrastructures ? » Si la réponse est non, vous êtes en réalité face à un SaaS classique, avec toutes les contraintes réglementaires associées.
Gemma 4 : ce que Google a effectivement publié
Google DeepMind a présenté la famille Gemma 4 comme une gamme de modèles à poids ouverts, publiée sous une licence de type Apache 2.0. La famille comprend plusieurs tailles, optimisées pour différents matériels (modèles « efficaces » de quelques milliards de paramètres pour le poste de travail, modèles autour de 25–30 milliards de paramètres pour les serveurs équipés de GPU). Les variantes les plus légères peuvent tourner sur un ordinateur portable récent ou un serveur d’entrée de gamme, tandis que les plus grandes nécessitent un GPU dédié, tout en restant déployables sur des infrastructures on‑premise accessibles aux PME et aux collectivités.
Trois caractéristiques méritent l’attention du DPO :
-
Le modèle est multimodal sur certaines variantes : il peut traiter du texte et des images, et parfois de l’audio. Cela ouvre des usages intéressants (analyse de documents scannés, extraction de données de formulaires papier), mais implique d’anticiper les risques liés au traitement d’images potentiellement identifiantes.
-
La fenêtre de contexte atteint plusieurs dizaines, voire plus d’une centaine de milliers de tokens sur les variantes les plus récentes. En pratique, cela correspond à des centaines de pages de texte traitées en une seule requête, ce qui est opérationnellement significatif pour un DPO travaillant sur des registres ou des procédures longues.
-
Gemma 4 est compatible avec des outils d’inférence locale comme Ollama ou llama.cpp, qui permettent un déploiement en quelques minutes sur un serveur existant, sans compétence avancée en développement.
Ce que dit le RGPD lorsque le modèle tourne dans vos propres locaux
Passons aux conséquences réglementaires concrètes d’un déploiement local. Ce n’est pas accessoire : c’est là que se joue l’essentiel de l’intérêt pour le DPO.
-
Le transfert hors UE disparaît du périmètre. L’article 44 du RGPD encadre tout transfert de données personnelles vers un pays tiers ne bénéficiant pas d’une décision d’adéquation, sauf garanties appropriées (article 46) ou dérogations limitées (article 49). Lorsqu’un LLM fonctionne en mode SaaS américain, chaque requête contenant des données personnelles constitue un transfert soumis à cette exigence. Avec un modèle déployé localement, la donnée ne sort pas du système d’information : le problème de l’article 44 ne se pose tout simplement plus.
-
L’AIPD reste nécessaire, mais son périmètre change. L’article 35 du RGPD impose une AIPD lorsqu’un traitement est « susceptible d’engendrer un risque élevé pour les droits et libertés des personnes physiques ». L’utilisation d’un modèle d’IA générative pour traiter des données RH, de santé ou relatives à des mineurs relève de cette obligation. En revanche, les risques à analyser dans l’AIPD sont fondamentalement différents selon le mode de déploiement : avec un modèle local, on ne traite plus les risques de transfert illicite ni d’accès non autorisé par le fournisseur cloud, mais plutôt les risques d’inférence non souhaitée, de réponses inexactes et d’accès interne non maîtrisé.
-
L’article 25 (privacy by design) trouve enfin une application concrète. Le principe de protection des données dès la conception s’applique directement ici : choisir dès l’origine une architecture qui empêche structurellement le transfert de données vers des pays tiers est précisément ce que demande l’article 25. Un modèle local n’est pas seulement plus sobre en transferts : il est architecturalement aligné avec ce principe.
-
L’alimentation du modèle par vos données : une crainte à préciser. Dans les SaaS commerciaux, les conditions générales déterminent si vos données peuvent être réutilisées pour améliorer le modèle général. Avec un modèle local à poids ouverts, le modèle est figé par défaut : il n’apprend pas de vos requêtes, sauf si vous décidez activement de lancer un fine‑tuning ou de stocker vos prompts pour d’autres usages analytiques.
Ce que l’AI Act prévoit pour les modèles à poids ouverts
L’AI Act, adopté en 2024 avec une application progressive jusqu’en 2026, introduit une catégorie spécifique pour les « modèles d’IA à usage général » (GPAI models, articles 51 à 56). Les grands modèles de langage comme Gemma 4 entrent dans cette catégorie.
L’article 53(2) de l’AI Act prévoit des obligations allégées pour les fournisseurs qui publient leurs poids sous une licence libre ou ouverte et rendent l’architecture et les informations d’usage accessibles. Concrètement, ces fournisseurs sont dispensés d’une partie des obligations de documentation technique et d’information descendante prévues à l’article 53(1), mais restent soumis à d’autres exigences, notamment en matière de respect du droit d’auteur et de résumé des données d’entraînement. Cette exemption ne s’applique pas aux modèles GPAI présentant un « risque systémique », pour lesquels l’intégralité des obligations de l’article 53 et les obligations supplémentaires de l’article 55 trouvent à s’appliquer.
Pour l’organisation qui déploie Gemma localement, la logique est différente : en tant que « déployeur » au sens de l’AI Act, vos obligations dépendent de l’usage. Si vous utilisez le modèle pour des décisions automatisées affectant des personnes (recrutement, évaluation de la santé au travail, notation de crédit), vous entrez dans le champ des systèmes à haut risque avec des obligations de conformité renforcées. Si l’usage est limité à de l’assistance à la rédaction ou à de la recherche documentaire interne, les exigences sont plus légères.
Cette articulation entre le RGPD et l’AI Act est précisément là où le DPO apporte de la valeur : identifier l’usage réel, qualifier le niveau de risque au sens de l’AI Act, déterminer si une AIPD RGPD est nécessaire, et construire la documentation de conformité croisée.
La vraie question que personne ne pose : êtes‑vous techniquement prêts ?
Les modèles à poids ouverts résolvent un vrai problème réglementaire, mais ils en créent un autre : la charge de la responsabilité technique passe entièrement à l’organisation.
Avec un SaaS, la sécurité de l’infrastructure est contractuellement à la charge du fournisseur (article 28 RGPD, obligations du sous‑traitant). Avec un modèle local, c’est votre serveur, vos mises à jour, votre cloisonnement réseau, votre gestion des accès. Si le serveur hébergeant Gemma est mal configuré et accessible depuis l’extérieur, vous avez créé une faille de sécurité bien plus grave que celle que vous cherchiez à éviter.
Avant tout déploiement, le DPO devrait obtenir des réponses écrites aux questions suivantes auprès de la DSI ou du prestataire technique : sur quel serveur le modèle sera‑t‑il déployé, et qui en a la gestion ? L’accès au modèle est‑il authentifié et journalisé ? Les logs de requêtes sont‑ils conservés, et si oui, où et pendant combien de temps ? Le modèle peut‑il être mis à jour automatiquement depuis l’extérieur ? Ces réponses conditionnent la solidité de tout l’édifice réglementaire construit autour du déploiement local.
Ce que le DPO doit inscrire dans son registre
Même en local, le traitement doit figurer au registre des activités de traitement (article 30 RGPD). La fiche de traitement devra préciser : la finalité du déploiement de l’IA, les catégories de données traitées via le modèle, les mesures de sécurité techniques mises en place, la durée de conservation des logs de requêtes, et l’absence de transfert hors UE (à documenter comme mesure de conformité, pas seulement comme fait technique).
Si le modèle est utilisé dans un contexte impliquant des données de santé ou des décisions individuelles automatisées, l’AIPD est obligatoire et doit être réalisée avant la mise en production, conformément à l’article 35 du RGPD et aux listes publiées par les autorités de contrôle.
En pratique : ce que cela change pour le DPO de PME ou de collectivité
Le discours habituel sur l’IA locale présuppose une DSI structurée et des budgets IT conséquents. La réalité de beaucoup d’organisations françaises, notamment les SPSTI, les CSE, les collectivités de taille moyenne et les cabinets libéraux, est différente.
La bonne nouvelle : des modèles de type Gemma 4 « compacts » peuvent fonctionner sur des configurations très accessibles (un serveur dédié avec GPU d’entrée de gamme chez un hébergeur français, par exemple), ce qui suffit pour des usages bureautiques courants. Des solutions comme Ollama permettent un déploiement en moins d’une heure, avec une interface utilisateur simple.
La contrainte réelle : il faut quelqu’un dans l’organisation, ou un prestataire externe identifié, capable de maintenir ce serveur, d’appliquer les mises à jour de sécurité et de répondre à un incident. Le DPO ne fait pas ce travail lui‑même, mais il doit s’assurer qu’il est fait et documenté.
Ce que vous devriez faire cette semaine
Si votre organisation utilise déjà des outils d’IA générative en mode SaaS, commencez par les recenser dans votre registre. Vérifiez si une DPA (Data Processing Agreement) est signée avec chaque fournisseur, et si les données transférées sont réellement personnelles.
Si vous envisagez un déploiement local, posez la question du périmètre d’usage avant d’approcher la DSI : à quelles finalités le modèle servira‑t‑il ? Quelles données seront soumises ? La réponse à ces deux questions détermine le niveau de risque et la documentation de conformité nécessaire.
L’IA locale n’est pas une solution miracle. C’est un outil qui déplace les risques, et déplacer les risques n’est utile que si la nouvelle configuration est mieux maîtrisée que l’ancienne.
