Datargo · Blog

Un incident, deux circuits de notification : CRA et NIS2 depuis le 11 septembre 2026

2026-09-17T00:00:00+00:00

L’article 14 du Cyber Resilience Act s’applique depuis le 11 septembre 2026. Les fabricants de produits comportant des éléments numériques doivent désormais notifier les vulnérabilités activement exploitées et les incidents de sécurité graves. Le reste du règlement ne s’applique qu’à partir du 11 décembre 2027 : l’obligation de notification est donc avancée de plus d’un an. Elle vise expressément aussi les produits mis sur le marché avant cette date.

Pour beaucoup d’entreprises, ce n’est pas la première obligation de ce type. Les entités essentielles et importantes au sens de la loi allemande de transposition de NIS2 notifient déjà les incidents importants au BSI depuis décembre 2025. Une entreprise qui commercialise un logiciel en tant que produit et qui est elle-même une entité NIS2 porte donc deux obligations qui se ressemblent sans se recouvrir.

Ce qu’exige le CRA

La notification passe par la plateforme unique de signalement mise en service par l’ENISA le 11 septembre. Une seule soumission parvient à la fois au CSIRT désigné comme coordinateur et à l’ENISA. Pour l’Allemagne, selon le BSI, il s’agit du CERT-Bund au sein du BSI. Aucun enregistrement préalable n’est nécessaire.

Les délais sont échelonnés :

Alerte précoce : sans retard injustifié, au plus tard 24 heures après que le fabricant en a pris connaissance.
Notification : au plus tard après 72 heures, avec de premières informations sur la nature, l’impact et les mesures correctives.
Rapport final : pour les vulnérabilités activement exploitées, au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation ; pour les incidents graves, dans le mois qui suit la notification.

S’y ajoute une obligation souvent oubliée : en vertu de l’article 14, paragraphe 8, le fabricant informe les utilisateurs concernés de la vulnérabilité ou de l’incident et des mesures d’atténuation disponibles. Les dispositions relatives aux sanctions ne s’appliquent qu’avec la pleine application du règlement à partir de décembre 2027. L’obligation elle-même, en revanche, vaut dès aujourd’hui.

Pourquoi une notification ne remplace pas l’autre

Le CRA et NIS2 n’ont pas le même objet. Le CRA vise le produit : une vulnérabilité est activement exploitée lorsqu’il existe des preuves fiables qu’un acteur malveillant l’a exploitée dans un système sans l’autorisation de son propriétaire. Cela peut se produire chez un client sans que l’infrastructure du fabricant soit touchée. NIS2 vise l’entité : selon l’article 2, point 11, de la loi allemande sur le BSI, un incident est important s’il cause ou peut causer une perturbation opérationnelle grave ou des pertes financières, ou un dommage considérable à des tiers.

Il en découle trois situations. Une faille exploitée dans un produit livré relève du CRA, mais pas nécessairement de NIS2. Une panne de sa propre exploitation relève de NIS2, sans concerner nécessairement un produit. Et une attaque contre son propre environnement via une vulnérabilité produit peut déclencher les deux, avec deux notifications par deux canaux : le portail du BSI pour NIS2, la plateforme de l’ENISA pour le CRA. En Allemagne, les deux aboutissent au BSI, mais pas dans le même dossier.

Une chronologie, deux évaluations

Deux canaux de notification se gèrent ; deux versions des faits, non. Tenir une chronologie distincte pour chaque obligation finit par produire des horodatages contradictoires. Ce qui fonctionne, c’est un registre d’incidents commun, avec une seule chronologie et deux examens séparés : un produit est-il concerné et y a-t-il exploitation active ? L’exploitation est-elle gravement perturbée ou un tiers a-t-il subi un dommage considérable ?

Trois points décident de la solidité du dispositif en situation réelle. D’abord, un moment de prise de connaissance clairement défini, car les deux délais de 24 heures en dépendent. Ensuite, une fonction nommée qui porte les deux évaluations et n’est pas désignée en plein incident. Enfin, des modèles pour les deux canaux, afin que l’alerte précoce n’échoue pas sur des questions de forme.

