Comment les entreprises technologiques européennes peuvent répondre aux exigences de protection des données clients dans les services financiers

Les entreprises technologiques européennes qui vendent à des banques, assureurs, sociétés d’investissement ou prestataires de paiement sont soumises à des exigences en matière de protection des données plus strictes que celles imposées aux fournisseurs d’autres secteurs. Les clients des services financiers traitent des données personnelles relevant du RGPD, des données de paiement régies par la PSD2, des informations de trading encadrées par la MiFID II, des données d’assurance relevant de l’IDD, ainsi que des informations clients protégées par des lois nationales sur le secret bancaire, assorties de sanctions pénales. Les fournisseurs technologiques doivent prouver que leur architecture répond à l’ensemble de ces cadres réglementaires en même temps — une matrice de conformité qui se complexifie à mesure que le client financier opère dans de nouvelles juridictions.

Cet article cartographie les exigences réglementaires imbriquées auxquelles sont confrontés les fournisseurs technologiques européens qui ciblent le secteur financier, explique pourquoi le chiffrement géré par le client constitue le socle architectural qui permet d’y répondre collectivement, et aborde les choix d’implémentation qui déterminent si un fournisseur peut obtenir — et conserver — des contrats dans les services financiers.

Résumé Exécutif

Idée principale : Les entreprises technologiques européennes qui servent le secteur financier font face à des exigences de protection des données superposées : le RGPD pose les contrôles de base, les réglementations sectorielles ajoutent des obligations supplémentaires, et les lois nationales sur le secret bancaire créent une responsabilité pénale en cas de divulgation non autorisée — autant d’exigences auxquelles répond une architecture de chiffrement gérée par le client, via une seule mise en œuvre technique. Banques, assureurs et sociétés d’investissement exigent des fournisseurs qu’ils démontrent un chiffrement géré par le client, une isolation géographique des données et une architecture technique empêchant tout accès gouvernemental transfrontalier.

Pourquoi c’est important : L’Autorité bancaire européenne a signalé que 68 % des banques ont mis à jour leur évaluation des fournisseurs en 2024–2025 pour intégrer les exigences de souveraineté des données après la mise en œuvre de DORA. Les fournisseurs technologiques incapables de démontrer une architecture conforme risquent d’être systématiquement exclus des opportunités dans les services financiers, qui représentent 30 à 40 % des dépenses technologiques des entreprises européennes.

5 points clés à retenir

1. Les exigences de protection des données dans les services financiers superposent les contrôles de base du RGPD à des réglementations sectorielles, créant des obligations cumulatives. Une plateforme fintech traitant des données bancaires doit satisfaire au chiffrement de l’article 32 du RGPD, aux standards d’authentification de la PSD2, aux lois nationales sur le secret bancaire et à la gestion des risques TIC imposée par DORA. Les fournisseurs technologiques doivent démontrer une architecture conforme à l’ensemble de ces cadres simultanément.
2. Les lois sur le secret bancaire créent une responsabilité pénale en cas de divulgation non autorisée de données clients, qui s’étend aux fournisseurs technologiques. L’article 47 de la loi bancaire suisse, les dispositions luxembourgeoises, l’article 38 de la loi bancaire autrichienne et les protections équivalentes en Allemagne et en France imposent aux banques des obligations qui s’appliquent directement à leurs prestataires technologiques. Lorsqu’une banque utilise une plateforme permettant au fournisseur d’accéder à des données financières clients, elle expose à une responsabilité pénale tant elle-même que son fournisseur.
3. Les données de transaction de paiement relevant de la PSD2 exigent une architecture technique empêchant tout accès non autorisé tout en permettant le reporting réglementaire. L’article 94 de la PSD2 impose une authentification forte du client, l’article 95 exige une communication sécurisée, et l’article 98 encadre l’accès aux comptes de paiement. Les entreprises technologiques qui fournissent des services de paiement doivent mettre en œuvre une architecture de chiffrement protégeant les données de transaction tout en assurant la conformité réglementaire.
4. Les exigences de la MiFID II en matière de données de trading vont au-delà de la protection des données personnelles et incluent la prévention des abus de marché et le reporting des transactions. Les sociétés d’investissement qui utilisent des plateformes technologiques pour l’exécution d’ordres ou la gestion de portefeuille doivent vérifier que les fournisseurs mettent en place des contrôles empêchant tout accès non autorisé aux données de trading, tout en maintenant des pistes d’audit conformes aux standards de l’ESMA.
5. Les exigences de l’Insurance Distribution Directive pour les données assurés créent des obligations qui s’appliquent aussi aux fournisseurs technologiques. L’article 29 de l’IDD impose aux distributeurs d’assurance de mettre en place des mesures appropriées pour protéger les informations clients. Lorsqu’un assureur utilise une plateforme pour la gestion des polices, le traitement des sinistres ou le CRM, il doit vérifier que le fournisseur satisfait aux exigences de l’IDD en plus de celles du RGPD.

