Comment les cabinets comptables européens peuvent protéger les données financières de leurs clients lors de missions à l’international

Lorsque les cabinets comptables européens réalisent des audits transfrontaliers, chaque document financier circule via une infrastructure qui soit respecte les obligations de secret professionnel, soit expose à des sanctions pénales. En Allemagne, le §203 StGB prévoit des peines de prison. En France, le secret professionnel entraîne une peine d’emprisonnement et une amende de 15 000 €. En Suisse, l’article 321 s’applique même au-delà des frontières pour les clients internationaux. Ces risques ne sont pas théoriques : ils découlent directement des choix technologiques des cabinets pour le stockage et la transmission des données clients.

Le problème structurel vient du fait que les cadres du secret professionnel ont été conçus avant que l’informatique en cloud n’ouvre la voie à l’accès des gouvernements étrangers. Lorsqu’un cabinet d’audit allemand stocke les dossiers de travail de ses clients sur une plateforme dont le siège est aux États-Unis, les autorités américaines peuvent obliger ce fournisseur à fournir les données sans passer par un tribunal européen, sans prévenir le cabinet, et sans que rien dans la lettre de mission du cabinet ne puisse s’y opposer. Ce guide explique à quoi ressemble une architecture conforme pour les missions comptables transfrontalières, et pourquoi le chiffrement géré par le client constitue le socle technique permettant de satisfaire simultanément au secret professionnel, au RGPD et à DORA.

Résumé Exécutif

Idée principale : Les cabinets comptables européens s’exposent à des sanctions pénales en cas de divulgation non autorisée de données clients, mais la plupart stockent les données financières de leurs clients sur des plateformes américaines qui ouvrent la voie à l’accès de gouvernements étrangers hors du cadre juridique européen — et contrairement aux avocats, les experts-comptables ne peuvent pas s’appuyer sur le secret professionnel pour combler cette faille. La CJUE a jugé que les comptables bénéficient de protections plus faibles que les avocats, ce qui fait de l’architecture souveraine le seul moyen fiable de respecter les obligations de secret professionnel.

Pourquoi c’est important : Trois cabinets du Big Four ont été touchés lors de la faille MOVEit en 2023, le Financial Reporting Council britannique a signalé 127 procédures disciplinaires en 2024, les défaillances technologiques représentant une part croissante des cas de manquements professionnels, et DORA impose désormais des exigences technologiques directement aux cabinets comptables via leurs clients du secteur financier. Les cabinets incapables de démontrer une architecture souveraine s’exposent à un risque accru de sanctions et à une exclusion systématique des marchés réglementés.

5 points clés à retenir

1. Le secret professionnel entraîne des sanctions pénales dans toute l’Europe, et les choix technologiques ont un impact direct sur la conformité. Le §203 StGB allemand, le secret professionnel français, l’article 321 suisse, l’article 272 néerlandais et les obligations de common law au Royaume-Uni s’appliquent aussi aux plateformes cloud. Il ne s’agit pas de simples décisions IT, mais de responsabilités professionnelles qui engagent la licence d’exercice et le risque de poursuites.
2. Les comptables ne bénéficient pas du secret professionnel des avocats, ce qui exige une architecture souveraine renforcée. La CJUE a jugé que les comptables disposent de garanties moins solides que les avocats. Alors que les avocats bénéficient de recommandations du CCBE sur le cloud et de protections conventionnelles à partir de 2025, les comptables doivent s’appuyer sur des contrôles techniques et non sur le secret professionnel pour éviter la divulgation forcée — l’architecture devient la première ligne de défense, et non un simple complément à la protection juridique.
3. DORA impose des exigences technologiques aux cabinets comptables via leurs clients du secteur financier. L’article 30 exige des contrats couvrant la souveraineté des données, la gestion des clés de chiffrement et les stratégies de sortie. Lorsque les banques font appel à des cabinets comptables, ces obligations technologiques s’appliquent aux plateformes utilisées pour les données clients — l’architecture du fournisseur devient donc une question réglementaire directe pour les cabinets travaillant avec des clients du secteur financier.
4. Les missions transfrontalières créent des failles de conformité lorsque les données clients traversent plusieurs juridictions. Un cabinet allemand auditant une filiale française d’une maison mère suisse traite des données soumises à trois régimes de secret professionnel, tandis que le CLOUD Act permet l’accès des autorités américaines, quel que soit le lieu de stockage. Les clauses contractuelles types ne peuvent pas s’opposer à l’autorité souveraine — seule l’architecture technique le peut.
5. Les grands cabinets comptables restent exposés malgré d’importants investissements en sécurité. Trois cabinets du Big Four ont été touchés par MOVEit. La faille chez Sax LLP est restée indétectée pendant 16 mois. Deloitte a payé 5 millions de dollars après quatre mois d’accès non détecté. Les assureurs en responsabilité professionnelle examinent désormais l’architecture technologique et exigent des options de déploiement souverain, certaines polices excluant les incidents où le fournisseur détient le contrôle des clés de chiffrement.

