Datargo · Blog

Le Data Act européen et la fin des frais de changement : le passage d'un cloud à l'autre devient une obligation

2026-06-23T00:00:00+00:00

L’enfermement propriétaire a longtemps servi de moyen de pression commercial : qui voulait partir payait pour la sortie, se débattait avec des formats propriétaires et perdait des semaines en travaux de migration. Le Data Act européen (règlement (UE) 2023/2854) inverse cette logique. Le règlement est applicable depuis le 12 septembre 2025, et son chapitre VI fait du changement de fournisseur cloud un droit opposable des clientes et clients.

Ce qui s’applique depuis septembre 2025

Les fournisseurs de services de traitement de données (IaaS, PaaS, SaaS) doivent lever tous les obstacles qui compliquent un changement, qu’ils soient précommerciaux, commerciaux, techniques, contractuels ou organisationnels. Concrètement, cela signifie : un préavis maximal de deux mois, une phase de transition de 30 jours pour le déménagement proprement dit (prolongeable jusqu’à sept mois en cas d’impossibilité technique) et le droit d’emporter ses données et ses actifs numériques. Pour les nouveaux contrats, ces obligations s’appliquent déjà.

Le frein sur les frais jusqu’en janvier 2027

Le Data Act réduit les frais de changement par étapes. Le 12 janvier 2027, l’interdiction totale entre en vigueur : aucun frais ne pourra plus être facturé pour le passage d’un service de traitement de données à un autre. D’ici au 12 septembre 2027, les contrats B2B existants devront en outre être expurgés de leurs clauses abusives. Qui a fondé ses modèles de prix et de contrat sur les coûts de sortie en perdra le socle à une échéance prévisible.

Changer de fournisseur, c’est plus qu’un export de données

Le point de friction pratique tient à l’équivalence fonctionnelle. Un export de données brutes ne suffit pas si l’environnement cible ne peut rien en faire. Le Data Act exige des interfaces ouvertes et, lorsque c’est possible, des formats courants, afin qu’un service redevienne opérationnel chez la destination. Trois questions déterminent en pratique si un changement est réellement réalisable :

Modèle de données : les contenus sont-ils dans des structures ouvertes et documentées, ou dans un schéma propriétaire ?
Interfaces : existe-t-il des API stables et versionnées pour exporter les données courantes comme historiques ?
Métadonnées : la configuration, les droits et la logique de traitement sont-ils transmis avec le reste, ou restent-ils dans l’ancien système ?

Ce que cela signifie pour l’architecture

La souveraineté n’est pas ici une case à cocher, mais une propriété de la conception du système. Qui ne pense la portabilité qu’au moment de partir l’a déjà perdue. Des modèles de données ouverts, des voies d’export documentées et un hébergement dans l’espace juridique européen ne réduisent pas seulement le risque d’enfermement : ils deviennent de plus en plus la condition même pour pouvoir remplir les obligations du Data Act. Dans une suite qui relie ses modules par des interfaces ouvertes et un hébergement à Francfort, le changement de fournisseur n’est pas un épouvantail, mais une opération traçable.

Le Data Act ne demande pas si vous voulez retenir vos clientes et clients. Il demande s’ils pourraient partir s’ils le voulaient.

Les passkeys en entreprise : une authentification résistante à l'hameçonnage, au-delà du mot de passe et de l'OTP

2026-06-23T00:00:00+00:00

L’hameçonnage reste la porte d’entrée la plus fiable vers les réseaux d’entreprise, et la plupart des seconds facteurs n’y changent pas grand-chose. Un mot de passe assorti d’un code SMS, d’une application TOTP ou d’une confirmation push passe pour de l’authentification multifacteur, mais reste attaquable en son cœur : qui attire l’utilisatrice sur une page falsifiée peut aussi capter le second facteur en temps réel. Les passkeys FIDO2 interviennent précisément à cet endroit.

Pourquoi la MFA classique reste hameçonnable

Le problème n’est pas le nombre de facteurs, mais leur transférabilité. Un code à usage unique est un secret partagé : il fonctionne partout où il est saisi, y compris sur la page d’hameçonnage. Ce qui manque, c’est le lien avec le correspondant authentique. C’est précisément ce lien qu’assure WebAuthn, le standard qui sous-tend les passkeys.

Ce que les passkeys font différemment

Un passkey est une paire de clés cryptographiques. La clé privée ne quitte jamais l’appareil, et la signature ne se fait qu’envers le domaine pour lequel le passkey a été enregistré. Ce lien à l’origine rend inopérante la redirection d’hameçonnage classique : un domaine falsifié n’obtient tout simplement aucune signature valide. Il n’existe aucun secret que l’on pourrait saisir sur le mauvais site. Le BSI a publié à ce sujet un modèle de menace formel, et la directive technique BSI TR-03188 fixe des exigences pour l’exploitation d’un serveur de passkeys.

Synchronisés, liés à l’appareil ou clé matérielle

Un passkey n’en vaut pas un autre. Un déploiement solide module la variante selon le besoin de protection :

Clés de sécurité matérielles : pour les accès privilégiés et l’administration, là où la plus haute sécurité compte.
Passkeys liés à l’appareil : sur les appareils d’entreprise gérés, couplés au matériel et non synchronisables.
Passkeys synchronisés : pour l’ensemble du personnel, pratiques sur plusieurs appareils, avec un niveau de durcissement un peu moindre.

Cette gradation rejoint l’attente que les autorités de contrôle et les auditeurs formulent de plus en plus : pour les accès administratifs sensibles, l’authentification résistante à l’hameçonnage est de plus en plus considérée comme une exigence, et non comme une recommandation.

Les questions ouvertes

La partie difficile ne réside pas dans la connexion, mais dans les cas limites. Que se passe-t-il en cas de perte de l’appareil ? À quoi ressemble une voie de récupération qui ne devienne pas elle-même une porte dérobée hameçonnable ? Et comment traiter les systèmes hérités qui ne parlent pas encore WebAuthn ? Un déploiement réfléchi répond à ces questions en amont, au lieu de les improviser en cas d’incident. Comme trait d’union de la plateforme, Datargo ID ancre l’authentification unique et la MFA en un seul endroit, ce qui regroupe ces questions au lieu de les disperser application par application.

Le basculement décisif est le suivant : s’éloigner d’un secret que l’on peut connaître et donc trahir, pour aller vers une clé qui reste liée à l’appareil et au correspondant.

Quand le chatbot doit se faire connaître : la transparence de l'IA dans le service client à partir d'août 2026

2026-06-23T00:00:00+00:00

Réponses initiales automatisées, préclassification des tickets assistée par IA, suggestions de réponse générées : dans le service client, l’IA est depuis longtemps une réalité quotidienne. À partir du 2 août 2026, l’article 50 de l’AI Act européen devient applicable, et des obligations de transparence contraignantes s’appliquent dès lors à ces systèmes précisément. Ces obligations sont à distinguer des règles visant les fournisseurs de modèles d’IA à usage général (GPAI) : il n’est pas question ici du modèle, mais de l’interaction avec les personnes.

Ce qu’exige l’article 50

