Registre des traitements (art. 30 RGPD) et IA : la ligne à copier

Dernière mise à jour : 2026-10-11

Une ligne de registre par finalité, avec la pseudonymisation locale comme mesure technique ; le modèle de ligne est ci-dessous.

Ce guide ne constitue pas un avis juridique. Il aide à rédiger une ligne de registre à partir de ce que fait ndaact.ai. Les rubriques marquées « À compléter » dépendent de votre situation : seul·e vous, avec votre DPO ou un conseil qualifié, pouvez les établir.

Ce que demande l’article 30

L’article 30, paragraphe 1, du RGPD impose au responsable du traitement de tenir un registre écrit, y compris sous forme électronique, qui comporte : son identité et ses coordonnées, les finalités, les catégories de personnes concernées et de données, les catégories de destinataires, les transferts vers un pays tiers le cas échéant, les délais d’effacement et une description générale des mesures de sécurité (ces deux derniers « dans la mesure du possible »). Le registre est mis à la disposition de l’autorité de contrôle sur demande.

Le paragraphe 5 écarte les organisations de moins de 250 employés, sauf si le traitement est susceptible de comporter un risque pour les droits et libertés des personnes, s’il n’est pas occasionnel ou s’il porte sur des catégories particulières de données (santé, par exemple). Un cabinet qui soumet régulièrement des dossiers à un assistant IA peut donc être concerné.

La CNIL propose un modèle de registre simplifié au format ODS. Ses rubriques reprennent celles de l’article.

Ce que vous devez inscrire

Utiliser ChatGPT ou Claude sur des documents de travail est un traitement de données personnelles : les noms, coordonnées et identifiants des personnes citées dans le texte sont transmis au fournisseur du modèle. Une ligne par finalité suffit : « rédiger des courriers », « résumer des dossiers » et « préparer des conclusions » sont trois lignes si leurs données ou leurs destinataires diffèrent.

Le modèle de ligne

Copiez le tableau dans votre registre, puis complétez chaque cellule marquée « À compléter ». Les autres cellules décrivent le comportement de ndaact.ai ; relisez-les et adaptez-les à votre usage réel.

RubriqueContenu proposé
Nom du traitementUtilisation d'un outil de caviardage avant envoi à un LLM (ChatGPT, Claude)
Responsable du traitement et contact (art. 30.1.a)À compléter : nom, coordonnées, DPO le cas échéant
Finalité (art. 30.1.b)Exemple à adapter : rédiger, résumer ou analyser des documents professionnels avec un assistant IA, en remplaçant par des marqueurs les données identifiantes détectées avant l'envoi
Base légaleÀ compléter. L'article 30, paragraphe 1, n'exige pas cette rubrique, mais votre analyse de licéité doit exister ailleurs
Personnes concernées (art. 30.1.c)À compléter selon votre activité : clients, patients, contreparties, collaborateurs, personnes citées dans les documents
Catégories de données (art. 30.1.c)Données contenues dans les textes soumis : identité, coordonnées, identifiants (numéro de sécurité sociale, IBAN, numéros d'entreprise), données de santé le cas échéant. Les entités détectées sont remplacées par des marqueurs avant l'envoi ; une entité non détectée part en clair. À compléter avec vos catégories réelles
Destinataires (art. 30.1.d)Le fournisseur du modèle utilisé (à nommer), qui reçoit le texte avec des marqueurs à la place des entités détectées. L'éditeur de ndaact.ai ne reçoit pas le contenu des textes
Transferts hors UE (art. 30.1.e)À compléter selon le contrat et les paramètres de votre fournisseur. Ne présumez pas l'absence de transfert
Durée de conservation et effacement (art. 30.1.f)À compléter. Côté fournisseur : durée définie par vos paramètres de compte et son contrat. Côté poste : le journal d'audit local reste tant que vous ne le supprimez pas
Mesures de sécurité (art. 30.1.g)Pseudonymisation locale par marqueurs avant envoi, sur le poste de l'utilisateur. Table de correspondance marqueur-valeur dans une base locale chiffrée (AES-256). Dans l'extension, envoi bloqué si la protection est indisponible, sauf désactivation volontaire par l'utilisateur. Journal d'audit local chaîné par empreinte. Limite à mentionner : la détection peut manquer des entités

Ce que fournit le journal d’audit local

L’application de bureau tient un journal local, en ajout seul, chaîné par empreinte SHA-256. Pour chaque opération, il enregistre l’horodatage, le fournisseur, l’état de la requête, les volumes échangés, et pour chaque entité détectée son type et sa position dans le texte. L’écran « Journal » de l’application affiche le nombre d’entités par catégorie. La valeur d’origine n’y figure pas.

Ce journal documente la mesure technique de la dernière rubrique : il montre que des entités ont été détectées et remplacées, à quelle date et dans quelle catégorie.

Ce que le journal ne fournit pas

  • Il ne contient pas les valeurs d’origine ni le texte des prompts.
  • Il n’identifie pas la personne qui a fait l’opération : il enregistre le poste, sans nom d’utilisateur.
  • Il ne prouve pas qu’aucune entité n’est restée en clair : il ne liste que ce qui a été détecté.
  • Il ne remplace pas le registre. Le registre est un document que vous rédigez et tenez à jour ; le journal en est une pièce technique.
  • À la date de ce guide, l’application n’offre pas de bouton d’export du journal d’audit mis en forme pour un DPO ou un contrôle.

Avant d’utiliser la ligne

  1. Copiez le tableau dans votre registre, une ligne par finalité.
  2. Complétez les cellules « À compléter » et vérifiez que le fournisseur du modèle figure bien parmi les destinataires.
  3. Faites relire la ligne par votre DPO ou un conseil, en particulier la base légale et les transferts.

Source : RGPD, article 30, règlement (UE) 2016/679 du 27 avril 2016 ; CNIL, « Le registre des activités de traitement », 13 avril 2018.