Quand une entreprise sait-elle quelque chose ?

Vendredi 11 septembre 2026, un formulaire est apparu en ligne. Il se trouve à l’adresse portal.cra-srp.enisa.europa.eu, on y entre avec un compte EU Login et une authentification à deux facteurs, et il sert à faire une chose qu’aucun fabricant européen de logiciel ou de matériel n’avait jamais eu à faire sous cette forme : déclarer à une autorité qu’une vulnérabilité de ses produits est activement exploitée par quelqu’un.

Parmi les champs à remplir, il y en a un qu’il vaut la peine de lire dans la langue où il est écrit, puisque la plateforme n’est pour l’instant disponible qu’en anglais : « Date/Time when you became aware of the incident/actively exploited vulnerability ». Date et heure à laquelle vous en avez eu connaissance.

De ce champ part un délai de vingt-quatre heures.

Il y a, dans la FAQ que l’ENISA a mise à jour le 12 septembre, le lendemain de l’ouverture, un détail que je trouve plus intéressant que tout le reste. L’agence explique que, dans la version actuelle de la plateforme, le compteur des 72 heures affiche une échéance calculée 48 heures après l’envoi de l’early warning, et qu’une notification peut donc apparaître en retard avant même que 72 heures se soient écoulées depuis que le fabricant a su. Puis elle ajoute que cette logique sera corrigée dans une version future, de manière à calculer l’échéance à partir du champ portant la date et l’heure de la connaissance.

Dit comme ça, c’est une note de version. C’est aussi le moment où quelqu’un, à l’intérieur d’un ticket, a dû décider comment on mesure un temps qui commence à un fait mental collectif. Pour l’instant la plateforme compte à partir du moment où vous avez parlé. Elle a écrit qu’elle comptera à partir du moment où vous avez su.

Prenons donc une nuit ordinaire.

À 02h13, la télémétrie d’un produit enregistre une séquence anormale de requêtes sur un point d’authentification. À 02h14, le SIEM corrèle cette séquence avec une règle et génère une alerte de sévérité moyenne, l’une des quatre cents de la semaine. À 07h55, un technicien de l’équipe du matin l’ouvre. À 09h20, après avoir lu les journaux applicatifs, il conclut qu’il ne s’agit probablement pas d’un scanner mais d’un exploit fonctionnel contre une bibliothèque tierce. À 11h40, le responsable sécurité reçoit le rapport. À 14h10, la réunion commerciale terminée, quelqu’un en parle à la direction.

Douze heures. Personne n’a rien caché, personne n’a violé une procédure, personne ne s’est comporté de façon déraisonnable. Chaque étape, prise isolément, est défendable.

Quand l’entreprise a-t-elle su ?

Ce n’est pas une question rhétorique et ce n’est pas une question philosophique. Depuis le 11 septembre, c’est un champ obligatoire dans un formulaire, et de ce champ part une horloge assortie de sanctions.

Sur cette échéance, sur le fait que la plateforme soit née le jour même de l’obligation et sur ce que signifie y arriver sans s’être enregistré, j’ai déjà écrit en août. Ce texte se terminait sur une phrase qui me semblait alors une conclusion et qui me semble aujourd’hui le début d’autre chose : l’horloge part de la connaissance, et la connaissance est un fait organisationnel avant d’être un fait technique. Cet essai commence là, et il ne parle pas du CRA.

Le droit travaille avec la connaissance bien avant le logiciel

L’objection d’abord, et dans sa version forte, car si elle tient il n’y a pas d’essai.

Il n’y a strictement rien de nouveau dans une règle qui fait courir un délai à partir du moment où quelqu’un prend connaissance d’un fait. C’est l’une des techniques législatives les plus anciennes qui soient. La prescription, la forclusion, le recours, la dénonciation des vices : le droit mesure le temps à partir de la connaissance depuis des siècles, et il le fait parce que l’alternative, le mesurer à partir du fait objectif, punirait ceux qui ne pouvaient pas savoir.