Au cœur du dispositif se trouve une obligation d’information. Les fournisseurs de systèmes d’IA destinés à interagir directement avec des personnes (comme les chatbots) doivent s’assurer que la personne concernée perçoit qu’elle communique avec un système d’IA. L’information doit être donnée au plus tard au moment de la première interaction, sauf si le recours à l’IA est évident au vu des circonstances. À cela s’ajoute : les contenus générés ou modifiés par IA doivent être marqués comme tels de façon lisible par machine, et les contenus d’intérêt public susceptibles de paraître authentiques doivent faire l’objet d’un marquage distinct.

Ce que « informé » signifie en pratique

Une ligne dans les mentions légales ne suffit pas. L’information doit être claire, donnée avant ou au début de la conversation et compréhensible pour l’utilisatrice. En pratique, cela représente plus qu’une bannière :

Visibilité : l’information sur l’IA figure au début du dialogue, pas dans une note de bas de page repliable.
Langue : l’information apparaît dans la langue dans laquelle la personne prend contact, et pas seulement en anglais.
Transfert : lors du passage entre l’IA et un traitement humain, il devrait rester perceptible avec qui l’on échange à cet instant.

Plus qu’une bannière d’information

Le versant le plus délicat est la capacité de preuve. Qui veut démontrer, le cas échéant lors d’un contrôle, que l’information a effectivement et systématiquement été affichée a besoin d’une journalisation de la configuration et des avis effectivement présentés. Dans les environnements multitenants s’ajoute le fait que chaque locataire exploite ses propres canaux, langues et voies d’escalade : la logique de transparence doit opérer par locataire, et pas seulement globalement. Un hub de service client comme Datargo CRM, qui réunit chat en direct, tickets et contacts de manière multitenant, offre l’endroit naturel pour ancrer de façon homogène l’information, l’attribution de la langue et le transfert vers un humain.

L’article 50 n’interdit pas l’IA dans le service client. Il exige seulement que personne ne reste dans l’ignorance de qui, ou de quoi, lui répond.

Certificats de 47 jours : la feuille de route CA/Browser jusqu'en 2029

2026-06-09T00:00:00+00:00

Le débat est tranché, et une partie en est déjà la réalité du terrain : depuis le 15 mars 2026, les certificats TLS publiquement reconnus ne peuvent plus dépasser 200 jours de validité, contre 398 auparavant. C’est le premier palier d’une feuille de route que le CA/Browser Forum a adoptée en avril 2025 avec le scrutin SC-081v3 : à l’unanimité, par 29 voix pour et aucune voix contre. Au terme de cette feuille de route, la durée de vie maximale tombera à 47 jours.

Quiconque commande encore ses certificats à la main et les note dans un agenda devrait considérer les trois prochaines années comme un chantier de transformation, et non comme une série d’échéances isolées.

La feuille de route en chiffres

La validité maximale décroît selon des paliers aux dates clairement fixées :

jusqu’au 14 mars 2026 : 398 jours (l’ancien standard)
à partir du 15 mars 2026 : 200 jours (en vigueur aujourd’hui)
à partir du 15 mars 2027 : 100 jours
à partir du 15 mars 2029 : 47 jours

En parallèle, et c’est la partie la plus exigeante sur le plan opérationnel, la réutilisabilité de la validation de domaine (Domain Control Validation, DCV) se réduit. Une fois le contrôle d’un domaine vérifié, sa « réutilisation » sera désormais possible sur une durée nettement plus courte avant qu’une nouvelle confirmation ne soit requise :

à partir du 15 mars 2026 : 200 jours
à partir du 15 mars 2027 : 100 jours
à partir du 15 mars 2029 : 10 jours

Pour les certificats OV et EV, la réutilisabilité des données d’organisation vérifiées (Subject Identity Information) passe en outre de 825 à 398 jours au 15 mars 2026.

Les 47 jours ne sont donc que le titre accrocheur. Les 10 jours de réutilisation DCV à partir de 2029 sont le véritable rythme imposé : à compter de cette date, il faudra de fait prouver tous les dix jours que le domaine est toujours sous votre contrôle.

Pourquoi cette réduction s’impose

Cette évolution repose sur une logique de sécurité simple. Un certificat est une déclaration de confiance assortie d’une date d’expiration. Plus sa validité est longue, plus une émission erronée, une clé compromise ou un paramètre cryptographique obsolète continue de produire ses effets. Le contre-mécanisme classique, la révocation via CRL et OCSP, fonctionne de manière peu fiable en pratique : les listes de révocation ne sont pas évaluées en temps utile partout, et OCSP est de plus en plus abandonné. Les durées de vie courtes remplacent la révocation par l’expiration. Un problème se résorbe de lui-même, parce que le certificat concerné devient de toute façon bientôt invalide.

Le deuxième moteur est l’agilité cryptographique. En renouvelant régulièrement ses certificats, on peut changer d’algorithmes, de longueurs de clés et de profils en cours d’exploitation : une condition indispensable à la migration imminente vers les procédés post-quantiques. À l’inverse, des durées de vie longues figent le statu quo.

Ce que cela implique pour l’exploitation

La conséquence centrale est aussi banale qu’inéluctable : le renouvellement manuel ne passe plus à l’échelle. Un certificat de 47 jours sera remplacé, avec une marge raisonnable, environ tous les 30 jours. Sur un parc de taille moyenne, ce n’est plus une entrée d’agenda, mais un processus qui doit s’exécuter sans intervention humaine.

Trois capacités déterminent la réussite de cette transformation :

L’automatisation. ACME (RFC 8555) est le standard établi pour l’émission et le renouvellement automatiques, non seulement pour Let’s Encrypt, mais aussi, de plus en plus, pour les CA commerciales et internes. Là où ACME ne s’applique pas, il faut des flux de renouvellement pilotés par API avec validation, afin de préserver les contrôles de conformité.

La découverte. On ne peut automatiser que ce que l’on connaît. La panne typique de 2029 ne sera pas le certificat bien entretenu du système principal, mais celui que l’on a oublié sur un point d’accès d’équilibreur de charge, sur une appliance ou dans un compte cloud que plus personne ne surveille. Les scans réseau actifs et la découverte cloud passive sont la condition pour que des durées de vie courtes ne se transforment pas en pannes à court terme.

La propriété. Chaque certificat doit avoir un responsable clairement désigné, une CA identifiée et une procédure de renouvellement consignée. Un inventaire qui tient ces trois informations par certificat constitue la véritable assurance face à la réalité des 47 jours.

C’est précisément ce schéma, la découverte d’abord, puis l’automatisation indépendante de la CA avec validation, qui sous-tend notre module NextPKI. L’orientation réglementaire en est indépendante : qui rend son parc visible et automatise le renouvellement est prêt, quel que soit l’outil employé.

Ce qui est pertinent dès maintenant

Trois ans, cela peut sembler beaucoup, mais le palier des 200 jours est déjà en cours. Concrètement, il vaut la peine dès maintenant : d’établir un inventaire complet de tous les certificats TLS à travers le réseau, le cloud et les points d’accès ; d’identifier tous les endroits où le renouvellement se fait encore à la main aujourd’hui ; de lancer un pilote de renouvellement automatique basé sur ACME sur des services non critiques ; et de déterminer quels systèmes internes pourront techniquement supporter, d’ici 2029, une revalidation de domaine tous les dix jours.

Les 47 jours n’arrivent ni par surprise ni d’un seul coup. Ils arrivent par paliers, et le premier est déjà là.