La chronologie commence presque toujours par une observation : une panne, un certificat expiré, une modification suspecte du DNS ou des en-têtes. Perstat, notre produit de supervision et de posture de sécurité, consigne ces événements avec leur horodatage et fournit ainsi le point de départ de cette chronologie. Savoir s’il faut notifier, et où, reste une décision de l’entreprise.

Deux obligations de notification n’exigent pas deux organisations. Elles exigent une chronologie qui résiste aux deux.

Fin de clientAuth : pourquoi le mTLS avec des certificats publics touche à sa fin

2026-09-16T00:00:00+00:00

Pendant longtemps, un certificat TLS de confiance publique pouvait remplir deux rôles à la fois : authentifier un serveur auprès des navigateurs et authentifier un client auprès d’un autre serveur. L’extension Extended Key Usage le permettait avec les usages serverAuth et clientAuth. Ce double rôle prend fin. La politique du Chrome Root Program exige des hiérarchies consacrées exclusivement à l’authentification des serveurs.

Les échéances

Selon la version 1.8 de la Chrome Root Program Policy, deux dates s’appliquent :

Depuis le 15 juin 2026, les autorités de certification intermédiaires nouvellement déclarées à la CCADB ne peuvent plus déclarer que l’usage serverAuth.
À partir du 15 mars 2027, la même règle vaut pour chaque certificat final émis.

Les autorités de certification anticipent. DigiCert, par exemple, émet par défaut ses certificats TLS publics sans clientAuth depuis le 1er octobre 2025 et, selon sa propre annonce, supprimera totalement cette option le 1er mars 2027. Qui se fie à l’échéance de Chrome risque donc de découvrir le changement dès le prochain renouvellement.

Les certificats existants restent valides jusqu’à leur expiration. Mais comme la durée de validité maximale est de 200 jours depuis le 15 mars 2026, la transition est courte : un certificat encore émis avec clientAuth le dernier jour autorisé expire au plus tard fin septembre 2027. Au-delà, plus aucun certificat final valide issu d’une hiérarchie reconnue par Chrome ne porte cet usage.

Là où ça casse

Les navigateurs sont à peine concernés, puisqu’ils vérifient des serveurs. Sont touchées les connexions dans lesquelles un système se présente comme client avec un certificat public :

Interfaces partenaires : connexions B2B où les deux parties s’authentifient par mTLS et où le certificat client provient d’une AC publique.
Trafic de serveur à serveur : services qui utilisent leur propre certificat serveur comme identité cliente auprès d’autres services.
Équipements et agents : terminaux qui se présentent à un service central avec des certificats émis publiquement.

Le piège tient au calendrier. L’erreur n’apparaît pas à la date butoir, mais au premier renouvellement qui suit, souvent automatisé et souvent la nuit. Le nouveau certificat est valide, et pourtant la négociation TLS échoue, parce que l’autre partie exige l’usage clientAuth.

Les identités clientes relèvent d’une PKI propre

Chrome ne supprime pas le mTLS. La politique se contente de séparer les usages : les AC publiques authentifient les serveurs auprès du public, tandis que les identités clientes sont émises dans une relation de confiance que les parties contrôlent elles-mêmes. C’est d’ailleurs plus sain sur le plan de la sécurité. Faire confiance à une AC publique comme émetteur de certificats clients revient potentiellement à accepter n’importe quel certificat de cette AC, et pas seulement ceux de son partenaire.

Quatre étapes ont fait leurs preuves pour la transition. D’abord l’inventaire : quels certificats portent aujourd’hui clientAuth, et lesquels sont réellement utilisés comme clients ? Le certificat seul ne le dit pas ; seul le rapprochement avec les connexions le révèle. Ensuite, une autorité de certification dédiée aux usages clients, séparée de tout ce qui authentifie des serveurs. Puis la coordination avec les partenaires, car chaque contrepartie doit installer la nouvelle ancre de confiance, ce qui demande du temps. Enfin, l’automatisation de l’émission et du renouvellement, pour que la PKI interne ne devienne pas une nouvelle charge manuelle.

