Quelles données un courtier peut transmettre à un outil externe ?

Réponse opérationnelle dès le départ. Comme règle interne prudente pour un premier pilote sur un service externe, nous proposons de ne pas transmettre à un outil externe des dossiers clients complets, des pièces d’identité, des relevés contenant des informations directement identifiantes, des échanges libres riches en contexte personnel, ni des données de santé éventuellement présentes dans certains dossiers. Peuvent être envisagées seulement après cadrage des données strictement nécessaires à une tâche précise, par exemple des extraits limités d’un devis, une liste de pièces manquantes, un texte de procédure interne ou un contenu métier déjà autorisé, à condition d’avoir qualifié les rôles, le fournisseur, les flux, la sécurité, la conservation et le contrôle humain. Pour les essais décrits ici, nous proposons de partir de données fictives. Si des données réelles présentées comme anonymisées sont envisagées, faites documenter leur statut et le risque de réidentification avec votre DPO, sans présumer qu’un simple masquage suffit. En revanche, la pseudonymisation ne doit pas être confondue avec l’anonymisation : remplacer un nom par un code ne supprime pas forcément la possibilité de réidentifier une personne si le reste du dossier ou une table de correspondance permet le rapprochement.

Autrement dit, la bonne question n’est pas seulement « l’outil est-il performant ? », mais d’abord « quelles données exactes sont nécessaires pour cette tâche, et sommes-nous autorisés à les partager dans cette architecture ? ». La CNIL rappelle, pour l’usage d’une IA générative, qu’il faut n’y soumettre que des informations que l’on est autorisé à partager et qu’en présence de données personnelles ou d’une documentation sensible, l’analyse du service doit se faire au cas par cas. Pour un courtier, cette logique vaut autant pour un assistant conversationnel externe que pour un module d’extraction intégré à un éditeur.

La méthode ci-dessous distingue clairement les faits sourcés issus des autorités officielles et les recommandations de méthode proposées pour aider un cabinet à décider sans s’en remettre à des slogans du type « validation humaine », « chiffrement », « consentement » ou « option sans entraînement ». Évaluez ces éléments ensemble dans votre cas d’usage.

Décider vite : quelles catégories de données transmettre, suspendre ou exclure par défaut ?

Pour éviter que les équipes copient trop d’informations dans un outil externe, commencez par une règle simple : on ne transmet jamais « le dossier » comme bloc unique. On qualifie des catégories de données par finalité. La matrice suivante sert de filtre opérationnel initial ; elle ne remplace pas l’analyse du cas d’usage, du contrat ni des flux réels.

Ce que couvrent les sources. La CNIL recommande de qualifier les rôles selon les faits et d’examiner les garanties d’un service externe selon le cas d’usage et les données. Le CEPD analyse l’anonymat des modèles d’IA au cas par cas ; son avis ne qualifie pas à lui seul les données saisies dans un outil. Pour un premier essai en cabinet, nous recommandons des dossiers fictifs plutôt que des échanges clients réels.

Recommandation de méthode. Pour le référent conformité comme pour le dirigeant, cette matrice sert d’instruction simple aux équipes : exclure d’abord les catégories les plus exposées, n’autoriser ensuite que des extraits minimaux utiles à une tâche définie, et réserver les essais réels aux cas où le besoin métier, les garanties du fournisseur et le cadre documentaire sont déjà établis.

Pourquoi la pseudonymisation ne suffit pas à elle seule

Fait sourcé. La CNIL distingue la pseudonymisation de l’anonymisation ; le CEPD rappelle que le caractère anonyme d’un modèle d’IA s’apprécie au cas par cas. Il ne suffit donc pas d’enlever le nom et le prénom pour conclure qu’un contenu peut circuler librement vers un outil externe.

Recommandation de méthode. Dans un cabinet de courtage, considérez comme encore personnelle une donnée pseudonymisée dès lors qu’un rapprochement reste plausible, par exemple grâce au numéro de dossier, à la date de naissance, à la commune, à la profession, au type de garantie, au montant assuré ou à l’historique d’échanges. Un extrait du type « cliente de 54 ans, pharmacienne à Angers, contrat prévoyance souscrit en 2024, échange sur arrêt de travail » peut rester réidentifiable même sans nom. Ce point est crucial pour les usages de résumé, de classement ou de rédaction de réponse.

