La mise à jour de Genmod publiée le 26 août 2026 par la Commission nationale de l’informatique et des libertés donne une portée très concrète à une question qui dépasse le seul choix d’un outil : que doit pouvoir démontrer une entreprise lorsqu’elle télécharge, modifie ou déploie un modèle d’intelligence artificielle en source ouverte ? Avec Genmod, la CNIL rend plus simple l’exploration de la généalogie des modèles, c’est-à-dire la recherche de leurs ascendants et de leurs descendants. Cette évolution intervient alors que les modèles peuvent être adaptés par un nouveau jeu de données, combinés à d’autres modèles, puis redistribués sous une nouvelle version.
Pour une société, le risque n’est pas limité à une réponse inexacte produite par un chatbot. Un modèle peut avoir mémorisé une donnée personnelle provenant de son entraînement ou d’un ajustement ultérieur. Une personne peut ensuite demander l’accès aux informations la concernant, leur rectification, leur effacement, la limitation du traitement ou s’opposer à certains usages. L’entreprise doit alors identifier les acteurs de la chaîne, retrouver la version du modèle, déterminer la source de la donnée, apprécier son rôle juridique et répondre dans les délais.
La source ouverte ne dispense donc pas d’un dossier de conformité. Elle facilite l’accès au modèle, mais elle ne transfère pas automatiquement la responsabilité au premier fournisseur ni ne transforme une licence logicielle en autorisation générale de traiter des données personnelles. L’enjeu est de passer d’un modèle téléchargé à un modèle documenté, testable et gouverné.
Le présent article expose la méthode à suivre pour une entreprise qui souhaite déployer un modèle open source sans perdre la maîtrise de ses preuves, de ses contrats et de ses réponses aux personnes concernées.
Lorsque la demande se transforme en litige entre l’entreprise, son client ou son prestataire, les règles de conservation et de présentation des preuves rejoignent celles du contentieux commercial à Paris : les versions, contrats, journaux et échanges utiles doivent être identifiés avant leur disparition.
I. IA open source et données personnelles : le RGPD s’applique-t-il à votre modèle ?
A. Quand un modèle open source mémorise-t-il des données personnelles ?
La première question ne consiste pas à savoir si le modèle est présenté comme « open source », « open weights » ou librement téléchargeable. Il faut déterminer ce que le modèle contient réellement et ce qu’une personne raisonnablement équipée peut en extraire. Le règlement général sur la protection des données définit largement la donnée personnelle : l’article 4, paragraphe 1, du RGPD vise « toute information se rapportant à une personne physique identifiée ou identifiable ». Le même texte définit le traitement comme toute opération appliquée à des données personnelles, notamment la collecte, la conservation, l’utilisation, la diffusion, la limitation, l’effacement ou la destruction. Le texte intégral du règlement (UE) 2016/679 doit être lu avec ces définitions.
Un paramètre mathématique ne ressemble pas à un nom, une adresse ou un numéro de téléphone. Cette différence visuelle n’est pourtant pas décisive. Si le modèle peut restituer un extrait de document, associer une personne à une caractéristique rare, reproduire une photographie ou permettre une inférence sur l’appartenance d’un individu à la base d’entraînement, l’analyse porte sur le risque d’identification et d’extraction, non sur l’apparence du fichier. La CNIL rappelle dans sa fiche sur le statut des modèles que « les modèles d’IA peuvent être anonymes : le RGPD ne leur est alors pas applicable », mais elle précise aussi que l’anonymat suppose une vraisemblance d’identification insignifiante dans le contexte considéré.
La fiche de la CNIL consacrée à l’analyse du statut d’un modèle demande d’examiner la possibilité de régurgitation, les attaques par extraction, l’inférence d’appartenance, la reconstruction ou l’inversion du modèle. Elle invite également à tenir compte de la taille du jeu d’entraînement, des données rares, des doublons, du nombre de paramètres, du fine-tuning et des fonctionnalités de génération. Une entreprise qui importe un modèle déjà entraîné ne peut pas remplacer cette analyse par une mention générale du fournisseur indiquant que le modèle est sûr. Elle doit conserver cette mention, vérifier son périmètre et apprécier le système final qu’elle met à disposition.
Dans sa présentation de Genmod du 26 août 2026, la CNIL explique que « les modèles d’IA publiés en source ouverte peuvent être téléchargés, modifiés, spécialisés à l’aide de nouvelles données ou combinés avec d’autres modèles, avant d’être à nouveau mis à disposition ». Cette description est essentielle pour l’entreprise : le modèle déployé n’est pas nécessairement identique au modèle téléchargé. Un fine-tuning avec les tickets du service client, les contrats, les dossiers de recrutement ou les comptes rendus de réunions crée une nouvelle étape de traitement. Le modèle dérivé doit avoir son propre identifiant, sa propre version et son propre dossier de risques.
Le premier réflexe doit être de distinguer trois objets : le jeu de données d’entraînement, le modèle de base et le système d’IA utilisé par les salariés ou les clients. Le jeu de données peut contenir des informations nominatives ; le modèle peut en mémoriser certaines ; le système peut encore conserver les prompts, les pièces jointes, les réponses, les journaux de connexion et les évaluations humaines. Chacun de ces objets peut relever du RGPD avec des finalités, des durées de conservation, des responsables et des mesures de sécurité différents.
La base légale doit être définie pour chaque étape. Le consentement n’est pas la seule voie, mais l’intérêt légitime, l’exécution d’un contrat, l’obligation légale ou l’intérêt public ne sont pas des formules automatiques. L’entreprise doit identifier l’intérêt poursuivi, démontrer la nécessité des données et mettre en balance cet intérêt avec les droits et libertés des personnes. Une collecte massive de contenus accessibles en ligne ne devient pas licite par le seul fait qu’elle est techniquement possible. Les données sensibles, les données de mineurs, les informations couvertes par le secret professionnel et les documents confidentiels appellent une analyse renforcée.
La limitation des finalités doit rester opérationnelle. Une base constituée pour répondre aux demandes internes ne peut pas être réutilisée sans analyse pour entraîner un modèle commercial destiné à des clients externes. Une entreprise qui achète une solution hébergée doit vérifier si le prestataire réutilise les prompts, les fichiers ou les sorties pour améliorer son propre modèle. La réponse doit figurer dans les conditions contractuelles, dans la documentation technique et dans les paramètres du service ; une simple promesse orale ne suffit pas pour reconstituer la preuve.
Le principe de responsabilité impose de pouvoir expliquer les choix effectués. L’article 57 de la loi n° 78-17 du 6 janvier 1978 dispose que le responsable du traitement « met en œuvre des mesures techniques et organisationnelles appropriées pour s’assurer et être en mesure de démontrer que le traitement est effectué conformément » au RGPD et à la loi. Le même article renvoie au registre des activités de traitement. Pour un modèle open source, le registre doit faire apparaître le fournisseur du modèle, le dépôt ou la source de téléchargement, les jeux de données ajoutés, l’usage prévu, les personnes ayant accès au système, les transferts éventuels et la procédure de réponse aux droits.
La sécurité ne se résume pas à chiffrer le disque. Il faut empêcher qu’un utilisateur puisse provoquer la restitution de données d’entraînement, limiter les accès aux poids du modèle, séparer l’environnement d’essai de la production, journaliser les téléchargements et maîtriser les connecteurs vers les outils externes. Les tests doivent porter sur les scénarios plausibles : question directe sur une personne, demande de continuation d’un texte, attaque par prompts répétés, accès d’un salarié à une version ancienne, export d’une base de tickets ou réutilisation d’un modèle dérivé par une filiale.
Enfin, l’argument selon lequel le modèle serait « anonyme » doit être relié à un protocole. La CNIL recommande de documenter les mesures prises lors de l’entraînement et, dans de nombreux cas, les résultats de tests d’attaques en réidentification. Si l’entreprise ne peut pas expliquer quand le test a été réalisé, sur quelle version, avec quelles données et selon quels scénarios, elle ne dispose pas d’une position défendable en cas de demande ou de contrôle.
B. Qui répond de la collecte, du modèle dérivé et de la demande d’effacement ?
La qualification des rôles s’effectue à partir des décisions concrètes. Le fournisseur qui choisit la finalité du développement, les sources d’entraînement et les capacités du modèle peut être responsable du traitement. L’entreprise qui sélectionne un jeu de données interne pour réaliser un ajustement et décide de l’usage du système peut l’être également. Le prestataire qui exécute des opérations sur instructions documentées peut être sous-traitant. Plusieurs acteurs peuvent encore déterminer ensemble les finalités et les moyens : une responsabilité conjointe doit alors être envisagée.
La CNIL indique que le fournisseur, le distributeur, l’importateur et le déployeur peuvent avoir des obligations distinctes, mais qu’un acteur ne peut pas se déclarer extérieur à la chaîne simplement parce qu’il n’a pas créé le modèle de base. Le rôle dépend du traitement considéré. Le fournisseur de la version initiale peut être responsable du développement ; l’entreprise qui incorpore le modèle à son logiciel peut être responsable du déploiement ; l’hébergeur peut être sous-traitant pour certains flux ; la même société peut changer de rôle selon la finalité et les moyens de l’opération.
Dans les contrats, la licence de logiciel et la clause de protection des données doivent être séparées. La licence peut autoriser la copie, la modification ou la redistribution du code et des poids ; elle ne règle pas la licéité de la collecte, l’information des personnes, le traitement de données sensibles, la conservation des journaux ni l’exercice du droit d’effacement. Le Code civil, article 1103, rappelle que « les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits ». Cette force obligatoire rend les annexes techniques déterminantes : versions couvertes, sous-traitants autorisés, lieu d’hébergement, procédure d’incident, coopération aux demandes et suppression des copies doivent y être précisés.
Le contrat doit aussi anticiper le modèle dérivé. Une entreprise peut fine-tuner un modèle avec un jeu de données appartenant à un client, puis transmettre les poids à un intégrateur. Il faut savoir si le client autorise cette opération, qui conserve les données originales, si le modèle dérivé peut être réutilisé pour d’autres clients et comment une demande d’effacement est répercutée. L’article 1194 du Code civil prévoit que « les contrats obligent non seulement à ce qui y est exprimé, mais encore à toutes les suites que leur donnent l’équité, l’usage ou la loi ». Une chaîne de traitement silencieuse, non décrite dans les annexes, expose les parties à une contestation sur le périmètre de leurs obligations.
Le traitement d’une demande individuelle doit commencer par l’identification de l’objet exact. Une personne peut demander l’accès à son compte client dans la base de tickets ; elle peut soutenir qu’une réponse générée reprend une information fausse ; elle peut demander la suppression de ses données d’utilisation ; elle peut encore contester une décision prise à partir d’un profilage. Ces demandes ne produisent pas toutes les mêmes effets sur le modèle. L’entreprise doit distinguer les données sources, les journaux du système, les sorties générées et les paramètres qui pourraient avoir mémorisé une information.
Le droit d’accès est organisé, pour les traitements relevant de la loi Informatique et libertés, par l’article 49 de la loi n° 78-17. Il renvoie à l’article 15 du RGPD et prévoit qu’« en cas de risque de dissimulation ou de disparition des données à caractère personnel, le juge compétent peut ordonner, y compris en référé, toutes mesures de nature à éviter cette dissimulation ou cette disparition ». L’entreprise doit donc préserver les journaux et les versions pertinentes dès qu’un litige est prévisible. Effacer les logs pour réduire le stockage, après réception d’une demande, peut détruire la preuve nécessaire à la réponse ou à la défense.
Une rectification n’implique pas toujours qu’une sortie ancienne puisse être réécrite instantanément. L’article 50 de la loi n° 78-17 indique que « le droit de rectification s’exerce dans les conditions prévues à l’article 16 du règlement (UE) 2016/679 ». Si l’information fausse se trouve dans une fiche source, l’entreprise peut la corriger et empêcher sa réutilisation. Si elle est seulement une inférence produite par un modèle, il faut établir la nature du traitement, le lien avec la personne et la mesure technique permettant d’éviter la répétition. Le Conseil d’État a rappelé, dans sa décision du 30 septembre 2025, n° 497566, que le droit de rectification ne s’étend pas automatiquement aux appréciations ou autres données personnelles subjectives figurant dans un traitement. Cette distinction ne dispense pas d’examiner une sortie erronée, mais elle évite de présenter tout résultat probabiliste comme une donnée source rectifiable.
Le droit à l’effacement obéit à l’article 17 du RGPD et à l’article 51 de la loi n° 78-17. Ce dernier dispose que « le droit à l’effacement s’exerce dans les conditions prévues à l’article 17 du règlement (UE) 2016/679 ». Une demande portant sur une donnée d’entraînement doit être instruite à partir de la source, de la version du jeu de données, de la copie conservée, des dérivés et des modèles auxquels elle a été transmise. La suppression du fichier d’origine ne prouve pas que l’information a disparu des poids du modèle. À l’inverse, l’existence d’un modèle dérivé ne signifie pas que l’extraction de la donnée est possible : cette question doit être testée et documentée.
La réponse peut conduire à plusieurs mesures : supprimer la source et les copies, désactiver une version, filtrer certaines requêtes, réentraîner le modèle, corriger la base de connaissances, suspendre un connecteur, informer les destinataires du traitement ou expliquer pourquoi une exception s’applique. La décision doit être motivée par les faits et la règle applicable. Une entreprise qui répond seulement « le modèle est open source, nous ne pouvons rien faire » prend le risque de confondre la disponibilité technique du modèle avec l’absence d’obligation juridique.
Les délais doivent être suivis par un responsable identifié. Le principe général du RGPD impose une réponse sans retard injustifié et, en principe, dans le mois, avec possibilité de prolongation lorsque la demande est complexe, à condition d’en informer la personne. La loi Informatique et libertés complète ce dispositif. L’article 53 encadre le droit à la limitation en prévoyant que « le droit à la limitation du traitement s’exerce dans les conditions prévues à l’article 18 du règlement (UE) 2016/679 ». L’article 56 précise que « le droit d’opposition s’exerce dans les conditions prévues à l’article 21 du règlement (UE) 2016/679 ». Chaque demande doit donc être enregistrée à sa date de réception, même si l’entreprise estime d’abord qu’elle ne concerne pas directement le modèle.
Lorsque plusieurs responsables interviennent, l’accord de répartition ne doit pas laisser la personne sans interlocuteur. L’entreprise qui exploite le système doit pouvoir recevoir la demande, vérifier l’identité, rechercher les sources pertinentes et coordonner la réponse avec le fournisseur. Si le fournisseur refuse de communiquer la version ou le résultat d’un test, cette difficulté doit être signalée et encadrée par le contrat. Elle ne justifie pas, à elle seule, une réponse incomplète à la personne.
II. Demande RGPD, audit et preuve : que faire avant de déployer un modèle open source ?
A. Quelles preuves conserver pour tracer la généalogie et répondre dans le délai ?
Le dossier de déploiement doit être construit avant la mise en production. Il doit commencer par une fiche d’identité du modèle : nom, dépôt d’origine, URL, licence, date et heure du téléchargement, empreinte cryptographique, format, nombre de paramètres, version du tokenizer, dépendances, documentation disponible et éventuelles restrictions. Toute modification doit créer une nouvelle version, même si le fichier porte un nom proche. L’entreprise doit conserver l’empreinte du modèle de base et celle du modèle déployé afin de démontrer qu’une demande a été examinée sur la bonne version.
La généalogie ne doit pas être réduite à un lien vers une page de téléchargement. La mise à jour Genmod de la CNIL permet d’explorer des liens entre modèles publiés en source ouverte, ascendants et descendants. Pour chaque modèle intégré, l’entreprise doit noter le modèle parent, les étapes de combinaison ou de fine-tuning, la source des données ajoutées, la personne ou l’équipe qui a validé l’opération, les tests réalisés et la destination du résultat. Si le modèle est ensuite transmis à un prestataire, la date de transfert, la version et les limitations d’usage doivent être conservées.
La fiche de données doit décrire les catégories de personnes concernées, les types d’informations, la provenance, la base légale, la période couverte, la méthode de sélection, les exclusions et les opérations de nettoyage. Il faut consigner les recherches de doublons, les suppressions de données rares ou excessivement identifiantes, la pseudonymisation, les filtres de contenu et les contrôles de données sensibles. Le dossier doit aussi expliquer ce qui n’a pas pu être vérifié : un dépôt public peut ne pas fournir la liste complète des données d’entraînement. Cette limite doit conduire à une mesure de réduction du risque, pas à une déclaration générale de conformité.
Une entreprise qui utilise des données issues de ses clients doit conserver les preuves de la relation contractuelle et de l’information fournie. L’article 1104 du Code civil impose que « les contrats doivent être négociés, formés et exécutés de bonne foi » et précise que cette disposition est d’ordre public. Pour l’IA, la bonne foi contractuelle implique de ne pas présenter comme un simple outil de recherche un système qui réutilise les documents pour entraîner un modèle, ni comme une suppression définitive une opération qui ne retire que la copie visible dans l’interface.
Les tests doivent être reproductibles. Il faut archiver le jeu de prompts, la version du modèle, les paramètres de génération, le contexte fourni, le résultat, la date, l’opérateur et la conclusion. Les tests peuvent rechercher une régurgitation directe, une association entre nom et information, une inférence d’appartenance, une extraction par requêtes répétées ou une inversion. Le rapport doit indiquer le périmètre de l’essai et ses limites. Un test négatif ne démontre pas une absence absolue de mémorisation ; il montre seulement ce qui n’a pas été observé avec le protocole employé.
La documentation de sécurité doit correspondre à l’usage réel. Un modèle interne réservé à quelques salariés n’est pas exposé comme une API ouverte au public. Le risque varie selon la possibilité d’obtenir les poids, de multiplier les requêtes, d’ajouter un document dans le contexte, de consulter les journaux ou de connecter la solution au système d’information. L’accès limité peut réduire la vraisemblance d’une extraction, mais il ne suffit pas, à lui seul, à démontrer l’anonymat du modèle. Les habilitations, les secrets, les journaux et les règles de conservation doivent être contrôlés séparément.
Le registre des demandes doit permettre de suivre une affaire de bout en bout. Il doit contenir la date de réception, l’identité vérifiée, l’objet de la demande, les sources consultées, la version du modèle concernée, les services interrogés, la mesure prise, les destinataires informés, la date de réponse et le motif d’un éventuel refus ou d’une prolongation. L’article 54 de la loi n° 78-17 rappelle que l’obligation de notification en cas de rectification, d’effacement ou de limitation s’exerce dans les conditions prévues à l’article 19 du RGPD. La personne doit recevoir une réponse compréhensible, pas une conclusion technique dépourvue d’explication.
Le responsable doit définir un circuit d’escalade. Une demande d’accès portant sur les données d’un salarié, d’un client ou d’un candidat peut toucher au secret des affaires, au secret professionnel, aux droits de tiers ou à une enquête. Ces limites ne doivent pas être invoquées sans examen. Il faut déterminer quelles informations peuvent être communiquées, quelles mentions peuvent être occultées, quelle exception est applicable et si une copie partielle reste possible. En cas de désaccord, l’entreprise doit conserver la demande, sa réponse et les éléments justifiant son choix.
Le droit de limitation peut être utilisé comme mesure provisoire lorsque l’exactitude ou la licéité d’un traitement est contestée. Dans ce cas, la société peut suspendre la réutilisation d’un jeu de données, bloquer une version du modèle ou empêcher un service de prendre une décision à partir du résultat, le temps de procéder à l’analyse. Cette suspension doit être techniquement effective. Une simple mention dans un ticket, alors que le modèle continue à interroger la source, ne suffit pas.
Les données de sortie doivent être conservées avec discernement. Une réponse générée peut devenir une pièce dans une relation contractuelle, un dossier disciplinaire, une décision de crédit ou un litige commercial. Sa conservation doit reposer sur une finalité et une durée. Le Code civil, article 1353, énonce que « celui qui réclame l’exécution d’une obligation doit la prouver ». La preuve d’un contrôle humain, d’une correction, d’une demande transmise au fournisseur ou d’une désactivation peut être décisive. Elle ne dispense toutefois pas de minimiser les données et de protéger les personnes étrangères au litige.
La Cour de cassation, dans son arrêt du 25 novembre 2020, pourvoi n° 17-19.523, a retenu que les adresses IP permettant d’identifier indirectement une personne sont des données personnelles et que leur collecte par un fichier de journalisation constitue un traitement. Cette décision est consultable sur le site officiel de la Cour de cassation. La leçon pratique est transposable aux journaux d’un système d’IA : les prompts, identifiants, adresses IP, horaires, pièces jointes et traces d’administration ne sont pas de simples fichiers techniques. Ils doivent être intégrés à l’analyse de conformité et à la politique de conservation.
La preuve doit aussi rester loyale et proportionnée. Dans son arrêt du 14 février 2024, pourvoi n° 22-23.073, la chambre sociale de la Cour de cassation a validé une production de données après avoir relevé que la cour d’appel avait mis en balance de manière circonstanciée le droit à la vie privée et le droit de l’employeur à la preuve, en vérifiant que les éléments étaient indispensables et proportionnés. La décision figure sur Légifrance. Pour une entreprise, un audit d’IA doit donc éviter la collecte indifférenciée de tous les échanges : il faut définir les éléments nécessaires, leur accès et leur durée.
Avant la mise en production, un comité doit décider si une analyse d’impact relative à la protection des données est nécessaire. Le document doit couvrir les personnes vulnérables, les conséquences d’une sortie erronée, la possibilité de décision automatisée, les transferts, les fournisseurs, les droits d’accès et d’effacement, les risques de fuite et les mesures résiduelles. La fiche de la CNIL sur le statut des modèles insiste sur l’importance de documenter l’analyse, y compris lorsque l’entreprise conclut qu’un modèle n’est pas soumis au RGPD. Cette conclusion doit être révisée si le modèle est fine-tuné, exposé à un public plus large ou connecté à une nouvelle source.
B. Quels recours et quelles précautions pour une entreprise à Paris et en Île-de-France ?
Lorsqu’une entreprise est établie à Paris ou intervient en Île-de-France, la première réponse doit rester opérationnelle : désigner un interlocuteur, préserver la version du modèle, geler les suppressions automatiques de logs, sécuriser les dépôts, vérifier le contrat du fournisseur et établir un calendrier. La localisation ne change pas les règles du RGPD, mais elle peut influencer l’organisation du dossier, le lieu des réunions, le tribunal compétent en cas de litige commercial et la coordination avec le DPO ou le conseil de l’entreprise.
Le dirigeant doit obtenir, dans les premières heures d’une alerte, cinq informations : quelle version du modèle est en cause, quelles données ont été utilisées, qui a décidé de l’opération, qui a accès aux résultats et quelle personne demande quelle mesure. Il faut ensuite identifier les flux hors de l’Union européenne, les sous-traitants secondaires, les copies locales et les connexions aux outils de messagerie, CRM ou ressources humaines. Cette cartographie évite de répondre sur la seule interface alors que la donnée persiste dans un stockage, un cache, un journal ou une version antérieure.
Une plainte peut être adressée à la CNIL lorsque la personne estime que ses droits n’ont pas été respectés. Le contrôle de l’autorité peut porter sur l’information, la base légale, la réponse à une demande, la sécurité, le registre ou la coopération avec les personnes. L’article 20 de la loi n° 78-17 autorise le président de la CNIL à avertir un responsable de traitement ou un sous-traitant lorsque les opérations envisagées sont susceptibles de violer le RGPD ou la loi. En cas de manquement, la CNIL peut notamment mettre en demeure de satisfaire les demandes de la personne, de mettre le traitement en conformité, de rectifier ou d’effacer des données, ou de limiter le traitement. Le texte officiel est disponible sur Légifrance, article 20 de la loi Informatique et libertés.
La même disposition prévoit qu’un délai de justification peut, en cas d’urgence, être fixé à vingt-quatre heures. Elle permet aussi la saisine de la formation restreinte, une injonction assortie d’une astreinte et, dans les conditions prévues par le RGPD, une amende administrative. Une entreprise qui reçoit une demande complexe doit répondre avec précision, même si l’enquête technique n’est pas terminée ; elle peut expliquer les opérations en cours, les limites rencontrées et le calendrier de la réponse. Le silence ou la réponse standardisée augmente le risque procédural.
La jurisprudence administrative récente rappelle l’importance de l’exercice effectif des droits. Dans sa décision du 16 juillet 2026, n° 507759, le Conseil d’État a examiné une contestation relative à un refus d’accès et a rappelé que le pouvoir d’appréciation de la CNIL, lorsqu’il se prononce sur des droits tels que l’accès, la rectification, l’effacement, la limitation ou l’opposition, s’exerce sous le contrôle entier du juge de l’excès de pouvoir. La décision peut être consultée sur Légifrance. Une entreprise doit donc préparer un dossier lisible, daté et communicable, plutôt que compter sur une explication orale de son équipe technique.
Le contentieux civil peut s’ajouter au contrôle de la CNIL. L’article 9 du Code civil affirme que « chacun a droit au respect de sa vie privée » et autorise le juge à prescrire, y compris en référé lorsqu’il y a urgence, les mesures propres à empêcher ou faire cesser une atteinte. Une personne ou une société peut demander la cessation d’une diffusion, la conservation de preuves ou une mesure de retrait lorsque la restitution d’une information personnelle cause un dommage. Le texte de l’article 9 du Code civil doit être rapproché de la nature du traitement et de la mesure sollicitée.
Une faute dans le choix du jeu de données, l’absence de mesures de sécurité, la transmission non autorisée à un prestataire ou le maintien d’une sortie après une alerte peuvent aussi nourrir une demande indemnitaire. L’article 1240 du Code civil prévoit que « tout fait quelconque de l’homme, qui cause à autrui un dommage, oblige celui par la faute duquel il est arrivé à le réparer ». Le lien entre la faute, le dommage et le traitement devra être démontré. Les rapports de test, les tickets, les versions et les décisions de gouvernance servent alors à expliquer ce qui a été fait, quand et par qui.
Les décisions de justice relatives aux données personnelles montrent que la qualification dépend de l’usage. Dans son arrêt du 3 octobre 2024, pourvoi n° 21-20.979, la deuxième chambre civile de la Cour de cassation a considéré, dans un litige de preuve, que la communication ordonnée par le juge de documents comportant des données personnelles pouvait répondre aux exigences de licéité lorsqu’elle était indispensable et proportionnée. La décision est accessible sur Légifrance. Pour un système d’IA, l’entreprise doit donc être capable de montrer pourquoi un document a été traité, pourquoi il était nécessaire et quelles mesures ont limité l’exposition des tiers.
Le recours contractuel doit être préparé en parallèle. Si un fournisseur refuse de communiquer la documentation d’une version, d’effacer une copie ou de coopérer à une demande, l’entreprise doit vérifier les clauses de service, les niveaux d’engagement, les obligations de notification, la loi applicable et la clause attributive de compétence. Les contrats ne doivent pas seulement répartir le coût d’une violation ; ils doivent donner accès aux éléments qui permettent de prévenir et de corriger cette violation. Une clause qui impose la coopération sous un délai court, la conservation d’un historique de versions et la notification des fine-tunings réduit le risque de blocage.
Pour une société parisienne, une réunion de crise efficace peut être organisée autour de quatre fonctions : direction ou direction juridique, DPO ou référent données, responsable technique et représentant de l’activité concernée. Le service juridique qualifie la demande et les risques ; le DPO vérifie les droits et délais ; l’équipe technique retrouve les versions, les sources et les traces ; le métier explique la finalité et les conséquences de l’usage. Les décisions doivent être consignées dans un procès-verbal ou un ticket sécurisé. Cette organisation est utile pour une PME comme pour un groupe, à condition d’adapter le niveau de documentation à la nature du traitement.
La réponse au demandeur doit rester intelligible. Elle peut expliquer qu’une donnée a été supprimée de la source, que les requêtes vers une version ont été suspendues, qu’un modèle sera réentraîné, que certaines informations ne peuvent pas être communiquées pour protéger les droits d’un tiers ou qu’une analyse complémentaire est nécessaire. Elle doit indiquer les voies de réclamation lorsque la réponse est négative ou partielle. Une formule technique telle que « les poids sont non interprétables » ne répond pas à elle seule à la question de savoir si l’entreprise traite encore une information concernant la personne.
Si la demande concerne une décision automatisée produisant des effets juridiques ou affectant significativement une personne, l’entreprise doit vérifier l’article 22 du RGPD, les exceptions applicables, l’intervention humaine et l’information due à la personne. Un outil d’aide à la décision n’est pas automatiquement une décision exclusivement automatisée ; inversement, appeler « validation humaine » un clic machinal ne suffit pas. Il faut pouvoir démontrer que la personne chargée de la décision a accès aux éléments pertinents, peut s’écarter de la recommandation et dispose du temps et de la compétence nécessaires pour le faire.
Enfin, la gouvernance doit prévoir la sortie du modèle. Lorsqu’une version est remplacée, l’entreprise doit définir les conditions de retrait, la conservation des preuves, le traitement des demandes qui la concernent encore et la suppression des copies inutiles. Un modèle décommissionné peut rester dans un dépôt, une sauvegarde ou le poste d’un développeur. La procédure doit préciser qui vérifie ces emplacements et comment la preuve de suppression ou de maintien légal est établie. La conformité ne s’arrête donc pas au jour du déploiement : elle accompagne toute la vie du modèle et de sa généalogie.
Conclusion
La mise à jour de Genmod rend visible une réalité juridique et technique : un modèle open source peut avoir des ascendants, des descendants, des jeux de données ajoutés et des usages différents selon l’entreprise qui le déploie. Le bon réflexe consiste à documenter la version, la provenance, les transformations, les tests et les responsables avant l’ouverture du service.
Lorsqu’une personne exerce un droit, l’entreprise doit rechercher la donnée dans toute la chaîne : source, base intermédiaire, journaux, système, modèle et versions dérivées. Elle doit répondre dans le délai, préserver les preuves, motiver les limites et coopérer avec ses fournisseurs. Les articles 49, 50, 51, 53, 54, 56 et 57 de la loi Informatique et libertés, les articles 9, 1103, 1104, 1194, 1240 et 1353 du Code civil, ainsi que la jurisprudence citée, offrent un cadre pour organiser cette réponse.
Une entreprise de Paris ou d’Île-de-France qui prépare aujourd’hui ce dossier peut encore choisir ses sources, réduire les données, encadrer le fine-tuning et prévoir le retrait d’une version. Une fois le modèle exposé au public ou relié à des données clients, le coût de la reconstitution augmente rapidement. La traçabilité n’est donc pas un document accessoire : elle devient la condition pratique d’une réponse fiable, d’un audit défendable et d’un recours maîtrisé.
Besoin d’un avis rapide sur votre dossier
Vous pouvez bénéficier d’une consultation téléphonique en 48 heures avec un avocat du cabinet pour analyser votre modèle, vos contrats et votre procédure de réponse aux demandes RGPD.
Pour organiser cet échange, appelez le 06 46 60 58 22 ou utilisez le formulaire de contact du cabinet. Le cabinet intervient à Paris et en Île-de-France pour les entreprises confrontées à un litige commercial, à une demande de données personnelles ou à un risque lié au déploiement d’un système d’intelligence artificielle.
Transmettez les pièces de votre dossier au cabinet. Maître Reda KOHEN vous répond personnellement sous 24 heures avec une première analyse stratégique.