Dans le numérique, le précédent est presque gênant tant il est explicite. L’article 33 du RGPD impose depuis 2018 la notification d’une violation de données à caractère personnel à l’autorité de contrôle « dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance ». Le considérant 87 ajoute qu’il convient de vérifier si toutes les mesures de protection technologiques et organisationnelles appropriées ont été mises en œuvre pour établir immédiatement si une violation a eu lieu. Les lignes directrices 9/2022 de l’EDPB, adoptées en version 2.0 le 28 mars 2023, précisent que le responsable du traitement doit être considéré comme ayant pris connaissance lorsqu’il dispose d’un « degré raisonnable de certitude » qu’un incident de sécurité s’est produit et a compromis des données personnelles.

NIS2 fait exactement la même chose avec exactement les mêmes chiffres. L’article 23, paragraphe 4, de la directive (UE) 2022/2555 exige un early warning dans les 24 heures suivant la connaissance d’un incident important, et une notification dans les 72. Le CRA, avec l’article 14 du règlement (UE) 2024/2847, reprend ce schéma presque mot pour mot : early warning dans les 24 heures à compter du moment où le fabricant « becomes aware », notification dans les 72, rapport final dans les 14 jours suivant la disponibilité d’une mesure corrective pour les vulnérabilités et dans le mois suivant la notification pour les incidents graves.

Trois textes, le même déclencheur, les mêmes chiffres. Il serait très facile de ranger l’affaire au rayon des minuteurs réglementaires et de passer à autre chose, et c’est exactement ce qu’ont fait la plupart des commentaires que j’ai lus cette semaine.

Je veux construire ce texte contre cette lecture, mais sans la nier. En niant sa conclusion.

Le législateur ne dit pas comment on sait, et c’est précisément pour cela qu’il a commencé à regarder

Le document qui a changé mon avis n’est pas le règlement. Ce sont les FAQ de la Commission sur la mise en œuvre du CRA, publiées une première fois le 3 décembre 2025 et mises à jour le 4 septembre 2026, une semaine avant l’ouverture de la plateforme. La section 5 porte sur les obligations de signalement, et la première entrée de cette section, la 5.1, demande comment un fabricant peut prendre connaissance d’une vulnérabilité activement exploitée ou d’un incident grave.

La réponse commence par dire que le CRA ne le précise pas. « The CRA does not specify how a manufacturer is to become aware », le texte se borne à imposer l’obligation de notifier une fois que la connaissance existe. Puis la Commission fait une chose à laquelle elle n’était pas tenue : elle énumère les canaux. Un client ou un partenaire qui signale une activité inhabituelle. Un rapport de threat intelligence. Des chercheurs en sécurité ou des sociétés de cybersécurité qui publient l’analyse d’un zero-day utilisé dans des attaques ciblées. Une agence gouvernementale qui a détecté l’exploitation avec ses propres systèmes de surveillance. Un hacker éthique. Et puis, en fin de liste, la phrase qui m’intéresse : le fabricant peut aussi prendre connaissance « via internal monitoring, scanning activities or telemetry ». Son propre système de télémétrie, ou un honeypot, qui indique l’exploitation d’une faille jusqu’alors inconnue. Sa propre équipe de sécurité qui surveille des forums du dark web et y trouve la preuve que quelqu’un a exploité une faille du produit.

Dans cette liste, le capteur n’est plus seulement un instrument technique. Il est l’un des moyens par lesquels une personne morale prend connaissance de quelque chose.

Une précision s’impose ici, car la tentation de forcer le texte est forte et y céder serait malhonnête. Juste après la liste, la Commission écrit que tout cela n’implique pas que le fabricant soit tenu d’exercer ces activités ou de surveiller ces canaux pour se conformer aux obligations de signalement. Il n’existe, dans l’article 14, aucun devoir de voir. Et je ne soutiens pas que la moindre alerte déclenche automatiquement le chronomètre : le texte ne le dit pas, la Commission ne le dit pas, et la notion concrète de connaissance demandera des années d’interprétation avant de se stabiliser.