Obligations de secret professionnel que les cabinets comptables européens ne peuvent pas déléguer

Le secret professionnel des comptables entraîne des sanctions pénales dans toute l’Europe, mais ces cadres juridiques sont antérieurs à l’ouverture des accès gouvernementaux étrangers par le cloud. Résultat : une tension structurelle, car des obligations conçues pour un monde de dossiers papier s’appliquent désormais à une infrastructure où le cabinet n’est plus forcément le seul à avoir un accès technique aux données clients.

Les articles §203 StGB et §43 WPO allemands créent une responsabilité pénale qui s’étend aux choix de plateformes technologiques

Le §43 WPO allemand fait du secret professionnel de l’auditeur une obligation professionnelle, tandis que le §203 StGB punit la divulgation non autorisée de peines de prison pour les personnes responsables. Plus de 15 000 professionnels sont concernés. L’Institut der Wirtschaftsprüfer a précisé que le secret professionnel du §43 WPO s’étend à tous les systèmes technologiques, et que les auditeurs ne peuvent pas remplir leurs obligations via des plateformes où le fournisseur détient les clés de déchiffrement. Lorsque les cabinets stockent les données clients sur une infrastructure contrôlée par les États-Unis, ils créent des voies de divulgation hors du contrôle juridique allemand — indépendamment de toute interdiction contractuelle d’accès non autorisé.

La France, la Suisse et les Pays-Bas imposent des obligations pénales équivalentes aux comptables

L’article L. 822-15 du Code de commerce français soumet les commissaires aux comptes au secret professionnel, avec l’article 226-13 du Code pénal qui prévoit prison et 15 000 € d’amende en cas de violation. La CNIL rappelle que les comptables restent responsables de la protection des données clients même avec des prestataires tiers — l’externalisation ne transfère pas l’obligation. L’article 321 du Code pénal suisse protège le secret de l’auditeur et du conseiller fiscal, y compris pour les clients internationaux. L’article 272 du Code pénal néerlandais impose le secret professionnel aux comptables inscrits à la NBA, et l’autorité néerlandaise de protection des données souligne que le secret professionnel s’applique aussi aux systèmes numériques et au cloud.

L’arrêt de la CJUE sur la protection moindre des comptables par rapport aux avocats fait de l’architecture technique la première ligne de défense

La comptabilité au Royaume-Uni relève du devoir de confidentialité de la common law, renforcé par les normes du FRC et de l’ICAEW. Même sans textes pénaux continentaux, la violation entraîne une responsabilité civile, des manquements professionnels et des poursuites potentielles au titre du Computer Misuse Act 1990 ou du Data Protection Act 2018 — le rapport 2024 du FRC recense 127 procédures disciplinaires, les défaillances technologiques étant en hausse. Surtout, l’arrêt Ordre des barreaux francophones de la CJUE a confirmé que les comptables bénéficient de protections juridiques moins strictes que les avocats. Les cabinets ne peuvent donc pas invoquer le secret professionnel pour s’opposer à une divulgation forcée : ils doivent mettre en place une architecture technique qui rende tout accès non autorisé impossible au niveau de l’infrastructure — via un chiffrement géré par le client, de sorte que le fournisseur ne puisse techniquement pas accéder aux données sans la coopération du cabinet.

Exigences technologiques du RGPD et de DORA pour les cabinets comptables

Le RGPD fixe les exigences minimales de sécurité, tandis que DORA les complète par des obligations technologiques transmises par les institutions financières à leurs prestataires comptables. Ensemble, ils forment un cadre de conformité que les seuls contrats ne suffisent pas à respecter.

