Dynamics 365 et RGPD : consentements et flux

Dans Dynamics 365, une opposition enregistrée dans une fiche contact ne garantit pas que chaque parcours marketing la consulte. La revue RGPD doit donc relier les règles juridiques aux paramètres de Sales, Customer Insights, Dataverse et des outils connectés.

Identifier les environnements et engagements applicables

Constituez un inventaire des services, environnements et connexions réellement utilisés. Récupérez le DPA depuis le centre documentaire Microsoft, puis rapprochez-le des conditions de vos produits et de votre abonnement.

L’EU Data Boundary ne repose pas uniquement sur une adresse française. Pour Dynamics et Power Platform, la documentation exige notamment le provisionnement du tenant et des environnements dans la macro-région couverte ainsi qu’une adresse de facturation éligible. Elle prévoit également des exceptions et distingue les données de services professionnels, stockées au repos dans le périmètre.

Conservez donc la preuve de la région de chaque environnement et examinez les flux supplémentaires. Notre guide des transferts hors UE aide à analyser les accès et destinataires, au-delà de la résidence principale.

Comprendre les choix dans Customer Insights

La documentation de Customer Insights – Journeys décrit des choix rattachés au point de contact, par exemple une adresse email, à un canal et à une finalité. Une même personne peut utiliser plusieurs coordonnées avec des préférences différentes.

Elle distingue trois modes : « Restrictive » exige un accord enregistré, « Non-restrictive » permet l’envoi en l’absence d’opposition enregistrée, et « Disabled » ne vérifie pas les choix pour la finalité concernée. Ces noms décrivent un comportement technique, pas une conclusion de licéité.

Pour une campagne commerciale, le paramètre doit correspondre au public et au canal. Les règles de la CNIL distinguent notamment consentement B2C, exception client sous conditions et prospection professionnelle pertinente. Ne sélectionnez pas un mode permissif pour compenser l’absence de preuve.

Contrôler les champs historiques et les profils partagés

La documentation des paramètres de conformité indique que les parcours temps réel ne vérifient pas par défaut les champs DoNotEmail, DoNotBulkEmail et DoNotTrack. Une option permet ces contrôles supplémentaires, mais le centre de préférences ne met pas lui-même ces champs à jour.

Préparez donc une correspondance explicite entre anciens champs, choix par point de contact et synchronisations. Vérifiez un contact importé, un prospect et une personne utilisant plusieurs adresses. La liste d’opposition du CRM doit atteindre les circuits réellement actifs.

Examinez aussi les finalités partagées entre profils : un changement de mode peut affecter plusieurs marques. Désigner un responsable de ces paramètres évite qu’une correction locale modifie involontairement un autre parcours.

Définir les durées sans relancer artificiellement le délai

Le référentiel CNIL 2021-131 propose, pour les prospects, trois ans à partir de la collecte ou du dernier contact provenant de la personne. Une relance restée sans réponse ne recommence pas le délai.

Distinguez les informations utiles à une relation active, les données commerciales devenues inutiles et les justificatifs à conserver séparément. Les activités automatiques, doublons et pièces jointes doivent entrer dans cette analyse.

La conformité du CRM implique aussi de maîtriser les notes et les copies issues des connecteurs. Un effacement dans une table ne prouve pas la suppression dans une application synchronisée.

Encadrer Copilot et les décisions

Pour chaque fonction d’IA utilisée, précisez les sources accessibles, les destinataires des résultats, les durées et la validation humaine. Vérifiez sa documentation propre au lieu d’étendre une garantie à toutes les fonctions Microsoft.

L’Art. 22(1) du RGPD vise les décisions fondées exclusivement sur un traitement automatisé produisant des effets juridiques ou similaires significatifs. Tout score commercial ne relève donc pas automatiquement de ce régime ; inversement, une validation humaine purement formelle ne suffit pas à l’écarter.

Les permissions restent essentielles : limitez ce qu’une fonction peut consulter ou produire. Le guide Microsoft Copilot et RGPD complète cette analyse.

Exemple : reprendre les refus lors d’une migration

Situation fictive. Maison Tilleul, une PME française de vente de linge aux particuliers, utilise Sales pour les contacts et prépare ses premiers parcours dans Customer Insights – Journeys. Jeanne, responsable du projet, choisit une première campagne réservée aux abonnés ayant accepté les nouveautés par email. Les confirmations de commande restent dans leur circuit distinct ; l’équipe n’ajoute pas de publicité à ces messages pour contourner le contrôle commercial.

L’ancien fichier contient une liste d’abonnés et des refus enregistrés ailleurs dans les fiches. L’intégrateur propose de reprendre seulement la liste, car elle est plus simple à exporter. Jeanne refuse cette migration partielle : elle recréerait des accords apparents en perdant les décisions postérieures des personnes. L’Art. 7(1) et (3) exige de pouvoir démontrer le consentement et de permettre son retrait ; la facilité d’un export ne modifie pas ces exigences.

La table de correspondance réellement approuvée

Les lignes suivantes appartiennent à un jeu de recette fictif. Les identifiants évitent d’utiliser des adresses de clients dans le dossier de paramétrage partagé avec toute l’équipe.

Jeanne fait valider cette table par la personne chargée de la conformité et l’administratrice CRM. Pour T-104, l’équipe ne remplace pas la preuve manquante par la date du transfert. La décision concerne cette campagne fondée sur le consentement ; elle n’interdit pas de gérer, sur son fondement propre, une commande passée par la même personne.