Sauf que cette phrase porte une note de bas de page, la dixième, et cette note dit le reste. « Nonetheless », malgré tout, l’annexe I, partie II impose au fabricant de disposer, entre autres, d’un point de contact unique où les vulnérabilités peuvent être signalées, d’adopter et de faire respecter une politique de divulgation coordonnée des vulnérabilités, et de prendre des mesures pour faciliter le partage d’informations sur les vulnérabilités potentielles.

Traduit : l’obligation de signalement ne vous impose pas de regarder, mais le règlement qui la contient vous impose d’être joignable. Ce n’est pas un devoir de voir. C’est un devoir d’avoir une porte, de la laisser ouverte et de dire à tout le monde où elle se trouve.

Il y a un second indice, dans le même règlement, sur lequel personne n’a selon moi assez appuyé. L’article 14 dit « becomes aware », connaissance effective. L’article 13, paragraphe 21, même sujet, même texte, utilise une autre formule : les fabricants « who know or have reason to believe » que le produit n’est pas conforme doivent immédiatement prendre les mesures correctives. Savoir, ou avoir des raisons de croire. C’est le standard de la connaissance imputée, celle que le droit attribue à qui aurait dû savoir.

Le législateur européen connaît parfaitement la différence entre les deux formules et les a employées à quelques lignes d’écart. Il n’a pas étendu la connaissance imputée à l’obligation de signalement, et ce choix est délibéré. Mais il a écrit un règlement où cohabitent, à une page de distance, le standard de ce que vous savez et celui de ce que vous avez des raisons de croire. Qui pense que l’ambiguïté sur l’awareness est une étourderie n’a pas lu d’assez près.

La thèse, dès lors, n’est pas que l’Europe a ordonné aux entreprises de savoir. Elle est plus subtile et, je crois, plus importante. Morceau par morceau, le droit numérique européen rend juridiquement pertinente l’architecture par laquelle une organisation en vient à savoir quelque chose. Il n’impose pas de surveiller. Il crée une incitation très forte à savoir décrire comment un signal devient de la connaissance.

Architecture épistémique

J’appelle architecture épistémique l’ensemble des mécanismes par lesquels une organisation recueille des signaux du monde, leur attribue un sens, décide quand les preuves suffisent, et transforme cette appréciation en un fait sur lequel agir. Le terme n’a rien d’ésotérique et la chose n’a rien de nouveau. Elle existe dans toutes les entreprises, y compris celles qui ne l’ont jamais nommée.

Un SOC est une architecture épistémique. Un processus de gestion des incidents en est une. Une chaîne d’escalade en est une. La règle non écrite selon laquelle une certaine catégorie d’alertes est mise en sourdine le vendredi après-midi en est une. La décision de ne pas intégrer une source, de ne pas renouveler un flux, de ne pas lire une boîte aux lettres en est une aussi : négative, implicite, presque jamais délibérée, et parfaitement opérante.

Dans le logiciel, nous avons construit un vocabulaire extrêmement sophistiqué pour discuter de l’observabilité des machines. Logs structurés, métriques, traces distribuées, cardinalité, percentiles, alerting fondé sur des SLO. Je peux savoir en quelques secondes que la latence au quatre-vingt-dix-neuvième percentile d’un endpoint a augmenté de 15 % par rapport à la semaine dernière, et je peux vous dire de quel service en aval elle provient.

Nous sommes bien moins doués pour décrire l’observabilité de l’organisation qui possède ces systèmes.

Quand une alerte a été vue, et par qui. Qui avait, à ce moment-là, les éléments pour l’interpréter. Quelles preuves manquaient, et qui les détenait. À quel moment le doute est devenu une certitude raisonnable. Qui avait l’autorité de le déclarer, et si cette personne était joignable.