Concrètement, si l’objectif est de tester une IA sur la rédaction d’un e-mail de relance, mieux vaut fournir une structure de dossier fictive et des variables génériques plutôt qu’un échange réel simplement “dépersonnalisé” à moitié. La pseudonymisation peut réduire l’exposition ; elle ne transforme pas automatiquement les données en données anonymes.

Matrice de décision : faut-il transmettre cette donnée à cet outil externe ?

La matrice suivante aide à décider avant tout envoi. Elle combine des éléments sourcés — qualification du rôle, garanties du sous-traitant lorsqu’il agit comme tel, nécessité éventuelle d’une AIPD, sécurité et contrat — avec une méthode de cabinet orientée usage.

1. Quelle est la tâche exacte ? Exemple : rédiger un brouillon de demande de pièce, extraire des champs d’un devis, résumer un échange, classer un document.
2. Quelle donnée minimale suffit ? Si la tâche peut être réalisée à partir d’un modèle de courrier, d’un extrait ou d’un faux dossier, le dossier réel complet ne doit pas être envoyé.
3. La donnée est-elle personnelle, sensible ou riche en contexte ? Plus la réponse est oui, plus l’analyse du service et de l’architecture doit être poussée.
4. Le fournisseur agit-il comme sous-traitant au regard des faits observés, ou son rôle doit-il être examiné autrement ? La CNIL rappelle que la qualification dépend des faits, pas d’une simple étiquette commerciale.
5. Le contrat et les garanties sont-ils vérifiables si le fournisseur agit comme sous-traitant ? La CNIL rappelle, au regard de l’article 28 du RGPD, qu’il faut retenir un sous-traitant présentant des garanties suffisantes et prévoir un contrat définissant notamment l’objet, la durée, la finalité et les obligations de sécurité.
6. Les flux sont-ils compris ? Où vont les données, combien de temps sont-elles conservées, qui y accède, quels sous-traitants ultérieurs interviennent, comment s’organise la restitution ou la suppression ?
7. Le risque justifie-t-il une AIPD ? La CNIL rappelle qu’elle est exigée avant traitement lorsqu’un traitement est susceptible d’engendrer un risque élevé pour les droits et libertés.
8. Le cabinet peut-il arrêter sans dommage majeur ? Si l’usage ne peut pas être suspendu rapidement ou si les données injectées sont difficiles à récupérer ou effacer, le pilote est mal conçu.

Si l’une de ces réponses reste floue, la bonne décision n’est pas « essayer quand même », mais revenir à un périmètre plus sobre : documentation interne, données fictives, ou environnement mieux maîtrisé.

Exemples concrets propres au cabinet de courtage

Devis. Pour reformuler un message d’accompagnement ou détecter des champs manquants, un extrait limité du devis peut parfois suffire après cadrage. En revanche, envoyer le devis complet avec toutes les coordonnées, l’historique et des annexes n’est pas le réflexe à adopter.

Pièces justificatives. Les pièces comme carte d’identité, RIB, justificatif de domicile ou avis d’imposition sont à exclure par défaut d’un outil externe généraliste. Si une extraction documentaire est envisagée dans un outil tiers spécialisé, la validation du fournisseur et des flux devient centrale.

Échanges e-mail. Les fils d’e-mails concentrent souvent trop d’informations : identité, situation familiale, commentaires libres, pièces jointes, appréciations internes. Pour demander à un outil de proposer une réponse, il est généralement plus prudent de lui fournir une question reformulée et un contexte minimal plutôt que le fil complet.

Données de santé éventuellement présentes. Si le cas d’usage envisagé comprend des données de santé, placez-le hors du premier pilote décrit ici. Identifiez leur présence éventuelle avant l’essai, évitez leur envoi automatique et faites examiner séparément la nécessité et les garanties par le référent compétent.

CRM et historique de relation. Dans le CRM, identifiez les seuls champs utiles à la tâche du pilote. Notre méthode propose un jeu de champs défini plutôt que la copie d’un historique libre complet. Consultez également notre guide CRM pour les courtiers.

