DPIA agent conversationnel IA — Template et méthode

Quand vous déployez un chatbot ou un agent vocal IA en production, la question n'est pas sivous devez faire une analyse d'impact relative à la protection des données (DPIA), mais quand et comment. Ce guide donne la méthode complète, conforme à la doctrine CNIL et au RGPD, avec un template structuré que vous pouvez reprendre tel quel.

1. Ce qu'est une DPIA et son fondement légal

La DPIA — Data Protection Impact Assessment, ou AIPD en français pour Analyse d'Impact relative à la Protection des Données — est l'outil prévu par l'Article 35 du RGPD pour évaluer et documenter les risques qu'un traitement de données personnelles fait peser sur les droits et libertés des personnes concernées. Le texte est disponible sur EUR-Lex — Règlement (UE) 2016/679 (RGPD).

Elle est obligatoire quand un traitement est « susceptible d'engendrer un risque élevé pour les droits et libertés des personnes physiques » (Article 35.1). La CNIL a publié une liste des traitements pour lesquels une AIPD est obligatoire et une liste de ceux pour lesquels elle ne l'est pas. Pour les agents conversationnels, la situation n'est pas tranchée par les listes et demande une analyse au cas par cas, mais la pratique sectorielle penche largement pour le « oui » dès qu'on dépasse le simple FAQ-bot.

2. Quand un agent conversationnel impose une DPIA

Le Comité européen de la protection des données (CEPD/EDPB) a publié neuf critères permettant d'identifier un traitement à risque élevé. Un traitement qui en cumule deux ou plus déclenche en général l'obligation de DPIA. Pour un agent conversationnel, regardez chaque critère :

• Évaluation ou scoring: oui dès qu'il qualifie un lead, calcule un budget, recommande un produit, classe un ticket support.
• Décision automatisée à effet juridique ou significatif: oui pour les bots de pré-qualification crédit, validation devis, refus d'inscription.
• Surveillance systématique : oui pour les agents qui tracent les parcours utilisateurs et déclenchent des actions.
• Données sensibles: oui dès qu'on évoque la santé (bots médicaux), l'orientation, la situation financière détaillée.
• Traitement à grande échelle : oui pour un bot grand public qui traite quotidiennement des milliers de conversations.
• Croisement de données : oui si le bot enrichit la conversation avec votre CRM, votre ERP, votre datalake.
• Personnes vulnérables : oui si la cible inclut mineurs, patients, personnes en situation de précarité.
• Usage innovant de technologie : oui par nature pour tout LLM déployé en production en 2026 (la jurisprudence évoluera).
• Empêchement d'exercer un droit ou un service: oui si le bot conditionne l'accès à votre service.

Mon retour de terrain : quasiment tout agent conversationnel qui collecte des données personnelles identifiables et que vous mettez en production tombe sous l'obligation. L'exception réelle est le FAQ-bot stateless qui ne stocke rien et ne fait aucun profilage.

3. La méthodologie CNIL en six étapes

La CNIL met à disposition un logiciel libre PIA (Privacy Impact Assessment), téléchargeable sur cnil.fr/fr/outil-pia. Il structure l'analyse en quatre piliers (contexte, principes fondamentaux, risques, validation) et génère un rapport PDF. La méthodologie complète est détaillée dans les trois guides PIA publiés par la CNIL (méthode, bases de connaissance, modèles), accessibles sur cnil.fr/fr/RGPD-analyse-impact-protection-des-donnees-aipd.

Je résume la séquence opérationnelle en six étapes :

Étape 1 — Décrire précisément le traitement

Nature de l'agent (chatbot web, agent vocal entrant, agent vocal sortant), finalités explicites (qualification commerciale, support, prise de rendez-vous), populations concernées (clients, prospects, salariés, grand public), volumétrie attendue (conversations / jour, durée moyenne), enjeux pour les personnes.

Étape 2 — Identifier la base légale

L'Article 6 RGPD impose une base légale. Pour un agent conversationnel commercial, l'intérêt légitime (6.1.f) est le plus souvent invoqué, parfois le consentement (6.1.a) pour les enregistrements vocaux. Si vous traitez des données sensibles, vous devez en plus respecter l'Article 9 (consentement explicite, le plus souvent).

Étape 3 — Évaluer le respect des principes fondamentaux

• Minimisation : votre prompt système demande-t-il seulement les données strictement nécessaires ?
• Exactitude : comment corrigez-vous une réponse fausse (cas hallucination LLM) ?
• Limitation de conservation: combien de temps gardez-vous les transcriptions et l'audio brut ?
• Information: la personne sait-elle qu'elle parle à une IA (Article 50 AI Act, voir notre guide Article 50 — Deadline 2 août 2026) ?
• Exercice des droits : comment une personne accède-t-elle à ses conversations, les fait-elle rectifier ou supprimer ?