NextPKI suit précisément ce schéma : rendre d’abord l’inventaire visible, puis automatiser le renouvellement, indépendamment de l’AC émettrice. L’étape décisive précède toutefois tout outil : identifier les connexions qui dépendent aujourd’hui, sans que personne le sache, de clientAuth.

Le 15 mars 2027 n’est pas le jour où le mTLS casse. C’est le jour à partir duquel chaque renouvellement peut le casser.

NIS2 après le délai de grâce : de l'enregistrement à la notification

2026-09-15T00:00:00+00:00

Le délai légal d’enregistrement prévu par la loi allemande de transposition de NIS2 a expiré le 6 mars 2026, et la tolérance accordée par le BSI a pris fin le 31 juillet. Le BSI indique aujourd’hui sans ambiguïté que le délai est écoulé et invite les entreprises concernées à s’enregistrer sans attendre. Celles qui ne l’ont pas fait ne se trouvent plus dans une phase de transition.

Pour les entités enregistrées, une autre question se pose. L’enregistrement est une démarche ponctuelle ; l’obligation de notification prévue à l’article 32 de la loi allemande sur le BSI est un état permanent. La capacité d’une entreprise à la remplir ne se révèle qu’au moment de l’incident.

Ce que disent les chiffres

Le BSI publie régulièrement ses chiffres. Au 30 juin 2026, 17 945 entités étaient enregistrées, dont 11 501 entités importantes et 6 215 entités essentielles. À la même date, le BSI recensait 692 notifications initiales au titre de NIS2 et 1 659 notifications NIS2 au total transmises via le portail. La prochaine mise à jour est annoncée pour le 31 octobre 2026.

Ces chiffres ne permettent de juger aucune entreprise en particulier, mais ils autorisent une observation : le rapport entre entités enregistrées et notifications initiales est faible. Cela peut signifier que peu d’incidents importants surviennent. Cela peut aussi signifier que des incidents ne sont pas reconnus en interne comme devant être notifiés. Chaque direction devrait savoir quelle lecture s’applique à sa propre organisation, car l’article 38 de la loi sur le BSI la rend responsable de la mise en œuvre.

Quand un incident est-il important ?

Tout incident de sécurité ne doit pas être notifié, seulement les incidents importants. L’article 2, point 11, de la loi sur le BSI pose deux critères : une perturbation opérationnelle grave ou des pertes financières pour l’entité elle-même, ou un dommage matériel ou moral considérable causé à des tiers. Les deux valent expressément aussi lorsque le dommage n’est que possible. Pour les fournisseurs d’infrastructures et de services numériques, comme les services d’informatique en nuage, de centres de données et de DNS ou les services gérés, le règlement d’exécution (UE) 2024/2690 précise les seuils.

Le critère est donc volontairement large, et il vise l’impact plutôt que la technique d’attaque. Une indisponibilité de plusieurs heures d’un service utilisé par les clients peut être importante, même si c’est finalement une erreur de configuration, et non un attaquant, qui en est la cause.

Le délai court dès la prise de connaissance

L’article 32 de la loi sur le BSI échelonne la notification : une première notification précoce dans les 24 heures suivant la prise de connaissance, indiquant si une action illicite ou malveillante est soupçonnée ou si des effets transfrontaliers sont possibles ; une notification dans les 72 heures avec une première évaluation de la gravité et de l’impact et, le cas échéant, des indicateurs de compromission ; un rapport intermédiaire à la demande du BSI ; et un rapport final au plus tard un mois après la notification.

Le point critique est le point de départ. Le délai court à compter de la prise de connaissance, et non du moment où quelqu’un qualifie l’incident de notifiable. Si une alerte arrive le vendredi soir et que l’évaluation n’a lieu que le lundi, le délai de 24 heures est écoulé avant même que la notification ait été discutée.

Devenir capable de notifier

La capacité de notification se construit avant l’incident. Quatre éléments la portent :

Fixer les seuils à l’avance : quelles pannes, fuites de données ou dégradations sont importantes pour ses propres services ? Une qualification documentée évite un débat de principe en pleine crise.
Désigner les responsabilités : qui décide de la notification, qui assure la suppléance, et comment joindre cette personne en dehors des heures ouvrées ?
Garantir l’accès : la notification passe par le portail du BSI. L’accès et les droits doivent exister avant d’en avoir besoin.
Tenir une chronologie : détection, évaluation et mesures horodatées, afin que les notifications initiale, de suivi et finale reposent sur les mêmes faits.