Documents de procédure et modèles internes. Pour un premier usage, un courtier peut souvent obtenir plus de valeur sur des contenus non personnels que sur des dossiers clients : trames de relance, modèles de réponses, checklists de complétude ou glossaires produit. Ces contenus ne dispensent pas d’un cadrage contractuel avec le fournisseur, mais ils réduisent d’emblée l’exposition par rapport à un usage centré sur des pièces nominatives.

Procédure de validation du fournisseur : ce qu’un cabinet doit vérifier

Faits sourcés. La CNIL indique qu’il faut bien identifier les rôles selon les faits et, lorsque le prestataire intervient comme sous-traitant, vérifier ses garanties et conclure un contrat écrit précis. Sa fiche sur la sous-traitance en sécurité rappelle aussi que le contrat doit cadrer l’objet, la durée, la finalité, la confidentialité, l’authentification, la restitution ou destruction, les incidents et l’assistance, avec des garanties de sécurité vérifiables.

Recommandation de méthode. Pour un outil IA externe, utilisez une validation fournisseur en trois blocs :

• Bloc 1 — Rôle et périmètre. Quelle fonction exacte rend le fournisseur ? Sur quelles données ? Pour quelle finalité ? Le cabinet garde-t-il la maîtrise des finalités et des moyens essentiels ? Quels sous-traitants ultérieurs interviennent ?
• Bloc 2 — Flux et sécurité. Où les données sont-elles traitées et stockées ? Quels journaux sont conservés ? Comment fonctionne l’authentification ? Quelle politique d’accès administrateur ? Quelles modalités d’effacement, de restitution et de notification d’incident ?
• Bloc 3 — Exploitabilité métier. Le fournisseur permet-il de limiter les données envoyées, de gérer des profils d’accès, de documenter les versions, de désactiver facilement l’usage, et de récupérer les éléments nécessaires en cas d’arrêt ?

Pour éviter les raccourcis, documentez séparément la base juridique envisagée, les rôles, la nécessité, le contrat et les risques. Vérifiez aussi la validation humaine, le chiffrement, la conservation, les accès du fournisseur, la suppression, les journaux, l’assistance technique, les sous-traitants et les transferts. Demandez au fournisseur ce que couvre précisément son option « pas d’entraînement ». Il s’agit de questions à instruire pour votre cas d’usage.

Pour le référent conformité, cette validation doit produire une trace exploitable : périmètre autorisé, catégories de données admises, catégories exclues, responsables internes, date de revue, conditions de suspension et points restant en attente. Pour le dirigeant, elle sert aussi d’outil d’arbitrage : si le fournisseur ne documente pas clairement son fonctionnement, notre méthode de décision propose de réduire le périmètre du pilote ou de différer ce pilote jusqu’à clarification.

Protocole de pilote réversible : tester sans s’enfermer

Dans notre méthode, appelez « pilote réversible » un essai dont l’arrêt, la désactivation des flux et le sort des données ont été préparés avant le lancement.

Étape 1 — Choisir une tâche étroite. Par exemple : générer un brouillon de relance pour pièce manquante à partir d’un formulaire standard et d’un statut de dossier. Évitez d’emblée les cas engageants comme l’analyse personnalisée d’une garantie ou un tri de dossiers comportant des données de santé.

Étape 2 — Préparer un jeu de test réversible. Pour ce premier essai, privilégiez des scénarios fictifs ; si des données réelles sont envisagées, faites qualifier leur statut et les risques avant tout envoi. Constituez des cas simples, ambigus, incomplets et erronés. Définissez aussi des cas où la bonne réponse est l’abstention.

Étape 3 — Limiter les accès et journaliser. Réservez l’essai à quelques utilisateurs formés. Tracez qui a envoyé quoi, pour quelle finalité et avec quel résultat métier, sans conserver plus de données que nécessaire.

Étape 4 — Prévoir la sortie. Avant le premier essai, écrivez la procédure de retour au mode manuel : désactivation des comptes, récupération des exports utiles, suppression ou restitution des données prévues, arrêt des connecteurs et information interne.

Étape 5 — Décider sur preuves. Notre grille de pilotage propose de comparer le temps gagné ou perdu, le taux de correction, les erreurs critiques, les incidents de confidentialité, la qualité perçue par les gestionnaires et la facilité d’arrêt. Si le pilote réussit, cela ne vaut pas feu vert général : toute extension à d’autres données, équipes ou effets doit être réexaminée.