L’article 32 du RGPD exige un chiffrement qui n’offre une protection suffisante que si le responsable du traitement détient seul les clés

L’article 32 du RGPD impose des « mesures techniques et organisationnelles appropriées », dont le chiffrement, la confidentialité, l’intégrité et la disponibilité. Le principe d’« intégrité et confidentialité » de l’article 5(1)(f) impose une protection contre tout traitement non autorisé — ce qui est incompatible avec les architectures où le fournisseur peut accéder aux données, car ces systèmes ne peuvent garantir la protection si le fournisseur est soumis à une contrainte légale hors du contrôle du responsable du traitement. Le groupe de travail Article 29 est explicite : le chiffrement n’offre une protection suffisante que si le responsable du traitement détient seul les clés de déchiffrement. Le chiffrement géré par le fournisseur ne répond qu’à la forme, pas au fond de l’exigence.

L’arrêt Schrems II a établi que les SCC ne suffisent pas lorsque des gouvernements tiers peuvent accéder aux données

L’arrêt Schrems II a établi que les SCC ne suffisent pas à garantir une protection adéquate lorsque les données sont transférées vers des juridictions où la surveillance gouvernementale ne présente pas de garanties équivalentes à l’Europe. La CJUE a examiné les cas où les obligations des pays tiers permettent un accès des autorités publiques allant au-delà de ce qui est nécessaire et proportionné — c’est précisément la situation des fournisseurs cloud américains soumis au CLOUD Act. L’EDPB exige que les responsables du traitement évaluent si le droit ou la pratique du pays tiers porte atteinte à l’efficacité des garanties, et mettent en place des mesures techniques complémentaires si c’est le cas. Pour les cabinets comptables, cela signifie que les SCC doivent s’accompagner d’un chiffrement géré par le client, et non s’y substituer.

L’article 30 de DORA impose des obligations technologiques aux cabinets comptables via leurs clients du secteur financier

L’article 28(5) de DORA impose aux entités financières d’évaluer leurs prestataires TIC, tandis que l’article 30 exige des contrats garantissant des mesures de sécurité, dont la protection des données et le chiffrement. Lorsque les institutions financières font appel à des cabinets comptables, ces obligations s’appliquent aux plateformes utilisées. L’article 30(2)(j) impose de traiter la localisation des données, l’article 30(2)(k) prévoit des dispositions sur l’accès, la récupération, la restitution et la suppression des données. Les contrats prévoyant un stockage dans des data centers européens ne suffisent pas si les opérateurs conservent un accès technique depuis des pays hors UE soumis à l’autorité de gouvernements étrangers. L’article 28(3) exige des stratégies de sortie permettant la suppression totale des données — ce qui impose des architectures évitant l’enfermement propriétaire et permettant la migration sans intervention du fournisseur.

Les missions transfrontalières amplifient les risques de souveraineté des données

Les audits transfrontaliers créent des situations où des données clients soumises à plusieurs régimes de secret professionnel transitent par des infrastructures relevant d’autorités souveraines différentes. Cette faille de conformité n’est pas théorique : elle est structurelle, et s’aggrave à chaque nouvelle juridiction concernée par la mission.

Les missions multi-juridiction soumettent les dossiers de travail à plusieurs régimes de secret professionnel en même temps

Un cabinet allemand auditant une filiale française d’une maison mère suisse avec des activités aux Pays-Bas génère des dossiers soumis au §43 WPO allemand, au Code de commerce français, à l’article 321 suisse, et potentiellement au secret professionnel néerlandais. Chaque juridiction définit les accès autorisés que le cabinet doit garantir par l’architecture technique — et non par la lettre de mission, ni par les contrats de traitement, mais par des contrôles rendant tout accès non autorisé techniquement impossible, quel que soit le gouvernement à l’origine de la demande.

Le CLOUD Act permet l’accès des autorités américaines aux données clients européennes, quel que soit leur lieu de stockage