Cyber Resilience Act : ce que le 11 septembre 2026 signifie pour les fabricants de produits numériques

2026-06-09T00:00:00+00:00

Dans à peine trois mois, un règlement devient réalité opérationnelle. À partir du 11 septembre 2026 prennent effet les premières obligations contraignantes du Cyber Resilience Act (règlement (UE) 2024/2847), précisément celles qui supposent le plus de processus : la notification des vulnérabilités activement exploitées et des incidents de sécurité graves. Les autres obligations de produit et de conformité suivent avec l’application complète le 11 décembre 2027.

Quiconque fabrique, importe ou distribue dans l’UE des produits comportant des éléments numériques ne devrait donc pas traiter septembre comme une date lointaine, mais comme le jour où une voie de notification opérationnelle doit exister.

Ce qui commence le 11 septembre 2026

Le CRA oblige les fabricants à notifier une vulnérabilité activement exploitée ou un incident de sécurité grave selon une procédure échelonnée. Un premier avertissement précoce part dans les 24 heures vers le CSIRT compétent et vers l’ENISA, une notification plus détaillée suit dans les 72 heures, un rapport final plus tard. Le tout passe par une plateforme de notification européenne centralisée.

La distinction avec NIS2 est importante : là, une entité concernée notifie des incidents survenus dans sa propre exploitation. Avec le CRA, le fabricant notifie une vulnérabilité dans son produit, quel que soit le client chez qui elle est exploitée. Les deux régimes peuvent s’appliquer en même temps, et ils exigent des voies de notification distinctes.

Ce qui s’ajoute d’ici décembre 2027

L’obligation de notification n’est que la première brique. Avec l’application complète, le CRA exige une sécurité démontrable sur l’ensemble du cycle de vie du produit :

Sécurité dès la conception : la sécurité fait partie du développement, et non d’un ajout ultérieur. Cela inclut des réglages par défaut sécurisés et une surface d’attaque maintenue aussi réduite que possible.
Nomenclature logicielle (SBOM) : les fabricants doivent connaître et documenter les composants et dépendances qu’ils intègrent. Sans cette nomenclature, une nouvelle vulnérabilité laisse sans réponse une question simple : mon produit est-il concerné ?
Gestion des vulnérabilités et mises à jour : les mises à jour de sécurité doivent être fournies pendant au moins cinq ans, ou pendant la durée de vie attendue du produit si celle-ci est plus courte.
Marquage CE : à partir de décembre 2027, les produits comportant des éléments numériques ne pourront plus être mis sur le marché de l’UE sans conformité au CRA.

Il n’existe pas d’exception pour les petites et moyennes entreprises. Quiconque fabrique ou importe des produits concernés relève du règlement, quelle que soit sa taille.

Ce que cela signifie en pratique

L’obligation de notification à partir de septembre est, sur le plan organisationnel, plus exigeante que ne le laisse penser le court délai. Vingt-quatre heures jusqu’à l’avertissement précoce ne laissent pas le temps de commencer par clarifier une responsabilité. Il faut au préalable un responsable désigné, un processus documenté et la capacité technique de détecter un incident en temps utile, tout simplement.

C’est précisément ici que se rejoignent deux sujets souvent traités séparément : la détection (surveillance et posture de sécurité) et la preuve (une trace traçable de qui a notifié quoi et quand). Quiconque a déjà bâti les deux pour NIS2 ou ISO 27001 peut s’appuyer dessus. Dans notre module Datargo Monitor, ce schéma de surveillance continue et de preuve auditable est intégré, mais l’exigence réglementaire vaut indépendamment de l’outil : sans détection fiable, tout délai de notification tourne à vide.

Ce qui est judicieux dès maintenant

Trois étapes valent la peine avant septembre : premièrement, clarifier lesquels de ses propres produits comptent comme « produits comportant des éléments numériques » et tombent ainsi dans le champ d’application. Deuxièmement, mettre en place le processus de notification des vulnérabilités activement exploitées, avec une responsabilité claire et les délais de 24 heures, 72 heures et rapport final. Troisièmement, commencer à constituer une SBOM, car elle est la condition pour pouvoir dire, le cas échéant, si l’on est concerné.

Le 11 septembre 2026 ne marque pas la fin de la préparation, mais le début de l’obligation. Le travail qui se cache derrière, détection et documentation, ne se rattrape pas en 24 heures.

eIDAS 2.0 et l'EUDI-Wallet : ce que les parties utilisatrices doivent préparer d'ici fin 2026

2026-06-09T00:00:00+00:00

Dans environ six mois expire une échéance que bien des entreprises traitent encore comme une réglementation lointaine : d’ici au 24 décembre 2026, les 27 États membres de l’UE devront mettre à la disposition de leurs citoyennes et citoyens au moins un European Digital Identity Wallet (EUDI-Wallet). Le fondement en est le règlement (UE) 2024/1183 (« eIDAS 2.0 »), entré en vigueur le 20 mai 2024.

Pour la plupart des entreprises, la question la plus intéressante n’est pas de savoir quand le wallet arrive, mais quand elles devront l’accepter. Et cette échéance suit de près.

Où en est le déploiement en juin 2026

Le socle réglementaire est déjà bien avancé. L’Architecture and Reference Framework (ARF) existe en version 2.8, et 31 actes d’exécution ont d’ores et déjà été publiés, renvoyant à des dizaines de normes techniques. Le 8 avril 2026, la Commission européenne a complété ce dispositif par le règlement d’exécution relatif à l’enrôlement (Enrollment), une brique centrale puisqu’il régit la manière dont les utilisateurs déposent leur identité de façon sécurisée dans le wallet.

L’état d’avancement des États membres reste toutefois inégal. La France, avec « France Identité », fait figure de pionnière : elle exploite déjà un service en production et le fait évoluer vers l’EUDI-Wallet officiel ; l’Italie et la Pologne suivent de près. L’Allemagne a annoncé le lancement de sa variante portée par l’État pour le 2 janvier 2027, soit peu après l’expiration de l’échéance européenne.

La partie utilisatrice : un rôle qui concerne presque tout le monde

Une partie utilisatrice (relying party, partie qui se fie aux attestations) est toute entité qui souhaite s’appuyer sur les attestations du wallet pour identifier ou authentifier des personnes : de l’onboarding à la vérification de l’âge, jusqu’à l’authentification forte du client.

La logique temporelle du règlement est sans ambiguïté : dès que les wallets sont disponibles, les secteurs régulés et les très grandes plateformes en ligne doivent accepter l’EUDI-Wallet pour l’authentification environ un an plus tard. L’échéance de mise à disposition de fin 2026 se mue ainsi, pour beaucoup, en obligation d’acceptation à compter de fin 2027 environ. Les banques, les assureurs, les opérateurs de télécommunications et d’énergie, le secteur de la santé et les grandes plateformes sont en première ligne ; tous les autres peuvent accepter le wallet sur une base volontaire, et ont tout intérêt à ne pas entamer l’intégration au dernier moment.

Ce qu’une partie utilisatrice devrait clarifier dès maintenant

Enregistrement. Avant la première utilisation, les parties utilisatrices doivent s’enregistrer auprès d’une autorité d’enregistrement nationale et y déclarer quels attributs elles consultent et à quelle fin. Cet enregistrement n’est pas une formalité : c’est le fondement juridique qui autorise à demander des données.