Comment le RGPD, DORA et les réglementations sectorielles créent des exigences imbriquées

Le RGPD pose les exigences de base en matière de protection des données, mais les réglementations financières imposent des obligations supplémentaires qui alourdissent la charge de conformité. Les fournisseurs technologiques doivent satisfaire à la fois aux exigences horizontales du RGPD et aux obligations verticales propres à chaque secteur.

Le RGPD pose la base sur laquelle toutes les autres réglementations financières s’appuient

L’article 32 du RGPD impose des mesures techniques appropriées, dont le chiffrement, la pseudonymisation et des mesures garantissant la confidentialité, l’intégrité, la disponibilité et la résilience. L’article 33 impose la notification des violations sous 72 heures. Les articles 44 à 50 encadrent les transferts internationaux de données, exigeant une protection adéquate lorsque les données sortent de l’UE. Ces exigences de base s’appliquent à tout fournisseur du secteur financier — mais pour ce secteur, elles ne constituent qu’un minimum.

DORA ajoute des exigences spécifiques de gestion des risques TIC et de supervision des tiers qui lient directement les fournisseurs technologiques

DORA complète les protections de base par des exigences spécifiques pour les entités financières et les prestataires de services TIC. L’article 28 impose un cadre de gestion des risques TIC, incluant l’évaluation de tous les prestataires tiers. L’article 30 exige des dispositions contractuelles garantissant la mise en œuvre de mesures de sécurité, le contrôle de la localisation des données et la mise en place de stratégies de sortie permettant la suppression complète des données. Surtout, DORA impose des obligations directement aux fournisseurs technologiques, et pas seulement aux institutions financières utilisatrices — faisant des choix d’architecture un enjeu réglementaire direct.

PSD2, MiFID II et IDD ajoutent chacune des exigences sectorielles qui se cumulent avec le RGPD et DORA

La PSD2 ajoute des exigences propres au paiement via l’authentification forte de l’article 94, les standards de communication sécurisée de l’article 95 et les exigences opérationnelles de l’article 97. La MiFID II impose des exigences pour les services d’investissement via l’article 16 (organisation), l’article 25 (reporting des transactions) et l’article 76 (conservation des enregistrements). L’IDD impose des obligations via l’article 29 sur la protection des données. Résultat : une matrice de conformité où une plateforme destinée aux banques, assureurs et sociétés d’investissement doit répondre à l’ensemble de ces cadres via une seule mise en œuvre technique — un choix d’architecture qui ne répond qu’à une partie de ces exigences ne suffit pas.

Lois nationales sur le secret bancaire et responsabilité pénale

Les lois sur le secret bancaire dans les grands centres financiers européens créent une responsabilité pénale en cas de divulgation non autorisée d’informations financières clients, avec des obligations qui s’étendent explicitement aux fournisseurs technologiques. Ces lois ne considèrent pas la divulgation non autorisée comme une simple question civile — il s’agit d’un crime, et l’exposition se transmet par la chaîne contractuelle jusqu’aux prestataires.

L’article 47 de la loi bancaire suisse crée une responsabilité pénale qui s’applique directement aux fournisseurs de services technologiques

L’article 47 de la loi bancaire suisse prévoit des peines pouvant aller jusqu’à trois ans d’emprisonnement et 250 000 CHF d’amende pour divulgation non autorisée. L’obligation s’étend aux prestataires technologiques via la réglementation bancaire suisse, qui impose aux banques de s’assurer que leurs tiers appliquent des protections de confidentialité équivalentes. Lorsque les banques suisses utilisent des plateformes où des entités non suisses conservent un accès technique aux données, elles s’exposent à des violations de l’article 47. La seule architecture qui élimine ce risque est celle où le fournisseur ne peut techniquement accéder aux données en clair — le chiffrement géré par le client, appliqué au niveau de la gestion des clés.

