Six règlements européens, une décision d’architecture :  ce que les organisations doivent anticiper lors du choix d’une plateforme CCM

Les entreprises européennes qui conduisent une migration CRM évoluent aujourd’hui dans l’un des environnements réglementaires les plus denses de ces dernières années. Six instruments de l’Union européenne — le Data Act, l’AI Act, eIDAS 2.0, NIS2, DORA et les exigences de souveraineté du cloud — entrent en vigueur dans le même intervalle de temps, entre 2025 et 2027. Chacun a des implications directes sur la façon dont les systèmes CRM et les plateformes de gestion des communications s’intègrent et échangent des données.

Pour les organisations qui opèrent sur les marchés DACH, en Italie et en France, la direction est sans ambiguïté : la conformité ne s’ajoute pas après la mise en production. Elle doit être intégrée à l’architecture dès le départ, pendant la phase de conception. C’est le sens concret du Compliance by Design.

La conformité peut-elle intervenir après la mise en production ?

Les six règlements ne constituent pas des obligations isolées. Ils convergent vers un point commun : établir un cadre réglementaire définissant comment les données client peuvent être extraites du CRM, transformées en communications et acheminées.  Ils se superposent et produisent des effets cumulés.

Traiter ces obligations après qu’une intégration a déjà été conçue et déployée revient à intervenir sur une architecture en production — à un coût et avec un risque nettement plus élevé. Le Compliance by Design inverse cette logique. Chaque obligation est traduite en exigence architecturale avant que les systèmes soient connectés, pas après.

Le Compliance by Design en pratique : Data Act et AI Act

Le Data Act exige que toutes les données traitées par la plateforme CCM soient exportables dans des formats interopérables.  Il s’agit d’une exigence architecturale fondamentale. Elle dépend de la manière dont les structures de données et les interfaces sont construites dès l’origine — et elle est beaucoup plus difficile à introduire une fois que les formats sont déjà actifs en production.

L’AI Act s’applique dès lors que les communications sont personnalisées par intelligence artificielle. Dans ces cas, le système doit conserver trois éléments pour chaque message généré : les données d’entrée utilisées, la version du modèle ayant produit le contenu, et la logique de décision. Une plateforme ne peut enregistrer ces informations que si elle a été conçue pour le faire dès le départ.  Ces informations doivent être capturées au moment où elles sont produites ; elles ne peuvent être reconstituées de manière fiable a posteriori.

Six règlements, un point de convergence

Il est utile d’identifier ce que chaque instrument exige concrètement — non de façon exhaustive, mais avec suffisamment de précision pour en comprendre les implications architecturales.

• Les exigences de souveraineté du cloud imposent que l’ensemble de la chaîne de traitement des données reste sous juridiction européenne, à l’abri des législations extraterritoriales telles que le CLOUD Act américain.
• Le Data Act vise à prévenir la dépendance fournisseur et impose de facto la portabilité des données.
• L’AI Act introduit une classification par niveau de risque pour les systèmes d’intelligence artificielle impliqués dans des décisions affectant des personnes.
• eIDAS 2.0 redéfinit l’identité électronique et les services de confiance, et impose la prise en charge des signatures qualifiées ainsi que du portefeuille européen d’identité numérique.
• NIS2 étend les obligations de résilience en matière de cybersécurité aux opérateurs de services essentiels — énergie, eau, télécommunications, santé, infrastructures numériques et autres secteurs jugés critiques — ainsi qu’à leurs fournisseurs.
• DORA impose aux entités financières une gestion documentée du risque informatique, étendue aux prestataires tiers.

Le point décisif est que ces six règlements n’opèrent pas dans des compartiments séparés. Une communication réglementaire émise par une banque peut être simultanément soumise à DORA pour la résilience, à l’AI Act si le contenu est personnalisé par un modèle, à eIDAS 2.0 pour la signature, et aux exigences de souveraineté pour la résidence des données.

