Andrea Margiovanni .it
Un indicateur analogique de précision affiche sa valeur maximale sur un établi de laboratoire ; derrière lui, un appareil électronique ouvert, des schémas techniques et des registres montrent tout ce que le nombre ne peut contenir.

Un score n’est pas une preuve de conformité

Le niveau Advanced mesure la maturité d’une organisation. Il ne démontre pas qu’un produit donné est conforme au CRA. La différence n’oppose pas autoévaluation et contrôle extérieur : elle sépare un diagnostic d’une déclaration qui engage la responsabilité.

Le confort d’un nombre

Le 13 juillet 2026, ENISA a publié le SME Cyber Resilience Maturity Assessment Model. Le titre n’a rien d’inoubliable. L’outil, lui, mérite qu’on s’y arrête. Il vise les micro, petites et moyennes entreprises qui fabriquent ou mettent sur le marché des produits comportant des éléments numériques, et peut aussi servir aux intégrateurs et aux prestataires de services. Il couvre cinq domaines : gouvernance et documentation, gestion des risques et security by design et by default, gestion des vulnérabilités et des correctifs, cycle de vie du produit, sensibilisation et compétences. Chaque critère est évalué sur cinq niveaux, depuis les pratiques inexistantes ou informelles jusqu’aux processus gouvernés et améliorés en continu. Le résultat débouche sur trois profils : Basic, Intermediate, Advanced.

Un tableur Excel officiel accompagne le modèle. Il guide l’évaluation, calcule le score et permet de recommencer l’exercice dans le temps. Pour un éditeur de logiciels de quinze personnes qui entend parler du CRA depuis deux ans comme d’un nuage menaçant fait d’articles, d’annexes, de standards encore inachevés et de calendriers mouvants, difficile d’imaginer objet plus rassurant. Enfin quelque chose qui a des bords. On l’ouvre, on répond, on voit où l’on se situe. Six mois plus tard, on recommence et on mesure le chemin parcouru.

Ce soulagement est légitime. L’outil est gratuit, lisible et bien plus proche de la vie d’une PME que tant de référentiels conçus pour des organisations dotées d’un CISO, d’une direction juridique interne et de salariés capables de consacrer leur vendredi après-midi à la gouvernance. ENISA ne traite pas le manque de ressources comme une faute morale. L’agence essaie de transformer un règlement complexe en chemin praticable pour une petite entreprise, sans lui demander de faire semblant d’être une banque.

Et le modèle est plus rigoureux que le mot autoévaluation pourrait le laisser croire. Le document exige que le score repose sur des preuves objectives — procédures documentées, pratiques effectivement mises en œuvre, comportements observables — plutôt que sur des hypothèses ou des impressions informelles. Il ne demande pas simplement : « Vous trouvez-vous compétents ? » Il demande de regarder ce qui existe. Ceux qui le réduisent à un questionnaire bureaucratique ne l’ont pas lu.

C’est justement parce que le modèle est bien construit que le nombre final sera si facile à détourner.

La phrase qu’ENISA a écrite d’avance

ENISA place l’avertissement décisif dans la synthèse et le répète dans les objectifs du modèle. Même un niveau de maturité Advanced ne remplace pas les obligations juridiques et ne doit pas être considéré comme une preuve de conformité. Ce n’est pas une précaution défensive ajoutée à la fin par un service juridique. C’est une limite de conception : l’outil mesure une chose, le CRA en demande une autre.

La distinction paraît évidente jusqu’à l’apparition du score. Basic, Intermediate et Advanced sont des mots qui décrivent une organisation. Placés dans une cellule colorée, ils prennent l’allure d’un verdict. Advanced ne sonne plus comme « nos pratiques sont assez structurées ». Il sonne comme « nous avons réussi ». Ajoutez le nom de l’Agence de l’Union européenne pour la cybersécurité en haut du tableur, et le glissement sémantique devient presque inévitable. Un indicateur interne se transforme en titre de compétence extérieur sans que personne ait formellement décidé qu’il en serait ainsi.

ENISA ne minimise pas son propre travail. L’agence dit quelque chose de plus intéressant : la maturité favorise la conformité, elle ne se confond pas avec elle. Une organisation qui attribue les responsabilités, gouverne les vulnérabilités, produit de la documentation et revoit ses processus part avec un avantage considérable sur celle qui tient dans la mémoire de deux personnes. Elle peut néanmoins avoir un produit non conforme. À l’inverse, une organisation encore peu mature peut réussir à établir la conformité d’un produit simple et bien délimité, peut-être au prix d’un effort manuel qu’elle ne saura pas répéter pour le suivant.