Étape 4 — Identifier les sources de risque (sous-traitants)

Listez toute la chaîne : provider LLM (OpenAI, Anthropic, Mistral...), transcripteur (Whisper, Gladia, Speechmatics), synthèse vocale (ElevenLabs, Cartesia), hébergement applicatif (Vercel, AWS, OVH), base de connaissance (Pinecone, pgvector), CRM connecté. Chaque acteur est un sous-traitant au sens RGPD : il faut un DPA signé, une localisation des données documentée, une analyse des transferts hors UE le cas échéant.

Étape 5 — Évaluer les risques résiduels

Pour chaque risque (accès illégitime, modification non désirée, disparition des données), évaluer la gravité et la vraisemblance avant et après mesures. La CNIL recommande la grille à quatre niveaux : négligeable, limité, important, maximal. Documenter les mesures techniques (chiffrement au repos et en transit, MFA, cloisonnement) et organisationnelles (formation, charte, audit).

Étape 6 — Décider et publier

La DPIA est validée par le responsable de traitement (le dirigeant ou son délégataire), après avis du DPO si vous en avez un. Si des risques élevés subsistent malgré les mesures, vous devez consulter la CNIL avant de mettre en œuvre le traitement (Article 36 RGPD). La DPIA n'est pas publique par défaut, mais doit être tenue à disposition de l'autorité de contrôle.

4. Template DPIA agent conversationnel (structure)

Voici la structure que j'utilise pour les DPIA d'agents PilotCrew. Vous pouvez la transposer dans le logiciel PIA de la CNIL ou la maintenir dans un document maîtrisé.

Section A — Description du traitement

1. Identité du responsable : raison sociale, SIREN, adresse, DPO si applicable.
2. Nature de l'agent : type (chat web, vocal entrant, vocal sortant), canal de déploiement, intégrations.
3. Finalités : 2 à 5 finalités précises (ex. qualification de prospects, support de niveau 1, prise de rendez-vous médicaux).
4. Catégories de personnes concernées : prospects, clients, salariés, grand public, mineurs ?
5. Catégories de données collectées : nom, email, téléphone, contenu des conversations, audio (le cas échéant), métadonnées techniques (IP, user-agent).
6. Durées de conservation : transcriptions actives, archives, audio brut, logs techniques.
7. Destinataires : équipes internes, sous-traitants, autorités publiques en cas de réquisition.

Section B — Conformité aux principes fondamentaux

1. Base légale Art 6 RGPD (et Art 9 si données sensibles).
2. Information des personnes (formulation, support, accessibilité Art 12-14).
3. Mécanismes d'exercice des droits (accès, rectification, effacement, opposition, portabilité, Art 15-22).
4. Sous-traitance : liste, DPA, localisations.
5. Transferts hors UE : mécanisme (CCT, DPF), évaluation TIA.

Section C — Étude des risques

1. Cartographie des actifs (données, supports, logiciels, personnes).
2. Trois scénarios de risque type : (a) accès illégitime à des transcriptions (fuite), (b) modification non désirée (manipulation prompt), (c) disparition de données (perte ou rançon).
3. Mesures techniques en place pour chaque scénario.
4. Mesures organisationnelles en place pour chaque scénario.
5. Évaluation du risque résiduel.

Section D — Validation et plan d'action

1. Avis du DPO le cas échéant.
2. Validation responsable de traitement.
3. Plan d'action pour les risques non couverts.
4. Date de prochaine revue (annuelle au minimum, ou sur changement majeur).

5. Spécificités IA à intégrer absolument

Une DPIA d'agent conversationnel doit aller au-delà de la DPIA classique. Sept sujets méritent une section dédiée :

5.1. Hallucination et exactitude

Un LLM peut générer une réponse fausse. Pour les domaines réglementés (santé, droit, finance), c'est un risque opérationnel et de conformité. La DPIA doit documenter : le taux d'erreur acceptable, la procédure de correction, les avertissements affichés à l'utilisateur.

5.2. Prompt injection et contournement

Risque que la personne contourne les garde-fous par injection (par exemple, faire cracher le prompt système pour découvrir les règles métier). Mesures : prompt système isolé, filtres en sortie, journalisation des tentatives.

5.3. Données d'entraînement

Si vous fine-tunez ou si vous laissez le fournisseur LLM réutiliser vos prompts à des fins d'entraînement, c'est un nouveau traitement avec sa propre base légale. La majorité des fournisseurs commerciaux désactivent cette réutilisation par défaut sur les plans business, à vérifier au cas par cas.

5.4. Conversation comme donnée personnelle

