La souveraineté numérique dans l'infrastructure documentaire : ce que cela signifie et pourquoi c'est important

“Hébergé dans l’UE” n’est pas synonyme de “souverain dans l’UE.” Cette distinction est à l’origine de la plupart des problèmes de conformité que les organisations découvrent trop tard : après une analyse d’impact relative au transfert de données, après une enquête réglementaire, ou après qu’un fournisseur a modifié ses conditions.

Pour les documents à valeur juridique, la question de la souveraineté n’est pas théorique. Elle détermine si votre organisation contrôle ses propres preuves, ou si ce contrôle est délégué à un fournisseur sous des conditions susceptibles de changer.

Ce que signifie la souveraineté dans l’infrastructure documentaire

La souveraineté sur l’infrastructure documentaire implique :

Résidence des données : les documents sont stockés sur une infrastructure physiquement située dans une juridiction où la loi de protection des données applicable s’applique, et aucune copie n’est conservée ou traitée en dehors de cette juridiction sans consentement explicite.

Contrôle d’accès sans exceptions fournisseur : le fournisseur ne peut pas accéder à vos documents en dehors des conditions que vous avez explicitement acceptées. Cela exclut l’accès à des fins de maintenance, les demandes des forces de l’ordre relevant d’un droit étranger, et l’accès par des sociétés mères situées dans d’autres juridictions.

Portabilité des preuves : vous pouvez exporter tous vos documents, pistes d’audit, horodatages et packs de preuves dans un format vérifiable sans la participation du fournisseur. Si le fournisseur ferme demain, vos preuves restent valides.

Aucune exposition à une juridiction étrangère : le fournisseur n’est pas soumis à des lois qui contraignent la divulgation de données à des gouvernements ou agences étrangers, tels que le CLOUD Act américain ou une législation équivalente dans d’autres juridictions.

Pourquoi “hébergé dans l’UE” ne suffit pas

Un service en nuage peut héberger des données dans des centres de données de l’UE tout en restant soumis à une juridiction hors UE. Si la société exploitante est constituée aux États-Unis, si sa société mère est américaine, ou si elle est soumise au droit américain par d’autres moyens, elle peut être contrainte par le CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) de produire des données stockées dans des installations de l’UE pour les autorités américaines, à l’insu et sans le consentement de la personne concernée.

La Cour de justice de l’UE (CJUE) a invalidé le Privacy Shield UE-États-Unis en 2020 (Schrems II) précisément parce que la législation américaine sur la surveillance rend une protection adéquate impossible pour les données personnelles transférées vers des entités sous contrôle américain ou accessibles par celles-ci. Le cadre de protection des données UE-États-Unis adopté par la suite fait l’objet d’une incertitude juridique depuis son adoption.

Pour les documents contenant des données personnelles (ce qui inclut les factures, les dossiers RH, les contrats et les dossiers médicaux), un fournisseur soumis à la juridiction américaine qui stocke des données dans des centres de données de l’UE n’est pas une solution souveraine. La résidence des données est dans l’UE ; l’exposition juridique, non.

Le problème de dépendance fournisseur spécifique aux preuves documentaires

La plupart des plateformes documentaires créent une dépendance qui est invisible jusqu’au moment où vous essayez de partir. Pour les documents sans valeur juridique, c’est un inconvénient. Pour les documents servant de preuves juridiques, c’est un risque structurel.

Les mécanismes de dépendance spécifiques à surveiller :

Formats de piste d’audit propriétaires : si la piste d’audit du fournisseur n’est pas exportable dans un format vérifiable, votre chaîne de garde dépend du bon fonctionnement du système du fournisseur et de l’accessibilité continue de son API. Si le fournisseur est racheté, cesse ses activités ou modifie son API, votre chaîne de garde peut devenir invérifiable.

Horodatages provenant d’autorités contrôlées par le fournisseur : si les horodatages RFC 3161 de vos documents sont émis par une TSA exploitée par le fournisseur, la vérification de ces horodatages après la fin de la relation fournisseur nécessite la coopération continue du fournisseur. C’est une contradiction : l’horodatage est censé être vérifiable de manière indépendante.