Ces questions semblent administratives jusqu’à ce qu’une règle fasse partir de l’une d’elles un délai de vingt-quatre heures. Depuis vendredi, en Europe, l’une d’elles est un champ obligatoire avec une date et une heure dedans.

Le paradoxe de l’observabilité régulée

Vient ici l’objection que je considère comme la plus sérieuse de tout le texte, et je lui laisse toute la place qu’elle mérite parce qu’elle est vraie.

Une organisation qui voit mieux se place, en apparence, dans une position réglementaire plus mauvaise.

Si j’ai une excellente télémétrie sur le produit en production, si j’achète de la threat intelligence, si je scanne les dépendances en continu, si j’ai des gens d’astreinte à trois heures du matin et une chaîne d’escalade qui fonctionne, je découvrirai les incidents plus tôt. Et si je les découvre plus tôt, le chronomètre part plus tôt. Mon confrère qui n’a rien de tout cela ne sait rien, et aucune horloge ne semble démarrer.

En une ligne : plus vous êtes bon pour savoir, plus vite vous devenez responsable de ce que vous savez.

C’est le paradoxe de l’observabilité régulée, et ce n’est pas un exercice de séminaire. Une régulation mal construite produit exactement cette incitation perverse, et l’incitation ne se manifeste jamais sous forme explicite. Aucun conseil d’administration ne délibère « nous préférons ne pas savoir ». Elle se manifeste dans les reports : le projet d’intégration des journaux applicatifs au SIEM qui glisse de trimestre en trimestre, le flux de threat intelligence qu’on ne renouvelle pas parce qu’il génère trop de faux positifs, l’astreinte de nuit qui reste informelle, le critère d’ouverture d’un incident rédigé de façon si exigeante qu’il repousse de plusieurs heures le moment où quelqu’un peut dire que c’est vraiment arrivé. Chacune de ces décisions a une justification technique ou budgétaire raisonnable. La somme est une cécité organisationnelle, construite par accumulation et non par choix.

Qui travaille depuis assez longtemps dans la compliance sait que c’est ainsi que les organisations se défendent réellement. Non pas en mentant. En se structurant pour n’atteindre jamais le point où la vérité devient un fait déclarable.

Il faut donc se demander si la stratégie fonctionne.

Le RGPD, qui a huit ans d’avance sur ce terrain, a déjà répondu non, et la réponse est plus dure qu’on ne la cite d’habitude. Le considérant 87 ne dit pas que le responsable doit notifier quand il sait. Il dit qu’il convient de vérifier si les mesures techniques et organisationnelles appropriées ont été mises en œuvre pour établir immédiatement si une violation a eu lieu. L’objet du contrôle n’est pas la notification. C’est la capacité de s’apercevoir. L’EDPB, au paragraphe 37 des lignes directrices, écrit que le responsable doit donc disposer de processus internes lui permettant de détecter et de traiter une violation, et ajoute que lorsqu’une violation est détectée, il importe qu’elle soit remontée au niveau de direction approprié, afin d’être traitée et, si nécessaire, notifiée. Le paragraphe 126 boucle la boucle : si la notification arrive en retard, le responsable doit être en mesure de fournir les raisons de ce retard, et la documentation correspondante sert à démontrer que le retard était justifié et non excessif.

On ne peut pas fournir la raison d’un retard sans disposer d’une chronologie. Et on ne dispose pas de la chronologie d’un événement que ses propres systèmes n’ont jamais enregistré.

Avec le CRA, ce principe prendra une forme encore plus structurelle, et la date à surveiller n’est pas celle de vendredi dernier. C’est le 11 décembre 2027, quand le règlement deviendra pleinement applicable et avec lui l’annexe I, partie II, qui énumère les exigences de gestion des vulnérabilités. Le fabricant devra identifier et documenter les vulnérabilités et les composants de ses produits, en établissant une SBOM lisible par une machine couvrant au minimum les dépendances de premier niveau. Il devra appliquer des tests et des revues de sécurité efficaces et réguliers. Il devra adopter une politique de divulgation coordonnée et fournir une adresse de contact pour les signalements. Et l’article 13, paragraphe 7, lui impose de documenter systématiquement les aspects de cybersécurité pertinents de ses produits, y compris les vulnérabilités dont il prend connaissance et toute information pertinente fournie par des tiers.