Une transcription contient souvent des données qui n'auraient pas été collectées par un formulaire classique (humeur, opinions, mention de tiers). Le traitement doit l'anticiper : durée de conservation courte par défaut, anonymisation systématique pour les analyses qualitatives, pas de stockage indéfini « au cas où ».

5.5. Décisions automatisées (Article 22 RGPD)

Si l'agent prend ou influence significativement une décision à l'égard de la personne (refus, scoring, recommandation), l'Article 22 impose : droit d'obtenir une intervention humaine, droit d'exprimer son point de vue, droit de contester la décision. La DPIA doit documenter le dispositif d'appel humain.

5.6. Information AI Act Article 50

La DPIA n'est pas le bon véhicule pour l'information AI Act, mais elle doit la mentionner et la vérifier. Voir Article 50 — Deadline 2 août 2026.

5.7. Chaîne de sous-traitance LLM

La chaîne LLM est souvent multi-acteurs : votre éditeur SaaS qui héberge l'app sur Vercel, qui appelle OpenAI hébergé sur Azure, qui utilise Whisper pour la transcription. Documentez chaque maillon. Si OpenAI met à jour son DPA, votre DPA devient potentiellement non conforme.

6. Gouvernance, revue et conservation

La DPIA est un document vivant. Elle doit être revue :

• Annuellement a minima (la CNIL le recommande explicitement).
• Sur changement majeur: changement de fournisseur LLM, ajout d'une nouvelle finalité, intégration d'un nouveau canal, ajout d'une population vulnérable.
• Sur incident: violation de données, plainte d'une personne, audit fournisseur défavorable.

Conservez la DPIA et ses versions successives pendant toute la durée du traitement, plus une période raisonnable après (au moins 3 ans selon la pratique). Tenez un journal des modifications. La CNIL peut exiger l'historique en cas de contrôle.

7. Qui doit la rédiger ?

La responsabilité juridique relève du responsable de traitement (en pratique le dirigeant ou son délégataire). L'Article 39 RGPD confie au DPO la mission de « donner un avis » sur la DPIA et de veiller à sa réalisation. Si vous n'avez pas de DPO interne, vous pouvez vous appuyer sur un DPO externe mutualisé ou sur un cabinet spécialisé.

En pratique pour une PME : la DPIA est co-rédigée par le responsable produit (qui connaît le traitement), le DSI (qui connaît la stack technique) et le juridique (qui valide la conformité). Comptez 8 à 16 heures de travail pour une première DPIA, beaucoup moins pour les suivantes en réutilisant le template.

8. Lien avec le registre des traitements et l'AI Act

La DPIA n'est pas le registre des traitements (Article 30 RGPD), mais elle s'y articule. Le traitement décrit dans la DPIA doit figurer dans le registre. Voir notre guide Registre des traitements IA pour la cohérence d'ensemble.

Côté AI Act, la DPIA RGPD ne remplace pas l'analyse d'impact spécifique requise pour les systèmes à haut risque (Article 27 AI Act, FRIA). Pour la majorité des PME qui utilisent des chatbots à risque limité, la DPIA RGPD suffit. Pour les systèmes à haut risque (recrutement, scoring, biométrie), il faut produire les deux documents.

Questions fréquentes

Une DPIA est-elle obligatoire pour un simple FAQ-bot sans stockage ?

Non, dans la majorité des cas. Si le bot ne stocke aucune conversation identifiable, ne fait pas de profilage, ne croise pas de bases de données, il tombe en risque limité et la DPIA n'est pas obligatoire. Une analyse simplifiée interne suffit (et reste recommandée).

Combien de temps prend une première DPIA ?

Entre 8 et 16 heures de travail réparti sur 2 à 4 semaines pour bien collecter les informations. La principale difficulté est de mobiliser le bon interlocuteur dans chaque équipe (produit, IT, juridique, DPO).

Qui valide la DPIA juridiquement ?

Le responsable de traitement (le dirigeant dans une PME) la valide formellement, après avis du DPO si vous en avez un. C'est cette signature qui engage la responsabilité.

Faut-il publier la DPIA ?

Non, la DPIA n'est pas un document public. Vous devez la tenir à disposition de la CNIL en cas de contrôle. Vous pouvez en publier une synthèse expurgée des informations sensibles si cela renforce la confiance de vos clients B2B (notre cas chez PilotCrew).

Que se passe-t-il si je n'ai pas fait la DPIA et qu'il y a un incident ?

L'absence de DPIA est un manquement séparé du sinistre lui-même. La CNIL peut sanctionner les deux. En 2024, l'amende type pour absence de DPIA sur un traitement à risque élevé tournait autour de 0,5 à 2 % du CA pour une PME, à quoi s'ajoutent les conséquences de l'incident lui-même.

Brouillon assisté par IA, revu et signé par Curtys ACCIPE, fondateur PilotCrew. Dernière revue : 23 mai 2026.