Lorsque les cabinets stockent leurs dossiers de travail sur des plateformes américaines, le CLOUD Act permet aux agences américaines d’exiger la divulgation, quel que soit l’emplacement physique des données. La loi s’applique aux personnes et entités américaines même si elles « ne sont pas physiquement situées aux États-Unis ». Même avec des data centers européens et des contrats précisant un stockage en Europe, les opérateurs peuvent être soumis à des injonctions américaines qui prévalent sur ces dispositions. Ce conflit n’est pas théorique : l’affaire United States v. Microsoft portait sur un mandat visant des e-mails stockés en Irlande avant l’adoption du CLOUD Act, et le principe reste valable : les données européennes contrôlées par des sociétés américaines sont soumises à la procédure américaine, quel que soit leur emplacement. Les National Security Letters et les ordonnances FISA interdisent d’informer le client et ne peuvent pas être contestées devant les juridictions européennes.

Les contrôles de géolocalisation précisent le lieu physique des données mais pas le contrôle juridique ou technique

Les contrôles de géolocalisation définissent le lieu physique des données, mais n’affectent ni les obligations juridiques du fournisseur, ni ses capacités d’accès technique. L’emplacement physique du serveur diffère fondamentalement du contrôle juridique et technique des données — seul ce dernier détermine la souveraineté. L’EDPB, dans ses recommandations post-Schrems II, est explicite : les responsables du traitement ne peuvent pas se reposer sur les SCC si les mesures techniques ne protègent pas contre l’accès gouvernemental. Les clauses contractuelles types créent des obligations contractuelles entre les parties, mais ne peuvent pas s’opposer à l’autorité souveraine qui s’exerce unilatéralement via la juridiction du fournisseur. Le chiffrement géré par le client, avec contrôle exclusif des clés par le cabinet, est le seul mécanisme qui élimine l’accès technique du fournisseur, quel que soit le gouvernement à l’origine de la demande, car il rend le fournisseur techniquement incapable d’obtempérer, et non simplement juridiquement empêché.

Les incidents de sécurité révèlent les risques liés à l’infrastructure tierce

Les récentes failles touchant de grands cabinets comptables montrent que même les programmes de cybersécurité les plus avancés ne suppriment pas les risques liés à l’infrastructure tierce où le fournisseur conserve un accès technique aux données.

La faille MOVEit et les incidents ultérieurs montrent que même les investissements du Big Four n’éliminent pas l’exposition aux tiers

La vulnérabilité MOVEit de 2023 a touché trois cabinets du Big Four, exposant des données clients M&A via une injection SQL dans un logiciel de transfert de fichiers largement utilisé. Cela s’est produit malgré des programmes de cybersécurité sophistiqués et des budgets dédiés conséquents. Sax LLP a révélé fin 2025 qu’une faille de 2024 avait compromis les données de 228 000 personnes et était restée indétectée pendant 16 mois. Deloitte a versé 5 millions de dollars à Rhode Island après une faille ayant permis l’accès aux systèmes pendant quatre mois malgré des centaines d’alertes pare-feu. Si les grands cabinets restent exposés sur l’infrastructure tierce, les petits cabinets courent des risques proportionnellement plus élevés avec moins de ressources pour détecter et réagir.

Les assureurs et les régulateurs examinent désormais l’architecture technologique sous l’angle de la conformité

Face à la multiplication des failles, les assureurs en responsabilité professionnelle renforcent l’examen de l’architecture technologique. Plusieurs compagnies exigent désormais des options de déploiement souverain pour les missions transfrontalières. Certaines polices excluent les incidents où le fournisseur conserve un accès administratif ou contrôle les clés de chiffrement — considérant l’accès du fournisseur comme un risque connu et maîtrisable que le cabinet a choisi de ne pas éliminer. Le FRC britannique intègre désormais les défaillances de contrôle technologique dans ses catégories de sanctions. La Wirtschaftsprüferkammer allemande rappelle que les obligations du §43 WPO s’étendent aux choix technologiques et que les cabinets ne peuvent pas déléguer ces obligations aux fournisseurs. Lorsque les données clients sont stockées sur une infrastructure où le fournisseur conserve un accès technique, cela crée des voies de divulgation non autorisée, par compromission ou contrainte gouvernementale — et la seule architecture qui élimine ces deux risques est celle où les données restent chiffrées sous des clés contrôlées exclusivement par le cabinet comptable.

Une architecture de chiffrement gérée par le client répond aux exigences du secret professionnel