Minimisation des données. Le wallet est conçu pour la divulgation sélective : l’utilisateur ne partage que les attributs dont un service a réellement besoin, par exemple « plus de 18 ans » plutôt que la date de naissance complète. Quiconque demande plus que ce que la finalité justifie entre en conflit aussi bien avec la logique d’eIDAS qu’avec le RGPD. Définir l’ensemble minimal d’attributs pour chaque cas d’usage est donc la première tâche métier, pas la dernière.

Intégration technique. La présentation des attestations repose sur des protocoles et des formats ouverts éprouvés, parmi lesquels OpenID for Verifiable Presentations ainsi que les formats d’attestation ISO/IEC 18013-5 (mdoc) et SD-JWT VC. S’y ajoutent les listes de confiance, qui permettent à un service de vérifier qu’un wallet présenté et ses émetteurs sont authentiques et agréés. Miser ici sur des standards plutôt que sur des adaptateurs propriétaires, c’est garder ouverte la porte aux wallets des différents États membres.

Cas d’usage et gouvernance. L’onboarding et le KYC, la preuve d’âge, l’authentification forte du client et les signatures électroniques qualifiées via le wallet sont les terrains les plus immédiats. Chacun de ces cas exige une logique de consentement et de journalisation rigoureuse : qui a demandé et obtenu quel attribut, quand et à quelle fin.

Dans notre module Datargo ID, c’est précisément ce rôle de partie utilisatrice qui sert de fil conducteur : un login fédérateur, prêt pour le parcours EUDI. Mais l’essentiel ne dépend pas de l’outil : chaque partie utilisatrice arrête pour elle-même les choix en matière d’enregistrement, de minimisation des attributs et d’intégration fondée sur les standards.

Le calendrier, sans fard

D’ici fin 2026, les wallets sont mis à disposition ; à partir de début 2027, les solutions nationales apparaissent (l’Allemagne le 2 janvier 2027) ; et environ un an après leur disponibilité, l’obligation d’acceptation s’applique aux secteurs régulés. Cela sonne comme 2027 et 2028, mais cela commence dès aujourd’hui par un travail de préparation : déterminer les besoins en attributs, clarifier la voie d’enregistrement, piloter une intégration fondée sur les standards. L’échéance est fixée ; la préparation n’est plus facultative que dans son calendrier, pas dans son principe.

Souveraineté des données après le Data Privacy Framework : pourquoi l'hébergement européen devient une question d'architecture

2026-06-02T00:00:00+00:00

Quiconque transfère des données personnelles vers les États-Unis s’appuie depuis 2023 sur la décision d’adéquation relative au Data Privacy Framework UE-États-Unis (DPF). En septembre 2025, le Tribunal de l’Union européenne a rejeté un recours dirigé contre elle, ce qui laisse au cadre sa valeur de base juridique. Mais l’affaire n’est pas close : fin octobre 2025, un pourvoi a été formé devant la Cour de justice de l’Union européenne (affaire C-703/25 P). Un nouveau renversement, un « Schrems III », n’est pas exclu.

Cette incertitude n’est pas une raison de paniquer, mais une bonne occasion de hisser une question du niveau de la conformité à celui de l’architecture.

Pourquoi c’est plus qu’une case à cocher

La manière commode de gérer les transferts de données consiste à les traiter comme une question contractuelle : tant qu’une décision valable ou des clauses contractuelles types existent, le transfert est couvert. C’est juste sur le plan juridique, mais cela méconnaît le risque réel. Toute base juridique pour les transferts vers des pays tiers est sous réserve depuis des années. Le Safe Harbor est tombé en 2015, le Privacy Shield en 2020, et le cadre actuel fait l’objet d’un contrôle judiciaire. Aligner son architecture sur une base juridique qui vacille tous les quelques années, c’est intégrer une dépendance que l’on ne contrôle pas.

La question la plus robuste n’est pas « le transfert est-il couvert », mais « le transfert a-t-il seulement lieu ». Des données qui ne quittent pas l’UE et auxquelles aucun pays tiers n’a accès n’ont besoin d’aucune décision d’adéquation.

Trois décisions d’architecture

Le lieu d’hébergement. L’endroit où les données résident physiquement est la première décision, et la plus visible. Un centre de données à Francfort plutôt que dans une région américaine en est le fondement, mais ne suffit pas à lui seul, car le lieu ne dit rien, à lui seul, du contrôle.

Le contrôle de l’opérateur. Ce qui est déterminant, c’est qui a, en droit et en fait, accès aux données et à l’infrastructure. Un serveur situé dans l’UE mais exploité par une entreprise soumise à un droit tiers assorti d’obligations de communication étendues ne résout le problème qu’à moitié. La question du droit applicable à l’opérateur relève donc de l’architecture, et pas seulement du contrat.

La souveraineté des clés. Qui détient les clés contrôle l’accès. Un chiffrement où seul le client dispose des clés rend techniquement inopérant tout accès par un tiers, même s’il était juridiquement contraint. La souveraineté des clés fait passer le contrôle d’une promesse à une propriété technique.

La souveraineté par défaut, et non en rattrapage

Ces trois décisions ne se modifient qu’à grand-peine et à grands frais après coup. Elles ont leur place au début d’une architecture, et non dans un projet qui ne démarre qu’une fois qu’un tribunal a renversé la décision suivante. C’est exactement ce que signifie la souveraineté dès la conception : non pas sécuriser un transfert après coup, mais une conception qui rend le transfert problématique inutile dès le départ.

Dans notre plateforme, l’hébergement européen à Francfort est le réglage par défaut, et non l’option premium. Le point lui-même est cependant indépendant du fournisseur : qui règle tôt le lieu, le contrôle de l’opérateur et la souveraineté des clés se rend indépendant du prochain revirement judiciaire.

Le Data Privacy Framework survivra peut-être au réexamen actuel, ou non. Une architecture qui ne dépend pas de la réponse est, dans les deux cas, le choix le plus serein.

AI Act de l'UE : l'application aux modèles GPAI à partir du 2 août 2026 et ce que le Digital Omnibus a reporté

2026-05-26T00:00:00+00:00

L’AI Act de l’UE s’applique depuis août 2024, mais nombre de ses obligations entrent en vigueur par étapes. Une date se détache : le 2 août 2026 commence l’application active à l’égard des fournisseurs de modèles d’IA à usage général (GPAI) par le Bureau européen de l’IA, et les régimes nationaux de sanctions prennent effet en parallèle. En Allemagne s’y ajoute la loi sur les mesures et l’innovation en matière d’IA (KI-MIG). Quiconque utilise ou met à disposition de l’IA devrait connaître l’échéance, mais aussi les reports les plus récents.

Ce qui commence le 2 août 2026

Les obligations relatives aux modèles GPAI sont applicables depuis août 2025. Ce qui s’ajoute en août 2026, c’est l’application : un an après l’entrée en application, le Bureau de l’IA reçoit les pouvoirs de la mettre réellement en œuvre. Cela comprend les demandes d’informations, l’accès aux modèles et, en dernier recours, le rappel d’un modèle. Une obligation sur le papier devient ainsi une obligation opposable.

Pour la plupart des entreprises, le rôle pertinent n’est pas celui de fournisseur de GPAI, mais celui de déployeur ou de fournisseur de systèmes en aval. Elles aussi devraient savoir quelles obligations de transparence et de documentation prennent effet et à quel moment.