Le score de maturité répond à la question « notre manière de travailler est-elle fiable ? ». L’évaluation de la conformité répond à une autre : « ce produit, dans cette configuration, satisfait-il à ces exigences applicables ? » Les questions sont proches. Elles ne sont pas interchangeables.

Deux autoévaluations, deux objets

Une correction s’impose ici, parce que la manière la plus rapide d’expliquer la différence est aussi juridiquement fausse. On pourrait dire que le modèle ENISA est une autoévaluation tandis que la conformité serait certifiée par un acteur extérieur. Le récit serait propre. Le CRA ne raconte pas cette histoire.

La Commission européenne résume clairement les procédures. Pour la catégorie par défaut, qui couvre la plupart des produits comportant des éléments numériques, le fabricant peut recourir au contrôle interne. C’est le module A de l’annexe VIII : le fabricant constitue la documentation technique, veille à ce que la conception, le développement, la production et le traitement des vulnérabilités respectent les exigences essentielles, établit la déclaration UE de conformité et en assume la responsabilité. Pour certaines classes de produits importants, le contrôle interne dépend de l’application de normes harmonisées, de spécifications communes ou de schémas de certification. Les produits importants de classe II et les produits critiques relèvent de procédures de tierce partie ou de schémas européens applicables. Le détail varie selon la catégorie. Le principe reste le même : l’article 32 du CRA ne définit pas la conformité par la présence d’un auditeur.

Dans de nombreux cas, les deux opérations sont donc bien des autoévaluations. La même personne peut même les coordonner. Ce qui change tout, c’est l’objet de l’affirmation.

Dans le modèle de maturité, cet objet est l’organisation et la constance de ses pratiques. Les critères traversent les produits, les équipes et les processus. Le modèle précise lui-même qu’avant de le remplir, l’entreprise doit identifier les produits qui entrent dans le champ du CRA, déterminer leur catégorie et choisir la procédure d’évaluation de la conformité applicable. Il ajoute ensuite que son score ne distingue pas ces catégories. Ce n’est pas une faiblesse. C’est le prix de son utilité transversale.

Dans l’évaluation de la conformité, l’objet est un produit identifié. L’affirmation n’est pas « nous gérons bien les vulnérabilités », mais « cette version de ce produit, avec ces composants, pendant cette période de support, respecte les exigences applicables et nous pouvons montrer pourquoi ». La déclaration UE n’est pas une note. C’est l’acte par lequel le fabricant attache son nom à cette proposition et assume la responsabilité de sa véracité.

La différence ne tient pas à celui qui remplit le formulaire. Elle tient à ce qu’il affirme, à l’objet dont il parle et aux conséquences de son affirmation.

Ce que le nombre efface

Tout score est une machine à compresser. Il prend une réalité complexe, en supprime presque tout et conserve une valeur comparable. C’est précisément ce qui le rend utile : aucun dirigeant ne veut recevoir quatre cents pages de logs chaque trimestre pour savoir si l’entreprise progresse. Mais les informations perdues lors de la compression sont exactement celles qui deviennent nécessaires lorsqu’il faut établir la conformité.

Prenons la gestion des vulnérabilités. Une organisation peut avoir des rôles définis, un processus documenté, des sources extérieures surveillées, des SLA de correction et des revues périodiques. Si les preuves le confirment, cela justifie un niveau élevé dans le modèle ENISA. Rien ne garantit pourtant que le processus ait fonctionné sur chaque produit. Un signalement peut être resté dans le mauvais backlog. La SBOM d’une release peut ne pas avoir été générée. Une dépendance peut figurer dans l’artefact distribué et manquer à l’inventaire. Une vulnérabilité peut avoir été jugée non exploitable sans que personne conserve le raisonnement.

Le niveau de maturité continue à dire quelque chose de vrai sur l’organisation. Mais déclarer ce produit conforme exige la chaîne que le score ne contient pas : version évaluée, analyse des risques, inventaire des composants, signalements reçus, délais réels de prise en charge et de correction, tests, décisions motivées, période de support, responsabilités et dates. Il faut également pouvoir reconstituer l’évolution de cette chaîne entre deux releases.