Mises bout à bout, ces obligations ne disent pas au fabricant qu’il doit tout savoir. Elles lui disent qu’il doit tenir un inventaire à jour de ce qu’il a construit, un canal déclaré par lequel les signalements lui parviennent, un processus qui les prend en charge et une trace écrite de ce qu’il a su et de qui le lui a dit. J’ai écrit ailleurs que la compliance européenne échoue par manque d’inventaire bien plus que par manque de normes. Ici la chose s’élargit : l’inventaire ne porte plus seulement sur les composants. Il porte sur les chemins par lesquels les nouvelles concernant ces composants parviennent à quelqu’un qui peut décider.

Le législateur n’offre donc pas vraiment le choix entre savoir et ne pas savoir. Il commence à réguler la capacité de savoir, ce qui est une autre chose, et bien plus intrusive.

Avant le comportement, il y a la connaissance

C’est l’étape qui fait que cet essai ne porte pas sur le CRA.

Pendant des décennies, la compliance a été racontée comme une relation à deux termes, entre comportement et règle. Une norme établit ce que vous devez faire, l’organisation le fait, puis démontre qu’elle l’a fait. Tout l’appareil de l’audit, de la certification, de la preuve documentaire naît de ce schéma.

Un troisième terme émerge dans le numérique, et il se place avant les deux autres.

On ne peut pas remédier à une vulnérabilité qu’on n’a pas identifiée. On ne peut pas notifier un incident que personne n’a qualifié comme tel. On ne peut pas évaluer un risque si l’information nécessaire est restée dans le log d’un système que personne ne regarde, ou dans la session privée d’un outil qu’une seule personne utilise. La règle dit quoi faire, mais la possibilité même de l’appliquer dépend d’un fait que la règle ne décrit pas : que l’organisation en soit venue à savoir.

La qualité de la compliance devient donc une fonction de la qualité de l’appareil cognitif de l’organisation. Pas de sa bonne foi, pas de son budget juridique, pas du nombre de politiques qu’elle a approuvées.

Cela explique, au passage, pourquoi tant de programmes de conformité produisent du papier et pas de la sécurité. Ils décrivent avec une grande précision les comportements dus et ne décrivent jamais les chemins par lesquels l’organisation découvre qu’elle doit les tenir.

Quand un agent sait-il ?

Jusqu’ici, le problème est aussi vieux que les organisations. Voici ce qui le rend urgent.

Dans cette liste, la Commission cite le monitoring interne, le scanning et la télémétrie comme canaux par lesquels un fabricant prend connaissance d’un problème. C’est écrit en pensant à des systèmes qui produisent des signaux : un honeypot qui s’allume, une règle qui se déclenche, un compteur qui franchit un seuil. Le signal va ensuite à une personne, et la personne comprend.

Nous entrons rapidement dans un monde où ces systèmes ne se contentent plus de signaler.

Un agent peut lire un CVE publié il y a dix minutes, vérifier si la dépendance concernée figure dans la SBOM du produit, ouvrir le dépôt, contrôler si la fonction vulnérable est réellement atteignable depuis le code que nous livrons, corréler cela avec les soixante-douze dernières heures de télémétrie de production, et ouvrir un ticket avec une conclusion rédigée en langage naturel : cette vulnérabilité semble exploitée sur cette version du produit, et voici les éléments.

Ce n’est pas un scénario de frontière. C’est un après-midi de travail avec les outils dont nous disposons aujourd’hui.

Quand l’organisation sait-elle ?

Quand l’agent produit la conclusion ? Quand un être humain la lit ? Quand quelqu’un l’approuve ? Quand le ticket passe de triage à confirmed ? Quand elle atteint la boîte que l’entreprise a publiquement déclarée comme son canal de sécurité, c’est-à-dire ce point de contact unique que l’annexe I lui impose d’avoir ?

