IA dans le CRM : empêcher l'enrichissement intrusif
IA et enrichissement CRM : limitez les inférences sur les prospects, exigez une provenance et validez les données avant toute action commerciale.
- Séparer extraction, synthèse et inférence
- Lire une sortie comme une proposition, pas comme un dossier établi
- Définir un usage licite avant de choisir le modèle
- Un champ opérationnel doit garder sa provenance
- Ne transmettre au fournisseur que le nécessaire
- Bloquer l’action avant la validation, pas seulement afficher un avertissement
- Prévoir la correction jusqu’aux usages en aval
- Ce qu’il faut retenir
- FAQ
Une IA peut aider à extraire une demande ou préparer une synthèse dans le CRM. Elle ne doit pas transformer ses suppositions en faits commerciaux ni déclencher une relance sur cette seule base. Avant l’intégration, définissez les champs autorisés, les preuves attendues et les actions qui restent bloquées tant que le résultat n’est pas vérifié.
La question dépasse la qualité rédactionnelle. Une fonction inventée, une coordonnée devinée ou un jugement sur la personnalité peut modifier la manière dont votre entreprise traite un prospect. La mention « généré par IA » n’enlève ni le caractère personnel de ces informations ni vos obligations à leur égard.
Séparer extraction, synthèse et inférence
L’extraction reprend une information présente dans une source : une personne demande une documentation pour deux établissements. La synthèse reformule cette demande pour faciliter sa lecture. L’inférence ajoute une conclusion : cette personne disposerait d’un budget important ou serait prête à acheter rapidement.
Ces trois opérations ne présentent pas les mêmes besoins de contrôle. Une synthèse peut rester fidèle tout en perdant une réserve importante. Une inférence peut sembler plausible sans être nécessaire à l’action commerciale. L’Art. 5(1)(c) et (d) du RGPD impose minimisation et exactitude : conserver plus de champs ne signifie pas mieux connaître la personne.
La CNIL sur l’usage des systèmes d’IA générative, questions 2 et 7, rappelle le risque de réponses plausibles mais inexactes et l’importance d’examiner les sorties. Un lien fourni par le modèle ne dispense pas d’ouvrir la source et de vérifier qu’elle concerne la bonne personne.
Lire une sortie comme une proposition, pas comme un dossier établi
Prenons un exemple entièrement fictif. Clara écrit au fournisseur de matériel Atelier Nord pour son employeur :
« Je rassemble la documentation pour nos deux sites. Le projet n’est pas encore décidé. Merci de m’envoyer les caractéristiques ; vous pouvez me rappeler après le 14 octobre. »
L’entreprise envisage un assistant limité à la préparation de fiches. Supposons que sa sortie propose les éléments suivants. Il s’agit d’une sortie construite pour l’exemple, pas du résultat d’un essai de produit.
| Proposition pour le CRM | Ce que la source établit | Décision sur le champ |
|---|---|---|
| Documentation demandée pour deux sites | Information explicitement fournie | Conserver avec référence au message |
| Rappel après le 14 octobre | Accord limité au rappel décrit, sans date précise de rendez-vous | Conserver cette contrainte, sans planifier avant |
| Projet validé | Le message dit l’inverse | Rejeter et garder « projet non décidé » |
| Décideuse achats | Aucune fonction décisionnelle indiquée | Ne pas renseigner ce rôle comme fait |
| Budget estimé à 15 000 € | Aucun budget communiqué | Écarter du dossier opérationnel |
| Probabilité d’achat : 92 % | Aucun calcul ni modèle évalué dans le dossier | Ne pas utiliser pour classer ou relancer |
Le résultat utile est court : documentation à envoyer, projet encore indécis, rappel possible après la date indiquée. L’assistant n’a pas besoin d’inventer le pouvoir de décision de Clara pour que le commercial accomplisse cette tâche.
Cette lecture montre également pourquoi un taux de confiance n’est pas une preuve. Le nombre « 92 % » n’a de sens que si sa définition, sa méthode et sa qualité pour cet usage sont établies. Ici, aucune de ces conditions n’est documentée : le champ est écarté, pas simplement coloré en orange.
Définir un usage licite avant de choisir le modèle
L’entreprise doit déterminer une base légale pour chaque traitement. La préparation de la réponse au message et la recherche d’informations personnelles supplémentaires ne constituent pas automatiquement le même usage.
Dans le dossier fictif, Clara agit pour son employeur. Atelier Nord ne peut donc pas déduire que l’Art. 6(1)(b), relatif au contrat avec la personne, couvre tous les traitements de ses données. Il examine l’Art. 6(1)(f) pour organiser la réponse professionnelle demandée : intérêt identifié, nécessité de la synthèse limitée et mise en balance avec les droits et attentes de Clara. Le message, les champs retenus et l’absence d’enrichissement personnel supplémentaire délimitent cette analyse.
Cette hypothèse n’autorise pas à analyser ses activités privées ou à la classer selon une fragilité supposée. Une validation humaine ne crée pas une base légale et ne rend pas nécessaire une information inutile.
Si les données révèlent une catégorie particulière visée à l’Art. 9, une condition de cet article doit aussi être satisfaite. Un consentement publicitaire général ne suffit pas à autoriser n’importe quelle inférence de santé ou d’opinion. Pour le projet limité décrit ici, ces champs sont exclus. Le guide des notes libres CRM explique comment éviter qu’ils réapparaissent dans des commentaires.
Un champ opérationnel doit garder sa provenance
Pour la fiche Clara, le dossier de validation peut contenir : la référence interne du message reçu, sa date, le passage utile, la proposition produite, la décision du commercial et la date de validation. Il n’est pas nécessaire de recopier toute la boîte de messagerie dans chaque fiche.
Le champ « projet non décidé » doit rester rattaché à ce message. Si Clara annonce ensuite une décision, la nouvelle information remplace l’état opérationnel avec une trace appropriée de la mise à jour. Une ancienne hypothèse ne doit pas être conservée comme une caractéristique permanente de la personne.
Pour des données externes, demandez une provenance vérifiable : page exacte, date de consultation et élément réellement présent. « Internet » ou « connaissances du modèle » ne permettent pas de contrôler un poste professionnel actuel. Le guide de la traçabilité de l’enrichissement CRM précise les métadonnées utiles.
La CNIL sur la réutilisation de données publiques rappelle que leur accessibilité ne les rend pas librement réutilisables. L’IA ne régularise pas une collecte en dissimulant ses sources. Si la page ne peut pas être retrouvée ou si son rattachement à Clara est incertain, le champ ne devient pas une donnée validée.
Ne transmettre au fournisseur que le nécessaire
Le projet doit décrire ce qui quitte le CRM : message utile, pièces jointes, historique, coordonnées et éventuelles données de tiers. Une invite limitée à la demande professionnelle peut encore contenir des données personnelles. Remplacer le nom par un code réduit certains risques sans rendre automatiquement le texte anonyme.
L’Art. 28 du RGPD encadre le prestataire lorsqu’il traite pour votre compte. Examinez le service effectivement souscrit, les instructions, la conservation, les accès, les sous-traitants ultérieurs et les possibilités d’utilisation pour d’autres finalités. Une promesse générale « vos données sont protégées » ne répond pas à ces points.
Un hébergement indiqué dans une région ne décrit pas nécessairement les accès de support ou les autres flux. Les transferts éventuels doivent être examinés au regard du chapitre V du RGPD. Aucun nom de produit ne permet de conclure à lui seul que la configuration retenue répond à ces exigences.
Tant que le périmètre du fournisseur reste indéterminé, n’envoyez pas les dossiers réels pour « voir ce que cela donne ». L’équipe peut préparer des exemples inventés, examiner le contrat et les réglages, ou poursuivre la synthèse manuelle. Cette réserve concerne les données personnelles effectivement présentes, y compris les comptes et journaux techniques d’un pilote.
Bloquer l’action avant la validation, pas seulement afficher un avertissement
Dans le projet Atelier Nord, la proposition de l’IA reste dans un espace de préparation. Seuls les champs autorisés et validés alimentent la fiche opérationnelle. Les règles de relance ne lisent pas la proposition brute.
Le commercial doit pouvoir consulter la source, modifier ou refuser la proposition et comprendre l’effet du champ. Un bouton « valider tout » utilisé sans lecture ne constitue pas un contrôle substantiel. Pour Clara, la réservation « après le 14 octobre » doit rester visible lors de la préparation du rappel ; la synthèse ne doit pas la réduire à « à rappeler rapidement ».
Le classement de personnes selon leurs intérêts ou leur comportement peut constituer un profilage au sens de l’Art. 4(4). L’Art. 22(1) du RGPD concerne, plus précisément, les décisions exclusivement automatisées produisant des effets juridiques ou des effets significatifs similaires. Tout enrichissement n’atteint pas ce seuil ; une intervention humaine purement formelle ne permet toutefois pas de l’écarter artificiellement. Le guide du lead scoring traite cette analyse des conséquences.
L’Art. 35(1) impose par ailleurs une analyse d’impact avant un traitement susceptible d’engendrer un risque élevé. Le seul mot « IA » ne constitue ni une dispense ni une conclusion automatique : appréciez la nature des évaluations, l’échelle, les données et les conséquences envisagées.
Prévoir la correction jusqu’aux usages en aval
Si Clara conteste une information, le processus doit rechercher le champ et les décisions qui en dépendent. L’Art. 16 et l’Art. 18(1)(a) encadrent la rectification et, lorsque l’exactitude est contestée, la limitation pendant la vérification. L’Art. 19 prévoit l’information des destinataires dans les conditions qu’il fixe.
Corriger seulement l’écran principal peut être insuffisant si un export, un segment ou une prochaine synchronisation réintroduit l’erreur. Documentez la source de remplacement et la règle empêchant l’ancien résultat d’écraser la correction.
Pour recevoir le projet, l’équipe prépare des messages fictifs comportant une réserve, une donnée absente et une correction ultérieure. Elle observe si l’outil préserve la réserve, laisse le champ absent et respecte la correction lors d’un nouveau passage. Ce sont des résultats attendus, pas des tests prétendument réalisés.
Si l’outil continue à écrire directement des suppositions dans les champs actifs, ce circuit reste désactivé. La synthèse peut être maintenue comme brouillon séparé seulement si les autres conditions de traitement sont satisfaites. Le lancement se décide sur un fonctionnement démontré pour le périmètre retenu, pas sur la fluidité des textes produits.
Ce qu’il faut retenir
Choisissez d’abord les champs utiles et les actions permises. Conservez la provenance, distinguez fait et hypothèse, puis bloquez les conséquences opérationnelles jusqu’à validation. Le contrat du fournisseur, la base légale et les droits des personnes restent nécessaires, même si chaque proposition est relue.
FAQ
Peut-on laisser un champ vide plutôt que demander à l’IA de le compléter ?
Oui. Une donnée absente est souvent plus fidèle et moins risquée qu’une estimation inutile. Dans le dossier Clara, aucun budget n’est nécessaire pour envoyer la documentation : le champ reste vide jusqu’à une information pertinente effectivement obtenue.
Une source publique permet-elle d’éviter d’informer le prospect ?
Non par principe. L’Art. 14 prévoit l’information lorsque les données n’ont pas été obtenues auprès de la personne, avec ses délais et exceptions précis. Une page publique ou une collecte par l’assistant n’efface pas cette obligation ; la provenance doit rester explicable.
La correction doit-elle supprimer tout historique ?
Il faut distinguer l’état opérationnel et une trace nécessaire de correction. Une ancienne erreur ne doit plus diriger l’action. Une conservation limitée de preuve peut répondre à un besoin distinct, à justifier avec sa base, sa durée et ses accès ; elle n’autorise pas à maintenir le profil erroné en usage.
Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.
Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.