Un exercice fondé sur un scénario réaliste montre vite où la chaîne se rompt. C’est rarement la technique ; bien plus souvent, c’est le passage de relais entre l’équipe qui remarque l’incident et la fonction qui décide de la notification.

Perstat, notre produit de supervision et de posture de sécurité, intervient au début de cette chaîne : les pannes et les changements pertinents pour la sécurité sont détectés, escaladés et consignés avec leur horodatage. Qualifier un incident d’important et le notifier restent de la responsabilité de l’entreprise.

Être enregistré décrit un statut. Être capable de notifier décrit une aptitude, et seule l’aptitude est mise à l’épreuve le moment venu.

Facture électronique en 2027 : ce que les émetteurs doivent régler avant la fin de l'année

2026-09-10T00:00:00+00:00

Depuis le 1er janvier 2025, les entreprises établies en Allemagne doivent être en mesure de recevoir des factures électroniques. Pour l’émission, une règle transitoire s’applique en vertu de l’article 27, paragraphe 38, de la loi allemande sur la TVA : jusqu’au 31 décembre 2026, tous les émetteurs peuvent encore établir une « autre facture » au lieu d’une facture électronique, c’est-à-dire une facture papier ou un format électronique non structuré. Au changement d’année, cette règle prend fin pour une grande partie des entreprises.

Qui est concerné

Selon le ministère fédéral des Finances, la période transitoire n’est prolongée jusqu’à fin 2027 que pour les émetteurs dont le chiffre d’affaires de l’année précédente ne dépasse pas 800 000 euros. Pour 2027, c’est donc le chiffre d’affaires de 2026, l’année en cours, qui compte. Au-delà de ce seuil, l’entreprise émet des factures électroniques à partir du 1er janvier 2027. À partir de 2028, l’obligation s’applique à tous.

Il en résulte un enchaînement inconfortable : le chiffre d’affaires définitif n’est connu qu’après la clôture des comptes, alors que l’obligation commence le premier jour de la nouvelle année. Les entreprises proches du seuil ont donc intérêt à décider dès maintenant sur la base de leur projection, sans attendre la clôture. Celles qui clarifient la question avec leur conseil fiscal devraient aussi consigner la base de calcul retenue.

Une seconde règle transitoire concerne l’échange de données informatisé. Les procédures EDI qui ne remplissent pas déjà les exigences d’une facture électronique peuvent encore être utilisées jusqu’à fin 2027. Cela donne du temps, mais ne dispense pas de définir ce que sera l’échange de données ensuite.

Quelles factures sont concernées

L’obligation vise les factures entre entreprises établies en Allemagne. Les factures adressées aux particuliers n’en relèvent pas. Les factures de faible montant, jusqu’à 250 euros TTC au sens de l’article 33 du règlement d’application de la loi sur la TVA, sont également exclues.

Seul un format structuré conforme à la norme européenne EN 16931 constitue une facture électronique. En pratique, il s’agit de XRechnung et de ZUGFeRD à partir de la version 2.0.1, à l’exclusion dans les deux cas des profils MINIMUM et BASIC-WL, qui contiennent trop peu d’informations. Un PDF reste une « autre facture », même envoyé par courriel. Le cadre est fixé par les circulaires du ministère des 15 octobre 2024 et 15 octobre 2025.

Ce qui reste utile d’ici décembre

Un peu plus de trois mois ne suffisent pas à refondre la facturation, mais suffisent pour traiter les points qui, sinon, susciteront des questions en janvier :