Je n’ai pas la réponse juridique et je me méfie de qui la donne aujourd’hui avec assurance. Je la laisse ouverte parce qu’elle l’est vraiment, et parce qu’il n’y aura pas de jurisprudence là-dessus avant des années.

Ce que je peux dire, c’est que l’IA ne crée pas le problème. Elle le rend impossible à repousser. Nous avons toujours traité les systèmes automatiques comme des instruments par lesquels les personnes acquièrent de la connaissance : le capteur détecte, l’humain sait. Avec les agents, nous commençons à construire des systèmes qui rassemblent des éléments, formulent des inférences, évaluent leur propre confiance et décident seuls que quelque chose mérite attention. La frontière entre « la machine a détecté » et « l’organisation sait » deviendra de moins en moins nette, et elle le deviendra vite.

D’où une conséquence concernant la gouvernance interne de l’IA, et qui me paraît sous-estimée.

Gouverner un agent ne consistera pas seulement à établir ce qu’il peut faire. Il faudra établir quels faits il est autorisé à faire devenir de la connaissance organisationnelle.

Un agent qui trouve une vulnérabilité et laisse le résultat dans la session privée d’un développeur, c’est une chose. Le même agent, même modèle, même prompt, intégré à la chaîne de l’entreprise de façon à ouvrir automatiquement un incident de sécurité horodaté, c’en est une autre. Techniquement, c’est le même système. Institutionnellement, ce sont deux entités différentes, parce que la seconde peut faire partir un délai et la première non.

J’ai écrit il y a quelque temps que l’autorité arrive avant l’intelligence, et qu’un agent est intéressant non parce qu’il fait des choses tout seul, mais parce que quelqu’un lui a concédé le droit de les faire. C’est la même idée appliquée au savoir plutôt qu’à l’agir. Le droit de déclarer, à l’intérieur d’une organisation, qu’une chose est vraie, est une délégation comme les autres, et jusqu’à hier nous ne l’avions jamais écrite nulle part parce que seules les personnes l’avaient.

Il y a aussi un revers positif, et il faut le dire. Si le coût marginal d’investiguer un signal s’effondre, la quantité d’événements qu’une organisation peut se permettre de comprendre augmente. Nous n’aurons pas seulement plus de code écrit par des machines. Nous pourrions avoir des organisations bien plus sensibles à leur environnement, capables de prendre au sérieux des signaux que l’on ferme aujourd’hui sans les lire parce que les lire coûte quarante minutes d’une personne compétente.

C’est une bonne chose. Et cela produit un changement presque contre-intuitif pour ceux qui font mon métier : le problème ne sera plus de construire des outils assez intelligents pour voir les risques. Ce sera de concevoir le processus par lequel ce qu’ils voient acquiert un statut organisationnel.

Le système nerveux d’une institution

La métaphore que j’utilise quand je dois expliquer cela à un client est anatomique, et elle a le mérite de casser d’emblée la rhétorique du « il faut plus de monitoring ».

Une entreprise n’est pas un cerveau. C’est un organisme distribué. Elle a des récepteurs périphériques, des voies de transmission aux latences différentes, des centres où les signaux sont intégrés, et des mécanismes par lesquels un stimulus devient un réflexe, une douleur, ou une décision consciente.

La mauvaise gouvernance, dans ce tableau, ne consiste pas seulement à avoir peu de récepteurs. Elle peut consister en un système nerveux qui sent parfaitement mais transmet lentement, et arrive au centre quand le dommage est fait. Ou en un système qui produit tant de signaux qu’il ne distingue plus la douleur du bruit, ce qui est l’état clinique de bon nombre de SOC que j’ai vus.

Si un SOC reçoit dix mille alertes non pertinentes par semaine, l’organisation n’est pas mieux informée. Elle a seulement plus de bruit, et elle s’est en prime construit une raison parfaitement défendable de ne pas regarder la dix mille unième.

