Le 10 novembre 2026, le Comité européen de la protection des données (CEPD) a adopté la version 2.0 de ses lignes directrices 1/2024 sur l’intérêt légitime. La version soumise à consultation datait d’octobre 2024. Le texte final fixe la grille de lecture commune des autorités européennes de protection des données. Il n’impose pas l’intérêt légitime comme base juridique de l’IA et n’autorise rien en bloc. Pour les directions, les métiers et les DPO, l’exercice consiste désormais à transformer une justification de principe en décision défendable, adossée au fonctionnement réel du projet. (1)
Ce que le texte impose, et ce qu’on lui prête à tort
On lit déjà que l’intérêt légitime serait « devenu obligatoire pour l’IA ». Le lecteur en conclurait que le consentement, le contrat, l’obligation légale et la mission d’intérêt public sont écartés. L’article 6 du RGPD conserve tous ses fondements, et le bon choix dépend du traitement. Une autorité publique ne peut d’ailleurs pas invoquer l’intérêt légitime pour les traitements liés à l’exécution de ses missions. (3)
Le test de mise en balance existait avant novembre 2026. En décembre 2024, l’avis 28/2024 du CEPD sur les modèles d’IA examinait déjà le recours à cette base. En juin 2025, la CNIL détaillait ses conditions et rappelait que d’autres bases pouvaient convenir. La version finale clarifie un cadre connu, à intégrer dans les pratiques. Aucune nouvelle loi ne rend l’intérêt légitime obligatoire pour l’IA. (2, 4)
Pour le client, l’enjeu est concret. S’il a acheté un outil sans examiner les usages, la documentation du fournisseur ne suffira pas lors d’un audit ou d’une certification. S’il a déjà mené une analyse sérieuse, inutile de tout refaire : il vérifie qu’elle correspond toujours aux données, aux utilisateurs et aux fonctions réellement activées. On évite ainsi la régularisation de façade comme la campagne documentaire sans objet.
Décrire le traitement avant de parler de l’outil
« Nous utilisons une IA » ne décrit aucun traitement. Le même assistant peut reformuler un texte sans donnée personnelle, résumer des réclamations nominatives, classer des candidatures ou produire une synthèse médicale. Le modèle et le contrat ont beau être identiques, chacun de ces usages appelle sa propre analyse.
Prenons un assistant du service client. Il reçoit une question et quelques données de commande pour proposer une réponse. Le fournisseur conserve parfois les échanges pour sécuriser son service. Il peut aussi vouloir les réutiliser pour entraîner ses modèles. Finalités, durées et parfois responsables diffèrent d’une opération à l’autre, et l’accord donné pour la première ne couvre pas automatiquement les suivantes.
Dans le registre, une fiche générique « Intelligence artificielle » masque les vrais risques. Mieux vaut rattacher l’assistance par IA au traitement concerné et décrire à part une réutilisation pour l’entraînement quand elle poursuit sa propre finalité. Inutile de multiplier les fiches en doublon. Le registre doit montrer ce qui change pour les personnes.
Le test de nécessité oblige à rediscuter le projet
Un objectif compréhensible ne rend pas toutes les données nécessaires. Réduire le délai de réponse aux clients peut être un objectif valable. Il ne justifie pas d’envoyer à un prestataire cinq années de courriels, les pièces jointes et tout le CRM.
L’analyse compare des options concrètes. Une base documentaire sans données personnelles suffit-elle ? Un identifiant temporaire peut-il remplacer l’identité complète ? Un extrait du dossier donne-t-il la réponse attendue ? Le traitement peut-il tourner dans l’environnement de l’organisme plutôt que dans un service ouvert ? Le gain de performance justifie-t-il les données supplémentaires ?
Personne ne demande à chaque projet d’IA de prouver qu’aucun humain ne pourrait accomplir la tâche. La question porte sur la possibilité d’atteindre l’objectif, avec une efficacité comparable, par des moyens moins intrusifs. La CNIL invite justement à interroger le besoin d’IA et le besoin de données personnelles. (4)
Un dossier solide nomme les options écartées et donne des raisons vérifiables. « Trop compliqué » ne compare rien. « La version sans identité ne retrouvait pas la commande ; un numéro de commande suffit, sans nom ni adresse » amorce une analyse exploitable.
Mettre en balance oblige à regarder les personnes
Une analyse centrée sur le risque de fuite passe à côté d’une partie du sujet. L’IA peut produire des appréciations fausses, sortir une information de son contexte confidentiel, écarter un candidat d’un recrutement ou provoquer une décision injustifiée. La sécurité traite certains de ces risques. Elle ne suffit pas à rendre l’usage acceptable.
En pratique, on se demande ce que la personne attend raisonnablement quand elle confie ses données, ce que l’IA change à cet usage, quelle conséquence elle peut subir et si elle peut la comprendre, la contester ou l’éviter.
Chaque garantie répond à un risque identifié. Si le risque est une synthèse erronée qui débouche sur une décision, raccourcir la durée de conservation ne corrige rien. Il faut une validation par une personne compétente, l’accès aux sources et la possibilité d’écarter la proposition. Si le risque est l’accès à des dossiers non autorisés, une consigne dans le prompt ne vaut pas un contrôle effectif des habilitations.
La conclusion peut prendre plusieurs formes : avis favorable avec un corpus limité, usage accepté sans réutilisation pour l’entraînement, projet reporté dans l’attente de garanties contractuelles, refus en l’état. Une analyse qui ne peut jamais aboutir à modifier ou arrêter le projet n’aide personne à décider.
LIA et AIPD répondent à deux questions différentes
La LIA, ou analyse de l’intérêt légitime, vérifie que cette base peut porter le traitement. L’AIPD examine plus largement la nécessité, la proportionnalité et les risques pour les droits et libertés. Elle devient obligatoire quand le traitement est susceptible d’engendrer un risque élevé. La CNIL rappelle qu’elle commence avant la mise en œuvre et se met à jour au fil du cycle de vie. (5)
Les deux documents peuvent s’articuler, sans recopier deux fois les mêmes flux ou mesures. Un audit de sécurité, une certification du fournisseur ou une AIPD générique sur son produit ne remplacent pas l’analyse du cas d’usage propre à l’organisme.
Si l’AIPD laisse un risque élevé résiduel que le responsable ne parvient pas à réduire suffisamment, la consultation préalable de l’autorité prévue à l’article 36 doit être examinée. Le DPO n’a pas à signer une « décharge » pour passer outre. (6)
En SPST, la donnée de santé change la question
L’intérêt légitime de l’article 6 ne lève pas l’interdiction de traiter les catégories particulières de données. Pour des données de santé, il faut en plus une condition de l’article 9 et le respect du cadre applicable, dont les garanties liées au secret professionnel. Les conditions propres à la médecine du travail ne couvrent pas n’importe quelle réutilisation. (3)
Un SPST distingue ses propres salariés collaborateurs, les salariés suivis des entreprises adhérentes, les représentants de ces entreprises et les candidats à ses recrutements. Leur relation avec le service et leurs attentes diffèrent. Une catégorie vague « salariés » fausse l’information, les habilitations et la mise en balance.
Ces exemples ne tranchent pas la base juridique d’un SPST sans connaître sa mission et le projet. Ils montrent comment la formule « IA = intérêt légitime » mène à une erreur de fond.
Le fournisseur ne décide pas à la place du client
La qualité de sous-traitant ne découle ni d’un nom commercial ni du caractère informatique du service. Elle dépend de qui décide des finalités et des moyens essentiels pour l’opération en cause. Un fournisseur qui agit sur instructions pour le compte du client n’est pas dans la même situation que celui qui réutilise les contenus pour ses propres fins. Le contrat doit refléter les pratiques. (6)
Avant tout achat ou activation, le dossier répond à des questions précises. Quels contenus sortent de l’organisme ? Quels journaux sont conservés ? Qui peut lire les prompts ? Les données servent-elles à entraîner ou améliorer un modèle, et au profit de qui ? Quels autres prestataires interviennent ? Où sont stockées les données et depuis quels pays y accède-t-on ? Que deviennent-elles à la fermeture du compte ?
La mention « données non utilisées pour l’entraînement » ne dit rien de la conservation, des accès humains ou des transferts. La présence d’un prestataire ne prouve pas davantage, à elle seule, un transfert hors de l’Espace économique européen : on examine les flux et les accès réels, puis les garanties du chapitre V quand il s’applique. (7)
Le droit d’opposition doit fonctionner dans le système
Quand le traitement repose sur l’intérêt légitime, la personne peut s’y opposer pour des raisons tenant à sa situation particulière. Le responsable cesse alors le traitement, sauf à démontrer des motifs légitimes impérieux qui prévalent sur ses intérêts et droits, ou un besoin lié à la constatation, à l’exercice ou à la défense de droits en justice. Ce seuil est plus exigeant que la mise en balance initiale. En matière de prospection, le traitement à cette fin doit cesser. (8)
Les clients posent la question : « Si quelqu’un refuse, faut-il arrêter toute notre IA ? » Pas forcément. On identifie l’opération et les données concernées, puis on traite la demande dans le cadre applicable. Encore faut-il avoir prévu un mécanisme qui fonctionne : retrouver les données, les exclure des traitements visés et répercuter l’instruction aux prestataires.
Un bouton de contact ne sert à rien si l’équipe ne sait pas retrouver les données dans le corpus, les historiques ou les index de recherche. Effacer une fiche dans le CRM n’efface pas les copies techniques. Pour un modèle déjà entraîné, mieux vaut ne pas promettre un effacement individuel immédiat sans avoir vérifié sa faisabilité et la réponse appropriée au regard du RGPD.
L’information préalable doit suivre. Finalités, base juridique, intérêts poursuivis, destinataires, durées et droits ne se résument pas à « nous utilisons des technologies innovantes ». Les articles 13 et 14 fixent le contenu et le calendrier de cette information, avec leurs cas particuliers. (8)
La validation humaine ne doit pas servir d’alibi
L’article 22 encadre certaines décisions fondées exclusivement sur un traitement automatisé et produisant des effets de droit ou des effets significatifs similaires. L’intérêt légitime ne figure pas parmi les exceptions qui autorisent une telle décision. (8)
Il faut donc regarder le pouvoir réel de la personne placée « dans la boucle ». A-t-elle les informations nécessaires, le temps et la compétence pour réexaminer le résultat ? Peut-elle le modifier sans en subir les conséquences ? Le processus la pousse-t-il à valider par défaut ?
Un parcours de décision avant le lancement
- Vérifier la présence de données personnelles. Documents, prompts, identifiants, sorties et journaux sont examinés. Si l’organisme invoque l’anonymat, il conserve les éléments qui le démontrent. Une donnée accessible publiquement n’est, pour cette seule raison, ni anonyme ni librement réutilisable.
- Séparer les finalités et attribuer les rôles. Usage opérationnel, entraînement, amélioration, sécurité et analyse des utilisateurs sont distingués. On identifie qui décide et qui exécute.
- Choisir la base appropriée. L’intérêt légitime ne se choisit pas pour éviter de recueillir un consentement. Les règles sur les données sensibles et les décisions automatisées sont vérifiées quand le projet les touche.
- Mener le test si l’intérêt légitime est retenu. On décrit l’intérêt, on compare les options moins intrusives, on apprécie les effets et les attentes des personnes, on retient des garanties et on conclut par écrit. Si le test échoue, le projet est revu ou une autre base réellement appropriée est examinée. Sans fondement valable, les données ne sont pas traitées. Changer l’étiquette dans le registre ne régularise rien.
- Examiner l’AIPD et rendre les garanties effectives. Contrats, flux, durées, information, habilitations et gestion des droits sont vérifiés. Les conditions de lancement doivent pouvoir être testées.
- Décider et surveiller les changements. Le dossier désigne qui décide, dans quelles conditions, et ce qui déclenche un réexamen : nouveau corpus, autre population, nouvel objectif, changement de modèle ou de fournisseur, incident, opposition révélant une difficulté imprévue.
Nous proposons ce parcours comme méthode de travail. Il n’a rien d’un formulaire réglementaire et s’ajuste à l’ampleur du traitement.
Les pièces à réunir avant le feu vert
Un dossier utile réunit la description du cas d’usage et de ses limites, un schéma des flux, la base juridique justifiée, l’analyse d’intérêt légitime le cas échéant, la décision sur l’AIPD, les contrats pertinents, l’information des personnes et une procédure testée pour l’exercice des droits.
Il contient aussi des preuves de fonctionnement. Un « historique désactivé » se vérifie dans la configuration et dans ce que le fournisseur conserve malgré ce réglage. Pour un « accès réservé au service », on contrôle les habilitations, y compris lors d’une recherche transversale dans plusieurs espaces documentaires. Une « validation humaine » suppose de décrire ce que le relecteur voit et peut réellement modifier.
Le DPO conseille et contrôle le respect du RGPD. Il n’a pas vocation à administrer le système ni à garantir personnellement sa sécurité. Le métier décrit le besoin, la direction décide, les équipes techniques et les achats apportent les garanties qui relèvent d’eux. La position du DPO et les arbitrages restent traçables. (6)
Sources officielles
(3) RGPD, articles 5, 6 et 9, texte reproduit par la CNIL.
(4) CNIL, Mobiliser la base légale de l’intérêt légitime pour développer un système d’IA, 19 juin 2025.
(5) CNIL, Ce qu’il faut savoir sur l’analyse d’impact relative à la protection des données.
(6) RGPD, articles 24, 28, 30, 35, 36, 38 et 39, texte reproduit par la CNIL.
(7) RGPD, chapitre V, transferts de données, texte reproduit par la CNIL.
(8) RGPD, articles 12 à 22, information et droits, texte reproduit par la CNIL.