Le Luxembourg, l’Autriche, l’Allemagne et la France imposent chacun des obligations équivalentes, appliquées par leurs régulateurs nationaux

Au Luxembourg, les dispositions sur le secret bancaire protègent les informations financières des clients via des sanctions pénales, la CSSF imposant aux banques de vérifier que les fournisseurs technologiques mettent en place des contrôles empêchant tout accès non autorisé. La place du Luxembourg dans l’administration de fonds implique que les entreprises technologiques au service des gestionnaires d’actifs font l’objet d’une vigilance accrue sur l’architecture de souveraineté des données. L’article 38 de la loi bancaire autrichienne instaure le secret bancaire avec sanctions pénales, sous la supervision de la FMA. En Allemagne, le secret bancaire découle du §203 StGB et des recommandations de la BaFin, qui insiste sur le fait que les banques doivent empêcher tout accès gouvernemental étranger via leurs prestataires. En France, le secret bancaire est issu du Code monétaire et financier, l’ACPR exigeant la vérification de protections de confidentialité appropriées.

Le chiffrement géré par le client est la seule architecture qui satisfait simultanément à toutes les lois nationales sur le secret bancaire

La convergence de ces lois nationales avec le RGPD et DORA crée un cadre où les fournisseurs technologiques doivent démontrer une architecture empêchant toute divulgation non autorisée, quelle que soit la base juridique invoquée. La seule approche technique qui répond à tous ces cadres consiste à mettre en œuvre un chiffrement géré par le client, où l’institution financière détient seule le contrôle des clés de déchiffrement — garantissant que même si le fournisseur reçoit une injonction gouvernementale dans n’importe quelle juridiction, il n’a aucun moyen technique d’accéder aux données financières en clair. La conformité devient alors un fait technique, et non plus seulement un argument juridique.

Exigences sur les données de paiement selon la PSD2

La PSD2 crée des obligations spécifiques pour les entreprises technologiques qui fournissent des services de traitement de paiement, d’information sur les comptes, d’initiation de paiement ou d’infrastructures associées. Les standards techniques réglementaires de la PSD2 fixent des exigences de sécurité qui vont au-delà des protections de base du RGPD et interagissent avec les attentes des régulateurs nationaux du paiement dans chaque pays.

Les standards techniques de l’EBA sur l’authentification forte du client imposent des exigences architecturales spécifiques au-delà du chiffrement général

L’article 94 impose une authentification forte du client, reposant sur deux éléments indépendants parmi les catégories connaissance, possession et inhérence. Les plateformes facilitant les transactions de paiement doivent intégrer une architecture d’authentification conforme à ces exigences. L’article 95 impose des standards de communication sécurisée, les RTS de l’EBA fixant les exigences de chiffrement, de gestion des certificats et de protocoles de sécurité. Les entreprises technologiques qui proposent des API pour l’information sur les comptes ou l’initiation de paiement doivent mettre en œuvre TLS avec des suites de chiffrement spécifiques et une surveillance de la sécurité — des exigences qui s’articulent avec le chiffrement géré par le client, mais ne le remplacent pas.

Les opérations de paiement multi-juridictionnelles exigent une architecture de résidence des données adaptée à la géographie

La difficulté s’accentue pour les prestataires de paiement opérant dans plusieurs juridictions européennes. Une plateforme de paiement qui dessert des banques en Allemagne, en France et aux Pays-Bas doit satisfaire aux attentes de la BaFin, de l’ACPR et de la banque centrale néerlandaise, tout en appliquant uniformément les RTS de la PSD2. Les exigences de résidence des données varient selon les pays, ce qui impose une topologie complexe où le fournisseur doit démontrer que les données des clients allemands sont traitées en Allemagne, celles des clients français en France, et celles des clients néerlandais aux Pays-Bas. Le chiffrement géré par le client, avec une gestion des clés propre à chaque juridiction, est le mécanisme qui rend cette architecture géographiquement adaptée opérationnelle.

Données de trading MiFID II et protection des informations clients corporate

Les réglementations sur les services d’investissement imposent des exigences distinctes de la protection des données clients particuliers, en se concentrant sur l’intégrité des marchés, le reporting des transactions et la prévention des abus de marché. Les entreprises technologiques qui fournissent des plateformes de trading, des systèmes de gestion de portefeuille ou des outils de recherche doivent satisfaire aux exigences de la MiFID II en plus de celles du RGPD — deux cadres qui protègent des choses différentes.