C’est le point le plus facile à manquer. ENISA demande des preuves objectives avant d’attribuer le score, et c’est juste. Mais l’existence de preuves ne donne pas au score une procuration générale sur celles-ci. Il reste à établir qu’elles concernent bien le produit, qu’elles couvrent les exigences applicables, qu’elles correspondent à la version mise sur le marché et qu’elles seront maintenues pendant la durée requise. Le nombre indique que la maison possède une bonne méthode d’archivage. Il ne dit pas que le dossier recherché se trouve dans les archives.

Le marché adore les substituts

Dans quelques mois, ce score se retrouvera dans les appels d’offres, les dossiers de qualification fournisseur et les présentations commerciales. Nul besoin d’imaginer une fraude. Il suffit de suivre les incitations.

Le service commercial veut une phrase qui ferme la question de la préparation au CRA. « Profil Advanced selon le modèle ENISA » tient sur une ligne, porte un nom qui rassure et dispense d’expliquer la différence entre un produit de la catégorie par défaut et un produit important de classe II. Les achats veulent ramener cent fournisseurs à un tableau comparable. Demander un score coûte peu ; ouvrir les dossiers techniques, vérifier un échantillon de preuves et discuter du périmètre coûte cher. Le consultant veut une prestation reproductible. Remplir un tableur possède un début, une fin et un livrable qui rend bien sur la dernière slide.

Aucun des trois n’a besoin de mentir pour que le substitut s’impose. Il suffit que chacun préfère le nombre à la question suivante.

C’est la forme classique de la loi de Goodhart : lorsqu’une mesure devient une cible, elle cesse d’être une bonne mesure. Si Advanced devient une condition informelle du procurement, les organisations optimiseront leur manière de répondre. Pas nécessairement en falsifiant. Elles choisiront le périmètre le plus favorable, interpréteront « appliqué de manière cohérente » avec générosité, prépareront les preuves qui font monter le niveau et reporteront celles qui ferment réellement le risque sur le produit. Le modèle conçu pour révéler les lacunes servira à rendre leur moyenne présentable.

L’autorité d’ENISA renforce le danger, non parce qu’ENISA aurait commis une erreur, mais parce que son nom survivra à l’avertissement qui délimite l’outil. Le logo restera sur le document. Entre la page de publication et la présentation commerciale, la phrase « ne doit pas être considéré comme une preuve de conformité » disparaîtra.

Du score au dossier technique

Le bon usage du modèle consiste à traiter chaque réponse comme le début du travail, pas comme sa conclusion. Si un critère affirme que les vulnérabilités sont suivies et priorisées, la question suivante n’est pas « combien de points cela vaut-il ? ». Elle est : pour quels produits, dans quel système, sous quel identifiant, au regard de quelle exigence, déclenché par quel événement, vérifié par qui et mis à jour quand ?

Une chaîne apparaît alors. Critère, produit, exigence, preuve, owner, date, historique des modifications. Si l’un de ces liens manque, le score peut encore guider la feuille de route interne, mais il ne peut pas être promu au rang de raccourci probatoire. Si les liens existent et sont alimentés par le travail ordinaire — la SBOM par le build, le registre des vulnérabilités par le ticketing, les décisions par le processus de release —, le score devient presque secondaire. L’organisation ne s’est pas contentée de se déclarer mature : elle s’est donné les moyens de le démontrer produit par produit.

C’est le passage du registre rempli à la main à l’inventaire vivant, et aucun document plus élégant ne le réalisera. Il faut de la compliance comme architecture : des preuves générées par les systèmes réels, reliées aux décisions et conservées assez longtemps pour survivre aux personnes qui les ont prises.

C’est aussi là que se mesure la valeur du conseil. Remplir le modèle pour le client produit une version mieux ordonnée de la perception du client. Échantillonner les réponses, ouvrir les dépôts, suivre une vulnérabilité du signalement au correctif, comparer la SBOM à l’artefact distribué et construire les liens manquants transforme un diagnostic en capacité probatoire. Ce sont deux métiers différents. Le premier laisse un score. Le second laisse une infrastructure qui continuera à produire des preuves lorsque le consultant ne sera plus dans la pièce.

Le miroir et la fenêtre

L’outil ENISA n’est pas la réponse au Cyber Resilience Act. C’est la question bien posée. Il demande à une PME de regarder cinq dimensions de son travail trop souvent maintenues séparées et lui donne un langage commun pour décider par où commencer. Utilisé ainsi, le profil compte moins que l’écart qu’il révèle. Basic, Intermediate et Advanced sont des coordonnées sur une carte, pas des tampons sur un passeport.