La documentation Microsoft sur la migration précise que le chargement depuis une liste d’abonnement ne consulte pas les champs de refus de la fiche. Elle décrit une reprise complémentaire des choix des contacts vers la finalité parente. Il faut donc contrôler les deux niveaux, sans transformer les anciennes valeurs techniques en preuves juridiques.

Dans le scénario, l’administratrice reçoit instruction de charger les choix conformément à la table, de vérifier l’adresse utilisée et de réserver les paramètres aux personnes habilitées. La finalité de cette campagne utilise le mode « Restrictive », choisi pour exiger un accord enregistré. Elle ne reproduit pas un accord sur toutes les coordonnées d’un même individu. La fiche de recette consigne aussi la source du refus de T-102 : fermer les yeux sur ce refus parce que la personne figure encore dans une liste serait une erreur de migration.

Le premier contrôle échoue malgré un import réussi

L’import ne signale aucune erreur technique. Pourtant, la comparaison montre que T-102 est encore présenté comme admissible dans le circuit préparé : la première reprise a traduit son ancienne inscription en accord, sans achever le traitement des refus plus récents. Jeanne bloque le lancement et fait corriger l’état de la finalité concernée. L’équipe vérifie ensuite T-101 comme témoin positif, pour éviter qu’une correction générale ait simplement bloqué tous les destinataires.

Après correction, T-101 reste admissible ; T-102 et T-104 sont exclus ; seule la première adresse de T-103 possède le choix correspondant. L’agence conserve le relevé de ces résultats et les paramètres du message. Elle contrôle également le lien proposé au destinataire et la portée exacte du retrait annoncé. Une page de préférences accessible mais sans effet sur le parcours ne suffit pas.

Le dossier fictif comprend ensuite un retrait de T-101 entre la préparation et l’envoi. Le résultat attendu, puis constaté dans le scénario corrigé, est son exclusion. La documentation d’envoi Microsoft situe le contrôle des choix immédiatement avant l’envoi : c’est donc cette étape qu’il faut vérifier, et pas seulement l’appartenance initiale au segment.

Ces opérations décrivent un exemple pédagogique, pas un essai de Dynamics effectué pour cet article. Dans votre projet, joignez les observations obtenues sur votre propre configuration, avec l’identité de l’opérateur et les écarts restant ouverts.

Une restauration ne doit pas faire réapparaître l’accord

Jeanne ajoute un contrôle au plan de reprise : que deviennent les refus plus récents que la sauvegarde restaurée ? Microsoft indique qu’une restauration replace aussi les consentements dans leur état sauvegardé. Une restauration réussie du service peut donc rétablir des choix devenus obsolètes. Point de vigilance sur la restauration.

Dans la simulation, une sauvegarde du lundi contient l’accord de T-101 ; le retrait intervient le mardi. La restauration du mercredi ramène d’abord l’état du lundi. Les parcours commerciaux restent suspendus pendant que l’administratrice rapproche la sauvegarde du relevé des changements conservé séparément. Elle réapplique le retrait, vérifie T-101 et un dossier inchangé, puis autorise la reprise.

Si le relevé est incomplet, elle ne déclare pas tous les anciens accords valables. Elle identifie les dossiers dont l’état reste incertain et les maintient hors des envois concernés jusqu’à résolution. Cette règle de reprise protège le droit d’opposition prévu aux Art. 21(2)–(3). Le relevé séparé doit lui-même avoir des accès restreints, une durée justifiée et une procédure de mise à jour : il ne devient pas un second fichier commercial.

Prévoir la sortie des données dans le dossier de projet

Avant de clôturer la migration, Jeanne demande la liste des copies créées : export de préparation, fichiers transmis à l’intégrateur, environnement de recette et connecteurs actifs. Pour chacune, elle affecte un responsable et une action. L’export de travail est supprimé après comparaison ; les résultats de recette restent sous forme de profils fictifs et de relevés limités. Les justificatifs utiles à la preuve des choix restent séparés de la sélection des destinataires.

Le responsable métier signe la décision de mise en service seulement lorsque les refus atteignent tous les circuits autorisés. L’intégrateur conserve une tâche distincte pour une ancienne connexion dont le devenir reste incertain : elle est désactivée dans l’attente de la vérification de ses copies. Une case « migration terminée » ne doit pas masquer cette réserve ni autoriser le redémarrage du connecteur.

Ce qu’il faut retenir

• Vérifiez les régions de tous les environnements, pas seulement l’adresse de facturation.
• Les modes de consentement sont des réglages techniques à justifier juridiquement.
• Les champs historiques de refus ne sont pas évalués par défaut dans Journeys.
• Une relance sans réponse ne prolonge pas la conservation d’un prospect.

FAQ

Le centre de préférences modifie-t-il les anciens champs de contact ?

La documentation indique qu’il ne met pas à jour les champs historiques mentionnés. Vérifiez votre architecture de synchronisation avant de vous appuyer sur eux.

Faut-il une AIPD pour tout usage de Dynamics ?

Non. L’Art. 35(1) l’exige si le traitement est susceptible d’engendrer un risque élevé. Il faut évaluer le traitement réel, notamment le profilage, l’ampleur et les données utilisées.

Tout score généré par une IA relève-t-il de l’Art. 22 ?

Non. Les conditions portent notamment sur une décision exclusivement automatisée et ses effets. L’évaluation doit examiner le rôle concret du score dans la décision.

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.