Une scène me revient souvent, je la reconnais à la première minute. Quelqu’un évoque la compliance, en réunion projet ou en call avec un client un peu structuré, et la réponse arrive presque automatique.
« Le juridique s’en occupe. »
Je ne le dis pas pour le cynisme. C’est juste que cette phrase, en 2026, risque d’être l’une des plus coûteuses qu’une entreprise logicielle européenne puisse prononcer.
Parce que ce qui arrive ne ressemble pas à une mise à jour de policy ou à un round d’informations. Ça ressemble plus à un changement de fondations. Et, plus inconfortable encore, avec des échéances très rapprochées.
La tempête parfaite : cinq échéances dans une fenêtre trop courte
Si tu fais du logiciel pour le marché européen, le calendrier n’est plus un détail dans un fichier partagé. C’est une timeline qui entre dans ton architecture.
Entre fin 2024 et 2026, des normes s’empilent. Prises seules, tu pourrais peut-être les gérer péniblement. Ensemble, en revanche, elles s’emboîtent exprès.
NIS2 est en vigueur depuis octobre 2024 et a élargi le périmètre de qui doit prendre la cybersécurité au sérieux, supply chain incluse. Première surprise fréquente : pas besoin d’être « critique » pour en sentir les effets. Il suffit d’être fournisseur de quelqu’un qui l’est.
L’European Accessibility Act est opérationnel depuis juin 2025 et déplace l’accessibilité du monde des « améliorations » à celui des « exigences ».
Puis vient 2026, l’année où le nœud se serre.
En août 2026, l’AI Act entre en pleine application pour les systèmes à haut risque. Ce n’est pas qu’éthique ou transparence. On parle d’évaluations de conformité, de documentation technique, de gouvernance des données, de supervision humaine. Et oui, de sanctions réelles, jusqu’à 3 % du CA mondial ou 15 millions.
En septembre 2026, le Cyber Resilience Act amène des obligations qu’on ne peut pas « ajouter après ». Notamment la signalisation d’une vulnérabilité activement exploitée sous 24h et d’incidents graves sous 72h. Et ce que beaucoup sous-estiment : ça ne vaut pas que pour les produits futurs. Ça vaut aussi pour ce qui est déjà sur le marché. Legacy compris.
En décembre 2026, la Product Liability Directive redéfinit ce qu’est un « produit » à l’ère numérique. Le logiciel, même standalone ou en SaaS, devient produit à part entière, avec responsabilité objective. Les bugs cessent d’être un simple ennui opérationnel et deviennent un défaut potentiel, avec conséquences juridiques directes. La responsabilité ne s’arrête pas à la livraison, elle s’arrête quand tu n’as plus la capacité de fournir des mises à jour.
Et en arrière-plan, le RGPD, qui n’est jamais parti, avec un enforcement de moins en moins timide.
Ce qui déstabilise le plus, c’est peut-être que ces normes ne s’additionnent pas linéairement. Elles se renforcent.
L’erreur fondamentale : traiter la compliance comme une couche externe
La réaction la plus courante est compréhensible : « on appelle le consultant, on met à jour les policies, on rédige la doc, on coche les listes ». L’approche compliance-as-paperwork.
Avec le RGPD, même mal fait, ça tenait parfois. On pouvait coller au-dessus d’un système existant des process, informations, registres, rôles.
Avec le pacte 2026, ça ne tient plus. Pas par manque de bonne volonté. Parce que certaines exigences, sans le support de ton archi et de ton processus de release, tout simplement n’existent pas.
Cas concret : pour respecter le CRA, quand émerge une vulnérabilité activement exploitée, tu dois pouvoir réagir et signaler dans les délais. Pour ça, il faut savoir précisément ce qu’il y a dans ton produit. Pas « à peu près ». Exactement.
Dépendances directes, transitives, composants, versions, builds. Tout.
Cela t’amène droit à un objet ni juridique ni bureaucratique : le SBOM, software bill of materials. Et pas un SBOM en PDF généré une fois pour faire plaisir. Un SBOM vivant, régénéré à chaque build, en format machine-readable, intégré à la pipeline.
Si ton processus de build ne produit pas un SBOM comme sortie naturelle, ce n’est pas que tu es « un peu en retard ». C’est que tu ne peux pas l’être, point.
Et là se cristallise la phrase la plus importante de tout ça : la compliance n’est pas une exigence que tu ajoutes. C’est une propriété émergente de ton architecture.
La compliance comme contrainte d’architecture
En architecture logicielle, on est habitués aux contraintes. Latence, disponibilité, scalabilité, compatibilité, coûts. Elles restreignent l’espace des solutions.
La compliance EU 2026 est une contrainte d’architecture. Pas un ticket à assigner « en fin de projet », pas un document à produire « avant l’appel d’offres ». Une contrainte qui traverse le système.
Quand tu la regardes ainsi, des conséquences deviennent presque évidentes.
L’observabilité n’est plus un extra
L’AI Act, pour certains systèmes, exige logs et traçabilité. Le CRA pousse vers la détection et la réponse. La PLD te place en position de devoir démontrer l’état du logiciel au moment de l’incident.
Sans audit trails suffisants, ce n’est pas que tu « monitores peu ». C’est que ton système ne peut pas soutenir les questions que le marché et les normes te poseront.
La gestion des dépendances devient un processus critique
Pendant des années, on a normalisé l’idée que mettre à jour des libs est un travail « quand on a le temps ». Un npm install à la va-vite, un lockfile que personne ne regarde, une mise à jour reportée parce que « ça marche ».
Avec CRA et NIS2, cette légèreté devient un risque de supply chain. Et le risque supply chain, en 2026, ne reste pas confiné à la tech. Il se propage aux contrats, aux appels d’offres, aux partenariats.
La question à laquelle tu dois savoir répondre est simple et dure : « ce CVE qui vient de sortir impacte-t-il nos produits en prod ? ». La réponse doit arriver en minutes ou heures, pas en semaines.
Le concept de « produit fini » s’effrite
PLD et CRA, ensemble, rendent moins crédible l’idée qu’une release ferme un chapitre. Releaser devient le début d’une relation de longue durée avec un système à entretenir, surveiller, soigner.
Cela change aussi la façon d’estimer, planifier, vendre. Parce qu’une partie de la valeur — et de la responsabilité — vit après la livraison.
L’accessibilité est une propriété du design system
L’EAA n’est pas tendre avec les retrofits. Si tu as un design system accessible by default, tu as un avantage structurel. S’il faut « rendre accessible » un frontend grandi pendant des années sans règles, le volume de findings revient ingérable.
Je me demande souvent si on ne sous-estime pas combien l’accessibilité est, en réalité, une forme de standardisation interne. Pas qu’une exigence externe.
La human oversight n’est pas un bouton
Une des incompréhensions les plus courantes de l’AI Act est de penser que « supervision humaine » signifie ajouter une étape d’approbation à la fin.
En pratique, c’est une question de flux : où l’humain peut intervenir, avec quelles informations, avec quelle possibilité d’override, avec quelle traçabilité. C’est de l’architecture du processus de décision, avant même de l’architecture logicielle.
L’intersection que beaucoup ne regardent pas
Le point le plus intéressant, et peut-être le plus dangereux, ce n’est pas chaque obligation. C’est leur emboîtement.
La PLD dit qu’un produit logiciel est défectueux s’il ne satisfait pas aux exigences de cybersécurité applicables. Le CRA définit une part importante de ces exigences. L’AI Act ajoute des exigences spécifiques quand il y a de l’IA.
Donc la non-conformité au CRA peut devenir un défaut de produit au sens de la PLD.
On ne parle plus seulement d’amende administrative ou de non-conformité « à corriger ». On parle de responsabilité civile pour dommages, avec des dynamiques comme l’inversion de la charge de la preuve.
Pour te défendre, tu dois pouvoir démontrer que le produit était conforme au moment de l’incident. Ce qui te ramène, encore, à SBOM, audit trails, logging, doc technique. Pas comme théâtre de la compliance, mais comme architecture défensive.
Le paradoxe italien : fragiles, mais rapides
Ici, un morceau que je sens proche, parce que c’est la réalité quotidienne de beaucoup de boîtes avec qui je discute.
Le tissu logiciel italien est en grande partie fait de PME : équipes de 5 à 20, produits verticaux, croissance par stratification, roadmap dictée par les clients, dette technique accumulée selon la logique feature-first.
Beaucoup sont impréparées. Pas par incapacité, par structure.
Et pourtant un paradoxe : la même structure qui les rend vulnérables peut devenir un avantage.
Une boîte de dix personnes, si elle décide vraiment, peut redessiner des pans importants de son archi en 12 mois. Une grande organisation met souvent des mois rien que pour comprendre ce qu’elle a en prod.
Une petite équipe connaît son domaine et son produit intimement. Elle peut faire une gap analysis réaliste en quelques semaines.
Et un founder-CTO qui investit aujourd’hui en compliance-by-design peut bouger dans une fenêtre qui, dans 18 mois, sera déjà fermée. Pas parce que ce sera impossible, mais parce qu’il sera trop tard pour le faire avec calme.
Compliance-by-design : décisions d’archi, pas slogans
Quand je dis compliance-by-design, je n’entends pas « bien faire les choses » en général. J’entends des choix concrets que tu peux commencer maintenant, sans tout révolutionner.
Le SBOM comme artefact de première classe, par exemple. Chaque build produit un SBOM en CycloneDX ou SPDX. La pipeline le génère, le conserve, le confronte aux bases de vulnérabilités, et au besoin bloque un déploiement. Des outils comme syft, grype ou trivy rendent cela bien plus accessible qu’il ne semble.
Puis l’audit trail, mais pas celui des logs système. Un audit trail de domaine : qui a fait quoi, quand, pourquoi, avec quel rôle, dans quel contexte. Event sourcing ou append-only log, l’idée est qu’il soit citoyen de première classe du modèle de données.
La doc technique comme code, autre point clé. Si la doc vit dans un wiki mis à jour à la main, tôt ou tard elle cesse de représenter la réalité. Avec des ADR versionnés, des spécifications déclaratives, et de la doc générée depuis le code, elle devient un sous-produit inévitable du travail.
Et le vulnerability management ne peut pas être un événement annuel. Ça doit être un processus continu : scan automatique, triage, remédiation à délais définis. Quand la signalisation d’une vulnérabilité exploitée arrive, le système doit t’aider à réagir en heures.
Sur l’accessibilité, ce qui marche est de la traiter comme design tokens et règles du design system. Si les composants naissent accessibles, le produit le reste. S’il faut corriger après, chaque nouvel écran ajoute de la dette.
Le développement AI-native comme accélérateur, pas que comme risque
Petite ironie : l’AI Act arrive pendant que l’IA change la façon dont on écrit du logiciel.
Beaucoup voient le développement AI-native comme un risque pour la compliance : plus de code généré, moins de contrôle. Je soupçonne que, dans bien des cas, c’est l’inverse.
Une approche spec-driven, où le logiciel naît de spécifications déclaratives lisibles et vérifiables, est intrinsèquement plus favorable à la conformité. Parce que les spécifications sont de la doc. Parce qu’elles sont versionnées. Parce qu’elles rendent explicites des hypothèses qui restent sinon dans la tête de qui a écrit ce bout de code il y a deux ans.
Des outils comme un fichier projet claude.md, speckit, des pipelines qui génèrent des artefacts de compliance dans le flux, ne sont pas de la science-fiction. C’est une autre manière de travailler, qui peut faciliter la production d’évidences, de traçabilité, de reconstructibilité.
Le futur n’est peut-être pas « écrire plus de doc ». C’est construire le logiciel pour que la doc soit inévitable.
Le vrai coût de la non-conformité est bien plus proche qu’une amende
Les sanctions impressionnent, mais pour beaucoup de PME elles restent abstraites. Ce n’est pas la peur de l’amende qui change les priorités.
Le coût réel est plus quotidien.
C’est l’appel d’offres public auquel tu ne peux pas répondre faute de répondre aux exigences de sécurité du cahier.
C’est le client enterprise qui te demande le SBOM et tu ne sais pas par où commencer.
C’est le partenaire qui fait du supply chain risk management et t’écarte de la shortlist.
C’est l’incident que tu ne peux pas gérer dans les délais du CRA et qui s’imbrique dans un cadre de responsabilité plus dur.
Pour beaucoup d’entreprises italiennes, ce ne sont pas des scénarios théoriques. Ça ressemble beaucoup à 2027.
La fenêtre, c’est maintenant — et c’est de la bonne ingénierie
Architecte logiciel, la tête souvent partagée entre roadmap, budget, dette technique et demandes du marché, je comprends que tout cela puisse paraître écrasant.
Mais un aspect mérite d’être en avant : beaucoup des pratiques exigées par ces normes sont simplement de la bonne ingénierie.
Générer un SBOM, c’est de la bonne ingénierie. Avoir un audit trail, idem. Gérer les vulnérabilités des dépendances, idem. Documenter les décisions d’architecture, idem. Construire des interfaces accessibles, idem.
Ce que la compliance EU 2026 fait, peut-être, c’est rendre obligatoire ce qu’on aurait dû faire de toute façon. Elle transforme les best practices en baseline.
Et elle crée un marché où qui traite la compliance comme un problème d’architecture, et pas comme un truc à déléguer au juridique, se retrouve avec un logiciel plus robuste, plus maintenable, et plus vendable.
La fenêtre pour bâtir cet avantage est ouverte maintenant. Dans dix-huit mois, qui n’a pas commencé courra. Qui commence maintenant, vraisemblablement, sera de l’autre côté.
Ce qu'il faut retenir
La compliance 2026 est une propriété d’architecture, pas un artefact juridique : si la pipeline ne produit pas de SBOM en natif, la conformité est impossible — pas seulement coûteuse.
Les cinq règlements se renforcent : les regarder isolément masque les coûts qui apparaissent à l’intersection (CRA × PLD, AI Act × NIS2).
Le design-in coûte 5 à 10× moins que le retrofit sous pression d’enforcement.
La fenêtre concurrentielle est ouverte pour qui bouge tôt et se referme vite à mesure que les marchés publics et les grands clients exigeront la compliance par contrat.
Le développement AI-native est un accélérateur, pas seulement un risque — si la pipeline IA est gouvernée avec la même rigueur que le produit.
Questions & réponses
Quelles sont les cinq normes européennes qui changent le logiciel entre 2024 et 2026 ?
NIS2 (en vigueur octobre 2024, étend la cybersécurité aussi aux fournisseurs de sujets critiques), EAA (juin 2025, fait de l’accessibilité une exigence et non une amélioration), AI Act (août 2026 pour les systèmes à haut risque), CRA (septembre 2026, obligations de sécurité y compris sur le legacy déjà sur le marché), PLD (décembre 2026, le logiciel devient produit avec responsabilité objective). Et le RGPD reste en arrière-plan.
Pourquoi la compliance-as-paperwork ne marche-t-elle plus ?
Parce que le pacte 2026 contient des exigences qui n’existent que si elles sont soutenues par l’architecture. Exemple : signaler en 24 heures une vulnérabilité activement exploitée (CRA) suppose un SBOM vivant, régénéré à chaque build, intégré à la pipeline. Pas un PDF généré une seule fois. Si ton processus de build ne produit pas un SBOM comme sortie naturelle, tu ne peux pas être conforme — ce n’est pas une question de checklist.
Que veut dire « compliance comme propriété émergente de l'architecture » ?
Que des obligations comme la signalisation des vulnérabilités à 24h, la traçabilité des dépendances, les audit logs, la supervision humaine sur l’IA à haut risque, la documentation technique — sont des conséquences de la façon dont tu conçois le système, pas des couches à ajouter après. Si ta pipeline, ton logging et ton observabilité ne sont pas structurés d’une certaine façon, la compliance est impossible, pas coûteuse.
Quel est le risque réel pour une PME logicielle italienne qui ne se prépare pas ?
Le risque concret n’est pas d’abord l’amende (même si elle peut atteindre 3 % du CA mondial sur l’AI Act). C’est d’abord la perte de marchés publics et de grands clients privés qui exigeront la conformité par contrat, puis le coût du retrofit d’architecture sous pression — soit 5 à 10× le coût d’un design-in fait maintenant. La fenêtre concurrentielle s’ouvre maintenant pour qui bouge, se referme vite pour qui attend.
L'auteur