C’est pourquoi l’évaluation d’une plateforme CCM ne peut pas s’arrêter au périmètre fonctionnel. Elle doit s’étendre à l’architecture. C’est l’architecture qui détermine si ces obligations peuvent être satisfaites simultanément — sur la même communication, dans le fonctionnement normal de la plateforme — plutôt que par des mesures correctives construites au cas par cas.

L’intégration comme infrastructure réglementaire

Du croisement de ces obligations découle une conclusion opérationnelle précise : l’intégration entre le CRM et le système de communication doit être conçue comme un composant soumis aux mêmes exigences réglementaires que chacun des deux systèmes individuels — et non comme un simple mécanisme de transfert de données entre eux.

Concrètement, cela se traduit par quatre exigences spécifiques.

La portabilité des données doit être garantie par l’architecture elle-même. Les plateformes construites sur des interfaces ouvertes et des modèles de données documentés satisfont cette exigence. Celles qui reposent sur des formats propriétaires et fermés, non.

La journalisation des décisions prises par l’IA — données d’entrée, version du modèle et logique de décision pour chaque communication générée — doit être conservée et mise à disposition des équipes de conformité.

La remise de documents avec signature qualifiée doit être acheminée via des services de confiance conformes à eIDAS.

La résilience opérationnelle exige de définir en amont ce qui se passe si le CRM ou la plateforme de communication devient indisponible. Et l’ensemble de la chaîne — extraction depuis le CRM, transit, traitement, archivage — doit rester sous juridiction européenne. Pour les établissements financiers de la zone DACH et pour l’administration publique française en particulier, cette dernière exigence n’est pas négociable.

Le cadre réglementaire européen, par pays et par secteur

Le cadre européen est commun, mais chaque pays y ajoute des réglementations nationales. C’est là que le choix d’une plateforme CCM doit tenir compte des spécificités locales.

Allemagne

En Allemagne, le Bundesdatenschutzgesetz (BDSG) — loi fédérale sur la protection des données — complète le RGPD par des dispositions plus strictes sur les relations avec les fournisseurs. La BaFin, l’autorité de surveillance financière, exige une gestion documentée du risque informatique couvrant explicitement les dépendances vis-à-vis des prestataires de communication.

Italie

En Italie, les recommandations de l’Agence nationale pour la cybersécurité (ACN) sur la mise en œuvre de NIS2 s’étendent aux prestataires de services informatiques. Le Code de l’administration numérique (CAD) impose également, pour les administrations publiques, des normes d’accessibilité et l’intégration avec l’infrastructure nationale d’identité numérique.

France

En France, l’orientation vers la souveraineté technologique — renforcée par SecNumCloud, le référentiel de qualification développé par l’ANSSI — conduit les organisations des secteurs régulés à privilégier systématiquement les infrastructures qui maintiennent les données et leur traitement au sein de l’Union européenne.

Des obligations différentes selon les secteurs, une même décision d’architecture

Aux différences nationales s’ajoutent les obligations propres à chaque secteur. Un opérateur d’énergie doit garantir des communications d’urgence authentifiées et traçables au titre de NIS2. Une compagnie d’assurance est soumise à DORA et aux exigences de l’AI Act pour les communications issues d’évaluations automatisées. Une autorité publique doit respecter les normes d’accessibilité et s’intégrer aux systèmes d’identité nationaux.  Des obligations différentes, mais qui convergent toutes vers les mêmes choix architecturaux.

Les vérifications à conduire au moment de la migration

La convergence de ces six règlements conduit à une conclusion opérationnelle : la migration CRM est aussi le moment de vérifier si la plateforme de communication retenue est capable de répondre durablement à l’ensemble des exigences réglementaires Reporter cette vérification après la mise en production expose l’organisation à une période où les communications sont gérées sans conformité pleine et entière — précisément au moment où les échéances européennes deviennent contraignantes.

Le livre blanc Migration vers le CRM cloud : quand l’engagement client rencontre les communications intelligentes analyse en détail chacun des six règlements, leurs implications au niveau de l’intégration, et les spécificités des marchés DACH, italien et français.  Il fournit un cadre méthodologique permettant de transformer ces obligations réglementaires en critères d’évaluation concrets pour le choix d’une plateforme CCM et de son architecture d’intégration.