RGPD et IA : le Digital Omnibus ouvre la voie à l'entraînement sur les données personnelles

Le 21 octobre 2026, le Coreper (comité des représentants permanents des États membres, c'est-à-dire les ambassadeurs auprès de l'UE, pas les ministres) a arrêté le mandat de négociation du Conseil sur le Digital Omnibus. Ce texte, proposé par la Commission européenne le 19 novembre 2025, modifie entre autres le RGPD pour encadrer le traitement des données à caractère personnel dans le cadre de l'entraînement de modèles d'intelligence artificielle. Il ne s'agit pas d'une loi adoptée : c'est une position de négociation. Le Parlement européen n'a pas encore voté sa propre position (ni en commission ITRE/LIBE, ni en plénière au 24 octobre 2026), et un trilogue reste à mener avant toute adoption définitive, avec un objectif affiché de fin 2027 et des effets concrets pas avant 2028 environ.

Sources : Legal 24/7, « Digital Omnibus: GDPR », 22 octobre 2026 ; document du Conseil ST 14756/26 ; Trending Topics EU, 21 septembre 2026 ; lettre ouverte EDRi, 24 septembre 2026.

Ce que prévoit l'article 88 bis

Le texte arrêté par le Conseil ajoute au RGPD un article 88 bis. Son principe : le développement et le fonctionnement d'un système ou d'un modèle d'IA peut reposer sur l'intérêt légitime du responsable du traitement (article 6, paragraphe 1, point f du RGPD). Concrètement, un fournisseur de service d'IA pourrait invoquer son intérêt commercial pour entraîner un modèle sur des données à caractère personnel, à condition de passer le test de mise en balance au cas par cas prévu par le RGPD : son intérêt ne doit pas primer sur les droits et libertés fondamentaux de la personne concernée.

Le responsable du traitement reste tenu de choisir la base juridique appropriée et de documenter les finalités de chaque traitement. L'article 88 bis n'ouvre pas un droit général à collecter n'importe quelle donnée : la nécessité et la proportionnalité restent des conditions cumulatives. Des données collectées pour une finalité initiale (fournir un service cloud, héberger une messagerie, exploiter un site internet) ne deviennent pas automatiquement exploitables pour entraîner un modèle d'IA.

Ce n'est pas une rupture totale avec le cadre actuel. L'intérêt légitime est déjà reconnu comme base juridique possible pour l'IA au cas par cas, notamment par l'avis 28/2024 du Comité européen de la protection des données (CEPD) et par les fiches pratiques publiées par la CNIL (Commission nationale de l'informatique et des libertés) le 19 juin 2025 sur le recours à l'intérêt légitime pour le développement de systèmes d'IA. La nouveauté du Digital Omnibus est d'inscrire cette possibilité directement dans le texte du RGPD, avec un niveau de garde-fous réduit par rapport à ce que la Commission avait initialement proposé.

Les garde-fous retirés par le Conseil

La proposition initiale de la Commission incluait une liste de mesures de protection des données personnelles et un droit d'opposition inconditionnel pour les personnes dont les données seraient utilisées pour l'entraînement. Le Conseil a supprimé ces deux éléments. Dans le texte arrêté par le Coreper :

• la liste de garde-fous spécifiques prévue par la Commission a été supprimée ;
• le droit d'opposition inconditionnel a été retiré ;
• seul le droit d'opposition général prévu par l'article 21 du RGPD est maintenu : la personne peut s'opposer au traitement, mais le responsable du traitement peut refuser si ses intérêts légitimes prévalent.

Pour les données sensibles (origine ethnique, opinions politiques, données de santé, etc.), le Conseil introduit une dérogation limitée aux données « résiduelles » traitées de manière « incidente ». L'entreprise doit effacer ces données « sans retard indu » dès qu'elle les identifie. Si l'effacement est techniquement impossible, les données doivent être protégées contre tout traitement ultérieur, toute utilisation dans les résultats du modèle et toute divulgation.

Quelles données à caractère personnel circulent sur un serveur

Pour un administrateur de VPS Linux ou de serveur dédié, les données à caractère personnel ne se limitent pas aux formulaires d'inscription. Elles circulent dans toute l'infrastructure, souvent sans que l'on en mesure le volume :

• Adresses IP : les logs d'accès de vos sites internet et sites web enregistrent l'adresse IP de chaque visiteur. Cette donnée est qualifiée de donnée personnelle par la jurisprudence européenne.
• Bases de données : un serveur MySQL ou PostgreSQL héberge les comptes utilisateurs, les adresses email, les historiques de commandes et les messages. Chaque enregistrement peut contenir des données à caractère personnel collectées avec des finalités précises.
• Emails et messagerie : un serveur de messagerie stocke les emails et mails entrants et sortants. Le contenu, les métadonnées (expéditeur, destinataire, horodatage) et les pièces jointes sont des données personnelles dès qu'elles permettent d'identifier une personne.
• Cookies : les cookies de suivi, d'authentification ou d'analyse déposés par vos sites web collectent des identifiants qui peuvent être croisés avec d'autres données.
• DNS et noms de domaine : les requêtes DNS enregistrées par votre résolveur ou votre hébergeur révèlent les sites consultés par chaque adresse IP. Le nom de domaine lui-même est associé à un titulaire identifiable auprès du bureau d'enregistrement.
• Transferts de fichiers : les logs FTP et SFTP enregistrent qui a transféré quoi, quand et depuis quelle adresse. Ces métadonnées, une fois conservées, constituent des données personnelles.

Toutes ces données, si elles sont transmises à un service d'IA en ligne (un assistant de code, un outil d'analyse, un chatbot hébergé dans le cloud), pourraient demain être couvertes par l'article 88 bis. Le fournisseur du service pourrait invoquer son intérêt légitime pour les utiliser dans l'entraînement de ses modèles, à condition de passer le test de mise en balance.