La qualité épistémique ne se confond pas avec la quantité de données disponibles. C’est la capacité de transformer des preuves en croyances assez fiables pour justifier une action. Ce sont deux choses distinctes, et la seconde ne s’achète pas.

Savoir assez pour agir

La référence de l’EDPB au degré raisonnable de certitude est utile précisément parce qu’elle reconnaît ce point et le dit en une ligne. La connaissance juridiquement pertinente ne se confond pas avec la certitude absolue. Les mêmes lignes directrices précisent qu’une brève période d’enquête initiale est légitime et que, durant celle-ci, le responsable ne peut être considéré comme ayant pris connaissance, mais elles ajoutent que l’enquête doit commencer au plus tôt et établir, avec un degré raisonnable de certitude, si une violation a eu lieu. Le détail vient après.

Cela met le doigt sur un fait culturel qui pèse, à mon avis, plus que la norme.

Beaucoup d’organisations ont bâti leurs processus de décision sur une prémisse implicite de certitude. Avant de faire remonter un problème, il faut être sûr. Avant d’ouvrir un incident, il faut des confirmations. Avant d’impliquer le juridique ou la direction, il faut savoir exactement ce qui s’est passé, parce que se présenter avec une hypothèse fausse coûte de la crédibilité, et la crédibilité est la monnaie dans laquelle les carrières sont payées.

Les régimes de signalement que l’Europe a construits depuis huit ans sont conçus précisément pour fonctionner avant que cette certitude existe. C’est pourquoi le CRA et NIS2 séparent l’early warning de la notification ultérieure : les vingt-quatre premières heures sont, par construction, des heures d’information incomplète, et le contenu exigé dans l’early warning le reflète. Pour un incident grave, le CRA demande, sous 24 heures, au moins si l’on soupçonne qu’il a été causé par des actes illicites ou malveillants. Au moins si on le soupçonne. Pas ce qui s’est passé.

Le droit demande une chose que beaucoup d’entreprises trouvent culturellement très difficile : être capable de dire, et de l’écrire à une autorité, qu’on en sait assez pour agir et pas assez pour tout savoir.

C’est une forme de maturité épistémique, et elle est rare.

Dans mon expérience, le point de rupture n’est presque jamais technique. Sur un projet complexe auquel j’ai travaillé, avec une chaîne de responsabilité répartie entre plusieurs prestataires, le problème n’a jamais été l’absence de données : les données étaient là, avec leurs horodatages, depuis des mois. Le problème était que la même anomalie changeait de nature selon qui la regardait. Pour le développeur, c’était un bug à mettre en backlog. Pour celui qui tenait les opérations, une alerte récurrente avec un runbook. Pour le responsable sécurité, un incident possible, mais « possible » ne suffisait pas à en ouvrir un. Pour la direction, cela n’existait pas tant qu’une communication formelle n’arrivait pas, et la communication formelle exigeait que quelqu’un, avant, ait appelé la chose un incident.

La réalité ne changeait pas en franchissant ces frontières. Ce qui changeait, c’était le statut que l’organisation lui attribuait, et le temps écoulé entre une frontière et la suivante était le véritable risque. Je n’ai pas de noms à citer et ce n’est pas nécessaire : quiconque a travaillé dans une structure de plus de vingt personnes a déjà reconnu la scène.

Les objections qui méritent une réponse

Deux, et la seconde m’inquiète bien plus que la première.

La première est que je lis trop de choses dans un mot. L’awareness est une technique législative ordinaire, le législateur européen n’a jamais entendu construire une théorie de la connaissance organisationnelle, et lui prêter des intentions philosophiques est le vice classique de qui commente les normes sans les rédiger.