L’architecture technique qui répond simultanément aux obligations de secret professionnel, aux exigences du RGPD et de DORA repose sur un principe : les données clients restent chiffrées sous des clés contrôlées exclusivement par le cabinet comptable. Tout découle de là.

Des HSM contrôlés par le cabinet rendent le fournisseur techniquement incapable d’accéder aux données clients en toute circonstance

Le chiffrement géré par le client commence par la génération et le stockage des clés sous contrôle exclusif du cabinet. Les clés sont générées dans des modules matériels de sécurité (HSM) offrant une protection inviolable, physiquement sous contrôle du cabinet ou hébergés chez des fournisseurs européens conçus pour la souveraineté des clés. Lorsque les données clients arrivent via la messagerie électronique, le partage ou le transfert sécurisé de fichiers, elles sont immédiatement chiffrées avec les clés HSM du cabinet. Les données chiffrées peuvent alors résider sur différentes infrastructures, car le fournisseur ne peut pas les déchiffrer — même sous contrainte gouvernementale ou en cas d’incident de sécurité, les données restent protégées. Cela répond directement au problème structurel posé par la CJUE pour les comptables : le secret professionnel ne peut pas remplacer l’architecture technique, mais une architecture qui rend l’accès impossible aboutit au même résultat pratique.

L’architecture répond à l’article 32 du RGPD, à l’article 30 de DORA et aux lois nationales sur le secret professionnel en une seule mise en œuvre

Le chiffrement géré par le client permet de satisfaire l’ensemble des exigences de conformité en une seule fois. Il répond à l’article 32 du RGPD sur le chiffrement, tout en respectant la recommandation du groupe de travail Article 29 selon laquelle le chiffrement n’offre une protection suffisante que si le responsable du traitement détient seul les clés. Il répond aux exigences de DORA en garantissant que seul le cabinet accède aux données en clair — respectant ainsi les obligations techniques contractuellement imposées par les clients du secteur financier à leurs prestataires. Il satisfait aux obligations de secret professionnel en Allemagne, France, Suisse, Pays-Bas et Royaume-Uni en éliminant toute voie de divulgation non autorisée au niveau cryptographique, et non en s’appuyant sur des interdictions contractuelles inopérantes face à un gouvernement étranger.

La flexibilité de déploiement permet d’adapter l’architecture souveraine à la taille et aux besoins des clients

La flexibilité de déploiement équilibre souveraineté des données et besoins opérationnels. Un déploiement entièrement sur site offre un contrôle maximal pour les cabinets gérant les missions les plus sensibles. Un cloud privé ou des appliances virtuelles durcies dans des data centers européens offrent la même souveraineté tout en allégeant la gestion de l’infrastructure pour les cabinets qui souhaitent l’architecture sans expertise dédiée sur site. Pour les missions transfrontalières, les données restent chiffrées sous les clés du cabinet tout au long de leur cycle de vie — les contrôles d’accès déterminent qui peut déchiffrer tel document, mais le contrôle des clés reste au cabinet, quel que soit l’emplacement des membres de l’équipe.

Points clés pour la mise en œuvre

La transition vers une architecture souveraine nécessite une planification autour de la migration technique, de l’intégration des workflows et de la documentation réglementaire — mais l’ordre des étapes est aussi important que les choix techniques.

Cartographier les flux de données actuels permet d’identifier les systèmes nécessitant une architecture souveraine

L’évaluation technique commence par la cartographie des flux de données actuels. Il s’agit d’identifier les flux impliquant des informations clients soumises au secret professionnel, par opposition aux données internes de gestion qui peuvent faire l’objet de contrôles moins stricts. Toutes les données du cabinet ne requièrent pas un chiffrement géré par le client — mais toutes les données financières clients, les dossiers de mission et les communications contenant des informations confidentielles le nécessitent. Cette analyse permet de dimensionner le déploiement et l’architecture de gestion des clés, et d’éviter l’erreur courante consistant à appliquer l’architecture souveraine à tous les flux de données au lieu de cibler ceux pour lesquels le secret professionnel et le RGPD l’exigent.

L’architecture de gestion des clés est la décision la plus critique et doit s’aligner sur les attentes réglementaires de chaque juridiction