Les exigences de conservation et de reporting des transactions MiFID II imposent des pistes d’audit qui doivent coexister avec le chiffrement

L’article 16 de la MiFID II impose aux sociétés d’investissement de mettre en place une organisation garantissant la conformité, l’article 16(6) encadrant l’externalisation — avec obligation de s’assurer que les prestataires appliquent des mesures de sécurité appropriées. L’article 25 impose le reporting des transactions aux autorités compétentes. Les plateformes technologiques doivent conserver des pistes d’audit conformes aux standards techniques de l’ESMA, tout en empêchant tout accès non autorisé aux données de trading. L’article 76 impose la conservation des enregistrements de services et de transactions pendant au moins cinq ans, avec une architecture qui garantit l’intégrité des données, empêche toute modification non autorisée et permet l’accès réglementaire tout en protégeant la confidentialité des clients.

Les données de trading des clients corporate exigent une architecture contractuelle de confidentialité, au-delà des protections du RGPD

Les données de trading des clients corporate bénéficient d’une protection distincte de celle des données personnelles des clients particuliers. Lorsqu’une société d’investissement sert des clients corporate — gestionnaires d’actifs, fonds de pension, compagnies d’assurance — les informations de trading constituent une intelligence stratégique : positions, stratégies, compositions de portefeuille qui révèlent un avantage concurrentiel. Le RGPD s’applique aux coordonnées, mais cette intelligence de trading relève de la confidentialité contractuelle et du devoir fiduciaire. Les fournisseurs technologiques doivent mettre en œuvre une architecture qui distingue ces catégories, répondant aux exigences du RGPD pour les clients particuliers et à la confidentialité contractuelle pour les données corporate, via des hiérarchies de clés de chiffrement séparées qui imposent des contrôles d’accès différenciés selon la catégorie de données.

Protection des données d’assurance selon l’IDD

L’Insurance Distribution Directive crée des obligations pour les entreprises technologiques qui servent les assureurs, intermédiaires et plateformes de distribution. L’article 29 de l’IDD impose des mesures appropriées pour protéger les informations clients, complétant les exigences de base du RGPD par des dispositions spécifiques à l’assurance, particulièrement exigeantes pour les données de santé et de sinistres.

Les données d’assurance santé déclenchent les exigences du RGPD sur les catégories particulières, en plus des obligations de l’IDD

Les données assurés incluent des informations personnelles relevant du RGPD, les conditions de la police, les paiements de primes et l’historique des sinistres. Les données de santé bénéficient d’une protection particulière selon l’article 9 du RGPD, ce qui impose des exigences renforcées pour les plateformes traitant des demandes d’assurance-vie, des sinistres santé ou des données médicales pour la souscription. Les données de sinistres posent des difficultés spécifiques car elles incluent souvent des informations sensibles — dossiers médicaux pour l’assurance santé, rapports de police pour l’auto, expertises pour l’habitation. Les plateformes qui traitent ces données doivent répondre à la fois aux exigences spécifiques de l’IDD et au niveau de protection le plus élevé du RGPD.

Les plateformes de distribution multi-assureurs exigent une isolation cryptographique entre les données clients de concurrents

Les régulateurs nationaux de l’assurance imposent des exigences supplémentaires au-delà des protections de base de l’IDD. La BaFin en Allemagne, l’ACPR en France et la FCA au Royaume-Uni exigent que les assureurs s’assurent que les contrats d’externalisation prévoient des clauses de protection des données appropriées. Les plateformes de distribution qui servent plusieurs assureurs doivent garantir la ségrégation des données : une plateforme permettant à des intermédiaires de proposer et vendre des contrats de plusieurs compagnies doit veiller à ce que les données clients de chaque assureur restent isolées, empêchant tout accès par un concurrent, tout en permettant aux intermédiaires de servir efficacement leurs clients. Cela impose une architecture multi-tenant avec isolation cryptographique, et non une simple séparation logique — seul le chiffrement géré par le client, avec des hiérarchies de clés distinctes par assureur, permet une séparation réellement opposable.

Architecture de chiffrement géré par le client pour la conformité financière

