Une équipe branche un modèle à son produit web, puis découvre que les prompts contiennent des courriels, des numéros de contrat et parfois des pièces jointes. Personne ne sait si le fournisseur conserve les entrées, dans quelle région les journaux résident ni comment supprimer le contenu d’une personne. Le symptôme arrive souvent après le prototype : une demande d’exercice de droit ou un incident oblige à reconstituer un flux que l’interface avait rendu invisible.
Le vrai enjeu n’est pas de trouver une case « conforme RGPD », mais de concevoir un traitement explicable, limité et exploitable. Finalité, rôles, base légale, minimisation, contrat, transferts, conservation, droits et sécurité doivent se traduire dans l’architecture et le parcours. C’est aussi ce qui permet à une application web sur mesure intégrant une IA de couper le composant sans perdre le service essentiel.
Contre-intuitivement, masquer quelques champs avant l’appel ne clôt pas le sujet. Un texte libre peut réidentifier une personne, les métadonnées peuvent rester personnelles et la sortie peut créer une nouvelle information. À l’inverse, la présence de données personnelles n’interdit pas automatiquement tout usage : elle impose une qualification juridique et des contrôles proportionnés au cas. Cet article fournit une méthode produit, à compléter par le DPO et le conseil compétent selon le contexte.
Définir la finalité avant la capacité technique
Nommer le résultat attendu et les usages exclus
Écrivez une finalité précise : proposer un résumé à l’agent avant lecture, extraire quatre champs pour préremplir un formulaire, suggérer une réponse que l’agent valide. « Améliorer l’expérience grâce à l’IA » ne permet pas de juger quelles données sont nécessaires ni d’informer correctement.
Nommez les personnes concernées, la décision suivante, l’effet de la sortie et les usages exclus. Une suggestion destinée au support ne doit pas être réutilisée pour évaluer les salariés ou profiler les clients sans nouveau cadrage. Le prototype, la validation et la production peuvent eux-mêmes constituer des traitements différents.
Définissez le parcours sans IA. Si la brique tombe, l’utilisateur peut-il continuer ? Cette alternative aide à limiter la collecte, l’autonomie et la dépendance. Elle rend aussi le consentement réellement libre lorsqu’il est envisagé, ce qui doit être apprécié avec le DPO.
Qualifier les rôles et responsabilités RGPD
L’organisation qui détermine finalités et moyens essentiels est généralement responsable du traitement. Le fournisseur peut agir comme sous-traitant pour le service, mais ses propres réutilisations peuvent modifier la qualification. Les étiquettes commerciales ne remplacent pas l’analyse des faits et du contrat.
Cartographiez client, éditeur du produit, fournisseur de modèle, hébergeur, outil d’observabilité et éventuels sous-traitants ultérieurs. Pour chacun, indiquez données reçues, action, localisation, durée et instruction. Le contrat de sous-traitance doit couvrir les exigences applicables de l’article 28, notamment sécurité, assistance et sort des données.
Attribuez aussi les responsabilités internes : métier pour la finalité et les limites, DPO pour le conseil et le contrôle, sécurité pour les risques techniques, produit pour le parcours, équipe de développement pour les garanties et run pour les incidents. Le DPO ne devient pas propriétaire unique du système.
Cartographier le flux réel des données
Partez d’une requête réelle et suivez-la : navigateur, backend, enrichissement, base de connaissances, fournisseur, outils appelés, cache, journaux, analytics et support. Ajoutez la sortie, les corrections humaines et les données dérivées. Une architecture annoncée « sans stockage » peut néanmoins conserver des traces dans plusieurs composants.
Pour chaque étape, listez catégories de données, personnes, identifiants, secrets et contenu sensible. Distinguez données de production, jeux d’évaluation et données utilisées pour améliorer le système. Les copies dans des environnements de test ou des exports d’incident font partie du flux.
Validez la carte par des preuves : configuration, logs échantillonnés, clauses, test de suppression et questions au fournisseur. Une documentation générale ne prouve pas l’option activée dans votre compte. Conservez date et version, car l’offre peut évoluer.
Choisir une base légale adaptée au traitement
La base légale dépend de la finalité, de la relation avec la personne et des effets. Contrat, obligation légale, intérêt légitime, mission d’intérêt public ou consentement ne sont pas des options interchangeables. Le consentement doit répondre à ses conditions et son retrait ne doit pas être fictif.
Documentez le raisonnement pour chaque traitement, y compris évaluation, journaux et réutilisation. Un intérêt légitime appelle l’analyse nécessaire et la mise en balance appropriée. Les catégories particulières de données exigent en plus une condition de l’article 9 lorsqu’elles sont traitées.
Ne supposez pas que la base du processus historique couvre automatiquement l’envoi à un modèle ou un nouvel usage. Vérifiez nécessité, attente raisonnable, information et impacts. Le DPO conseille et contrôle, le conseil juridique peut éclairer l’analyse, tandis que le responsable du traitement décide et documente la qualification ; le code met ensuite en œuvre ses limites.
Minimiser les données envoyées au modèle
Construisez l’entrée à partir des seuls champs utiles, plutôt que d’envoyer un dossier complet « au cas où ». Retirez identifiants directs, signatures, historique sans lien et pièces inutiles. Une pseudonymisation réduit certains risques mais les données restent personnelles si la réidentification demeure possible.
Traitez le texte libre : détection et suppression peuvent aider, sans garantir l’anonymat. Testez les erreurs de masquage et préférez parfois une synthèse structurée produite localement. Les secrets, mots de passe, tokens et données d’autres clients sont bloqués avant l’appel.
Minimisez aussi la sortie et les traces. Si seul un code catégorie est utile, ne conservez pas un raisonnement détaillé contenant des données. La journalisation garde identifiant, version, statut et preuve nécessaires ; le contenu complet relève d’un mode diagnostic autorisé et limité.
Vérifier contrat, réutilisation et sous-traitants
Lisez les conditions de l’offre exacte : usage des entrées et sorties pour améliorer les services, durée de rétention, options de contrôle, sous-traitants, assistance aux droits, notification d’incident, suppression et audit. Une politique grand public ne décrit pas toujours une offre API entreprise, et inversement.
Vérifiez si la désactivation de l’entraînement couvre aussi revue humaine, abus, télémétrie et journaux. Demandez ce qui reste conservé pour la sécurité, combien de temps et sous quelle forme. Testez les paramètres au niveau organisation et projet ; une option par défaut peut différer entre environnements.
Prévoyez la sortie : export de configuration, changement de modèle, suppression des données et preuve de fin de contrat. Une clause sans procédure technique crée une dépendance. Réévaluez lors d’un nouveau sous-traitant, d’une région ou d’une fonctionnalité.
Encadrer localisation et transferts internationaux
Identifiez où chaque composant traite les données et depuis quels pays un accès de support est possible. Une région d’hébergement ne suffit pas toujours à exclure un transfert. Le chapitre V du RGPD et la jurisprudence applicable doivent être examinés avec les mécanismes proposés.
Lorsque des clauses contractuelles types ou une décision d’adéquation sont invoquées, documentez leur périmètre et les mesures complémentaires nécessaires selon le risque. La qualification reste contextuelle ; un label « Europe » ne remplace pas l’analyse.
Réduire les données et chiffrer aide, mais un fournisseur qui doit lire le contenu pour l’inférence reçoit nécessairement le texte en clair dans son environnement d’exécution. Les promesses de chiffrement doivent donc être comprises par étape, y compris clés, accès et journaux.
Maîtriser conservation, journaux et suppression
Définissez des durées par catégorie : requêtes métier, résultats, feedback, logs de sécurité, jeux d’évaluation et incidents. « Tant que nécessaire » n’est pas un réglage. L’application applique purge ou anonymisation et surveille leurs échecs.
La suppression doit traverser copies, index vectoriels, caches, exports et fournisseurs selon les obligations et possibilités applicables. Conservez un identifiant de provenance pour localiser les dérivés. Un index sans lien vers la source rend l’exercice de droit et la correction difficiles.
Testez la procédure sur un dossier fictif : recherche, rectification, suppression, propagation et preuve. Documentez les limites techniques et juridiques. Une sauvegarde suit une politique spécifique de rétention et de restauration qui évite de réinjecter indéfiniment une donnée supprimée.
Rendre les droits des personnes réellement exerçables
L’information explique finalité, données, destinataires, durée, droits et, lorsque pertinent, logique et conséquences. Elle doit être accessible au bon moment, avec un niveau de détail compréhensible. Une mention « nous utilisons l’IA » ne décrit pas le traitement.
Le support des droits doit retrouver les entrées, sorties et données dérivées liées à la personne sans exposer celles d’autres personnes. Prévoyez correction d’une source et traitement des résultats qui en dépendaient. Rectifier le CRM sans corriger un index peut maintenir la sortie erronée.
La contestation et le recours sont intégrés au parcours lorsque la sortie influence une décision. La personne ou l’agent sait qui peut revoir, sur quelles informations et avec quel délai. Le mécanisme humain ne doit pas être une validation automatique sans pouvoir réel.
Préserver la décision humaine et le recours
L’article 22 du RGPD encadre certaines décisions fondées exclusivement sur un traitement automatisé produisant des effets juridiques ou affectant significativement. Son application dépend du cas. Ne concluez ni qu’une simple présence humaine écarte toujours le texte, ni que toute suggestion IA est une décision automatisée.
Évaluez l’autorité réelle : la personne dispose-t-elle du temps, des informations et du droit de contredire ? Voit-elle les sources et limites ? Les objectifs ou l’interface la poussent-ils à accepter ? Mesurez les corrections et les divergences, sans transformer ce suivi en surveillance individuelle.
Pour les enjeux élevés, conservez entrée, version, proposition, décision finale et motif proportionné. Un recours peut rouvrir le dossier avec une personne compétente. Le système ne modifie pas silencieusement une décision déjà notifiée.
Concevoir la sécurité propre au parcours IA
Appliquez les contrôles habituels : authentification, moindre privilège, chiffrement, secret, segmentation, journalisation et tests. Ajoutez les risques IA : injection dans les documents, exfiltration via outils, récupération de contenu d’un autre utilisateur, sortie active et dépendances non maîtrisées.
Une base documentaire filtre les résultats selon les droits avant de les transmettre. Le modèle ne décide pas seul de l’autorisation. Les outils appelés utilisent des permissions bornées, valident les paramètres et exigent confirmation pour un effet sensible. La sortie est encodée avant affichage et ne devient pas du HTML ou une commande fiable.
Testez des documents hostiles, demandes de contournement, références croisées et erreurs de fournisseur. Les scénarios de sécurité rejoignent la CI et la recette. Un incident peut couper l’outil ou le corpus concerné sans interrompre tout le produit.
Déterminer si une AIPD est nécessaire
Une analyse d’impact relative à la protection des données est requise lorsqu’un traitement est susceptible d’engendrer un risque élevé pour les droits et libertés, selon l’article 35 et les critères applicables. La présence d’IA n’entraîne pas mécaniquement le même verdict pour tous les usages.
Évaluez nature, portée, contexte et finalité : volume, vulnérabilité, surveillance, données sensibles, décision, croisement et nouveauté. Consultez les listes et recommandations de l’autorité compétente. Si l’AIPD est requise, elle précède le déploiement et vit avec le système.
Même sans obligation formelle, un registre de risques proportionné aide à relier scénario, impact, mesure et risque résiduel. L’équipe conserve la justification de sa décision et les déclencheurs de réévaluation : nouveau public, données, modèle, autonomie ou fournisseur.
Cas concret : assister la réponse du support client
Limiter l’entrée et garder l’agent responsable de l’envoi
Un support souhaite résumer un fil et proposer une réponse. Les tickets peuvent contenir coordonnées, identifiants de contrat et pièces jointes. La finalité est bornée à l’aide à la réponse ; le modèle ne décide ni remboursement ni priorité contractuelle.
Le backend extrait les messages nécessaires, retire les pièces par défaut, masque certains identifiants et récupère des extraits documentaires autorisés. L’agent voit sources et avertissement, puis modifie ou rejette. Les catégories sensibles déclenchent le parcours manuel. Le fournisseur est configuré selon le contrat retenu ; les journaux internes n’enregistrent pas le contenu complet.
Par exemple, si la proposition invente une clause ou cite une source non autorisée, alors le lot est bloqué et l’incident rejoint le jeu d’évaluation. Le pilote local impose zéro envoi automatique, une reprise disponible et un budget maximal de corrections. Ces seuils illustrent la décision du projet, pas une règle juridique universelle.
Mettre en œuvre une intégration bornée
Faire correspondre architecture et dossier de conformité
Les entrées sont construites côté serveur avec un schéma autorisé ; les sorties restent des propositions. Le propriétaire métier porte la finalité, le produit le parcours, le DPO le conseil, la sécurité les contrôles et l’équipe technique le contrat fournisseur, la journalisation et le rollback.
Créez environnements séparés, secrets, droits, quotas et drapeau d’activation. Le contrat d’interface définit timeout, refus, contenu maximal et comportement de repli. Les tests utilisent des données synthétiques ou un jeu gouverné, jamais une copie opportuniste de production.
La CI vérifie format, absence de secret, contrôle d’accès et scénarios d’injection. Une revue avant mise en production rapproche carte des flux, registre, clauses, information, AIPD éventuelle et preuves de test. Toute réserve a un owner et une limite de périmètre.
Préparer incidents, retrait et mode dégradé
Le monitoring suit disponibilité, coût, corrections, refus, violations de politique et accès aux corpus. Les alertes portent sur une action : couper une source, désactiver un cas, basculer vers le parcours manuel ou contacter le fournisseur. Les journaux soutiennent l’investigation sans dupliquer inutilement les données.
Le runbook couvre fuite suspectée, prompt contenant un secret, sortie envoyée au mauvais utilisateur, suppression non propagée et changement fournisseur. Il indique conservation des preuves, personnes à alerter et évaluation des obligations de notification avec le DPO.
Testez le retrait : désactiver le modèle, vider la file, traiter les dossiers en cours et confirmer la suppression contractuelle. Un rollback de code ne retire pas les données déjà envoyées. Le plan associe mesure technique, action fournisseur et communication métier.
Pour qui cette grille de cadrage est utile
Elle s’adresse aux responsables produit, équipes de développement, data/IA, DPO, sécurité, achats et responsables métier. Elle permet de traduire une exigence juridique en décisions vérifiables sans faire du développeur l’unique juriste ni du DPO l’unique owner technique.
Elle est prioritaire pour les textes libres, documents, décisions concernant des personnes, corpus multi-clients et outils capables d’agir. Un assistant facultatif sur contenu non personnel peut demander un dispositif plus léger. La qualification reste fondée sur les données et l’impact réels.
La grille sert aussi lors d’un changement de fournisseur ou d’une nouvelle fonctionnalité. La conformité n’est pas acquise une fois : les flux, finalités et garanties évoluent avec le produit.
Éviter les erreurs fréquentes IA et RGPD
Les erreurs classiques sont de déclarer les données anonymes sans test, de choisir le consentement par défaut, de croire qu’une région exclut tout transfert et de confondre désactivation d’entraînement avec absence de conservation. S’ajoutent les logs oubliés et les jeux d’évaluation sans provenance.
Évitez aussi le « human in the loop » décoratif, la notice générale, l’index impossible à purger et le fournisseur accepté sur une brochure. Une autre erreur consiste à collecter davantage pour améliorer plus tard, sans finalité définie.
Enfin, ne réduisez pas le RGPD à un formulaire juridique ajouté avant le go. Les droits, durées, accès et suppressions doivent fonctionner dans le code et le run. Une clause ne répare pas un produit incapable de retrouver les données.
Décider avec des seuils locaux qualifiés
Relier les seuils aux risques et aux capacités du run
Un pilote peut exiger toutes les sources autorisées, aucune donnée interdite dans les tests, suppression propagée sur les composants couverts et reprise manuelle exécutée. Il fixe un budget de corrections et une durée de traitement des exceptions selon les capacités locales.
Le seuil d’arrêt couvre fuite, accès croisé, décision sensible envoyée sans revue, suppression impossible ou contrat non respecté. Un seuil d’extension exige information validée, droits testés, risques acceptés et mode dégradé. Ces critères sont des décisions produit et conformité locales.
Bloc de décision. D’abord bloquer les données interdites ; ensuite corriger les contrôles testables ; puis limiter le cas lorsque le risque reste circonscrit ; enfin ouvrir seulement après validation des preuves. Si le risque résiduel ne peut pas être accepté, alors l’usage est refusé ou redessiné.
Plan d’action : cadrer le traitement en huit semaines
Semaines 1 et 2 — finalité et flux. Nommez résultat, personnes, données, sortie et parcours de repli. Cartographiez composants, fournisseurs, rôles et transferts. Inscrivez le traitement et les questions ouvertes.
Semaines 3 et 4 — règles et contrats. Qualifiez base légale, information, droits, durées, AIPD et relation fournisseur avec les responsables compétents. Réduisez les entrées et choisissez les données de test.
Semaines 5 et 6 — construction. Implémentez schéma d’entrée, droits, sources filtrées, traces minimales, suppression, quotas et mode dégradé. Automatisez tests de sécurité et d’accès. Rédigez le runbook.
Semaines 7 et 8 — preuve et verdict. Exécutez droits, purge, incident, panne fournisseur et rollback. Ouvrez un pilote borné. Rapprochez preuves techniques et dossier de conformité. Décidez extension, limitation, correction ou arrêt. La durée est indicative et dépend du risque et des acteurs requis.
- D’abord, nommer la finalité et les usages interdits.
- Ensuite, documenter les flux, contrats et responsabilités.
- Puis, tester minimisation, droits, suppression et reprise.
- Enfin, décider sur le risque résiduel et les preuves du run.
Consulter les sources officielles
- CNIL — IA : comment être en conformité avec le RGPD, pour les étapes de cadrage et les principes applicables.
- CNIL — questions-réponses sur l’IA générative, pour les points d’attention liés aux usages et aux données.
- EDPB — Opinion 28/2024 on certain data protection aspects related to AI models, pour l’analyse européenne de certains aspects des modèles d’IA.
- Commission européenne — cadre réglementaire de l’IA, pour le calendrier et les obligations du règlement IA selon les rôles et catégories.
Ces sources ne remplacent pas une qualification juridique du cas. Le RGPD et le règlement IA ont des champs et obligations distincts qui peuvent se cumuler ; leur application dépend du système, du rôle et de l’usage.
Relier conformité, responsabilité et évaluation
Le guide sur la responsabilité humaine dans un workflow IA approfondit l’autorité, le recours et les traces. Celui consacré à la mesure de valeur d’une brique IA aide à relier risque et résultat.
La conformité devient durable lorsque ces décisions partagent les mêmes objets : finalité, unité de travail, version, preuve et owner.
Conclusion : faire de la conformité une propriété du produit
Intégrer une IA de manière responsable ne consiste pas à ajouter une notice après le prototype. Le produit doit savoir quelles données il envoie, pourquoi, à qui, pendant combien de temps et comment une personne exerce ses droits. L’architecture doit préserver la sécurité, l’autorité et la possibilité de couper la brique.
Ce cadrage peut réduire le périmètre initial, mais il accélère les décisions suivantes : une nouvelle source, un modèle ou un public se compare à une carte et des seuils existants. Les inconnues deviennent des actions attribuées plutôt que des risques acceptés par défaut.
Le prochain geste est de tracer une requête réelle de bout en bout et d’exécuter une suppression avant tout élargissement. Si le flux reste introuvable ou le fournisseur ambigu, le go doit attendre. Dawap peut accompagner cette conception et son implémentation dans une application web sur mesure conforme à son contexte, avec le DPO, la sécurité, le métier et le run réunis autour de preuves concrètes.