Des réactions tranchées

Max Schrems, fondateur de l'organisation noyb et figure de la défense des droits numériques en Europe, a qualifié le projet (dans sa version de septembre 2026) d'« expropriation numérique des Européens ». Dans leur avis conjoint du 11 février 2026, le Comité européen de la protection des données et le Contrôleur européen de la protection des données ont soutenu l'objectif de simplification tout en émettant de sérieuses réserves ; sur l'IA, ils jugeaient inutile une disposition spécifique sur l'intérêt légitime, puisque l'avis 28/2024 permet déjà d'y recourir dans certains cas. Une lettre ouverte publiée par European Digital Rights (EDRi) le 24 septembre 2026 alerte sur le risque de concentration des données entre les acteurs qui en possèdent déjà le plus, au détriment de la concurrence et des droits individuels.

EDRi soulève un point qui concerne directement les administrateurs de serveurs et les hébergeurs : le terme « IA » décrit une technologie, mais « en dit très peu » sur le fait qu'un usage particulier des données personnelles soit justifié ou non. Le simple fait qu'un traitement de données utilise de l'intelligence artificielle ne devrait pas suffire à le légitimer. L'organisation pointe le risque que des entreprises qualifient davantage de traitements comme « liés à l'IA » pour bénéficier d'un cadre juridique plus souple.

De son côté, la Commission présente le Digital Omnibus comme une simplification destinée à alléger les contraintes administratives et à renforcer la compétitivité des entreprises européennes, notamment dans l'entraînement de modèles d'IA.

Ce qui reste à venir

Le texte n'entrera pas en vigueur demain. Voici les étapes restantes avant que les mises à jour du RGPD ne s'appliquent :

Le Parlement européen doit encore adopter sa propre position. Les commissions ITRE (industrie) et LIBE (libertés civiles) n'ont pas encore voté de rapport, et aucun vote en séance plénière n'est intervenu au 24 octobre 2026. Le texte final, s'il est adopté, pourra différer sensiblement de la position du Conseil.

Ce que ça change pour un administrateur de serveur

Pour un administrateur de serveur virtuel (VPS), d'hébergement dédié ou d'une infrastructure en housing, la question n'est pas abstraite. Elle se pose chaque fois qu'un service tiers d'IA traite des données provenant de votre serveur ou de vos utilisateurs : logs envoyés à un outil d'analyse IA, données clients transmises à un assistant conversationnel hébergé dans le cloud, contenus de sites web indexés par un moteur de recherche IA, bases de données répliquées vers un service de backup en ligne.

Si le Digital Omnibus est adopté dans sa forme actuelle, le fournisseur d'un service d'IA en ligne pourrait invoquer son intérêt légitime pour entraîner ses modèles sur ces données, sous réserve du test de mise en balance. Pour l'administrateur, cela implique une vigilance accrue sur plusieurs points :

• Les conditions d'utilisation des services cloud et d'IA auxquels vous confiez des données : certaines clauses autorisent déjà l'utilisation des données pour « améliorer le service ».
• Les clauses de sous-traitance (article 28 du RGPD) : votre hébergeur, votre prestataire d'infogérance ou votre fournisseur cloud agit-il comme sous-traitant ou comme responsable du traitement sur les données qu'il manipule ?
• Le droit d'opposition de l'article 21 : vos utilisateurs peuvent s'opposer au traitement de leurs données à des fins d'entraînement IA, mais le responsable du traitement peut refuser s'il démontre des motifs légitimes impérieux.
• Les transferts de données hors UE : un service d'IA hébergé hors d'Europe reste soumis aux règles sur les transferts internationaux, indépendamment du Digital Omnibus.