Documenter son assujettissement : projection du chiffre d’affaires 2026, décision et motivation consignées par écrit.
Vérifier les factures sortantes : le système produit-il un format conforme, ou seulement un PDF représentant une facture ? Une validation selon les règles de l’EN 16931 le montre rapidement.
Recenser les cas particuliers : autofacturation, factures d’acompte et factures de solde ainsi que les corrections suivent les mêmes règles et sont souvent oubliées lors des tests.
Tester avec les principaux clients : quelques factures d’essai adressées aux clients professionnels les plus importants montrent si le canal de transmission et le format sont réellement traités chez le destinataire.
Assainir les données de référence : les informations manquantes ou obsolètes apparaissent immédiatement dans un format structuré, car les champs obligatoires ne peuvent plus être masqués par du texte libre.

Reste la conservation. Ce qui fait foi, c’est l’enregistrement structuré, et non la copie lisible. Qui n’archivait jusqu’ici que des PDF doit s’assurer que l’original est conservé de manière inaltérable dès janvier.

Pour beaucoup d’entreprises, le 1er janvier 2027 ne sera pas une surprise. Il le deviendra là où c’est la première facture rejetée qui révèle que son propre format ne tient pas.

Enregistrement NIS2 : pourquoi le 31 juillet 2026 est la vraie échéance

2026-07-20T00:00:00+00:00

Le délai d’enregistrement de trois mois prévu par la loi allemande de transposition de NIS2 a expiré le 6 mars 2026. Pourtant, pour de nombreuses entités, la date la plus importante est une autre : le 31 juillet 2026. Le BSI attend d’ici là les enregistrements en suspens et traite les déclarations tardives avec une certaine indulgence pratique jusqu’à cette date. Sur environ 29 500 entreprises concernées, seules quelque 11 500 s’étaient enregistrées à l’échéance légale, pour atteindre environ 18 500 fin mai. Une part importante manque donc toujours.

La bonne lecture de ce report est essentielle. Il s’agit d’une tolérance sur l’enregistrement, non d’un report de la loi. Les obligations de fond s’appliquent depuis le 6 décembre 2025, que l’entité se soit déjà manifestée ou non.

L’enregistrement n’est pas un acte administratif, mais une auto-évaluation

Contrairement à l’ancien système KRITIS, le BSI n’émet pas de décision constatant qui est concerné. Chaque entité doit déterminer elle-même si elle relève de la loi et, le cas échéant, s’enregistrer activement. Cette auto-évaluation au titre de l’article 28 BSIG est le véritable premier pas, et non le remplissage du formulaire en ligne.

En gros : entités importantes à partir de 50 salariés ou de plus de 10 millions d’euros de chiffre d’affaires annuel, entités particulièrement importantes à partir de 250 salariés ou de plus de 50 millions d’euros de chiffre d’affaires. L’appartenance à l’un des 18 secteurs doit également s’appliquer. Certaines entités comptent indépendamment de leur taille, comme les prestataires de services de confiance qualifiés, les opérateurs DNS et TLD ou les fournisseurs de services de communications électroniques publiques. Quiconque évalue trop étroitement et se classe à tort hors du champ en supporte seul le risque.

Qui doit agir avant la fin juillet

Est concerné quiconque remplit les critères et ne s’est pas encore enregistré. Aujourd’hui, il s’agit surtout des entités qui n’ont pas évalué leur situation et de celles qui l’ont évaluée mais ont différé l’enregistrement. Les deux peuvent être rattrapés dans les jours qui restent ; l’enregistrement en soi représente l’effort le plus faible.

L’effort le plus important est l’état des lieux honnête qui se cache derrière : mon entreprise relève-t-elle de la loi, et est-ce que je remplis déjà les obligations en vigueur depuis décembre ? Qui procède à l’enregistrement sans répondre à cette question a déposé un formulaire, mais gagné peu sur le fond.

Les obligations s’appliquent indépendamment de l’enregistrement

L’enregistrement est le ticket d’entrée, non l’obligation elle-même. L’article 30 exige des mesures de gestion des risques, parmi lesquelles la surveillance, la journalisation, la gestion des incidents, la continuité d’activité et la sécurité de la chaîne d’approvisionnement. L’article 32 régit les obligations de notification échelonnées, avec une alerte précoce dans les 24 heures, une notification dans les 72 heures et un rapport final dans un délai d’un mois. L’article 38 engage la responsabilité de la direction, et l’article 65 fixe le cadre avec des amendes pouvant atteindre 10 millions d’euros.