La convergence du RGPD, de DORA, de la PSD2, de la MiFID II, de l’IDD et des lois nationales sur le secret bancaire crée un cadre de conformité auquel répond une architecture de chiffrement géré par le client, via une seule mise en œuvre technique.

Le contrôle des clés par l’institution financière via des HSM constitue le socle architectural qui satisfait à tous les cadres

Le chiffrement géré par le client commence par la génération des clés sous le contrôle exclusif de l’institution financière. Les clés sont générées dans des modules matériels de sécurité (HSM) déployés sur site ou via des services HSM européens conçus pour la souveraineté financière. L’institution contrôle tout le cycle de vie des clés, sans intervention du fournisseur technologique. Lorsqu’une donnée financière client entre sur la plateforme — transaction de paiement, ordre de trading, demande d’assurance ou information de compte — le chiffrement s’effectue immédiatement avec les clés du HSM de l’institution. Les données chiffrées peuvent alors résider sur différentes infrastructures, le fournisseur n’ayant aucun moyen technique de les déchiffrer.

La même architecture répond au RGPD, à DORA, à la PSD2, à la MiFID II, à l’IDD et aux lois sur le secret bancaire sans implémentations séparées

Cette architecture unifiée répond simultanément à toute la matrice de conformité. Pour les prestataires de paiement, le chiffrement géré par le client protège les identifiants et transactions tout en maintenant les flux d’authentification forte de la PSD2. Pour les sociétés d’investissement utilisant des plateformes de trading, il protège les données de trading tout en assurant les capacités de reporting MiFID II. Pour les assureurs utilisant des systèmes de gestion de polices ou de sinistres, il protège les données assurés, y compris les informations de santé et les décisions de souscription. La flexibilité de déploiement permet aux institutions financières d’arbitrer entre souveraineté et besoins opérationnels : les banques qui exigent un contrôle maximal déploient sur site, les prestataires de paiement qui recherchent l’économie du cloud optent pour un cloud privé avec chiffrement géré par le client, les assureurs déploient des appliances virtuelles durcies pour conjuguer souveraineté et simplicité opérationnelle.

Points d’attention pour la mise en œuvre

Les entreprises technologiques qui ajoutent des fonctions de conformité financière doivent faire des choix architecturaux concernant la gestion des clés de chiffrement, les modèles de déploiement, le contrôle de la résidence des données, le reporting réglementaire et les capacités d’audit.

L’architecture de gestion des clés doit prendre en charge plusieurs options HSM selon les attentes réglementaires de chaque juridiction

L’architecture de gestion des clés doit permettre l’intégration de plusieurs options HSM, afin que chaque institution financière puisse choisir selon les exigences de son régulateur. Les banques en Suisse, au Luxembourg ou en Allemagne peuvent exiger des HSM sur site pour respecter le secret bancaire national. Les prestataires de paiement peuvent privilégier des services HSM européens conciliant souveraineté et exigences opérationnelles de la PSD2. Les assureurs peuvent adopter des approches différentes pour la gestion des polices et pour les systèmes marketing. L’exigence clé est que la plateforme du fournisseur puisse s’intégrer à l’infrastructure de gestion des clés attendue par le régulateur de l’institution — une flexibilité non négociable pour tout fournisseur opérant dans plusieurs juridictions européennes.

Les interfaces de reporting réglementaire doivent permettre la conformité sans exposer les données en clair au fournisseur

Les interfaces de reporting réglementaire doivent être conçues avec soin pour permettre la conformité sans compromettre l’architecture de chiffrement. Le reporting des transactions MiFID II, le reporting des incidents PSD2 et le reporting réglementaire assurance doivent s’effectuer via des mécanismes qui permettent à l’institution financière de générer les rapports à partir des données chiffrées, sans jamais exposer d’informations en clair au fournisseur technologique. Cela signifie que le reporting doit s’exécuter côté institution, de l’autre côté de la frontière de chiffrement — une exigence architecturale souvent négligée par les fournisseurs jusqu’à ce qu’ils soient engagés dans des cycles de vente avancés dans la finance.

L’architecture multi-tenant pour plusieurs institutions financières exige une isolation cryptographique plutôt que logique