Un contrat d'hébergement mutualisé ou d'infogérance qui ne précise pas les finalités de traitement autorisées expose l'administrateur à une perte de contrôle sur les données personnelles de ses clients. Un serveur virtuel dont l'hébergeur propose en parallèle des services d'IA pose la question de l'étanchéité entre hébergement et exploitation des données collectées.

Héberger son propre modèle d'IA

L'alternative existe : faire tourner un modèle d'IA en local, sur une infrastructure que vous contrôlez. Des outils comme Ollama permettent de déployer des modèles de langage open source (Llama, Mistral, Gemma) directement sur un VPS ou un serveur dédié. Couplé à une interface comme Open WebUI, vous obtenez un assistant conversationnel qui fonctionne sans envoyer de données à un tiers.

Ce choix ne vous exempte pas du RGPD. En tant que responsable du traitement, vous restez soumis à toutes les obligations du règlement : base juridique, minimisation des données, droits des personnes concernées, sécurité du traitement. La différence est que les données restent sur votre serveur : aucun fournisseur tiers ne peut invoquer son propre intérêt légitime pour les réutiliser à des fins d'entraînement.

Concrètement, sur un serveur dédié avec suffisamment de RAM et de puissance CPU, un modèle de 7 à 13 milliards de paramètres tourne correctement sur processeur, plus lentement qu'avec une carte graphique. L'espace de stockage requis va de 4 Go pour un modèle quantifié à 26 Go pour un modèle complet en 16 bits : un espace disque en SSD accélère le chargement du modèle en mémoire. Pour des besoins plus légers (classification de tickets, extraction de mots-clés, résumé de documents internes), un VPS avec 8 Go de RAM et 4 vCPU peut suffire. La bande passante n'est pas un facteur critique pour un modèle local puisque les données ne quittent pas le serveur. À la différence d'un service cloud où chaque requête IA transite par Internet et où les appels API sont soumis à des quotas, un modèle hébergé localement n'est limité que par la puissance de votre machine, sans quota d'API ni coût réseau additionnel.

Côté résilience, la stratégie de backup de votre modèle et de vos données doit être pensée dès le départ. Un backup chiffré hors site protège à la fois contre la perte de données et contre l'accès non autorisé. La haute disponibilité n'est pas toujours nécessaire pour un modèle IA interne, mais elle le devient si le service est exposé à vos clients. La sécurisation de l'accès SSH et le chiffrement des communications restent indispensables.

L'hébergement en France ne protège pas du Digital Omnibus

Un point important : le lieu d'hébergement de votre serveur n'a aucune incidence sur l'application du Digital Omnibus. Ce texte modifie le RGPD lui-même, qui s'applique de la même façon dans tous les pays de l'Union européenne. Un serveur hébergé en France, en Allemagne ou aux Pays-Bas sera soumis aux mêmes règles si le texte est adopté.

Ce qui fait la différence, c'est le contrôle technique : qui a accès aux données, où elles transitent, et à quelles conditions elles peuvent être réutilisées. Héberger votre propre modèle d'IA sur un serveur que vous administrez vous donne la maîtrise de ces paramètres. Confier vos données à un service tiers vous place dans une relation contractuelle où le fournisseur pourrait, demain, disposer d'une base juridique explicite pour les réutiliser.

Protéger les données personnelles sur votre serveur

Que le Digital Omnibus soit adopté ou non, la protection des données personnelles hébergées sur votre infrastructure reste votre responsabilité en tant que responsable du traitement. Voici les mesures à vérifier :

• DPO : le délégué à la protection des données (DPO) n'est obligatoire que dans certains cas (traitement à grande échelle, données sensibles, autorité publique), mais il est recommandé dès que vous gérez des données personnelles de clients sur vos serveurs.
• Registre des traitements : pour chaque base de données MySQL, chaque service de messagerie, chaque outil de logs, documentez quelles données à caractère personnel sont collectées, pour quelles finalités, combien de temps elles sont conservées et qui y a accès (article 30 du RGPD).
• Audit des services tiers : vérifiez les conditions d'utilisation de chaque service cloud, IA ou infogérance qui accède à vos données. Recherchez les clauses autorisant l'utilisation des données pour l'amélioration du service ou l'entraînement de modèles.
• Sauvegardes chiffrées : un backup chiffré hors site protège les données conservées contre l'accès non autorisé.
• Sécuriser les accès : les connexions SSH, FTP et les accès aux bases de données doivent être protégés par des clés, des mots de passe forts et un pare-feu. Le durcissement initial d'un serveur dédié est la première ligne de défense.
• Mises à jour : maintenir à jour le système, les services et les dépendances réduit la surface d'attaque et les vulnérabilités qui pourraient exposer des données personnelles.

Questions fréquentes