L’objection est fondée et je l’accepte entièrement. C’est justement pourquoi il n’est pas nécessaire de prêter au législateur la moindre intention. Il suffit d’observer les effets organisationnels produits par des textes différents qui emploient systématiquement le même déclencheur, se superposent sur les mêmes acteurs et exigent chacun une déclaration datée. Une entreprise européenne qui produit du logiciel finira avec trois horloges qui partent de la connaissance et une seule organisation chargée de les déclencher. À ce moment-là, la question de savoir comment on sait cesse d’être philosophique et devient un problème de conception, quoi qu’ait eu en tête Bruxelles.

La seconde objection est plus sérieuse. Formaliser excessivement la connaissance peut créer des organisations défensives, où chaque information est classée, enregistrée, transmise au juridique et traitée comme une pièce à conviction, avec pour effet de dégrader précisément la capacité de réagir. Qui a vu ce qu’est devenue la médecine défensive sait que le risque n’est pas théorique. Et un ingénieur qui sait que son commentaire sur un ticket pourrait être lu par une autorité dans trois ans écrira de moins bons commentaires, pas de meilleurs.

Cette objection est vraie elle aussi, et je n’ai pas de réponse qui l’annule. J’ai seulement une distinction, dont je me sers comme critère quand je dois concevoir ces processus.

L’objectif n’est pas de bureaucratiser le savoir. C’est de réduire l’ambiguïté aux quelques passages où l’ambiguïté empêche une décision rapide. Ils sont peu nombreux et se comptent : qui a l’autorité de déclarer un incident ouvert, sous quel délai un signal non évalué doit tout de même être regardé par quelqu’un, quelle boîte est le canal officiel et qui la lit la nuit, ce qui se passe quand la personne qui doit décider ne répond pas. Quatre ou cinq points d’articulation. Tout le reste peut et doit rester informel, car une organisation où chaque conversation est un acte cesse de penser.

La différence entre les deux est celle qui sépare un système nerveux d’un plâtre.

Qui transforme une possibilité en un fait

Vendredi, l’Europe n’a pas simplement ouvert un portail de signalement.

Elle a rendu visible un fait qui accompagnera de plus en plus la régulation technologique. Une entreprise qui construit des produits numériques doit être capable de s’observer elle-même. Elle doit savoir quels yeux elle possède, quels signaux elle tient pour fiables, où s’arrête l’incertitude qu’elle peut tolérer et qui, à quel moment, transforme une possibilité en un fait dont l’organisation est prête à répondre.

Pendant des années, nous avons lu l’accountability numérique comme la capacité d’expliquer ce que nous avons fait. Le niveau suivant est la capacité d’expliquer quand nous en avons su assez pour le faire.

La nature de la preuve change avec elle. Le rapport final sur l’incident ne suffit plus, celui qui est bien écrit, avec la chronologie reconstruite après coup et les leçons apprises. Deviennent pertinents les vrais horodatages, les escalades, les tickets, les journaux de décision, la provenance de l’information, la classification initiale et les changements d’appréciation. Non pas parce que Bruxelles aime les logs. Parce que sans cette chaîne il est impossible de reconstituer l’histoire épistémique d’une organisation, et une organisation qui ne peut pas la reconstituer ne peut pas non plus se défendre.

Il ne s’agit pas de démontrer que vous avez réagi. Il s’agit de démontrer que vous n’avez pas eu besoin de feindre de ne pas savoir.

Le contraire de la compliance n’est pas seulement de violer une règle. Ce peut être de construire une organisation incapable de savoir quand elle la viole.

Les institutions, comme les personnes, ne sont pas responsables seulement de ce qu’elles savent. Dans certaines conditions, elles deviennent responsables de la manière dont elles ont choisi de connaître. Un père qui ne demande pas, un médecin qui ne lit pas l’examen, une entreprise qui ne branche pas le log : le droit et la morale commune ont toujours su que l’ignorance peut être une construction, et que la construire est déjà une décision.

La technologie rend simplement cette vieille intuition beaucoup plus concrète, et beaucoup plus datable.

L'auteur

Andrea MargiovanniCompliance UE

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 →