Ce que le Digital Omnibus de mai 2026 a reporté

Le 7 mai 2026, l’UE a, avec ce que l’on appelle le Digital Omnibus, étalé dans le temps certaines obligations partielles. Cela ne change rien à l’échéance d’août pour l’application aux GPAI, mais reporte d’autres briques :

Systèmes à haut risque relevant de l’annexe III : reportés au 2 décembre 2027.
Systèmes à haut risque relevant de l’annexe I : reportés au 2 août 2028.
Obligations de transparence au titre de l’article 50 (par exemple le marquage des contenus générés par IA) : reportées au 2 décembre 2026.
Bacs à sable réglementaires pour l’IA : reportés au 2 août 2027.

Cet étalement n’est pas un blanc-seing. Il dégage du temps pour les exigences plus lourdes liées au haut risque, mais laisse intactes l’application aux GPAI et les sanctions nationales prévues pour août.

Ce que cela signifie en pratique

Trois tâches sont utiles indépendamment de la date exacte. Premièrement, un état des lieux : quels systèmes d’IA l’entreprise utilise-t-elle ou met-elle à disposition, et dans quelle classe de risque tombent-ils ? Sans cette clarté, aucune échéance ne peut se planifier utilement. Deuxièmement, la transparence : à partir de décembre 2026, l’article 50 exige que certaines interactions avec l’IA et certains contenus générés par IA soient rendus reconnaissables. Troisièmement, la documentation, car l’application à partir d’août repose sur le fait que les obligations ne sont pas seulement remplies, mais aussi prouvées.

Ce dernier point relie l’AI Act aux autres régimes de conformité. Que ce soit NIS2, DORA ou l’AI Act, l’exigence récurrente est une trace traçable et auditable de ce qu’un système fait et de qui en répond. Une plateforme qui produit de toute façon cette trace comme sous-produit de l’exploitation facilite la préparation, quel que soit le régime. La tâche elle-même reste pourtant la même : d’abord savoir ce que l’on exploite, puis prouver que cela respecte les règles.

Le 2 août 2026 n’est pas une échéance abstraite. C’est le moment où les obligations GPAI acquièrent des dents. Ce que le Digital Omnibus a reporté concerne le volet du haut risque, pas ce noyau.

SD-JWT VC et OpenID4VP : les protocoles derrière l'EUDI Wallet

2026-05-12T00:00:00+00:00

On parle beaucoup de l’EUDI Wallet au niveau politique et organisationnel : mise à disposition par les États membres d’ici fin 2026, obligations d’enregistrement, délais d’acceptation. Mais quiconque veut effectivement accepter le wallet se trouve tôt ou tard face à une question technique : comment vérifier concrètement qu’un attribut présenté est authentique, valide et suffisant pour mon usage ? Cet article se penche sur le versant de la vérification et sur les briques qui s’y assemblent.

Trois formats, une interaction

L’Architecture and Reference Framework (ARF), désormais en version 2.x, fixe les standards techniques. Pour les parties utilisatrices, trois d’entre eux sont centraux.

SD-JWT VC (Selective Disclosure JWT Verifiable Credential) est un format d’attestation qui permet la divulgation sélective. L’émetteur signe un faisceau d’attributs, mais de telle façon que la personne utilisatrice puisse en divulguer certains sans révéler les autres. Techniquement, cela passe par des condensats salés (salted hashes) : chaque attribut est haché individuellement, et la signature porte sur les condensats. Qui montre un attribut fournit le texte en clair et le sel correspondants, le reste demeure caché, la signature reste vérifiable.

ISO/IEC 18013-5 (mdoc) est le format issu du permis de conduire mobile, utilisé en parallèle pour certaines attestations dans le contexte EUDI. Une partie utilisatrice devrait pouvoir traiter les deux formats, car les États membres ne procèdent pas partout de manière identique.

OpenID for Verifiable Presentations (OpenID4VP) est le protocole par lequel se déroule la présentation. Il définit comment une partie utilisatrice formule une requête (quels attributs, à quelle fin) et comment le wallet renvoie la réponse signée.

Ce que la divulgation sélective change en pratique

L’exemple courant est la vérification de l’âge. Au lieu de transmettre la date de naissance complète, le wallet peut ne divulguer que l’attribut dérivé « plus de 18 ans ». Pour la partie utilisatrice, cela veut dire formuler ses requêtes de sorte qu’elle obtienne exactement le prédicat dont elle a besoin, et non le jeu de données complet qui se trouve derrière. La minimisation des données n’est pas ici une idée de protection ajoutée après coup, mais intégrée au protocole.

La partie difficile : la confiance, pas la validité

Vérifier une signature est la tâche facile. La difficile est la question qui se cache derrière : l’émetteur qui a signé cet attribut est-il seulement habilité et authentique ? C’est là qu’interviennent les listes de confiance. L’UE et les États membres tiennent des registres au moyen desquels une partie utilisatrice établit de manière fiable si un wallet et ses émetteurs sont authentiques et agréés. Sans ce raccordement, on vérifie certes une signature correcte, mais on ne sait pas si l’identité qui se trouve derrière est digne de confiance.

Le sens inverse compte tout autant : la partie utilisatrice elle-même doit s’enregistrer auprès d’un registre national avant la première utilisation, en indiquant quels attributs elle demande et à quelle fin. Seul cet enregistrement constitue la base juridique permettant de demander des données.

Pourquoi miser sur les standards en vaut la peine

Miser sur les formats et protocoles ouverts plutôt que sur des adaptateurs propriétaires maintient à portée les wallets des différents États membres, sans devoir réintégrer pays par pays. Dans notre module Datargo ID, ce rôle de partie utilisatrice est le fil rouge, de l’authentification unique (SSO) au parcours EUDI. Le cœur technique vaut cependant indépendamment de l’outil : qui sait traiter SD-JWT VC, mdoc et OpenID4VP et raccorde correctement les listes de confiance est armé pour la vérification, quel que soit l’État membre dont provient le wallet.

La mise à disposition du wallet est une échéance politique. Mettre en place proprement la vérification est une tâche technique, et elle commence par la compréhension de ces trois briques.

Archiver les factures électroniques structurées conformément aux GoBD : la question des huit ans

2026-04-21T00:00:00+00:00

Le débat sur la facture électronique tourne le plus souvent autour de l’émission et de la réception. L’obligation plus discrète, mais plus durable, ne commence qu’ensuite : la conservation. Une facture structurée n’est pas un document au sens classique, mais un jeu de données, et celui-ci doit demeurer inaltérable et exploitable par machine pendant des années. L’intégrer dès la construction de ses processus évite des reprises coûteuses plus tard.

Ce qui a changé pour le délai

Longtemps, les pièces comptables ont été soumises à un délai de conservation de dix ans. La quatrième loi allemande d’allègement bureaucratique (BEG IV) l’a réduit à huit ans au 1er janvier 2025. Le nouveau délai s’applique à toutes les pièces dont l’ancien délai de dix ans n’avait pas encore expiré à cette date.