Ces obligations courent depuis le 6 décembre 2025. L’indulgence du BSI n’y change rien. Une entité qui s’enregistre le 31 juillet mais n’a pas signalé un incident significatif en juin était déjà en défaut à ce moment-là.

Ce qui est utile maintenant

Trois étapes aident immédiatement : documenter proprement l’évaluation de votre situation au titre de l’article 28, afin que la classification soit défendable en cas de contestation ; procéder à l’enregistrement tant que dure l’indulgence du BSI ; et organiser la détection de sorte que l’alerte précoce de 24 heures soit réellement atteignable. Un seul exercice de notification révèle vite où la chronologie d’un incident se rompt.

Dans notre module Perstat, la surveillance, la posture de sécurité et une piste d’audit en ajout seul sont reliées de sorte que la chronologie d’incident exigée par l’article 32 puisse être produite de manière traçable. Le point essentiel reste toutefois indépendant de l’outil, à savoir clarifier sa propre situation et ne pas confondre l’enregistrement ponctuel avec les obligations permanentes.

L’enregistrement est le début de l’obligation, non sa fin.

ViDA : ce qui vient après l'obligation allemande de facturation électronique

2026-07-16T00:00:00+00:00

Beaucoup d’entreprises considèrent la facturation électronique comme un sujet allemand doté d’un calendrier allemand : réception depuis 2025, émission à partir de 2027 et 2028. C’est exact, mais incomplet. Au-dessus de ce plan national par étapes se trouve une réforme européenne qui fixe le cadre à long terme : la TVA à l’ère numérique, ou ViDA, formellement adoptée le 11 mars 2025 sous la forme de la directive (UE) 2025/516. Qui conçoit aujourd’hui son architecture de facturation électronique uniquement autour des échéances allemandes voit trop court.

Le point essentiel d’emblée : ViDA et l’obligation allemande ne se contredisent pas, elles s’emboîtent. Toutes deux reposent sur la norme européenne EN 16931 comme format structuré. Qui met en œuvre cette norme proprement travaille dans les deux directions.

Le cadre a déjà changé en 2025

Un élément souvent négligé est déjà en vigueur. Depuis le 14 avril 2025, les États membres peuvent instaurer une obligation nationale de facturation électronique B2B sans avoir besoin d’une autorisation spéciale de l’UE, et sans que le destinataire de la facture ait à y consentir. C’est précisément la base juridique sur laquelle reposent désormais, sans détour, des obligations nationales comme celle de l’Allemagne. La facture électronique structurée selon EN 16931 passe ainsi du cas particulier à la norme européenne.

2030 est la vraie date

Le plan allemand par étapes se termine en 2028 ; la réforme européenne ne commence vraiment qu’ensuite. Les dates centrales :

1er janvier 2027 : clarifications mineures pour le guichet unique (OSS) et l’IOSS.
1er juillet 2028 : nouvelles règles pour les plateformes (fournisseur présumé) pour la location de courte durée et le transport de personnes, ainsi que des étapes vers un enregistrement TVA unique.
1er juillet 2030 : obligations de déclaration numérique pour les transactions B2B intracommunautaires transfrontalières. La facture doit être émise sous forme structurée selon EN 16931, dans les 10 jours suivant le fait générateur. L’état récapitulatif actuel est supprimé.
1er janvier 2035 : les systèmes nationaux de déclaration en temps réel devront être alignés sur le modèle de l’UE.

Pour le commerce transfrontalier, 2030 constitue donc une rupture plus nette que 2028. Qui ne pense aujourd’hui qu’à l’émission nationale allemande passe à côté de la dimension déclarative qui suit peu après.

Déclarer n’est pas facturer

Le saut conceptuel de ViDA tient moins au format qu’au chemin de déclaration. Jusqu’ici, le schéma est : émettre la facture, collecter plus tard, déclarer périodiquement. À l’avenir, la déclaration se rapproche de la transaction. La facture structurée est en même temps l’enregistrement transmis à l’administration fiscale quasiment en temps réel. Cela modifie les exigences de qualité et de délai des données : un format qui n’est corrigé qu’après coup ne convient pas à une déclaration exigible en quelques jours.