Enregistrements de validation opaques : si les rapports de validation dans votre pack de preuves sont du HTML lisible par l’homme plutôt que des données structurées analysables par machine, un auditeur futur pourrait ne pas être en mesure de reproduire la validation sans la réexécuter, ce qui ne lui dit rien sur la validité du document au moment de l’archivage.

Le test de la véritable souveraineté : pouvez-vous confier vos documents et packs de preuves à un tiers techniquement compétent qui n’a jamais interagi avec votre fournisseur, et lui permettre de vérifier l’intégrité et la provenance de chaque document, en utilisant uniquement des standards ouverts et une infrastructure à clés publiques ?

Si la réponse est non, votre infrastructure de preuves n’est pas souveraine.

RGPD et obligations de conservation des documents

Le RGPD crée des tensions spécifiques avec la conservation documentaire à long terme. L’article 5, paragraphe 1, point e), exige la minimisation des données : les données personnelles ne doivent pas être conservées plus longtemps que nécessaire. L’article 17 établit le droit à l’effacement. Mais les lois fiscales nationales exigent la conservation des factures (qui contiennent des données personnelles) pendant sept à dix ans.

La solution est l’exception de conservation prévue à l’article 17, paragraphe 3, point b) du RGPD : les obligations d’effacement ne s’appliquent pas lorsque le traitement est nécessaire au respect d’une obligation légale. La conservation des factures au titre des GoBD, du code fiscal français ou de la législation belge sur la TVA est concernée.

L’implication pratique pour la souveraineté : vous devez être en mesure de démontrer, pour chaque document conservé, que la conservation est couverte par une obligation légale spécifique, et que la durée et le périmètre de conservation ne sont pas plus larges que ce que cette obligation exige. Il s’agit d’une exigence en matière de documentation et de piste d’audit, pas seulement d’une exigence de stockage.

À quoi ressemble une infrastructure documentaire souveraine

Une infrastructure documentaire souveraine répond aux critères suivants :

1. Exploitée par une entité constituée et opérant exclusivement dans une juridiction offrant une protection adéquate des données (les États membres de l’UE satisfont à cette exigence pour les données européennes)
2. Aucune société mère, structure d’investissement ou arrangement contractuel créant une exposition à une juridiction hors UE
3. Packs de preuves exportables dans des formats ouverts et vérifiables (PDF/A-3, jetons d’horodatage CMS, pistes d’audit JSON)
4. Horodatages RFC 3161 provenant de TSA figurant sur la liste de confiance de l’UE, et non de TSA exploitées par le fournisseur
5. Chaînes de hachage vérifiables avec des outils open source sans participation du fournisseur
6. Option d’auto-hébergement pour les organisations nécessitant un contrôle total de l’infrastructure

Le point 6 est particulièrement pertinent pour les organismes publics, les institutions financières réglementées et les opérateurs d’infrastructures critiques, qui peuvent avoir des exigences excluant l’utilisation de tout service hébergé par un tiers, quelle que soit la juridiction.

SealDoc et la souveraineté dans l’UE

SealDoc opère exclusivement sur une infrastructure basée dans l’UE sous juridiction européenne. Il n’existe aucune relation avec une société mère créant une exposition à une juridiction étrangère.

Les packs de preuves produits par SealDoc sont vérifiables de manière indépendante : horodatages RFC 3161 provenant de TSA de la liste de confiance de l’UE, chaînes de hachage vérifiables avec SHA-256, et pistes d’audit exportées en JSON structuré. La vérification ne nécessite aucun appel API à SealDoc ni relation continue avec SealDoc.

Pour les organisations nécessitant un déploiement sur site ou en nuage privé, SealDoc prend en charge le déploiement auto-hébergé sur votre propre infrastructure. Le format des preuves est identique à la version hébergée, de sorte que la migration de l’hébergé vers l’auto-hébergé ou inversement n’affecte pas la vérifiabilité des packs de preuves émis précédemment.

Le principe sous-jacent est que les preuves doivent survivre à toute relation fournisseur particulière. Si SealDoc n’existe plus en 2038, chaque pack de preuves émis aujourd’hui devrait encore être vérifiable par un auditeur disposant d’une implémentation SHA-256 et du certificat public de la TSA.