Deux réserves sont importantes. Premièrement, la réduction concerne les pièces comptables telles que factures, reçus et justificatifs de paiement. Les comptes annuels et la documentation des procédures restent à dix ans. Deuxièmement, le délai plus court n’est pas qu’un allègement : pouvoir supprimer des pièces après huit ans plutôt que dix signifie qu’il faut adapter en conséquence son concept d’effacement, en gardant aussi à l’esprit le RGPD. Une prolongation forfaitaire « par précaution » entre en tension avec l’obligation de ne pas conserver des données personnelles plus longtemps que nécessaire.

Ce que « à valeur probante » exige techniquement

Pour les documents électroniques soumis à conservation, les GoBD exigent pour l’essentiel trois propriétés : l’inaltérabilité, une saisie complète et en temps voulu, ainsi qu’une disponibilité permanente et une exploitabilité par machine sur tout le délai. L’inaltérabilité ne signifie pas qu’un fichier repose dans un dossier auquel personne ne touche. Elle signifie que les modifications ultérieures sont techniquement exclues ou journalisées sans lacune, et que l’état d’origine reste restituable.

Pour les formats structurés s’ajoute une seconde exigence, souvent sous-estimée.

La copie visuelle n’est pas le jeu de données

Une XRechnung est un pur jeu de données XML. ZUGFeRD est hybride : un PDF avec du XML embarqué. Le point décisif : ce qui est soumis à conservation, c’est le jeu de données structuré, et non une copie visuelle PDF qui en est issue. Qui imprime ou restitue une XRechnung entrante sous forme de PDF et n’archive que cette image n’a pas conservé la pièce faisant foi de manière conforme aux GoBD. L’original est la structure XML, et c’est précisément elle qui doit être disponible, inchangée et exploitable, pendant huit ans.

Cela a des conséquences pour l’architecture. Produire une belle vue à la réception ne suffit pas. Le jeu de données doit être stocké sous sa forme structurée, indexé et protégé contre toute modification. Une documentation des procédures consigne comment ce chemin se déroule exactement : de la réception au classement, en passant par le contrôle.

Où cela converge en pratique

À partir de 2027 au plus tard, lorsque la facture électronique structurée deviendra la règle dans les échanges B2B nationaux, trois choses se rejoignent : le format (XRechnung ou ZUGFeRD selon EN 16931), la comptabilisation dans le cœur commercial et l’archivage à valeur probante. Dans notre module Datargo ERP, la facturation électronique selon EN 16931 et la comptabilité conforme aux GoBD forment un chemin continu, mais l’exigence elle-même est indépendante de l’outil : le jeu de données faisant foi doit rester inchangé, exploitable et retrouvable pendant tout le délai.

Le délai de huit ans sonne comme moins d’efforts que l’ancien. Sur le fond, il ne fait que déplacer l’effort : du côté de l’effacement vers une conservation propre du bon objet, à savoir le jeu de données, et non son image.

NIS2 en pratique : de l'obligation de notification à la preuve solide

2026-04-14T00:00:00+00:00

Depuis le 6 décembre 2025, NIS2 a force de loi en Allemagne. La loi de transposition de NIS2 et de renforcement de la cybersécurité (NIS2UmsuCG) a été adoptée par le Bundestag le 13 novembre 2025, confirmée par le Bundesrat le 20 novembre, et est entrée en vigueur sans période de transition. Environ 29 500 entreprises, réparties sur 18 secteurs, sont concernées. La date limite d’enregistrement auprès du BSI, le 6 mars 2026, est passée ; un enregistrement tardif reste possible et demeure recommandé.

Beaucoup d’organisations ont abordé la mise en œuvre comme une tâche d’enregistrement et de documentation. La partie la plus difficile commence ensuite : pouvoir prouver, le moment venu, ce qui s’est réellement passé.

L’horloge tourne en heures, pas en semaines

Les obligations de notification (article 32) sont échelonnées et étroitement minutées. Pour un incident significatif : une alerte précoce dans les 24 heures, une notification dans les 72 heures, un rapport final dans un délai d’un mois. Ces délais ne peuvent être tenus que si un incident est détecté rapidement et reconstitué de façon traçable. Quiconque ne s’aperçoit qu’au moment de rédiger la notification que les données nécessaires manquent a, de fait, déjà manqué le délai.

Ce que l’autorité veut voir

L’article 30 exige des mesures de gestion des risques : surveillance, journalisation, traitement des incidents, continuité d’activité et sécurité de la chaîne d’approvisionnement. La différence décisive se joue entre « nous exploitons une surveillance » et « nous pouvons prouver ce qui s’est passé, et quand ». Une autorité de contrôle n’accepte pas une déclaration d’intention, elle veut des preuves.

Une preuve est solide lorsqu’elle réunit trois propriétés :

Sans lacune : détection, escalade et réaction sont horodatées en continu, sans zones d’ombre dans le déroulé.
Inaltérable : journaux et historiques d’incidents existent en append-only, non corrigibles discrètement après coup.
Reconstituable : à partir de la piste d’audit, la chronologie de l’incident peut être dérivée de manière à correspondre aux délais de 24 heures, 72 heures et un mois.

C’est précisément là que de nombreux dispositifs échouent : la surveillance existe, mais les données sont éparpillées, réinscriptibles, ou ne peuvent être assemblées en une chronologie probante.

La responsabilité ne se délègue pas

L’article 38 met la direction en première ligne : elle doit approuver les mesures et superviser leur mise en œuvre. Cette responsabilité ne peut être transférée à l’informatique. L’article 65 fixe le cadre, avec des amendes pouvant atteindre 10 millions d’euros. Cela fait passer NIS2 d’une tâche technique à une tâche de direction.

Ce qui est pertinent dès maintenant

Trois mesures portent leurs fruits immédiatement : cartographier proprement ses propres obligations au regard des articles 30 et 32 ; organiser la détection de sorte que l’alerte précoce des 24 heures soit réellement atteignable ; et faire basculer la journalisation vers des pistes inaltérables et conservées suffisamment longtemps. Un déroulé de notification répété une seule fois révèle vite où la chronologie se rompt.

Dans notre module Datargo Monitor, la surveillance, la posture de sécurité et une piste d’audit append-only sont reliées de sorte que la preuve NIS2 puisse être produite à la demande. L’essentiel, cependant, ne dépend pas de l’outil : il s’agit de mener la détection et la journalisation de façon à ce qu’il reste, au bout du compte, une chronologie probante et non un amas de lignes de journal éparses.

NIS2 ne demande pas si vous exploitez une surveillance. Elle demande si vous pouvez le prouver.

ACME au-delà du serveur web : automatiser les certificats pour les services internes et le mTLS

2026-03-17T00:00:00+00:00

La réduction des durées de vie des certificats TLS publics, vers 47 jours à terme, a fait prendre conscience que le renouvellement manuel ne tient plus l’échelle. Ce que l’on néglige souvent : à l’intérieur d’une entreprise se cachent en général bien plus de certificats qu’à la lisière visible de l’extérieur. La communication de service à service, le mTLS dans un service mesh, les API internes et les connexions de bases de données vivent toutes de certificats, et ceux-ci suivent d’autres schémas que le web public.

Pourquoi « interne » ne veut pas dire « plus simple »