L’architecture de gestion des clés est la décision de mise en œuvre la plus importante. Il faut déterminer s’il convient d’utiliser des HSM sur site, des services HSM cloud de fournisseurs européens, ou des appliances virtuelles durcies. Les grands cabinets privilégient souvent les HSM sur site pour un contrôle maximal, et parce que leurs clients du secteur financier soumis à DORA peuvent l’exiger contractuellement. Les petits cabinets préfèrent parfois des services HSM européens pour réduire la complexité opérationnelle. L’exigence essentielle dans tous les cas : les clés restent sous contrôle exclusif du cabinet et ne doivent jamais être accessibles au fournisseur, même en cas d’assistance d’urgence, de sauvegarde ou d’injonction gouvernementale visant le fournisseur.

La documentation réglementaire doit démontrer la conformité de l’architecture de façon proactive

La documentation réglementaire doit démontrer comment l’architecture technique satisfait à l’article 32 du RGPD, aux exigences de DORA et aux obligations nationales de secret professionnel. Incluez des schémas d’architecture technique, des procédures de gestion des clés, des politiques de contrôle d’accès, des procédures de gestion des incidents et des clauses contractuelles confirmant que le fournisseur ne peut pas accéder aux données clients. Les clients exigeants — notamment les institutions financières soumises à DORA — demandent de plus en plus des annexes techniques détaillées décrivant l’architecture de sécurité avant le début de la mission. Les cabinets capables de fournir cette documentation de façon proactive bénéficient d’un avantage concurrentiel sur les marchés réglementés ; ceux qui doivent la constituer dans l’urgence à la demande du client auront plus de mal à convaincre.

Kiteworks permet aux cabinets comptables européens de respecter le secret professionnel grâce à une architecture souveraine

Les cabinets comptables européens font face à une exigence de conformité que les contrats ne suffisent pas à remplir et que le secret professionnel ne couvre pas : des obligations de secret professionnel qui s’étendent aux choix technologiques, combinées aux exigences du RGPD et de DORA qui imposent des contrôles techniques et non de simples engagements contractuels. Le chiffrement géré par le client est l’architecture qui comble cette faille : il rend le fournisseur techniquement incapable d’accéder aux données clients, quel que soit le gouvernement à l’origine de la demande, et crée la traçabilité documentaire exigée par les régulateurs, les instances de contrôle professionnel et les clients soumis à DORA avant toute mission.

Kiteworks propose une architecture de chiffrement gérée par le client permettant aux cabinets comptables européens de respecter le secret professionnel en Allemagne, France, Suisse, Pays-Bas et Royaume-Uni, tout en répondant à l’article 32 du RGPD et aux exigences technologiques de DORA. La plateforme utilise des clés de chiffrement contrôlées par le client qui ne quittent jamais l’infrastructure du cabinet, ce qui garantit la protection des données financières clients même en cas d’injonction gouvernementale ou d’incident de sécurité chez Kiteworks — nous ne disposons d’aucun moyen technique d’accéder aux données clients.

Les options de déploiement flexibles incluent une installation sur site dans les data centers du cabinet, un déploiement cloud privé dans des infrastructures européennes sous contrôle du cabinet, ou des appliances virtuelles durcies offrant les avantages de l’architecture souveraine tout en réduisant la complexité de gestion de l’infrastructure. Les cabinets peuvent déployer en Allemagne pour respecter les recommandations du BfDI, en France pour répondre aux exigences de la CNIL, en Suisse pour la conformité au secret bancaire, ou dans d’autres pays européens selon leurs besoins opérationnels et ceux de leurs clients.

La plateforme intègre la messagerie électronique, le partage et le transfert sécurisé de fichiers, ainsi que les formulaires web dans une architecture unifiée, permettant aux cabinets comptables de gérer tous les échanges de données clients via une plateforme souveraine unique. Cela simplifie la gestion des clés, réduit la surface d’attaque en éliminant la multiplication des fournisseurs, et offre une journalisation unifiée des accès répondant aux exigences du FRC, de la Wirtschaftsprüferkammer et des autres instances de contrôle.

Pour en savoir plus, réservez votre démo sans attendre !

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
  Les pièges à éviter en matière de souveraineté des données
• Article de blog 
  Bonnes pratiques pour la souveraineté des données
• Article de blog 
  Souveraineté des données et RGPD [Comprendre la sécurité des données]