Qui construit aujourd’hui ses processus de réception et d’émission devrait donc séparer deux choses et penser aux deux : le format (EN 16931, en Allemagne sous forme de XRechnung et ZUGFeRD) et la capacité de déclaration ultérieure via des voies interopérables comme Peppol.

Ce qui est utile maintenant

Trois vérifications sont payantes : la solution utilisée est-elle réellement conforme à EN 16931, ou n’est-ce qu’un PDF avec pièce jointe ? Les transactions B2B transfrontalières sont-elles proprement isolées dans le processus, puisque ce sont précisément elles qui sont concernées en premier en 2030 ? Et l’architecture est-elle conçue pour une transmission interopérable, afin qu’une obligation de déclaration ultérieure n’impose pas une réimplémentation ?

Notre propre facturation émet dès le départ des factures conformes à EN 16931, avec XRechnung et ZUGFeRD, alignées sur la norme qui sous-tend à la fois l’obligation allemande et ViDA. Le point essentiel reste toutefois indépendant de l’outil, à savoir traiter la facturation électronique non comme un objectif intermédiaire allemand, mais comme une brique d’un système de déclaration européen qui entrera en vigueur en 2030.

L’obligation allemande est la première marche. ViDA est l’escalier.

Cadre de souveraineté du cloud : quand la souveraineté devient un critère de marché mesurable

2026-07-13T00:00:00+00:00

La souveraineté numérique a longtemps été un terme réservé aux discours de principe, difficile à cerner et plus difficile encore à vérifier. Avec le cadre de souveraineté du cloud, la Commission européenne en a fait une grille d’évaluation. La version publiée en octobre 2025 (1.2.1) définit huit objectifs de souveraineté et une méthodologie permettant de classer les fournisseurs de cloud de façon structurée. Avril 2026 a apporté l’épreuve pratique : un contrat-cadre de 180 millions d’euros pour des services de cloud souverain destinés aux institutions de l’UE, attribué à quatre fournisseurs européens.

Cela déplace le débat. La souveraineté n’est plus seulement une promesse marketing, mais un critère demandé et noté dans les appels d’offres.

Huit objectifs plutôt qu’une intuition

Le cadre regroupe la souveraineté en huit dimensions d’objectifs : stratégique, juridique et juridictionnelle, données et IA, opérationnelle, chaîne d’approvisionnement, technologique, sécurité et conformité, et durabilité environnementale. L’intérêt réside dans l’exhaustivité. Qui ne regarde que le lieu d’hébergement saisit peut-être la dimension juridique, mais néglige la chaîne d’approvisionnement derrière l’exploitation, ou la question de savoir qui garde le contrôle de la pile technique le moment venu.

Seule l’articulation de l’ensemble produit une image solide. Un fournisseur peut héberger à Francfort et dépendre malgré tout d’une maison mère hors de l’UE dont la juridiction l’emporte en cas de doute.

SEAL rend le résultat comparable

Au cœur de la méthodologie se trouve le Sovereignty Effectiveness Assurance Level, ou SEAL. Il regroupe l’évaluation en niveaux qui marquent des seuils pour différentes exigences de souveraineté : SEAL-2 pour le plus haut niveau de souveraineté des données, SEAL-3 pour l’autonomie technologique et SEAL-4 pour une souveraineté complète. Une administration n’a donc pas à pondérer elle-même chaque détail, mais peut fixer un niveau cible et y mesurer les offres.

C’est là le véritable progrès. Une logique de niveaux traduit un objectif diffus en une exigence qui peut être mise en concurrence, comparée et vérifiée. Pour les fournisseurs, cela signifie que la souveraineté devient attestable, et non seulement affirmable.

Pourquoi cela dépasse les institutions

La première attribution concernait les institutions de l’UE elles-mêmes, avec quatre fournisseurs européens retenus. Ce qui est intéressant, toutefois, c’est la suite annoncée : la Commission travaille à rendre la méthodologie d’évaluation accessible aux autres administrations et aux États membres. Dès lors que les pouvoirs adjudicateurs nationaux et locaux utilisent la même grille, SEAL devient un langage commun pour la souveraineté dans la commande publique.