Le CRA demande un autre geste. Avant de mettre un produit sur le marché, le fabricant doit pouvoir fermer le raisonnement autour de cet objet et le signer. Il le fera parfois seul, avec le module A. Il devra parfois associer un organisme notifié ou employer une autre procédure admise. Dans les deux cas, la qualité de la réponse dépendra des preuves que le modèle de maturité a aidé à retrouver, pas du niveau inscrit dans la dernière cellule.

ENISA a construit un miroir. Un miroir sert à voir où nous en sommes, et c’est déjà beaucoup. Ceux qui s’y regarderont obtiendront une feuille de route honnête, des priorités et des coûts réels. Ceux qui le présenteront aux autres comme une fenêtre découvriront qu’on n’y voit aucun produit, aucune exigence et aucune preuve. On y voit seulement leur propre conviction d’être prêts.

Ce qu'il faut retenir

  • Le modèle ENISA est un excellent outil de diagnostic : il évalue cinq domaines, demande que les réponses reposent sur des preuves objectives et rend visibles les chantiers qu’une PME doit traiter en priorité.

  • Le profil Advanced n’est pas une preuve de conformité, comme ENISA le dit explicitement. Il décrit la maturité des pratiques d’une organisation, pas la conformité d’une version identifiée d’un produit précis.

  • La distinction n’oppose pas autoévaluation et contrôle extérieur. Le CRA autorise le contrôle interne du module A pour de nombreux produits, mais cette procédure exige une documentation technique, une responsabilité sur le produit et une déclaration UE de conformité.

  • Un score rompt le lien entre critère, produit, exigence et preuve. Cette compression le rend utile pour s’orienter et dangereux lorsqu’un appel d’offres ou une présentation commerciale en fait le substitut d’un certificat.

  • Passer du score au dossier suppose une chaîne vérifiable : pour chaque réponse, il faut un produit, une exigence CRA, une preuve, un owner, une date et un historique des modifications. Le conseil crée de la valeur en bâtissant cette chaîne, pas en remplissant le tableur à la place du client.

Questions & réponses

Que mesure le modèle de maturité CRA d’ENISA ?

Il mesure à quel point les pratiques de sécurité d’une organisation sont structurées, appliquées avec constance et améliorées dans le temps, sur cinq domaines : gouvernance et documentation, gestion des risques et security by design, gestion des vulnérabilités et des correctifs, cycle de vie du produit, compétences. C’est un diagnostic organisationnel conçu pour aider les PME à savoir où elles en sont et quoi traiter d’abord.

Un niveau Advanced d’ENISA prouve-t-il la conformité au Cyber Resilience Act ?

Non. ENISA l’exclut explicitement : même le profil Advanced ne remplace pas les obligations juridiques et ne doit pas être considéré comme une preuve de conformité. Le score décrit une maturité organisationnelle ; la conformité doit être établie pour un produit donné, au regard des exigences et de la procédure qui lui sont applicables.

La conformité au CRA exige-t-elle toujours un organisme notifié ?

Non. Pour les produits de la catégorie par défaut, le fabricant peut utiliser le contrôle interne du module A et déclarer sous sa propre responsabilité que le produit respecte les exigences essentielles. Certaines catégories de produits importants ou critiques sont soumises à des procédures plus strictes, qui peuvent faire intervenir des normes harmonisées, une certification ou un organisme notifié.

Quelles preuves faut-il au-delà du score de maturité ?

Il faut des preuves rattachées au produit et à sa version : évaluation des risques, documentation technique, SBOM générée lors du build, registre des vulnérabilités, délais réels de traitement et de correction, décisions motivées, tests, période de support et historique des modifications. L’outil ENISA peut indiquer où chercher, mais le nombre final ne remplace aucun de ces éléments.

Comment une PME devrait-elle utiliser l’outil ENISA ?

Comme une feuille de route, pas comme un bouclier. Chaque réponse devrait être reliée aux produits concernés, aux exigences CRA applicables, aux preuves disponibles et à un owner chargé de les maintenir à jour. La valeur du score réside dans l’écart qu’il révèle et dans le travail qu’il permet de prioriser.

L'auteur

Andrea Margiovanni

Andrea Margiovanni

Je travaille aux côtés d'équipes qui conçoivent des systèmes sous AI Act, CRA, NIS2, RGPD. La règle n'est pas une liste à cocher : c'est une contrainte architecturale, à intégrer dès la conception, pas après.

Voir le parcours
© 2026 Andrea Margiovanni Fait avec soin, à la main