Sur le serveur web public, la situation est claire : une poignée de domaines, une autorité de certification publique, un chemin de validation bien défini. À l’intérieur, le rapport s’inverse. On y trouve souvent des centaines ou des milliers de points de terminaison éphémères, qui apparaissent et disparaissent dynamiquement, par exemple lorsqu’un orchestrateur démarre de nouveaux conteneurs. Une autorité de certification interne leur délivre des certificats que personne ne voit publiquement, mais qui expirent tout autant, doivent se renouveler tout autant et, en cas de défaillance, paralysent un service tout autant.

La différence avec le monde public n’est donc pas une moindre importance, mais une fréquence et une dynamique plus élevées. Avec le mTLS, où les deux parties s’authentifient mutuellement à l’aide d’un certificat, le nombre d’identités à gérer double encore.

ACME n’est pas réservé à Let’s Encrypt

ACME (RFC 8555) s’est fait connaître comme le protocole de délivrance et de renouvellement automatiques, surtout à travers Let’s Encrypt sur le web public. Le protocole lui-même est pourtant agnostique vis-à-vis de l’autorité de certification. Une autorité de certification interne peut offrir une interface ACME, et les services internes se renouvellent alors d’eux-mêmes selon le même mécanisme, sans que personne ne commande un certificat à la main.

Pour la validation interne, d’autres types de challenge entrent en jeu que sur le web public. Le challenge HTTP, courant pour les domaines publics, convient rarement aux services internes. On recourt plutôt à des procédés fondés sur le DNS ou, selon l’environnement, à des preuves d’identité liées à la plateforme. Les service meshes résolvent en partie la question en interne, au moyen de leur propre couche d’identité et de certificats éphémères dont la durée de vie se compte en heures plutôt qu’en semaines.

Ce qui fait la différence

Trois capacités déterminent si l’automatisation interne tient.

Une découverte tournée aussi vers l’intérieur. La panne dangereuse est rarement le certificat frontal bien entretenu. C’est le certificat oublié sur un service interne, un équipement ou un cluster que plus personne n’observe activement. Un inventaire doit recenser les points de terminaison internes autant que les publics.

Une vision agnostique des autorités de certification. Dans les environnements qui se sont développés au fil du temps, plusieurs autorités de certification coexistent le plus souvent : une publique pour la lisière externe, une ou plusieurs internes, et peut-être une propre au cloud. Une gestion qui offre, par-delà toutes, une vue unifiée et un renouvellement unifié évite que chaque autorité ne devienne son propre îlot avec ses propres lacunes.

Un renouvellement maîtrisé. L’automatisation complète est l’objectif, mais pas au prix d’une traçabilité perdue. Là où c’est nécessaire, le renouvellement automatique comporte une étape documentée d’approbation et de journalisation, afin que, même à haute fréquence, on puisse retracer ce qui a été délivré et quand.

C’est précisément ce schéma, la découverte d’abord, puis l’automatisation agnostique avec approbation, qui sous-tend notre module NextPKI. L’orientation vaut cependant indépendamment de l’outil : maîtriser les durées de vie courtes de la lisière externe mais négliger l’intérieur, c’est ne pas tenir le véritable volume.

Le débat sur les 47 jours est une bonne occasion d’élargir le regard. La plupart des certificats d’une entreprise ne sont pas en vitrine, mais dans la salle des machines.

DORA pour les prestataires TIC : risque lié aux tiers et notification des incidents

2025-12-09T00:00:00+00:00

DORA, le Digital Operational Resilience Act (règlement (UE) 2022/2554), s’applique au secteur financier européen depuis le 17 janvier 2025. Depuis le 19 novembre 2025, la supervision a pris une forme concrète : les autorités européennes de surveillance EBA, EIOPA et ESMA ont publié la première liste officielle de 19 tiers prestataires de services TIC désignés comme critiques, parmi lesquels AWS, Google Cloud, Microsoft, Oracle, SAP, IBM et Deutsche Telekom. Cette liste est actualisée chaque année.

La réaction instinctive de bien des prestataires informatiques est la suivante : cela ne me concerne pas, je ne suis pas une banque. C’est une erreur. DORA descend le long de la chaîne d’approvisionnement.

Pourquoi le règlement atteint chaque fournisseur

Les entités financières portent elles-mêmes le risque de leurs externalisations TIC et doivent le piloter de manière démontrable. Au plus tard le 30 avril 2025, elles devaient déclarer leur registre d’information, un relevé complet de tous les accords contractuels conclus avec des tiers prestataires de services TIC. Dès lors, chaque externalisation devient visible pour le régulateur, y compris celles vers des prestataires non critiques.

Toutes les obligations qui pèsent sur l’entité financière, celle-ci les répercute contractuellement sur ses prestataires. En pratique, les clients du secteur financier exigent désormais :

Des clauses contractuelles conformes à DORA, avec des règles claires de performance, de sécurité et de résiliation.
Des droits d’audit et d’accès, afin que le client comme le régulateur puissent contrôler.
De la transparence sur la sous-traitance en cascade, c’est-à-dire qui d’autre intervient derrière le prestataire.
Des chaînes de notification en cas d’incident, assez rapides pour que le client financier tienne ses propres délais.
Des plans de sortie et de continuité, ainsi que des preuves issues des tests de résilience.

La notification d’incident est une chaîne, pas un formulaire

Pour les incidents TIC majeurs, DORA impose une notification échelonnée : une notification initiale dans les quelques heures suivant la classification, un rapport intermédiaire et un rapport final dans un délai d’un mois. Pour les fournisseurs, cela signifie : l’incident ne doit pas seulement être détecté en interne, le client financier doit être informé assez tôt pour respecter sa propre horloge réglementaire. Quiconque notifie trop tard ou de façon trop vague met en péril la conformité du client, et avec elle la relation d’affaires.

Désigné critique signifie supervision directe

Quiconque est désigné comme tiers prestataire critique de services TIC relève de la supervision directe d’un superviseur principal à l’échelle de l’UE. Comme la liste est actualisée chaque année, la désignation n’est pas un état figé : qui n’y figure pas aujourd’hui peut s’y retrouver à mesure que son importance pour le secteur financier grandit.

Ce qui est pertinent dès maintenant

Pour les prestataires TIC ayant des clients financiers, il vaut la peine de passer ses propres contrats au crible des clauses DORA, de documenter proprement la sous-traitance en cascade et de répéter la notification d’incident pour que la chaîne, jusqu’au client financier, tienne en quelques heures. Dans notre module Datargo Monitor, la surveillance, un moteur d’incidents et une piste d’audit append-only s’imbriquent de sorte que les preuves nécessaires à de telles chaînes de notification puissent être produites. L’essentiel, cependant, ne dépend pas de l’outil : il s’agit de documenter sa propre résilience pour que le client financier puisse s’y fier.

DORA n’est pas qu’une affaire de banques. C’est l’exigence que vos clients financiers vous répercutent désormais.

Cryptographie post-quantique : pourquoi la migration commence en 2026, pas en 2030

2025-09-16T00:00:00+00:00

Depuis août 2024, les trois premiers standards post-quantiques sont définitifs. Le NIST a publié FIPS 203 (ML-KEM, dérivé de Kyber), FIPS 204 (ML-DSA, issu de Dilithium) et FIPS 205 (SLH-DSA, issu de SPHINCS+), concluant un processus de sélection de huit ans. Beaucoup lisent le titre, voient l’année 2030 souvent citée et remisent le sujet. C’est un malentendu : 2030 est une échéance, pas un coup d’envoi.