Si le projet s’inscrit dans un chantier d’outillage plus large, rapprochez ce protocole de votre réflexion sur le socle logiciel du cabinet. Consultez également notre dossier sur les logiciels pour un courtier en assurance.

Aller plus loin sur les contrôles préalables

Si votre cabinet souhaite approfondir la logique de cadrage avant tout traitement de dossiers clients avec une IA externe, vous pouvez compléter cette lecture avec notre article dédié aux sept contrôles à passer avant de traiter des dossiers clients avec une IA externe. Il reprend, sous un angle plus transversal, les points de finalité, de minimisation, de qualification des rôles, de contrat, d’AIPD, de contrôle humain et d’arrêt du dispositif.

Checklist de lancement pour le cabinet

• La tâche confiée à l’outil externe est décrite de manière précise, avec une finalité unique.
• La liste des données interdites par défaut est communiquée aux équipes.
• Les données nécessaires sont limitées à un extrait minimal plutôt qu’au dossier complet.
• Les données fictives sont privilégiées pour les tests et la formation initiale.
• La différence entre pseudonymisation et anonymisation est comprise et documentée.
• Les rôles RGPD du cabinet et du fournisseur sont qualifiés au regard des faits.
• Si le fournisseur agit comme sous-traitant, le contrat et les garanties ont été vérifiés de manière traçable.
• Les flux, accès, journaux, sous-traitants ultérieurs et modalités d’effacement sont connus.
• La nécessité d’une AIPD a été examinée avant le traitement si le risque peut être élevé.
• Le contrôle humain intervient avant toute action ou communication engageante.
• Le pilote peut être interrompu sans blocage métier ni perte de maîtrise sur les données.
• Les équipes savent quand ne rien transmettre et revenir au processus manuel.

Ce que disent les sources, et ce que le cabinet doit en faire

Faits sourcés. La CNIL recommande de ne soumettre à une IA générative que des informations que l’on est autorisé à partager et d’analyser au cas par cas les services impliquant des données personnelles ou une documentation sensible. Elle rappelle aussi que la qualification des rôles dépend des faits et que, si le prestataire agit comme sous-traitant, ses garanties doivent être vérifiées dans un contrat écrit. Sa doctrine sur la sous-traitance exige des clauses précises et des garanties de sécurité vérifiables. Enfin, l’AIPD est à mener avant la mise en œuvre d’un traitement susceptible d’engendrer un risque élevé pour les droits et libertés des personnes. Le CEPD, de son côté, aborde l’anonymat au cas par cas dans le contexte des modèles d’IA et n’autorise pas de présomption générale d’anonymat.

Recommandation de méthode. Pour un cabinet de courtage, la traduction pratique est simple : partir d’un usage interne borné, bannir le réflexe “copier-coller du dossier”, imposer une matrice de décision, vérifier le fournisseur comme un maillon critique, tester sur un périmètre réversible et n’élargir qu’avec des preuves. Cette méthode n’est pas une promesse de conformité ; c’est une discipline de déploiement responsable.

Un cabinet qui applique cette logique répond déjà à la question centrale : quelles données transmettre à un outil externe ? Notre recommandation de départ pour un pilote : n’envoyez ni dossier complet, ni pièce identifiante, ni donnée de santé sans analyse particulière ; délimitez les champs utiles à la finalité. Pour le premier essai décrit dans ce guide, utilisez un scénario fictif. Cette grille est une méthode proposée au cabinet, pas une règle juridique générale.

Pour un professionnel du courtage, l’enjeu n’est pas seulement juridique ; il est aussi organisationnel. Rédigez une consigne de transmission simple pour les gestionnaires, les producteurs et les fonctions support. Notre méthode propose de l’accompagner d’une liste de catégories exclues, d’exemples autorisés par finalité et d’une procédure d’escalade vers le référent conformité.

Sources

• questions-réponses de la CNIL sur l’utilisation d’un système d’IA générative
• guide CNIL pour bien identifier son rôle de responsable du traitement ou de sous-traitant
• fiche CNIL sur la gestion de la sous-traitance en sécurité
• rappel CNIL sur l’analyse d’impact relative à la protection des données
• avis du CEPD sur certains aspects de protection des données liés aux modèles d’IA
• CNIL : identifier les données personnelles, anonymisation et pseudonymisation