Pour les entreprises qui fournissent le secteur public ou servent des clients régulés, c’est un indicateur précoce. Ce qui vaut aujourd’hui pour les institutions de l’UE réapparaît généralement bientôt dans les appels d’offres en aval et les questionnaires fournisseurs.

Ce qui est utile maintenant

Trois questions valent la peine, indépendamment du prochain appel d’offres : dans laquelle des huit dimensions votre usage du cloud est-il réellement souverain, et où dépend-il d’une juridiction non européenne ? De quel niveau cible vos cas d’usage ont-ils réellement besoin, puisque toute charge n’exige pas SEAL-4 ? Et pouvez-vous prouver votre position, et pas seulement l’affirmer ?

La plateforme Datargo est conçue pour un hébergement dans l’UE à Francfort et un contrôle d’exploitation au sein de l’UE, ce qui adresse plusieurs de ces dimensions à la fois. Le point essentiel reste toutefois indépendant du fournisseur, à savoir évaluer désormais la souveraineté selon les huit objectifs plutôt qu’au seul emplacement du centre de données.

La souveraineté ne s’affirme plus. Elle s’évalue.

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 API dans la chaîne d'approvisionnement : pourquoi la sécurité des interfaces devient une question de preuve

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

Un logiciel est rarement un monolithe aujourd’hui. Composants, services partenaires et locataires communiquent par des interfaces, et ces API sont les liaisons discrètes de la chaîne d’approvisionnement. NIS2 exige expressément la sécurité de la chaîne d’approvisionnement dans l’analyse des risques. Une question longtemps jugée purement technique passe ainsi au premier plan : quel est le niveau de sécurité de ses propres interfaces, et peut-on le démontrer ?

L’interface est la surface d’attaque

Les faiblesses d’API les plus fréquentes ne sont pas des exploits sophistiqués, mais des défauts d’autorisation. Dans l’OWASP API Security Top 10, la Broken Object Level Authorization occupe la première place : une API livre des données sans vérifier correctement si le compte demandeur a le droit de les voir. Il suffit alors de modifier l’identifiant d’un objet dans la requête pour récupérer les données d’un autre. Trois points de contrôle déterminent la robustesse en pratique :

Autorisation par objet : chaque requête vérifie si l’appelant peut consulter ou modifier cet objet précis, et pas seulement s’il est connecté.
Authentification : des jetons de courte durée, liés et révocables, plutôt que des clés universelles à longue durée de vie.
Limitation du débit : limites de requêtes et quotas empêchent qu’une interface devienne un point d’exfiltration de données ou un vecteur de surcharge.

Ce qui n’est pas documenté ne peut être sécurisé

De nombreux incidents ne proviennent pas d’interfaces connues, mais d’interfaces oubliées : des API fantômes jamais inscrites à l’inventaire, des API abandonnées restées ouvertes après un changement de version. Sans inventaire complet et à jour, toute défense reste lacunaire. Une description OpenAPI bien tenue est ici davantage qu’un confort pour les développeurs : c’est le contrat au regard duquel les autorisations, les versions et le comportement attendu peuvent tout simplement être vérifiés. Un portail développeur dédié, qui conserve ces descriptions de manière versionnée et par locataire, transforme un savoir dispersé en un registre traçable.

La sécurité comme propriété démontrable

Lorsque l’autorité de contrôle pose la question, il ne suffit pas d’affirmer que les API sont sécurisées. Il faut des preuves : quelles interfaces existent, dans quelle version, avec quelles autorisations, et qui a consulté quoi, et quand. Le versionnage, les journaux d’accès et un registre des interfaces tenu à jour font de la sécurité non plus une affirmation, mais une propriété démontrable. C’est la logique que NIS2 applique ailleurs à la supervision et à la notification, transposée aux liaisons entre systèmes.

Une chaîne d’approvisionnement ne vaut que ce que valent ses interfaces. Et une interface que personne ne connaît entièrement ne peut être ni sécurisée ni démontrée.

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 Perstat, 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 propre système de facturation, la facture é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 Perstat, 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 Perstat, 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 propre facturation, 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.