Le « harvest now, decrypt later » rend la chose urgente

La menace n’attend pas le premier calculateur quantique performant. Des attaquants interceptent dès aujourd’hui du trafic chiffré et le stockent pour le déchiffrer plus tard. Tout ce qui doit rester protégé longtemps est dès lors déjà exposé : contrats, données de santé et de personnel, clés à longue durée de vie, propriété intellectuelle, secrets d’État et d’affaires. Pour ces données, ce qui compte n’est pas le moment où un calculateur quantique deviendra réalité, mais la durée pendant laquelle elles doivent rester secrètes.

Avec CNSA 2.0, la NSA fixe l’année 2030 comme échéance contraignante pour les systèmes de sécurité nationale. Le BSI allemand recommande depuis des années une migration précoce et la crypto-agilité. Les deux décrivent un objectif, non un report confortable.

Pourquoi la migration prend des années

Quiconque a un jour tenté d’inventorier son propre parc cryptographique connaît le problème : personne ne sait exactement où, partout, quels algorithmes, clés et certificats sont en usage. S’y ajoutent des dépendances envers des bibliothèques, du matériel, des protocoles et des partenaires qui ne migrent pas à votre rythme. Une migration PQC n’est donc pas un interrupteur, mais un programme pluriannuel.

Le chemin est clair dans son ordre :

Inventorier : rendre visible où se niche quelle cryptographie, y compris les usages embarqués et oubliés.
Prioriser : d’abord les données à longue durée de vie, celles qui sont déjà aujourd’hui exposées au risque du harvest now.
Établir la crypto-agilité : encapsuler les algorithmes de sorte qu’ils puissent être remplacés sans modifier le système appelant.
Piloter en hybride : procédés classiques et post-quantiques en parallèle, pour éprouver l’interopérabilité et la performance.
Automatiser et exiger : automatiser le renouvellement et engager fermement les fournisseurs sur une capacité PQC démontrable.

La crypto-agilité est le véritable levier

L’erreur la plus fréquente est de voir la PQC comme un remplacement ponctuel. Les algorithmes continueront d’évoluer, les paramètres seront resserrés, certains schémas pourraient tomber. Ce qui demeure, c’est l’exigence de pouvoir changer d’algorithmes sans toucher à chaque système appelant. Quiconque intègre cette agilité aujourd’hui survit non seulement à la première vague PQC, mais aussi à la suivante.

Dans notre module NextPKI, c’est précisément ce qui est prévu : crypto-agile dès le départ, RSA, ECDSA et Ed25519 aujourd’hui, procédés post-quantiques préparés, avec une politique par locataire. L’essentiel, cependant, ne dépend pas de l’outil : il s’agit de bâtir l’agilité comme une propriété, et non comme une migration ultérieure.

2026 est l’année où l’inventaire et le pilote devraient être en place. Alors 2030 ne sera plus que la ligne d’arrivée, et non une date à redouter.

L'obligation de facturation électronique en Allemagne : la feuille de route 2025 à 2028 sans les mythes

2025-02-11T00:00:00+00:00

Depuis le 1er janvier 2025, la facture électronique n’est plus facultative dans les échanges B2B en Allemagne. La première étape de la nouvelle obligation s’applique : toute entreprise établie sur le territoire doit être en mesure de recevoir des factures électroniques structurées. L’émission par voie électronique n’est pas encore obligatoire, mais la réception, elle, l’est. Le fondement juridique est la loi sur les opportunités de croissance (Wachstumschancengesetz), adoptée par le Bundesrat le 22 mars 2024 ; les modalités sont précisées par la circulaire du ministère fédéral des Finances (BMF) du 15 octobre 2024.

Autour de cette obligation circulent plus de demi-vérités que sur la plupart des sujets fiscaux. Trois méritent d’être dissipées.

Mythe 1 : « un PDF est une facture électronique »

Non. Une facture électronique au sens de la norme EN 16931 est un jeu de données structuré qu’un logiciel peut traiter sans rupture de support. Un PDF classique, même reçu par courriel, n’est plus qu’une « autre facture » une fois l’obligation applicable. Ce qui fait foi, c’est le XML lisible par machine, et non l’image destinée à l’œil humain.

En Allemagne, deux formats satisfont la norme : XRechnung, un XML pur conforme à la CIUS d’EN 16931, et ZUGFeRD à partir de la version 2, un format hybride associant un PDF/A-3 à un XML embarqué. Avec ZUGFeRD, c’est le XML qui fait foi, non le PDF visible. Un point important : seuls les profils à partir d’« EN 16931 » (Comfort) sont conformes à la norme. Les profils plus réduits MINIMUM et BASIC WL portent trop peu de données pour valoir comme facture à part entière.

Mythe 2 : « cela ne concerne que 2027, et seulement les grandes entreprises »

La réception concerne tout le monde depuis janvier 2025. Seule l’émission est échelonnée :

depuis le 1er janvier 2025 : obligation de réception, pour toutes les entreprises établies en Allemagne
à partir du 1er janvier 2027 : obligation d’émission, pour les entreprises dont le chiffre d’affaires de l’année précédente dépasse 800 000 euros
à partir du 1er janvier 2028 : obligation d’émission, pour toutes les autres relations B2B

Jusqu’à fin 2026, le papier et les formats non structurés restent admis d’un commun accord, et les plus petits émetteurs bénéficient d’un délai de grâce supplémentaire jusqu’à fin 2027. Les procédures EDI établies demeurent autorisées sous conditions, mais doivent se rapprocher de la norme. Quiconque ne s’attaque à l’émission qu’en 2027 a malgré tout, dès aujourd’hui, un chantier de réception.

Mythe 3 : « recevoir, c’est juste que le courriel arrive »

Juridiquement, une adresse électronique suffit pour qu’une facture électronique soit remise. Sur le plan métier, ce n’est que la moitié du travail. Trois éléments en font partie :

La validation : le XML entrant devrait être vérifié au regard du schéma et des règles de gestion d’EN 16931, faute de quoi des factures erronées se logent sans bruit dans les enregistrements.
La visualisation : un visualiseur qui restitue le XML de façon lisible, afin que les services métiers sans connaissance du XML puissent le contrôler.
L’archivage conforme à la GoBD : ce qui doit être conservé, c’est l’original structuré, inaltérable et chaîné de manière probante, et non un simple tirage PDF.

Ce dernier point en particulier est sous-estimé. Quiconque n’archive que le document visuel et écarte le XML n’a pas conservé la facture au sens juridique.

Ce qui est pertinent dès maintenant

La réception est obligatoire et devrait être mise en place proprement : validation, visualiseur, archive probante du XML. En parallèle, il vaut la peine de se pencher sur l’émission. Quelles relations clients tomberont sous l’obligation en 2027, quels formats les destinataires attendent-ils, et comment l’original structuré sort-il proprement de votre propre système. Dans notre cœur de gestion Datargo ERP, EN 16931, XRechnung et ZUGFeRD, ainsi que le chaînage conforme à la GoBD, sont prévus dès le départ. L’essentiel, cependant, ne dépend pas de l’outil : il s’agit de traiter l’original structuré comme le justificatif de référence, et non comme un accessoire du PDF.

L’obligation n’arrive pas en 2027. Elle a commencé en 2025, mais discrètement, du côté de la réception.