Ce qui suit est ma lecture personnelle de ce qui change dans le logiciel européen sur les 18-24 prochains mois, avec référence aux essais que j’ai écrits sur chaque thème. Ce n’est pas un avis juridique — c’est le point de vue de quelqu’un qui conçoit des architectures logicielles qui doivent passer en production et y rester.
Dernière révision : 27 mai 2026. Je mets à jour cette page quand sort une nouvelle échéance ou que je reviens sur un point dans un essai.
Thèse en une phrase
La compliance européenne 2026–2027 ne se « coche » pas en fin de projet : elle se conçoit en architecture dès le premier jour, comme n’importe quelle autre contrainte non fonctionnelle.
Tout ce qui suit est le raisonnement derrière cette phrase.
Les six règlements, en un souffle
- CRA (Cyber Resilience Act) — obligations de sécurité pour les « produits comportant des éléments numériques » : SBOM, gestion des vulnérabilités, signalement d’incidents, support pendant une période déclarée.
- AI Act — obligations échelonnées pour les systèmes IA selon le niveau de risque : modèles généraux, systèmes à haut risque (RH, crédit, justice), systèmes interdits, GPAI (general purpose AI).
- PLD (nouvelle directive responsabilité du produit) — étend la responsabilité objective au logiciel : le producteur répond des dommages dus à un défaut indépendamment de la faute.
- NIS2 — cybersécurité pour les entités essentielles et importantes : gouvernance, incident reporting sous 24/72h, obligations sur la supply chain numérique.
- EAA (European Accessibility Act) — accessibilité obligatoire pour e-commerce, ebooks, banking en ligne, billetterie, services de téléphonie et de transport à partir de juin 2025.
- DORA (Digital Operational Resilience Act) — résilience opérationnelle pour le secteur financier UE : gestion du risque ICT, tests de résilience, supervision des fournisseurs tiers critiques. En vigueur depuis janvier 2025 ; sa portée au-delà de la finance est considérable, car il fixe de facto les standards de résilience opérationnelle pour toute la supply chain numérique.
Six règlements rédigés à des époques différentes par des DG différentes avec des styles différents. Mais ils convergent vers une idée opérationnelle commune : le logiciel n’est plus une « œuvre de l’esprit exempte de responsabilité technique » — c’est un produit industriel avec des obligations de conformité comparables à celles d’un réfrigérateur.
Spécificité italienne — ACN. L’Agence italienne pour la cybersécurité nationale a publié une matrice de qualification (QC1–QC4) sur les services cloud destinés à l’administration publique, qui se superpose à NIS2, CRA et RGPD avec des contraintes opérationnelles plus serrées. Pour qui vend à l’administration publique italienne, c’est une variable non optionnelle, à lire avec — et non à la place de — le paquet UE.
Mes essais, regroupés par règlement
CRA, architecture, SBOM
AI Act, gouvernance, déployeur
Gouvernance et le métier du logiciel dans un monde de contraintes
Comment j’utiliserais cette page
Si vous êtes CTO ou Head of Engineering : mon conseil opérationnel est de traiter ces échéances comme du release engineering — ownership explicite, milestones en roadmap, RACI. Pas du juridique avec code review.
Si vous êtes product manager : commencez par l’EAA si vous avez un produit grand public, par le CRA si vous vendez B2B. Ce sont les deux qui ont les implications produit les plus tangibles.
Si vous êtes une PME logicielle française : ce n’est pas catastrophique, mais des décisions sont nécessaires maintenant sur trois plans — logging/audit, SBOM, procédure d’incident. J’en parle directement dans certains essais que j’ai regroupés ci-dessus.
Si vous êtes conseil/advisor : la fenêtre pour faire des assessments de readiness est maintenant, pas quand sortira le premier procès exemplaire.
Sources primaires (les lectures obligatoires)
- Cyber Resilience Act — Règlement (UE) 2024/2847
- AI Act — Règlement (UE) 2024/1689
- Product Liability Directive — Directive (UE) 2024/2853
- NIS2 — Directive (UE) 2022/2555
- European Accessibility Act — Directive (UE) 2019/882
Travaillons ensemble
Mon engagement ici n’est pas de vous dire « voici la norme ». C’est de vous aider à transformer six règlements européens en une série de choix architecturaux ordonnés, avec une roadmap et un ownership interne. Le juridique reste nécessaire, mais ce n’est pas le bon endroit pour commencer.
Pour qui c'est utile
CTO et Heads of Engineering de software vendors et SaaS qui opèrent sur le marché UE
Product managers qui doivent comprendre ce qui change dans leur produit avant de planifier les quatre prochains trimestres
Fondateurs de PME tech qui constatent que l’échéance CRA est trop proche pour être ignorée
Compliance officers qui veulent traduire les exigences en backlog, pas en policies PDF
Comment je travaille
- Assessment de readiness (2–4 semaines)
Je prends le produit, la pipeline et la supply chain et je les compare aux exigences CRA, AI Act, PLD, NIS2, EAA et DORA applicables. Output : une carte des gaps avec priorités, effort estimé et suggestions de design-in.
- Conception du plan de compliance (3–6 semaines)
De l’assessment à la roadmap. Qui fait quoi, avec quelles milestones mesurables, synchronisées avec les échéances UE. Un document qu’un board peut approuver et qu’une équipe peut exécuter.
- Second avis sur RFP et fournisseurs (1–2 semaines)
Je lis un contrat fournisseur ou une proposition d’achat et je vous dis si la chaîne de responsabilité tient face au nouveau PLD et au CRA. Utile avant de signer.
Questions opérationnelles
- Êtes-vous avocat ?
Non. Je suis un architecte système qui travaille avec des équipes juridiques. Mon output est opérationnel : diagrammes de flux, RACI, backlog. L’avis juridique, votre avocat le donne.
- Travaillez-vous aussi sur des règlements isolés (par ex. seulement l'AI Act) ?
Oui, mais à contrecœur. Les six règlements interagissent de manière subtile (par exemple CRA et PLD, ou AI Act et NIS2, ou NIS2 et DORA). N’en regarder qu’un seul cache souvent des coûts qui apparaissent sur le second.
- Combien de temps dure un engagement type ?
Deux à six semaines pour un assessment ou une review, deux à trois mois pour un plan de compliance complet.
- Faites-vous de la delivery ou des audits de certification ?
Non aux deux. Le conseil est indépendant précisément parce qu’il n’a pas d’incitation à vous vendre du travail de delivery. Pour la certification, je vous oriente vers des organismes accrédités.
Écrivez-moi à hello@margiovanni.it avec deux lignes de contexte. Je réponds sous quelques jours ouvrés avec une proposition concrète, ou un refus poli si ce n'est pas mon périmètre.
Vous voulez être averti quand je mets cette page à jour ?
Le flux RSS FR signale chaque mise à jour des essais principaux. Pour des conversations plus directes, écrivez-moi : hello@margiovanni.it.
Questions & answers
Quels règlements européens impactent le logiciel en 2026–2027 ?
Six : Cyber Resilience Act (CRA), AI Act, Product Liability Directive (PLD), NIS2, European Accessibility Act (EAA), DORA (sectoriel, finance). Ils entrent en vigueur à des moments différents entre 2024 et 2027 mais produisent des effets cumulés qui redessinent l’architecture du logiciel européen.
La compliance est-elle un problème juridique ou d'ingénierie ?
Les deux, mais l’aspect ingénierie est systématiquement sous-estimé. Ces règlements sont des contraintes système — des échéances de livraison de fonctionnalités (logs, audit, SBOM, accessibilité) avec une date obligatoire. Les traiter comme une bureaucratie à régler en fin de projet coûte 5–10× le design-in en amont.
À qui s'applique le Cyber Resilience Act ?
À tout « produit comportant des éléments numériques » vendu sur le marché UE : logiciel commercial, firmware, dispositifs connectés, SDK. Beaucoup de SaaS rentrent dans la catégorie. La première vague d’obligations (rapport d’incident) démarre en septembre 2026, le gros en décembre 2027.
Mon logiciel n'est pas de l'IA : l'AI Act me concerne-t-il ?
Potentiellement oui. L’AI Act s’applique aussi aux fournisseurs de systèmes qui intègrent de l’IA tierce (API OpenAI, Claude, Gemini, etc.) et aux rôles de « déployeur » — qui utilise l’IA pour prendre des décisions sur des personnes (RH, crédit, prestations sociales). Les échéances vont de février 2025 à août 2027.
Puis-je commencer plus tard, quand il y aura plus d'exemples ?
Non. Le design-in de la compliance demande des choix architecturaux (logging, data retention, SBOM, accessibilité) qui deviennent très coûteux à rétro-adapter. Qui attend « de voir comment font les autres » paie le double.