Le contrôle de la résidence des données doit s’adapter aux exigences spécifiques de chaque juridiction tout en maintenant une plateforme unifiée. Les banques allemandes peuvent exiger un traitement des données en Allemagne pour satisfaire la BaFin. Les établissements de paiement français peuvent exiger une résidence des données en France pour répondre à l’ACPR. L’architecture multi-tenant des plateformes qui servent plusieurs institutions financières doit mettre en œuvre une isolation cryptographique, et non une simple séparation logique, afin que les données clients de chaque institution restent chiffrées sous des clés distinctes — empêchant tout accès croisé, ce que ni les contrôles d’accès logiques ni les clauses contractuelles ne peuvent garantir pleinement.

Comment Kiteworks permet aux entreprises technologiques européennes de répondre aux exigences de protection des données financières

Les entreprises technologiques européennes qui servent le secteur financier ne peuvent pas satisfaire à la matrice réglementaire en se conformant à un seul cadre — le RGPD seul ne suffit pas, DORA seul ne suffit pas, et la conformité au secret bancaire national ne suffit pas non plus. L’architecture de chiffrement géré par le client est le socle technique qui répond à l’ensemble de ces cadres, car elle garantit que le fournisseur n’a aucun moyen technique d’accéder aux données financières clients, quelle que soit la demande d’un gouvernement dans n’importe quelle juridiction. Les fournisseurs qui mettent en œuvre cette architecture peuvent obtenir des contrats financiers ; ceux qui ne le font pas risquent d’être systématiquement exclus d’un secteur qui représente 30 à 40 % des dépenses technologiques des entreprises européennes.

Kiteworks fournit aux entreprises technologiques européennes qui servent la finance une architecture de chiffrement géré par le client, conforme au RGPD, à DORA, à la PSD2, à la MiFID II, à l’IDD et aux lois nationales sur le secret bancaire. La plateforme utilise des clés de chiffrement contrôlées par le client, qui ne quittent jamais l’infrastructure de l’institution financière, ce qui signifie que même si Kiteworks reçoit une injonction gouvernementale ou subit un incident de sécurité, nous n’avons aucun moyen technique d’accéder aux données financières clients.

La plateforme propose un déploiement flexible, incluant l’installation sur site dans les datacenters des institutions financières, le déploiement en cloud privé dans des infrastructures européennes sous contrôle client, et des appliances virtuelles durcies offrant les avantages de la souveraineté avec une complexité opérationnelle réduite. Les banques peuvent déployer en Suisse pour satisfaire à l’article 47 de la loi bancaire, les prestataires de paiement peuvent mettre en œuvre des architectures conformes à la PSD2, les assureurs peuvent répondre aux exigences de protection des données de l’IDD, et les sociétés d’investissement peuvent satisfaire aux obligations de confidentialité de la MiFID II grâce à un choix de déploiement adapté aux exigences réglementaires.

Kiteworks intègre la messagerie électronique, le partage et le transfert de fichiers, ainsi que les formulaires web dans une architecture unifiée permettant aux institutions financières de gérer les communications de données sensibles clients via une plateforme souveraine unique. Cette intégration simplifie la mise en œuvre des clés gérées par le client pour les transactions de paiement, les données de trading, les sinistres d’assurance et les informations de compte, tout en fournissant un audit unifié conforme aux exigences réglementaires du RGPD, de DORA, de la PSD2, de la MiFID II et de l’IDD.

Pour les entreprises technologiques qui servent des institutions financières soumises à DORA, l’architecture de la plateforme répond aux exigences de l’article 30 en matière de chiffrement, de contrôle de la localisation des données et de stratégies de sortie. Les clés de chiffrement gérées par le client répondent aux exigences d’accès et de suppression des données, tandis que la flexibilité de déploiement permet de satisfaire aux exigences de traitement géographique. Les fonctions de sortie de la plateforme permettent aux institutions financières de migrer sans la coopération de Kiteworks, évitant ainsi l’enfermement fournisseur tout en répondant aux exigences de DORA sur les stratégies de sortie.

Pour en savoir plus sur la façon dont Kiteworks aide les entreprises technologiques européennes à répondre aux exigences de protection des données clients du secteur financier, réservez votre démo personnalisée dès maintenant.

Ressources complémentaires

• Article de blog
  Souveraineté des données : bonne pratique ou exigence réglementaire ?
• eBook
  Souveraineté des données et RGPD
• Article de blog
  Évitez ces pièges de la souveraineté des données
• Article de blog
  Bonnes pratiques de souveraineté des données
• Article de blog
  Souveraineté des données et RGPD [Comprendre la sécurité des données]