La sécurité au bout de la prise électrique...

Pourquoi le dernier point d'application de la politique de sécurité que nous devons implémenter est la prise de courant.

Ce que le Cube sait de vos machines

16/09/2026

Un compteur communicant coûte trente euros et mesure très correctement ce qu'une machine consomme, mais il ne sait pas qui était dans la pièce. Notre Cube croise la consommation, les présences enrôlées et les capteurs que vous avez déjà. Il produit ce qu'aucune des trois sources ne donne seule : un journal d'usage attribué, sans jamais rien couper. Mesure, présence, corrélation : les rappors d'activité au fil de l'eau Un module du commerce clipsé sur un câble mesure très correctement une consommation. Il coûte quelques dizaines d'euros, sa précision est suffisante. Un tel module ne sait rien de qui se trouvait dans la pièce, ni de ce qu'il était normal de consommer ce jour-là, ni de ce qui doit déclencher une alerte. Ce que produit le Cube est d'une autre nature : un rapport d'activité attribué, des alertes motivées, et un journal signé exploitable en audit. Les capteurs en sont la matière première, pas le produit. C'est aussi pourquoi nous ne cherchons pas à fabriquer les capteurs. Nous cherchons à les lire pour compléter la décision du Cube : journaliser une action autorisée, alerter d'un usage inadéquat ou d'une intrusion, et en dernier recours, mettre en protection les équipements par une coupure définie selon des règles de sûreté et de sécurité. Trois sources d'entrée Les effecteurs , d'abord. Ce sont les modules que nous posons nous-mêmes sur l'alimentation des équipements. Ils ont une particularité utile : ils mesurent et ils commandent au même endroit . Ce n'est pas une commodité, c'est ce qui permet de passer de l'observation à l'action sans rien réinstaller le jour où l'exploitant le décide. La présence , ensuite, établie par le Cube à partir des badges, téléphones ou objets connectés enrôlés qui entrent et sortent du local et indiquent la présence d'utilisateurs connus. Et vos capteurs , si nécessaire. C'est le point que nous avons longtemps sous-estimé dans notre propre communication. Le Cube sait lire des sources qu'il n'a pas installées : sondes de température et d'hygrométrie, compteurs d'énergie existants interrogés en Modbus, contacts de porte, débitmètres, points d'une gestion technique de bâtiment déjà en place. Sur un site instrumenté, une bonne partie de la matière première est déjà là , mais n'a jamais été croisée avec autre chose. Un relevé de température qui vit dans un tableau de supervision et un registre d'entrées qui vit dans un classeur ne se sont jamais rencontrés. Pourquoi contrôle et mesure au même endroit Un module quadruple sur rail DIN, installé à l'intérieur de l'armoire électrique, apporte quatre choses d'un coup : Quatre circuits pour un seul appareil. Mesure et commande sur quatre départs, avec un seul point de raccordement et un seul appareil à enrôler. L'économie est réelle sur un parc. Mesure et coupure indissociables. La même électronique constate et agit. Il n'existe pas de configuration où l'on mesure un circuit et où l'on commande le voisin : le rapport et l'action portent sur le même objet, par construction. L'appareil est hors de portée. C'est le point le plus important. Un module posé en évidence sur une prise peut être débranché, réinitialisé, emporté. Le même module derrière la porte fermée d'une armoire hérite de la protection de l'armoire. Le risque résiduel que nous documentons ailleurs — une réinitialisation d'usine rétablit le comportement d'origine du module — se referme largement quand l'accès au module suppose déjà d'ouvrir un capot fermé à clé. Et la machine n'est pas touchée. L'armoire dans laquelle nous posons le module est l'armoire de distribution, pas celle de la machine. Nous restons à la frontière : le départ qui alimente l'équipement, pas l'équipement. Ce qu'une courbe de puissance raconte Une machine ne consomme pas de façon uniforme, et ses paliers sont lisibles. À l'arrêt complet , la consommation est nulle ou quasi nulle. C'est le seul état sans ambiguïté. En veille , elle est faible mais non nulle : électronique de commande, afficheur, ventilation d'armoire. Palier stable, propre à chaque machine, et c'est celui qu'on confond le plus souvent avec l'arrêt — une machine « éteinte » qui consomme quarante watts en permanence est une machine allumée. Au démarrage , un moteur appelle un courant nettement supérieur à son régime nominal pendant une fraction de seconde. Cette pointe est une signature : elle date le démarrage à la seconde près et distingue un vrai démarrage d'une sortie de veille. En fonctionnement à vide , la machine tourne sans travailler. En charge , elle consomme davantage, et l'écart est généralement franc. De ces paliers découlent quatre informations exploitables sans interprétation : nombre de démarrages, durée sous tension, durée en charge, énergie consommée. La différence entre les deux durées est souvent la donnée la plus parlante. Une machine sous tension huit heures et en charge quarante minutes n'est pas le même objet de gestion selon celle qu'on regarde. Ce que le croisement ajoute Quatre situations se dégagent, et chacune appelle une lecture différente. Usage attribué. La machine fonctionne, une seule personne enrôlée est présente pendant toute la période. Cas nominal, qui produit une ligne de journal exploitable : qui, quelle machine, de quand à quand, combien d'énergie. Usage non attribué. La machine fonctionne, personne n'est détecté. Trois explications possibles, à garder toutes les trois : un cycle programmé qui n'exige personne, une personne présente sans identifiant enrôlé, ou un démarrage à distance. Ce n'est pas une alerte en soi — c'est une ligne qui demande une explication, et elle est plus fréquente qu'on ne l'imagine. Présence sans usage. Quelqu'un est venu, la machine n'a pas démarré. Banal, mais utile pour distinguer une visite d'une intervention. Changement d'état pendant une présence. Le cas le plus intéressant. Personne ne voit un thermostat tourner. Mais si les résistances de chauffage se mettent à consommer davantage pendant qu'une personne identifiée était sur place, et que rien dans les conditions extérieures ne l'explique, une consigne a bougé. Et c'est précisément là que vos capteurs existants font la différence. Avec la seule consommation, l'inférence est indirecte et fragile. Avec en plus une sonde de température intérieure — que vous avez probablement déjà — le raisonnement devient franc : la température de consigne a manifestement changé, à telle heure, et voici qui était là. On passe d'une hypothèse à un constat. Prise de références Une consommation élevée ne signifie rien en soi. Un chauffage consomme davantage par une nuit froide, une pompe quand le niveau baisse, un compresseur en été. Le signal exploitable n'est pas la consommation, c'est l'écart entre la consommation observée et celle qu'on attendait dans ces conditions-là. Cela impose une phase préalable : mesurer le comportement normal de chaque équipement pendant plusieurs semaines, avec ses variations saisonnières et hebdomadaires. C'est ce que fait le mode Observation, et c'est pour cela qu'il dure : un modèle de référence construit sur trois jours ne vaut rien. Un système qui alerte sur un seuil absolu produira des fausses alertes tout l'hiver et sera débranché avant le printemps. C'est aussi une raison supplémentaire de lire vos capteurs plutôt que la seule consommation : une référence qui intègre la température extérieure est incomparablement plus fine qu'une référence calendaire. L'échelle d'inférence La grille que nous tenons à poser explicitement, parce que c'est là que se situe l'écart entre un usage honnête et un usage abusif de ces données. Niveau Exemple Statut Mesuré 1 240 W à 14 h 32 ; badge B présent de 14 h 10 à 15 h 05 ; 19,4 °C intérieurs Donnée brute, non discutable Établi La machine a été sous tension de 14 h 28 à 15 h 02, dont 22 minutes en charge Déduction directe des paliers Inféré, confiance élevée La machine a été utilisée, pas seulement allumée Repose sur un seuil de charge calibré par équipement Inféré, confiance modérée Une consigne a été modifiée pendant cette présence Repose sur un écart à la référence ; devient une confiance élevée si un capteur de température confirme Non inférable Ce que la personne a fait, ce qui a été produit, si c'était autorisé, qui exactement a agi si plusieurs personnes étaient présentes À ne jamais présenter comme une conclusion La dernière ligne est la plus importante, et c'est celle qu'un fournisseur est le plus tenté de franchir. Un rapport qui affirme « Untel a modifié le thermostat » ment. Ce qu'il peut écrire honnêtement : « la consommation de chauffage s'est écartée de la référence de 34 % à 14 h 40, la température intérieure de consigne a augmenté de 2 °C sur la même période, les personnes présentes étaient A et B. » La différence n'est pas cosmétique. La première formulation ne survit pas à une contestation ; la seconde, oui. Ce que le Cube ne dira jamais La puissance dit que la machine a tourné, pas ce qu'elle a fait. Aucune mesure électrique ne distingue une pièce conforme d'un rebut. Un circuit partagé brouille l'attribution. Trois machines sur le même départ, vous mesurez leur somme. C'est d'ailleurs l'argument concret en faveur d'un module à quatre voies plutôt que d'un module par tableau. Deux personnes présentes, aucune attribution individuelle. C'est structurel, et c'est sans doute une bonne chose : cela rend le dispositif inutilisable pour du suivi individuel de performance. Un badge prouve un badge. Un badge prêté produit une attribution fausse, datée et signée. Et la référence peut être trompée. Quelqu'un qui connaît le système peut modifier une consigne progressivement, sur plusieurs semaines, de sorte que chaque écart reste sous le seuil. Nous ne prétendons pas détecter cela. La question juridique, qui n'est pas la même qu'avant Mesurer qu'une machine a fonctionné est une donnée technique. Mesurer qu'une personne nommée était présente est une donnée personnelle. Croiser les deux pour en déduire ce qu'une personne a fait et pendant combien de temps relève du suivi de l'activité des salariés , et ce n'est pas le même régime. Ce qui rend un tel traitement légitime, c'est sa finalité . Refacturer l'usage d'un atelier partagé est une finalité claire et proportionnée. Alerter sur un fonctionnement hors créneau également. Établir un classement de productivité individuelle ne l'est pas, et un système qui le permettrait n'aurait pas dû être conçu ainsi. Trois conséquences, tirées en conception plutôt qu'en politique d'usage : L'agrégat est le mode par défaut. Les rapports sont produits par machine, par période et par organisation. L'attribution nominative n'apparaît que sur déclenchement défini — usage hors créneau, anomalie, demande d'audit motivée. Les durées de conservation sont distinctes. Celle des rapprochements nominatifs est courte ; celle des données de consommation, qui n'ont rien de personnel une fois détachées de la présence, suit vos besoins de gestion. Et le dispositif s'annonce. L'installation d'un système d'observation dans un local où travaillent des salariés relève de l'information et de la consultation du CSE, avant l'installation et non après. Pourquoi commencer par là Pour un grand nombre d'exploitants, ce mode est déjà un résultat suffisant , sans aller jusqu'au contrôle d'accès en marche / arrêt. Ils n'ont jamais eu besoin qu'une machine s'arrête. Ils avaient besoin de savoir qui l'avait démarrée, et de pouvoir le prouver dix-huit mois plus tard. Cela a une conséquence pratique agréable : un déploiement en observation ne peut, par construction, pas arrêter votre production. La question « et si votre boîtier se trompe ? » disparaît, et avec elle l'essentiel de la difficulté à faire accepter un pilote. Ce que vous obtenez malgré tout : un journal d'usage attribué, une détection des fonctionnements hors créneau, une base de refacturation, et le taux réel d'événements par machine sur votre site — la seule donnée permettant de décider, plus tard et en connaissance de cause, s'il vaut la peine d'armer quoi que ce soit. Et si vous décidez un jour de le faire, rien n'est à réinstaller. C'est le même appareil, dans la même armoire, qui mesurait déjà.

Accès distant et accès physique : deux problèmes différents

12/09/2026

Le même technicien, les mêmes effets, mais deux gestions distinctes Sécuriser l'accès distant à un équipement industriel et contrôler l'accès physique à ce même équipement sont deux problèmes différents, et aucun des deux ne couvre l'autre. Un bastion d'outils cyber protège la session du technicien qui se connecte depuis un autre site. Il ne dit rien du même technicien debout devant l'armoire le mardi suivant. Ces deux sujets sont régulièrement confondus et la confusion coûte cher : on achète l'un en croyant traiter l'autre. Voici ce que chacun couvre exactement. Série « Le modèle Purdue et l'accès physique », 4 sur 4 Le modèle Purdue, en dix minutes ( Seriez-vous Purdue ? ) Ce que toutes les critiques de Purdue ont en commun ( Purdue de vue ) Le conduit que personne ne dessine ( Le maillon Purdue ) Accès distant et accès physique : deux problèmes différents ← vous êtes ici Ce que couvre un accès distant sécurisé Commençons par le décrire correctement, parce que c'est un métier exigeant et bien décrit par le modèle. Un dispositif d'accès distant sérieux (bastion, passerelle applicative, courtier d'accès) traite une chaîne complète et cohérente. L'identité du demandeur est fédérée avec l'annuaire de l'exploitant ou celui du prestataire, avec authentification à plusieurs facteurs. On sait qui se connecte, et la preuve est cryptographique. L'accès est accordé à la demande et pour une durée bornée. Le compte du constructeur n'existe pas en permanence ; il est activé pour une intervention, sur un équipement désigné, pendant une fenêtre définie. La session est encadrée. Enregistrement complet de ce qui a été fait, parfois avec possibilité de la reprendre en direct ou de la couper. C'est ce que la gestion des accès à privilèges apporte de plus précieux : la trace exploitable. Le chemin est maîtrisé. La connexion ne traverse pas l'architecture de bout en bout : elle s'arrête dans la zone démilitarisée du niveau 3,5, où une rupture protocolaire s'opère, et un rebond prend le relais vers le système cible. La connectivité sortante uniquement, recommandée tant par l'ANSSI que par la CISA, complète le dispositif. Et le périmètre est restreint. Le technicien n'accède qu'à l'équipement pour lequel il est mandaté, pas au réseau de l'atelier. C'est solide, et un site industriel qui n'a pas cela a un problème plus urgent à régler que celui dont parle cet article. Ce qu'il ne couvre pas Reprenons maintenant le même technicien, dans une situation différente. Il prend l'avion et arrive sur site. Il ouvre l'armoire, branche son portable sur le port de programmation en façade, et fait exactement ce qu'il aurait fait à distance, parfois même avec le même logiciel, avec les mêmes droits sur l'automate, et la même capacité de reprogrammation. Le bastion n'a rien vu. Il n'était pas sur le chemin. Ce n'est pas un défaut du produit d'accès distant : il fait exactement ce pour quoi il a été conçu, et le lui reprocher serait absurde. C'est une question de périmètre. La gestion des accès à privilèges couvre l'accès distant du constructeur mais son accès physique (même homme, même service) n'est couvert par aucun dispositif technique , même lorsqu'une exigence normative le vise Et ce n'est pas une hypothèse de laboratoire. Sur la plupart des sites, l'intervention physique reste le chemin majoritaire de modification d'un équipement de niveau 0 ou 1, parce que ces équipements ne se paramètrent pas autrement. La comparaison, ligne par ligne Accès distant sécurisé Accès physique contrôlé Le sujet Une session ouverte depuis l'extérieur Une personne présente devant l'équipement Le chemin Un conduit réseau, dessiné dans l'architecture Une porte, dessinée nulle part Le point d'application Bastion, passerelle, rupture protocolaire au niveau 3,5 Effecteur sur l'alimentation ou l'interface physique La preuve d'identité Fédération avec un annuaire, plusieurs facteurs Défi cryptographique sur un élément sécurisé porté par la personne La preuve d'usage Enregistrement de session Journal signé des mises sous tension, des branchements de câbles et des refus La dépendance réseau Totale, par nature Nulle : la décision est locale Ce qu'il voit du technicien sur site Rien Tout Ce qu'il voit du technicien à distance Tout Rien Les deux dispositifs sont exactement complémentaires, et strictement disjoints. Quand vous sécurisez l'un, vous ne gagnez pas l'autre en effet bonus (un technicien présent devant la machine n'ouvre pas une session distante pour y accéder : il utilise le port en façade, et souvent d'autres accès encore, ce qui aggrave le problème plutôt que de le résoudre). Pourquoi la confusion existe Trois raisons, dont deux sont légitimes. Le vocabulaire est identique. « Contrôle d'accès », « identité », « autorisation », « privilège », « session », « révocation » : les deux domaines emploient les mêmes mots pour des objets différents. Un acheteur qui lit deux plaquettes voit deux fois la même chose. Le modèle Purdue ne les distingue pas , puisqu'il ne décrit pas la personne du tout. Comme nous l'avons vu dans le troisième article de cette série (le maillon Purdue), seul l'un des deux chemins figure sur le schéma. L'autre n'a donc pas de nom, et ce qui n'a pas de nom ne se compare pas. Et il y a une raison moins avouable : il est commercialement tentant de laisser croire qu'un produit couvre les deux. Personne ne ment vraiment, mais un tableau de fonctionnalités qui coche « contrôle d'accès aux équipements industriels » sans préciser lequel laisse l'acheteur remplir le blanc tout seul. Le cas qui les réunit Il existe une situation où les deux dispositifs se rejoignent, et elle mérite d'être posée parce qu'elle est fréquente. Le technicien du constructeur intervient à distance pour un diagnostic, conclut qu'un composant doit être remplacé, et vient sur site la semaine suivante. Même intervention, même ordre de travail, même personne, deux chemins. Un exploitant qui gouverne bien ce cas devrait pouvoir répondre à une question simple : l'ordre d'intervention est-il le même objet dans les deux systèmes ? Autrement dit, la fenêtre autorisée, l'équipement désigné et l'habilitation vérifiée sont-ils cohérents entre la session distante et la venue sur site, ou s'agit-il de deux autorisations sans lien ? Dans presque tous les cas que nous connaissons, ce sont deux autorisations sans lien. Le bastion connaît un compte technique et une fenêtre horaire et l'accueil du site connaît un nom et un badge visiteur. Rien ne rapproche les deux, et personne ne s'en aperçoit tant qu'un incident ne survient pas. C'est probablement là que se trouve le vrai travail des prochaines années, et il ne sera fait ni par les acteurs de l'accès distant seuls, ni par nous seuls. Ce que nous en disons Nous ne faisons pas d'accès distant sécurisé et nous n'avons pas l'intention d'en faire. C'est un métier exigeant, occupé par des acteurs compétents, et la frontière entre niveaux 3 et 4 reste selon toute vraisemblance le contrôle le plus conséquent de votre architecture. Nous faisons l'autre chemin : celui de la personne présente, sur des équipements qui n'ont ni écran, ni identité, ni réseau, avec une décision rendue localement même quand plus rien ne répond.

Le maillon Purdue

11/09/2026

Si on nous demande où notre système se place dans le modèle Purdue, la réponse est simple : nulle part, et c'est exactement pour résoudre ce manque d'existence qu'il a été créé. Le modèle Purdue n'a pas de niveau pour la personne Un technicien du constructeur qui ouvre une armoire et branche son portable sur le port de programmation d'un automate n'a franchi aucun pare-feu, aucune zone démilitarisée et aucune règle de segmentation. Il est entré directement au niveau 1 . Sa liaison répond pourtant à ce qu'IEC 62443-3-2 appelle un chemin de communication entre zones même si aucune architecture ne la dessine. Série « Le modèle Purdue et l'accès physique », 3 sur 4 Le modèle Purdue expliqué en dix minutes : Seriez-vous Purdue ? Ce que toutes les critiques de Purdue ont en commun : Purdue de vue Le conduit que personne ne dessine ← vous êtes ici Accès distant et accès physique : deux problèmes différents Un mardi matin ordinaire Un technicien du constructeur arrive sur site à neuf heures. Il se présente à l'accueil, on lui remet un badge visiteur, un responsable de maintenance l'accompagne jusqu'à l'atelier B. Il ouvre l'armoire d'un variateur avec la clé triangle qui traîne dans la boîte à outils, branche son portable sur le port de programmation en façade, ouvre son logiciel constructeur, modifie deux paramètres de rampe d'accélération, téléverse, referme l'armoire. Il repart à onze heures trente. Reprenons son trajet du point de vue de l'architecture de sécurité. Il n'a franchi aucun pare-feu. Il n'a pas traversé la zone démilitarisée du niveau 3,5, ni ouvert de session sur un bastion. Aucune règle de micro-segmentation ne s'est appliquée à lui. Aucune passerelle unidirectionnelle ne s'est interposée. Aucun système de détection n'a vu passer un paquet inhabituel, puisque son portable et l'automate ont dialogué en tête-à-tête sur un port série, hors de tout réseau. Il est entré directement au niveau 1, en franchissant une porte, pas un port. Et quasiment personne ne pourrait aujourd'hui répondre à ces trois questions élémentaires : quels paramètres exactement ont été modifiés, sur quel fondement contractuel, est-ce bien lui qui les a modifiés. Pourquoi le modèle ne le voit pas Ce n'est pas un oubli du consortium de Purdue, et il serait injuste de le présenter ainsi. Le modèle a été conçu pour organiser les flux de données d'une usine informatisée. Chacun de ses niveaux met en relation un système avec un autre système . Le niveau 0 est le process physique : capteurs et actionneurs. Le niveau 1 est le contrôle de base : automates et calculateurs. Le niveau 2 supervise, le niveau 3 gère les opérations, ... Nulle part il n'y a de niveau pour l'humain présent sur le terrain, parce que ce n'était pas la question qu'on posait au modèle en 1992. L'opérateur y figure implicitement, derrière une interface de niveau 2, en tant qu'utilisateur d'un système. Le mainteneur, lui, n'y figure pas du tout car il n'utilise pas un système, il ouvre un capot. La conséquence est que toutes les extensions ultérieures du modèle héritent de la même cécité. Les zones et conduits d'IEC 62443 décrivent des chemins de communication entre actifs. Le Zero Trust vérifie des flux. La micro-segmentation adosse des politiques à des identités d'équipements. Aucun de ces mécanismes n'a de prise sur une personne debout devant une armoire ouverte. Ce n'est pas un cas marginal On pourrait objecter que l'intervention physique est l'exception, et l'accès logique la règle. C'est l'inverse : sur la plupart des sites industriels, l'intervention physique est le chemin majoritaire de modification d'un équipement de niveau 0 ou 1. La grande majorité des automates, variateurs, régulateurs et bancs en service aujourd'hui ne se paramètrent pas autrement : il faut être devant, avec le bon câble et le bon logiciel. Et on utilise une main courante sur place dans le meilleur des cas, ou bien on espère penser à reporter dans l'outil informatique l'intervention de la journée une fois revenu (avec toutes les approximations liées). Ce sont d'ailleurs souvent les équipements dont l'exploitant a décidé souvent à juste titre qu'ils ne seraient jamais raccordés au réseau informatique, précisément parce que la connexion créerait plus de risque qu'elle n'en traiterait. Le résultat est paradoxal. Plus un équipement est isolé du réseau, mieux il est protégé des attaques réseau, et moins il est gouverné du tout. L'isolement ne supprime pas le besoin de contrôle d'accès. Il supprime seulement le moyen habituel de l'exercer. Et les sujets d'inquiétude ne sont pas non plus ceux qu'on imagine. Une part importante des personnes légitimement présentes devant une machine n'appartient pas à l'organisation : intérimaires, sous-traitants de rang deux, techniciens du constructeur jamais venus avant, prestataires mandatés par le mainteneur lui-même. Elles ne figurent dans aucun annuaire, et il n'existe souvent aucun annuaire côté fournisseur avec lequel se fédérer. Ce que les normes admettent déjà Le plus intéressant est que le corpus normatif dit tout cela, et parfois de façon désarmante. IEC 62443-3-2 pose la règle qui rend le sujet inévitable : toute communication entre zones passe par un conduit explicitement défini et surveillé. Si une connexion existe, c'est un conduit, et il est contrôlé. Un technicien avec un portable et un câble de programmation est une connexion entre le monde extérieur et un automate. Personne ne la traite comme telle, mais elle répond à la définition. IEC 62443-4-2 va plus loin, dans sa définition d'une contre-mesure compensatoire. Le contrôle d'accès physique à une salle de commande, destiné à restreindre l'accès à un groupe de personnels connus précise l'objectif : compenser l'exigence technique d'identifier de manière unique les personnes par le système industriel lui-même. Le comité de normalisation écrit donc noir sur blanc que le contrôle d'accès physique est ce qu'on déploie quand le système industriel est incapable de distinguer un être humain d'un autre. C'est-à-dire à peu près toujours. NIST SP 800-82 révision 3 place la sécurité physique dans son modèle de défense en profondeur par couches et son annexe F (l'adaptation des contrôles aux technologies opérationnelles) est sans ambiguïté sur le contrôle PE-3 : les contrôles d'accès physiques viennent compléter la sécurité OT lorsque les mécanismes électroniques sont incapables de satisfaire les exigences de sécurité. Deux référentiels majeurs, tous deux compatibles avec Purdue, disent la même chose : quand l'identification logique est impossible, c'est le physique qui prend le relais. Et ni l'un ni l'autre ne dit comment. Le sujet n'est pas absent des normes. IEC 62443-3-3 comporte une exigence système consacrée au contrôle d'usage des dispositifs portables et mobiles, IEC 62443-2-4 encadre les pratiques des prestataires de service, les deux visant bien la scène que nous venons de décrire. Ces exigences décrivent ce qu'il faudrait obtenir : un usage contrôlé, une autorisation vérifiée, une trace, sans dire par quel moyen l'obtenir sur un équipement qui n'a ni écran, ni identité, ni réseau. Dans la pratique, elles sont satisfaites par des procédures : une consigne d'accueil, un registre papier, une clause au contrat de maintenance. Mais une procédure ne refuse rien, ne mesure rien, et ne signe rien. Le résultat est une exigence formellement couverte et matériellement invérifiable. Où Trust-Buster se positionne Voici notre réponse à la question de départ, et elle est un peu inconfortable à formuler. Nous ne sommes à aucun niveau du modèle. Nous sommes en amont du niveau 0 . Le niveau 0, c'est le process physique : moteurs, vannes, capteurs, actionneurs. Mais il existe une condition à l'existence même de ce niveau, que le modèle ne dessine pas parce qu'elle allait de soi en 1992 : l'énergie . Une machine sans courant ne produit pas, ne chauffe pas, ne tourne pas, ne communique pas, et ne se laisse pas reprogrammer. Un point d'application de politique posé sur l'alimentation possède donc une propriété qu'aucun point d'application logiciel ne peut avoir : il s'applique avant que la cible n'existe fonctionnellement . Un point d'application logiciel s'exécute après le démarrage de la cible et dépend de son intégrité. Aucune vulnérabilité du micrologiciel de l'équipement ne permet en revanche de contourner l'absence de courant. C'est aussi ce qui rend l'approche agnostique. Aucune hypothèse sur le protocole, le micrologiciel, l'âge, le constructeur ou la présence d'une pile réseau. Le contrôle s'applique de la même façon à un automate de 1998 et à une machine livrée le mois dernier. Si vous préférez le vocabulaire des zones et conduits à celui des niveaux, la formulation est plus nette : nous dessinons le conduit humain, et nous y mettons une règle, un point d'application et un journal. Il existait déjà, il n'était gouverné par rien. La correspondance, niveau par niveau Pour ceux qui doivent présenter cela en comité d'architecture. Niveau Purdue Ce qui le protège habituellement Ce que nous y apportons 5 — entreprise IAM, pare-feu, détection sur les postes Rien. Ce n'est pas notre sujet. 4 — planification de site Idem Rien. 3,5 — DMZ industrielle Rupture protocolaire, diode, bastion Rien. Contrôle le plus conséquent de l'architecture, tenu par d'autres. 3 — opérations de site Segmentation, supervision Rien. 2 — supervision de zone Durcissement des IHM, journalisation L'intervention physique sur un poste de supervision est journalisée. 1 — contrôle de base Isolation en coupure, contrôle des flux Le conduit humain vers l'automate est dessiné et gouverné. 0 — process physique Rien, en pratique Le point d'application est en amont : l'alimentation. Ce que nous ne faisons pas Un lecteur qui vient de parcourir ces articles sur Purdue va légitimement se demander si nous prétendons remplacer son architecture. Non. Pas de segmentation réseau. Pas de pare-feu industriel, pas de microsegmentation, pas de politique est-ouest. Pas de frontière entre niveaux 3 et 4. La zone démilitarisée, la rupture protocolaire et les passerelles unidirectionnelles sont d'autres métiers, exercés par des acteurs sérieux et cette frontière reste très probablement le contrôle le plus conséquent de votre architecture. Pas de fonction de sûreté. Couper une alimentation est chez nous un contrôle de sécurité, pas une fonction certifiée. Cela ne se substitue ni à un arrêt d'urgence, ni à une consignation, ni à un relais de sécurité. Ce que nous faisons tient dans une phrase : contrôler et prouver qui met un équipement sous tension, sur un parc qui n'a ni écran, ni identité, ni réseau y compris quand plus rien ne répond. On continuera à proposer d'autres moyens de contrôle sur le niveau 0 avec des effecteurs série, USB, BLE, etc. afin de pouvoir détecter, identifier, vérifier et autoriser toute intervention d'un technicien sur le parc. Le seul effecteur pleinement opérationnel à ce jour est la coupure d'alimentation. Il ne manque pas un niveau au modèle La tentation serait de proposer un niveau supplémentaire, un « niveau moins un » pour l'humain et l'énergie. Ce serait élégant et probablement faux. Le conduit humain n'est pas un étage de la hiérarchie. Il la traverse. Le même technicien qui ouvre une armoire de niveau 1 peut, l'après-midi, se connecter à un poste de supervision de niveau 2 et brancher une clé sur un serveur de niveau 3. C'est un axe orthogonal, pas une couche. Il ne s'agit donc pas de compléter le schéma. Il s'agit d'admettre qu'une architecture qui ne décrit que des machines ne peut pas, à elle seule, gouverner ce que font les gens. Dernier article de la série : le même technicien, avec le même portable et la même capacité de reprogrammation, se connecte parfois à distance depuis un autre continent. Ce cas-là est bien traité mais par un autre métier que le nôtre. On le mentionne pour bien rendre explicite la distinction.

Purdue de vue

11/09/2026

Trois brèches réelles et un angle mort Le modèle Purdue est remis en cause depuis le début des années 2020 pour trois raisons justes : l'internet industriel des objets, la connectivité vers le nuage et l'accès distant court-circuitent sa hiérarchie. Les réponses proposées habituellement (zones et conduits d'IEC 62443, Zero Trust, microsegmentation, passerelles unidirectionnelles) sont solides et méritent d'être connues. Mais elles ont toutes un point commun qu'on remarque rarement : chacune décrit un chemin réseau que le modèle n'avait pas prévu, et chacune y répond par un contrôle réseau. Cet article ne dit pas que le modèle Purdue est mort. Il essaie de regarder précisément ce que la profession a corrigé depuis deux ans, et ce qui n'a été corrigé par personne, là où Trust-Buster peut améliorer la situation. Série « Le modèle Purdue et l'accès physique », 2 sur 4 Le modèle Purdue, en dix minutes Ce que toutes les critiques de Purdue ont en commun ← vous êtes ici Le conduit que personne ne dessine Accès distant et accès physique : deux problèmes différents Les trois brèches, sans complaisance Le capteur qui parle au nuage Le modèle repose sur une hypothèse simple : un niveau ne parle qu'à ses voisins. Un capteur connecté qui transmet directement ses mesures à un service en ligne court-circuite quatre niveaux d'un coup. Ce n'est pas un cas d'école. Un compresseur livré avec sa carte de télémétrie intégrée, une machine dont le constructeur assure la maintenance prédictive depuis ses propres serveurs, un capteur de vibration posé par un prestataire avec sa liaison cellulaire : ces équipements arrivent sur site en emportant leur propre chemin de sortie. Ils ne demandent pas la permission à la hiérarchie, ils l'ignorent. L'accès distant, devenu la norme Le télétravail, la maintenance à distance et la raréfaction des compétences ont fait de l'accès distant une nécessité opérationnelle, pas une commodité. Un constructeur allemand ne se déplace plus pour un réglage. Or le modèle d'origine n'avait aucune place pour cela. On l'a donc greffé, souvent dans l'urgence, parfois avec un outil de prise en main généraliste installé sur un poste de supervision. Les conséquences ne relèvent pas de la conjecture. Le 22 janvier 2026, le CERT-FR a publié une recommandation indiquant que l'ANSSI avait constaté plusieurs compromissions d'entités françaises des secteurs de la production d'énergie renouvelable et de la gestion de l'eau. Des groupes hacktivistes y sont parvenus en accédant à distance à des interfaces de gestion d'installations industrielles exposées sur Internet ; l'action la plus aboutie a arrêté un parc éolien pendant quelques heures, avec une perte financière pour l'exploitant. L'agence précise que ces activités sont le plus souvent d'un niveau de technicité faible, et que les équipements concernés étaient exposés sans authentification ou avec un mot de passe par défaut, certains protocoles industriels étant directement joignables depuis Internet sans chiffrement. Un chemin que le modèle n'avait pas prévu, exploité sans compétence particulière, sur des installations réelles et récentes. Le déplacement latéral, une fois dedans La hiérarchie protège les frontières entre niveaux. À l'intérieur d'une zone, elle ne protège rien. Un attaquant qui a pris pied sur un poste de niveau 2 se déplace librement vers les autres systèmes du même niveau, parce que le modèle n'a jamais dit ce qui devait se passer là. C'est un défaut structurel plutôt qu'une négligence : Purdue décrit la circulation verticale des données, pas la circulation horizontale. Les réponses de la profession, et elles sont bonnes Il faut reconnaître à la sécurité industrielle qu'elle n'est pas restée les bras croisés. Quatre réponses se sont imposées en quelques années, et elles fonctionnent. Les zones et conduits d'IEC 62443-3-2 prolongent le modèle plutôt qu'ils ne le remplacent. Une zone regroupe des actifs par exigence de sécurité et non par niveau : un système instrumenté de sécurité et une interface de supervision peuvent siéger au même niveau Purdue tout en appartenant à des zones différentes, parce que la conséquence de leur compromission n'a rien à voir. Chaque zone reçoit un niveau de sécurité cible, et tout chemin de communication entre zones devient un conduit qui doit être identifié, justifié et sécurisé. L'apport est décisif : ce mécanisme permet de faire entrer dans l'architecture les flux modernes que la hiérarchie ne savait pas décrire. Réplication vers le nuage, accès distant, messagerie de périphérie : si une connexion existe, c'est un conduit, et il est contrôlé. Le Zero Trust modernise ces conduits. Plutôt qu'un périmètre unique, chaque flux est vérifié à chaque connexion. La microsegmentation logicielle remplace les VLAN configurés à la main, avec des politiques adossées à des identités cryptographiques d'équipements plutôt qu'à des ports physiques. La frontière entre niveaux 3 et 4 se durcit. C'est le point le plus consensuel du domaine : la zone démilitarisée industrielle reste le contrôle le plus conséquent de toute architecture OT, et elle se traite sérieusement — rupture protocolaire réelle, passerelles unidirectionnelles matérielles, connectivité sortante uniquement. Et pour les équipements trop anciens pour porter un agent , l'isolation en coupure apporte une réponse élégante : un boîtier matériel placé en série devant l'automate, qui inspecte le trafic et applique les règles du conduit sans qu'on installe quoi que ce soit sur le système hérité, et sans réarchitecturer le réseau. Nous n'avons rien à redire à tout cela. C'est du bon travail, sur de vrais problèmes. Observation attentive Reprenez maintenant la liste, et regardez ce que ces six éléments ont en commun. Le capteur qui parle au nuage est un chemin réseau. L'accès distant est un chemin réseau. Le déplacement latéral est un chemin réseau. La microsegmentation, le bastion, la passerelle unidirectionnelle et l'isolation en coupure sont des contrôles réseau. Chaque critique adressée au modèle Purdue depuis cinq ans décrit un chemin de communication qu'il n'avait pas prévu, et chaque réponse apportée est un contrôle placé sur un chemin de communication. Ce n'est pas un reproche. C'est cohérent : le modèle décrit des flux de données, il est donc normal qu'on lui reproche des flux de données manquants, et qu'on y réponde en contrôlant des flux de données. Un acteur de ce marché énonce d'ailleurs la limite avec franchise. Dans son analyse du modèle Purdue et du Zero Trust, Brixio écrit que cette approche modernise les conduits et la frontière IT-OT, mais qu'elle ne change pas la topologie physique des niveaux 0 à 2 et qu'« il ne touche pas aux automates ». Le modèle n'est pas dépassé, il est incomplet La conclusion habituelle des articles sur le sujet est que Purdue serait obsolète. Nous ne le pensons pas. Les référentiels qui font autorité continuent de s'y adosser : IEC 62443 y ancre ses zones et ses conduits, NIST SP 800-82 révision 3 s'en sert pour décrire sa défense en profondeur, et les architectures de référence des grands équipementiers en dérivent directement. Ce qu'on lui reproche, en réalité, c'est de ne pas décrire des chemins qui n'existaient pas quand il a été écrit. Mais il en reste un, plus ancien que tous les autres, qui n'a jamais figuré sur le schéma et dont personne ne parle. Il ne passe pas par un port. Il ne transporte pas de paquets. Et sur la plupart des sites industriels, c'est encore lui qui sert le plus souvent. La doctrine américaine de novembre 2025 illustre bien cette position ambivalente. Elle affirme que le modèle Purdue, IEC 62443 et UFC 4-010-06 demeurent des cadres faisant autorité pour classifier les systèmes OT et elle choisit dans le même document de ne pas les utiliser, leur préférant une topologie abstraite à deux couches, jugée plus souple parce qu'elle n'assigne pas les composants et les utilisateurs à des niveaux rigides. Le vocabulaire fait toujours autorité. La grille, elle, commence à gêner. Suite de la série : un technicien qui ouvre une armoire et branche son portable sur le port de programmation d'un automate n'a franchi aucun pare-feu. Il est pourtant entré directement au niveau 1. C'est l'objet du troisième article. Sources : Department of War, Chief Information Officer, Zero Trust Portfolio Management Office. Zero Trust for Operational Technology Activities and Outcomes . 18 novembre 2025. Brixio. « Purdue model & Zero Trust: modernising OT segmentation ». Juin 2026. https://brixio.io/blog/purdue-model-zero-trust-ot/ ANSSI / CERT-FR. CERTFR-2025-DUR-003 — Recommandations à destination des acteurs du secteur de l'énergie et de l'eau . 22 janvier 2026. https://www.cert.ssi.gouv.fr/dur/CERTFR-2025-DUR-003/

Seriez-vous Purdue ?

10/09/2026

Le modèle Purdue organise les systèmes industriels en six niveaux numérotés de 0 à 5, auxquels la pratique a ajouté une zone démilitarisée intercalée au niveau 3,5 . Publié en 1992 par Theodore J. Williams et le consortium de l'université Purdue, il décrit quel système se trouve à quel niveau et comment les données devraient circuler entre eux. Trente-quatre ans plus tard, il reste la langue commune de l'atelier et du comité d'architecture. Nous le citons car il y est fréquemment fait référence dans la littérature, voire comme argument commercial, sans forcément coller à sa définition. Voici la version courte, pour qui arrive dans le monde industriel depuis l'informatique de gestion et la cybersécurité. D'où il vient, et ce qu'il visait En 1992, Theodore J. Williams et le consortium de l'université Purdue publient un modèle de référence pour la production intégrée par ordinateur. Le contexte est celui de l'informatisation des usines, longtemps avant l'Industrie 4.0 : on commence à raccorder des systèmes de gestion à des systèmes de production, et personne ne sait très bien comment décrire l'ensemble. L'idée est d'organiser l'environnement en niveaux fonctionnels distincts, chacun ayant son rôle, ses systèmes et ses interlocuteurs. Ce n'est pas une architecture de sécurité, le mot n'apparaît pratiquement pas dans le projet d'origine. C'est un modèle de flux de données , destiné à mettre de l'ordre dans une usine et à faire parler entre eux des gens qui n'employaient pas le même vocabulaire. Cette origine explique à la fois sa longévité et ses limites. Elle explique surtout pourquoi il a été reconverti en cadre de sécurité par l'usage plutôt que par conception : il était là, sa hiérarchie tombait bien, et il donnait un endroit évident où poser des pare-feu. Les six niveaux Niveau 0 : le process physique Ce qui produit, chauffe, tourne, mesure. Moteurs, vannes, pompes, vérins, capteurs de température, de pression, de position. C'est le monde du contact avec la matière, et le seul niveau où l'énergie s'exerce sur la matière, et donc celui où toute erreur commise ailleurs finit par se traduire en risque physique. C'est le niveau que nous cherchons à protéger, sans y résider, comme nous l'expliquons dans le troisième article de cette série. Niveau 1 : le contrôle de base Les équipements qui pilotent le niveau 0 : automates programmables, calculateurs de terrain, régulateurs, équipements électroniques intelligents. C'est ici que réside la logique de commande, ce qui décide qu'une vanne s'ouvre quand une température dépasse un seuil. C'est aussi le niveau le plus ancien du parc. Un automate installé en 2003 fait exactement ce qu'on lui demande et n'a aucune raison d'être remplacé. Mais il n'intègre pas forcément du contrôle d'accès, plutôt de la sécurité liée au service rendu par l'équipement (le fait-il bien, sans usure, sans défaut). Niveau 2 : la supervision de zone Les interfaces homme-machine, les postes de conduite, les systèmes de contrôle-commande d'un atelier ou d'une ligne. L'opérateur voit ici l'état du process et intervient dessus. Techniquement, on est déjà dans le monde du système d'exploitation généraliste — souvent une version de Windows dont la mise à jour supposerait d'arrêter la production. Niveau 3 : les opérations de site La gestion de la production à l'échelle de l'usine : systèmes d'exécution de la fabrication, historisation des données, gestion des lots, ordonnancement. C'est le dernier niveau considéré comme relevant du monde industriel, avec de l'informatique industrielle et du réseau M2M (machine-2-machine) et les premières étapes d'identification. Niveau 3,5 : la zone démilitarisée industrielle Ce niveau n'existait pas dans le modèle d'origine. Il a été ajouté par la pratique, quand il a fallu faire dialoguer l'usine et l'entreprise sans les mettre en contact direct. C'est une zone tampon : les systèmes industriels y déposent des données, les systèmes de gestion viennent les y chercher, et aucun flux ne traverse de bout en bout. On y place des serveurs relais, des historiseurs répliqués, parfois des passerelles unidirectionnelles qui rendent le retour physiquement impossible. Ce demi-niveau porte une grande partie de la charge de sécurité du modèle, ce qui explique qu'on en parle beaucoup. Niveau 4 : la planification de site Systèmes de gestion intégrée, logistique, planification des ressources, applications métier de l'établissement. On est alors passé du côté de l'informatique de gestion et on retrouve des équipements réseaux qu'on peut superviser. Niveau 5 : l'entreprise Le réseau du groupe, les services partagés, la connexion à Internet, les applications d'entreprise. C'est le monde que connaît un responsable de la sécurité des systèmes d'information classique. Le principe de fonctionnement La règle implicite du modèle tient en une phrase : un niveau ne parle qu'à ses voisins immédiats. Le niveau 4 ne s'adresse pas directement à un automate de niveau 1. Il passe par le niveau 3, qui passe par le niveau 2. Chaque frontière est un endroit où l'on peut poser un contrôle, filtrer, journaliser, ou refuser. C'est cette propriété qui a fait la fortune du modèle en sécurité. Elle transforme une usine en une succession de compartiments, et elle donne une réponse simple à une question difficile : où mettre le pare-feu ? Comment les référentiels s'en servent Le modèle n'est pas resté seul. Il a été absorbé par à peu près tout ce qui compte dans la sécurité industrielle. IEC 62443 définit ses zones, ses conduits et ses frontières de confiance en s'appuyant sur Purdue. Une zone regroupe des actifs partageant les mêmes exigences de protection, un conduit est un chemin de communication contrôlé entre deux zones. La partie 3-2 de la norme pose une règle forte : toute communication entre zones passe par un conduit explicitement défini et surveillé. NIST SP 800-82 , le guide américain de sécurité des technologies opérationnelles, s'appuie dessus pour décrire sa défense en profondeur par couches. Les architectures de référence des grands équipementiers en dérivent directement : l'architecture convergée de Cisco et Rockwell, l'architecture de référence sécurisée de Schneider Electric. Le modèle de référence SCADA du SANS superpose à la hiérarchie Purdue les emplacements où poser pare-feu, mandataires, sondes de détection et rebonds. Et la doctrine « Zero Trust pour les technologies opérationnelles » publiée par le département de la Défense américain en novembre 2025 reconnaît explicitement le modèle Purdue et IEC 62443 comme des cadres faisant toujours autorité pour classifier les systèmes OT. Ce qu'il faut en retenir Trois choses, si vous ne devez en garder que trois. C'est un modèle descriptif avant d'être prescriptif. Sa valeur première est de dire ce qui existe : quel système se trouve où, et comment les données devraient circuler. Le reste est une couche d'usage. C'est la langue commune. Quand un architecte sécurité dit « le 3,5 », un automaticien comprend immédiatement de quoi il parle. Dans un domaine où l'informatique et l'automatisme se comprennent mal, c'est une qualité qu'on sous-estime. Et il décrit des systèmes, pas des gens. Chacun de ses niveaux met en relation un système avec un autre système. C'est cohérent avec ce qu'on lui demandait en 1992, et c'est le point de départ du reste de cette série. Suite de la série : les critiques adressées au modèle depuis deux ans. L'internet industriel des objets (IIoT), le Cloud et l'accès distant court-circuitent sa hiérarchie. Mais elles ont toutes un point commun qu'on remarque rarement : c'est l'objet d'un second article. Sources : Williams, T. J. « The Purdue enterprise reference architecture ». Computers in Industry , vol. 24, n° 2-3, 1994, p. 141-158. DOI : 10.1016/0166-3615(94)90017-5. Williams, T. J. The Purdue Enterprise Reference Architecture . Instrument Society of America, 1992. Commission électrotechnique internationale. IEC 62443-3-2:2020 — Security risk assessment for system design . Genève : IEC, 2020. https://webstore.iec.ch Commission électrotechnique internationale. IEC 62443-3-3:2013 — System security requirements and security levels . Genève : IEC, 2013. https://webstore.iec.ch National Institute of Standards and Technology. SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security . Septembre 2023. https://csrc.nist.gov/pubs/sp/800/82/r3/final Department of War, Chief Information Officer. Zero Trust for Operational Technology Activities and Outcomes . 18 novembre 2025. https://dodcio.defense.gov/Portals/0/Documents/Library/ZT-OperationalTechnologyActivitiesOutcomes.pdf — ← le point de vigilance du dossier v1.1 est levé, la référence est citable Cisco Systems et Rockwell Automation. Converged Plantwide Ethernet (CPwE) Design and Implementation Guide . https://www.cisco.com/c/en/us/solutions/design-zone.html

Le roman qui avait raison

28/08/2026

Un article un peu plus léger que d'habitude. Nous ne parlons pas ici de normes ni d'architecture, mais d'un roman, et de ce qui arrive quand une fiction technique se fait rattraper par les faits. Si vous cherchez une lecture pour la rentrée qui vous rendra légèrement paranoïaque à propos de votre installation, vous êtes au bon endroit. Le livre Black-out — Demain il sera trop tard , de l'Autrichien Marc Elsberg, publié en 2012, best-seller à plus d'un million d'exemplaires. C'est le livre qui a fait connaître son auteur, avant Zero deux ans plus tard (pas mal non plus, plus privacy et réseaux sociaux). Le point de départ : par une soirée d'hiver, le réseau électrique européen commence à lâcher, et l'origine remonte au piratage de compteurs communicants en Italie et en Suède. Un ancien hacker italien comprend avant les autorités qu'il ne s'agit pas d'une panne. S'ensuit une course contre la montre, à mesure que l'Europe s'éteint pays par pays. Ce qui rend le roman intéressant pour quiconque travaille dans notre domaine, ce n'est pas l'intrigue mais le choix des vecteurs. Elsberg ne fait pas exploser une centrale, on n'est pas dans un Tom Clancy. Il passe par les compteurs, puis par le logiciel de supervision utilisé par la majorité des installations, en y injectant du code qui déclenche de fausses alertes. Ajoutez quelques sabotages de lignes haute tension, et le réseau se met à tomber tout seul. Pas de destruction spectaculaire : de la confiance mal placée dans des données de terrain. Pour le spectacle hollywoodien, il y a déjà Die Hard 4 qui est un vrai retour en enfer pour la partie hackers & centrales attaquées. Ce qui était déjà vrai quand il écrivait Deux faits étaient déjà publics au moment de la rédaction. Stuxnet , découvert en 2010, avait démontré qu'un programme pouvait modifier le comportement d'automates industriels tout en renvoyant aux opérateurs des mesures rassurantes. Le mensonge aux données de supervision, cœur du roman, était déjà une technique documentée. Les moteurs de recherche d'objets connectés existaient déjà. Shodan est apparu en 2009, rejoint ensuite par Censys et quelques autres. Ils ne cherchent pas des pages web mais des machines : ils interrogent en continu les adresses accessibles depuis Internet, notent ce qui répond et sur quel port, et rangent les réponses dans un index consultable. L'usage majoritaire est parfaitement légitime, les chercheurs s'en servent pour mesurer l'exposition d'un parc, les agences nationales pour prévenir des exploitants, et les équipes sécurité pour vérifier ce qui dépasse de chez elles. Mais ces outils recensent aussi des équipements industriels qui n'auraient jamais dû être joignables. Dès 2011, un travail de recherche universitaire montrait qu'on pouvait dresser une cartographie de systèmes de contrôle industriel exposés simplement en interrogeant ces bases. Cela fait donc quinze ans que le constat est public. Ce que la réalité a ajouté depuis C'est ici que la fiction se fait dépasser. Ukraine, décembre 2015. Première coupure de courant confirmée comme causée par une cyberattaque. Des centaines de milliers de foyers privés d'électricité, des postes ouverts à distance, et des opérateurs regardant leurs curseurs bouger seuls à l'écran sans pouvoir les arrêter. Le rapport établit que l'hameçonnage initial a eu lieu en mars 2015, neuf mois avant les coupures, et que les attaquants ont écrit du firmware malveillant sur mesure en adaptant leur stratégie aux conditions propres de chaque distributeur. Ces neuf mois contredisent l'image d'un piratage instantané que donne le roman. Triton, 2017. Une attaque contre un site pétrochimique visant non pas la production, mais le système instrumenté de sécurité qui déclenche l'arrêt d'urgence. Un cas très romanesque : Triton a échoué à cause d'un bug de l'attaquant. Le rapport documente que l'installation est passée automatiquement en sécurité après que plusieurs contrôleurs Triconex ont détecté une anomalie causée par des bugs dans le logiciel malveillant. Une protection physique existait pourtant : le contrôleur de sûreté Triconex n'accepte le téléversement d'un programme que lorsque son commutateur à clé est en position PROGRAM, et ce commutateur se manœuvre à la main, sur l'équipement. Le détail qui compte pour notre sujet est qu'il avait été laissé dans cette position. Le contrôle n'a pas été contourné : il avait été désarmé par commodité, ce qui est de très loin le mode de défaillance le plus fréquent des dispositifs de sûreté que nous rencontrons. Sur la Vesle. Une centrale hydroélectrique installée dans un ancien moulin à eau est victime d'une intrusion informatique. Selon les éléments repris par la base ARIA du ministère de la Transition écologique, qui recense les accidents technologiques, l'action des attaquants entraîne une baisse du niveau du cours d'eau de vingt centimètres. La suite vaut le détour. Quelques jours plus tard, un groupe d'attaquants russes diffuse une vidéo annonçant avoir pris le contrôle d'un important barrage hydroélectrique implanté sur l'Yonne, avec des images aériennes de l'ouvrage et des extraits d'un logiciel de commande. Sauf que le logiciel montré dans la vidéo n'est pas celui du barrage annoncé : c'est celui de la petite installation du moulin sur la Vesle. Ils ont revendiqué un barrage. Ils tenaient un moulin. Pennsylvanie, novembre 2023. Une régie des eaux perd le contrôle d'une station de surpression. L'automate SCADA visé est un modèle courant, exposé sur Internet sur son port de programmation par défaut, protégé par un mot de passe par défaut ou par aucun. Les attaquants ont renommé l'appareil et affiché un message sur l'interface. Plusieurs centaines d'appareils du même modèle étaient joignables de la même manière et d'autres régies ou établissements ont été touchés dans la même vague. Alors que le roman imaginait des attaquants brillants, patients et magnifiquement outillés, force est de constater dix ans plus tard que la réalité est encore souvent liée à des mots de passe d'usine sur un port documenté dans le manuel du fabricant. Ce que le roman exagère Trois réserves purement fonctionnelles, sans rien enlever au plaisir de lire ce livre. L'effet domino est trop rapide et trop total. Les réseaux électriques européens disposent de mécanismes de délestage, de reprise progressive et de conduite manuelle qui ne se laissent pas contourner par une seule ligne de code. Une bascule continentale en quelques heures relève de la licence romanesque. La monoculture logicielle est un artifice de scénario. Le roman suppose qu'un même logiciel de supervision équipe l'essentiel des installations. La réalité est un patchwork de constructeurs, de versions et de bricolages locaux, ce qui est un cauchemar à sécuriser, mais une excellente protection contre une attaque unique et universelle. Et une correction importante sur la peur liée aux équipements contrôlés à distance. L'incident de traitement d'eau d'Oldsmar en Floride, en 2021, a longtemps circulé comme l'exemple parfait de la prise de contrôle à distance. Tandis que d'autres analyses ultérieures ont conclu à une erreur de manipulation sur un poste partagé, pas à une intrusion. Il continue pourtant d'être cité dans des présentations commerciales. C'est pour quoi il faut aussi savoir se prémunir des contournements "de bonne foi" de mesures contraignantes pour les usages courants, qui mènent à des erreurs de manipulation aux conséquences catastrophiques. Le vrai enseignement n'est pas celui qu'on croit En refermant le livre, la tentation est de conclure « il faut mieux protéger les grandes infrastructures nationales ». C'est vrai, et c'est déjà largement en cours. L'enseignement plus intéressant est ailleurs, et il ressort surtout de la comparaison avec les incidents réels. Dans presque tous les cas documentés, le point d'entrée n'était pas le système central . C'était un modem cellulaire sur un petit barrage. Un automate à quelques milliers d'euros sur une station desservant peu de monde. Un équipement que personne ne considérait comme critique, installé par un prestataire, jamais inventorié, jamais mis à jour, et joignable depuis n'importe où. C'est exactement le parc dont nous parlons dans nos autres articles : celui qui est trop physique pour la DSI, trop numérique pour la maintenance, et qui ne figure sur la todo-list de personne. Rien de ce que nous fabriquons ne résout le problème de l'automate exposé sur Internet. Ça, c'est de la segmentation réseau et de la gestion des accès distants, et il existe de très bons acteurs pour cela. Notre affaire à nous, c'est l'autre chemin : quelqu'un qui se tient physiquement devant la machine. Les deux chemins existent, ils ne se recouvrent pas, et il faut se méfier de quiconque prétend tout résoudre avec un seul produit. Alors, on le lit ? Oui. D'abord parce que c'est un bon thriller, ce qui n'est pas rien pour un livre qui explique en passant le fonctionnement d'un réseau de transport d'électricité. Parce qu'il est le meilleur outil de vulgarisation que nous connaissions pour faire comprendre la dépendance en cascade à un interlocuteur non technique. Et parce qu'il vieillit d'une manière particulière. Les romans d'anticipation technique vieillissent en général mal : leurs détails deviennent risibles. Celui-ci vieillit dans l'autre sens car chaque année qui passe rend ses hypothèses un peu moins audacieuses. Alors bonnes lectures ! Autant le roman de fiction que les cas réels documentés :) Sources : Leverett, Éireann P. Quantitatively Assessing and Visualising Industrial System Attack Surfaces . Mémoire de MPhil en Advanced Computer Science, Darwin College, University of Cambridge, juin 2011. https://www.cl.cam.ac.uk/~fms27/papers/2011-Leverett-industrial.pdf Bodenheim, R., Butts, J., Dunlap, S., Mullins, B. « Evaluation of the ability of the Shodan search engine to identify Internet-facing industrial control devices ». International Journal of Critical Infrastructure Protection , vol. 7, n° 2, juin 2014, p. 114-123. DOI : 10.1016/j.ijcip.2014.03.001. Éditeur : https://www.sciencedirect.com/science/article/abs/pii/S1874548214000213 Notice libre : https://www.semanticscholar.org/paper/27d0b64d7aae31ffff7276ec3d940188498f1d4e Federal Bureau of Investigation. TRITON Malware Remains Threat to Global Critical Infrastructure Industrial Control Systems . Private Industry Notification 20220325-001, 24 mars 2022. https://www.ic3.gov/CSA/2022/220325.pdf — source gouvernementale, TLP:White, préférable aux analyses éditeurs pour Triton E-ISAC et SANS ICS. Analysis of the Cyber Attack on the Ukrainian Power Grid — Defense Use Case . 18 mars 2016. Miroir institutionnel : https://nsarchive.gwu.edu/document/15331-sans-and-electricity-information-sharing-and Et pour la partie européenne : ANSSI / CERT-FR. CERTFR-2025-DUR-003 — Recommandations à destination des acteurs du secteur de l'énergie et de l'eau . 22 janvier 2026. https://www.cert.ssi.gouv.fr/dur/CERTFR-2025-DUR-003/ ANSSI / CERT-FR. CERTFR-2024-CTI-011 — Secteur de l'eau : état de la menace informatique . https://www.cert.ssi.gouv.fr/cti/CERTFR-2024-CTI-011/ BARPI, base ARIA, fiche n° 62171 — intrusion informatique sur une centrale hydroélectrique. Ministère de la Transition écologique. https://www.aria.developpement-durable.gouv.fr/accident/62171/

Ce que le Cube entend

26/08/2026

Radio en atelier : ce qu'on peut savoir, ce qu'on ne peut pas, et comment détecter qu'on nous ment Un atelier industriel est un endroit bruyant. Pas seulement pour les oreilles : entre les téléphones des intervenants, les capteurs sans fil, les télécommandes de pont roulant, les traceurs oubliés dans une caisse à outils et les modems des machines récentes, un local de production émet en permanence sur une douzaine de bandes de fréquences. Cet article explique ce que notre matériel écoute, comment il distingue une présence d'une intoxication, et où sont les limites. Il est technique, mais chaque terme est expliqué au passage : aucune connaissance en radio n'est nécessaire pour le lire. Trois questions différentes, souvent confondues Avant les protocoles, une distinction qui structure tout le reste. « Faire de la détection radio » recouvre trois besoins qui n'ont ni les mêmes moyens ni les mêmes limites. La question Ce qu'il faut La difficulté principale Ce badge est-il ici, maintenant ? Écouter une balise connue et suivre sa présence Distinguer une vraie proximité d'un signal relayé Qu'est-ce qui émet dans cette pièce ? Inventorier tout ce qui passe, connu ou non Les adresses changent en permanence, et le RGPD s'applique Est-ce qu'on essaie de m'aveugler ? Mesurer l'état du spectre lui-même Un brouillage réussi ressemble beaucoup à une panne Notre système répond à la première en continu, à la deuxième en option, et à la troisième par construction — parce que c'est celle qui protège les deux autres. Niveau 1 : le BLE, le plus simple et le plus trompeur Ce qu'un appareil Bluetooth raconte sans qu'on lui demande Le Bluetooth Low Energy fonctionne par annonces : un appareil qui souhaite être découvert émet, toutes les quelques centaines de millisecondes, un petit paquet contenant son adresse, parfois un nom, parfois des données de service. Ces paquets circulent en clair sur trois canaux dédiés que n'importe quel récepteur peut écouter sans se connecter à quoi que ce soit. C'est ce qui rend la détection facile. Notre Cube en mode écoute voit passer les montres connectées, les écouteurs, les traceurs d'objets, les capteurs de température, les téléphones en mode découverte et surtout, c'est le point qui nous intéresse, les badges que nous avons enrôlés. À chaque paquet reçu s'ajoute une mesure : le RSSI , la force du signal reçu. C'est un indicateur en décibels qui décroît quand on s'éloigne. C'est ce qui donne l'illusion d'une mesure de distance, et nous verrons plus bas pourquoi c'en est une mauvaise. Un système de détection naïf compte les adresses et croit compter les appareils. Il se trompe massivement, parce que les appareils modernes changent d'adresse en permanence. Le mécanisme s'appelle RPA — Resolvable Private Address , adresse privée résoluble. Un téléphone ou une montre tire une nouvelle adresse toutes les quinze minutes environ. Pour un observateur extérieur, il devient un appareil différent quatre fois par heure. Un tableau de bord qui affiche « 47 appareils détectés ce matin » dans un atelier qui a vu passer six personnes ne ment pas volontairement : il compte des adresses. Donc forcément, c'est pas comme ça qu'il faut faire. Mais ce mécanisme a une propriété que l'on peut exploiter, et c'est elle qui fait toute la différence entre un appareil enrôlé et un inconnu. Chaque adresse privée est calculée à partir d'une clé, l' IRK ( Identity Resolving Key ), échangée une seule fois lors de l'appairage. Qui possède l'IRK peut vérifier qu'une adresse apparemment aléatoire appartient bien à l'appareil qu'il connaît. Qui ne la possède pas ne voit qu'une suite de nombres sans lien entre eux. Concrètement : nos badges enrôlés restent suivis en continu malgré leurs changements d'adresse, et les appareils que nous ne connaissons pas restent, par construction, non pistables. Ce n'est pas une politique de confidentialité que nous avons écrite : c'est une propriété du protocole, et nous la considérons comme un avantage plutôt qu'un obstacle. On peut l'étendre à d'autres appareils si on veut aussi faire de la logistique avec le Cube : suivre du matériel mobile et vérifier ce qui est sorti et ce qui est disponible. Ou mieux s'organiser avant de partir sur un chantier en ayant oublié juste la petite malette mise à recharger la veille au soir (on l'a tous vécu). Entrées et sorties : le piège du seuil unique Décider qu'un badge « est entré » quand son RSSI dépasse une valeur, et « est sorti » quand il repasse en dessous, produit un système inutilisable. Le RSSI fluctue de dix à vingt décibels quand quelqu'un se retourne, passe derrière une machine ou pose son badge sur un établi métallique. Un seuil unique génère des dizaines d'entrées-sorties par heure pour une personne assise. Trois mécanismes classiques corrigent cela, et ils valent pour n'importe quel système de ce type : L'hystérésis. Deux seuils au lieu d'un : on entre à −65 dBm, on ne sort qu'en dessous de −80 dBm. La zone grise entre les deux ne produit aucun événement. La fenêtre de persistance. Un badge n'est déclaré absent qu'après plusieurs cycles d'annonce manqués consécutifs, pas au premier paquet perdu. Une salve d'interférences ne coupe donc pas un accès en cours. Le lissage temporel. On travaille sur une moyenne glissante des dernières mesures, jamais sur la valeur instantanée. Le réglage de ces trois paramètres est propre à chaque local, car un atelier d'usinage avec des machines en fonte n'a pas la même signature qu'un laboratoire d'électronique. C'est précisément ce que le mode Observation mesure avant que quoi que ce soit ne soit armé. Niveau 2 : le Wi-Fi, le plus riche et le plus réglementé Ce qu'on voit sans se connecter Un module Wi-Fi placée en mode moniteur — un mode d'écoute passive où elle capte tout ce qui passe sur un canal sans rejoindre aucun réseau — voit une catégorie de trames que le chiffrement ne protège pas : les trames de gestion . Balises des points d'accès, requêtes de découverte des terminaux, demandes d'association, demandes de déconnexion. Même sur un réseau en WPA3, ces trames circulent en clair, parce qu'elles servent justement à négocier la connexion. Cela suffit pour repérer trois choses utiles : Un point d'accès non autorisé , d'abord : un boîtier 4G branché dans une armoire, un téléphone en partage de connexion posé sur une baie. Le mécanisme est plus banal qu'on ne l'imagine. Un smartphone configuré en point d'accès, associé à un adaptateur raccordé à un équipement, ouvre un chemin de données qui emprunte la liaison cellulaire du téléphone. Ce chemin ne traverse ni le pare-feu, ni les dispositifs de prévention des fuites, ni la collecte du SIEM : ils ne sont pas sur son trajet. Aucun outillage sophistiqué n'est nécessaire, et rien sur le réseau ne le voit. C'est précisément le genre de chemin qu'une écoute passive du spectre révèle, et qu'aucune supervision réseau ne peut révéler. Une attaque de déconnexion. L'envoi massif de trames de déconnexion forcée est l'attaque Wi-Fi la plus répandue, et elle est triviale à détecter : un volume anormal de ces trames en provenance d'une même adresse. À noter qu'elle échoue contre les réseaux qui activent la protection des trames de gestion (norme 802.11w), ce que fait WPA3 — encore faut-il que le parc le supporte. Un jumeau maléfique. Un point d'accès qui annonce le nom d'un réseau légitime depuis un emplacement où il n'a rien à faire, ou avec une adresse matérielle qui ne correspond pas à l'équipement déclaré. La même limite qu'en BLE, en pire Depuis iOS 14 et Android 10, les terminaux utilisent une adresse matérielle aléatoire différente pour chaque réseau, et randomisent aussi leurs requêtes de découverte. Compter des adresses Wi-Fi pour compter des personnes est encore moins fiable qu'en Bluetooth. Et surtout : écouter le Wi-Fi ambiant, c'est collecter des données personnelles. Nous y revenons plus bas, parce que c'est le chapitre que la plupart des articles techniques sur ce sujet omettent. Niveau 3 : le satellite SDR, pour tout le reste Ce qu'est une radio logicielle Une SDR — software-defined radio , radio définie par logiciel — est un récepteur qui ne sait rien faire tout seul. Il numérise une tranche de spectre brute et laisse un ordinateur décider comment l'interpréter. Le même matériel écoute donc une télécommande de portail, un capteur de température, un badge sans contact ou un modem, selon le programme qu'on lui donne. C'est ce qui permet d'envisager un effecteur dédié à l'écoute : une carte SDR dans un boitier étanche avec micro-ordinateur avec l'antenne adaptée à la bande visée. Encore faut-il couvrir la bande la plus intéressante en milieu industriel, les 2,4 GHz où vivent le Wi-Fi, le Bluetooth et Zigbee. Une écoute large spectre sérieuse suppose au minimum deux radios : une pour le sub-GHz, une pour les 2,4 GHz. Ce qu'on y trouve Sur la bande sub-GHz, l'outil de référence est rtl_433 , un décodeur libre qui reconnaît plus d'un millier de protocoles de capteurs et de télécommandes du commerce, sur 315, 433, 868 et 915 MHz. Ce qu'il révèle dans un atelier est souvent une surprise : sondes de température installées par un prestataire et oubliées, télécommandes de pont roulant, capteurs de porte, stations météo, et de temps en temps un équipement qui ne figure sur aucun inventaire. C'est là que la détection radio rejoint la conformité. Un parc dont on ne connaît pas les émetteurs est un parc dont l'inventaire des actifs est incomplet — et l'inventaire des actifs est une exigence explicite de NIS 2. Détecter qu'on nous aveugle Ce qu'est un brouillage Trois familles, de la plus grossière à la plus fine : Le bruit large bande. On émet de la puissance sur toute la bande, en continu. Simple, efficace, et parfaitement visible. Le brouillage réactif. L'émetteur écoute et n'émet que lorsqu'il détecte le début d'une trame légitime, juste assez pour la corrompre. Beaucoup plus discret : le plancher de bruit reste normal. Le brouillage protocolaire. On n'émet pas de bruit, on émet des trames valides comme des déconnexions forcées en Wi-Fi, par exemple. Rien d'anormal au niveau radio mais tout est anormal au niveau logique. Les signatures qui trahissent Aucune n'est décisive seule, c'est leur conjonction qui fait un signal. Un plancher de bruit qui monte sans trafic décodable. La signature classique. Beaucoup d'énergie reçue, aucun paquet valide : quelque chose émet qui ne parle pas notre langue. Un taux d'échec de contrôle d'intégrité qui explose. Les paquets arrivent mais leur somme de contrôle échoue : ils sont corrompus en vol. C'est la signature du brouillage réactif, celle que le plancher de bruit ne montre pas. Une occupation de canal anormale. Chaque local a une signature d'occupation propre, apprise pendant la phase d'observation après déploiement du Cube. Un écart marqué par rapport à cette référence est plus parlant qu'un seuil absolu. Et la plus utile de toutes : la disparition simultanée. Nos effecteurs émettent périodiquement. S'ils cessent tous d'être entendus en même temps, l'hypothèse « quatre pannes matérielles à la même seconde » est nettement moins probable que l'hypothèse « quelque chose couvre la bande ». C'est le signal le plus fiable dont nous disposons, et il ne coûte rien : il découle du fait que le système se parle à lui-même en permanence. Ce qu'on en fait Rien de plus qu'un refus, et c'est volontaire. On ne peut pas empêcher un brouillage, mais c'est un signal clair. Un brouillage détecté fait retomber la zone en refus, avec un événement journalisé portant son motif. La contrepartie doit être dite franchement : le système est vulnérable au déni de service. Quelqu'un qui veut arrêter votre production plutôt que d'y entrer y parviendra en couvrant la bande. La réponse à cela n'est pas technique mais organisationnelle : procédure de dérogation (le QR Code à scanner pour réactiver les effecteurs du Cube), mode secours, surveillance de la disponibilité radio. Et accessoirement juridique : en France, la détention et l'usage de brouilleurs radioélectriques sont interdits hors dérogations très encadrées, ce qui ne dissuade pas tout le monde mais change la nature de l'incident. Détecter qu'on nous intoxique Le rejeu et la copie Une annonce BLE circule en clair et se recopie. C'est pourquoi nous ne traitons jamais une annonce comme une preuve d'identité : elle déclenche une conversation avec le Cube, elle n'autorise pas l'accès. L'autorisation vient d'un défi cryptographique auquel seule la clé contenue dans l'élément sécurisé du badge ou du smartphone sait répondre, et qui ne peut être rejoué. C'est la parade fiable, et elle est bien comprise. Le problème suivant l'est moins. Le relais, ou l'attaque qu'aucune signature n'arrête Un attaquant place un premier appareil près du badge légitime resté au vestiaire et un second près de la machine, puis retransmet la conversation entre les deux. Rien n'est falsifié : les messages sont authentiques, les signatures sont valides, le défi cryptographique est correctement résolu. Ce qui est fabriqué, c'est la proximité, et la proximité n'est pas une propriété qui se signe. Aucune couche cryptographique ne voit cette attaque. Seule une mesure physique la contredit. D'où notre préférence pour le smartphone avec une action physique de déverrouillage de son utilisateur, si le matériel est autorisé dans votre contexte. Les mesures physiques qui contredisent un relais La mesure de temps de vol (UWB). La référence et certainement notre prochaine phase de R&D. L'ultra-large bande, normalisée dans IEEE 802.15.4z avec sa séquence d'horodatage brouillée, mesure le temps que met un signal à faire l'aller-retour. Comme la lumière ne se laisse pas accélérer, un relais ajoute forcément du délai. C'est la seule réponse structurelle au problème. Nous ne l'avons pas aujourd'hui. Le standard Aliro publié par la Connectivity Standards Alliance reste notre modèle de référence sur ce point. La cohérence multi-capteurs. Avec plusieurs récepteurs répartis dans un local, un émetteur réel produit un profil de niveaux cohérent avec sa position. Un relais produit souvent une incohérence : un signal très fort vu par un seul capteur, ou un profil qui ne varie pas alors que la personne se déplace. Ce n'est pas une preuve, c'est une invraisemblance et cela peut suffire à refuser l'accès. La radiogoniométrie. Déterminer la direction d'où vient un signal. Le KrakenSDR a rendu cette technique abordable : cinq récepteurs RTL-SDR partagés sur une horloge unique, avec matériel de calibration intégré, exploités par interférométrie corrélative, le tout avec un logiciel d'acquisition et de traitement en open source, tournant sur un Raspberry Pi 4 ou 5. Sa limite pour nous est franche : il monte à 1,766 GHz et ne couvre donc pas les 2,4 GHz du Bluetooth. Pour la direction en BLE, la voie normalisée est le Bluetooth 5.1 avec extension de tonalité constante , qui permet le calcul d'angle d'arrivée à l'aide d'un réseau d'antennes. L'empreinte radio de l'émetteur. Chaque émetteur porte des imperfections de fabrication mesurables (décalages de fréquence, bruit de phase, défauts de modulation) qui forment une signature difficile à imiter. C'est un domaine de recherche actif et prometteur. Nous le suivons avec attention. Le cas Flipper Zero Il est cité dans toutes les conversations sur ce sujet, souvent de travers. Autant poser les faits. Ce qu'il fait. Un émetteur-récepteur CC1101 couvrant les bandes 300–348, 387–464 et 779–928 MHz, avec une portée annoncée d'une cinquantaine de mètres. Sur ces bandes, il lit, enregistre et rejoue des télécommandes à code fixe : portails, barrières, interrupteurs radio, sonnettes. Contre un équipement à code fixe, il est redoutable et il a effectivement banalisé une compétence qui demandait auparavant un vrai savoir-faire. Ce qu'il ne fait pas. Sur les 2,4 GHz, il embarque un STM32WB55, donc une radio Bluetooth Low Energy native : elle sert nominalement à l'appairage avec l'application mobile, et les firmwares alternatifs s'en servent pour émettre en masse des annonces BLE forgées : nuisance réelle, notamment sur les terminaux mobiles à proximité. En revanche, il ne fait ni Wi-Fi ni Zigbee sans extension, et sa radio BLE n'est ni un analyseur ni un outil de relais : elle émet et se connecte, elle ne capture pas le trafic BLE de manière exploitable. Son étage de puissance interne est par ailleurs faible, au point qu'une tentative de brouillage ne porte qu'à quelques dizaines de centimètres. Le Flipper seul n'est donc pas la menace universelle qu'on décrit Ce qui change la donne. Les cartes d'extension à trois modules, vendues quelques dizaines d'euros, ajoutent un ESP32 pour le Wi-Fi, un nRF24 pour les 2,4 GHz propriétaires et un CC1101 amplifié à antenne externe. Avec cet ensemble, l'appareil accède aux attaques sur claviers et souris sans fil de la famille MouseJack, aux attaques Wi-Fi, et à un brouillage sub-GHz à bien plus longue portée. La menace n'est pas l'appareil à 170 €, c'est l'appareil plus la carte à 30 €. Comment il se voit. Chacun de ses modules laisse une trace. L'émission sub-GHz est visible d'un effecteur SDR. Le firmware Wi-Fi le plus répandu sur ces cartes produit des trames de déconnexion en volume caractéristique. Le module 2,4 GHz propriétaire émet sur des canaux et avec un format d'adressage distinctifs. Aucun de ces indices n'est une preuve d'intention mais ensemble, dans un atelier où rien de tel n'est censé se trouver, ils constituent une anomalie qui mérite une alerte. Tandis que revoilà le RGPD Écouter les ondes d'un local, c'est traiter des données personnelles. C'est la position constante de la CNIL : l'adresse matérielle d'un téléphone est une donnée à caractère personnel. L'histoire du sujet en France est instructive. En 2015, la CNIL refuse à JCDecaux un dispositif de comptage Wi-Fi sur le parvis de La Défense, au motif que l'anonymisation annoncée n'était pas irréversible, l'opérateur pouvait rejouer le procédé de hachage. En 2018, une société de mesure de fréquentation en magasin est mise en demeure. Entre-temps, la CNIL a précisé les règles applicables. Ce qu'elle demande, en substance Pour un simple comptage agrégé, une anonymisation dans les cinq minutes suivant la collecte ou bien une pseudonymisation immédiate suivie d'une anonymisation ou d'une destruction sous vingt-quatre heures, avec une information des personnes nettement plus complète. Une information visible sur place , sur le modèle de l'affichette de vidéosurveillance, renvoyant vers une information détaillée. Un droit d'opposition praticable . Et une précision qui tranche beaucoup de débats : demander aux gens d'éteindre le Wi-Fi de leur téléphone n'est pas une modalité d'opposition acceptable, puisque cela revient à les priver d'une fonction de leur appareil. Ce que nous en faisons Notre position découle plus de l'architecture que de la vertu. Nous n'avons pas besoin de suivre les inconnus. Le système doit répondre à « le porteur enrôlé est-il présent ? ». Les identifiants que nous conservons sont ceux des badges et téléphones volontairement enrôlés , dont les porteurs sont informés et dont l'IRK nous a été confié explicitement. Pour tout le reste, un compteur agrégé et une détection d'anomalie suffisent. Le mécanisme d'adresse tournante joue en notre faveur. Sans l'IRK, une adresse BLE inconnue n'est pas rattachable d'un cycle sur l'autre. Le non-pistage des tiers est une propriété du protocole, pas une promesse contractuelle. Les journaux nomment des personnes autorisées, pas des passants. Un événement d'anomalie enregistre qu'un émetteur non identifié était présent, avec son horodatage et sa bande — pas une identité de tiers reconstituée. Un dispositif d'écoute large spectre dans un local où travaillent des salariés relève par ailleurs de l'information et de la consultation du CSE. Ce n'est pas un détail de mise en œuvre mais c'est un prérequis de déploiement, et nous préférons le poser avant l'installation qu'après une réclamation. Dans notre carrière, nous avons vu de beaux projets techniques revenir à la feuille de papier pour des problèmes d'accord sur le suivi potentiel (mais non prévu par le projet) des horaires de présence, des lieux de présence voire de délai entre plusieurs positions. Ce que la détection prouve, et ce qu'elle ne prouve pas Mécanisme Ce qui est prouvé Ce qui ne l'est pas Réception d'une annonce BLE Un émetteur portant cet identifiant a émis à portée Que son porteur légitime est là Résolution d'adresse via l'IRK Cet émetteur est bien l'appareil enrôlé Qu'il n'a pas été prêté ou volé RSSI et hystérésis Une proximité radio plausible et durable Une distance réelle — le signal peut être relayé Écoute Wi-Fi en mode moniteur Présence d'un point d'accès ou d'une activité anormale Un inventaire complet des terminaux présents Balayage SDR large spectre Qu'un émetteur a été observé sur cette bande Qu'aucun autre n'a émis pendant qu'on regardait ailleurs Détection de brouillage Que la bande est devenue inexploitable Qui brouille, ni depuis où Cohérence multi-capteurs Une invraisemblance géométrique Un relais, de façon certaine, seul le temps de vol le fait Si l'on devait résumer la ligne éditoriale de ce tableau en une phrase : la détection radio corrobore une décision, elle ne la fonde jamais. Nos quatre piliers pour Trust-Buster tiennent dans la détection, l'identification, la validation et l'action (DIVA). Seules les deuxième et troisième reposent sur de la cryptographie. La première est un filtre qui réduit la surface, et nous ne l'écrivons jamais autrement. Où se situe ce que nous faisons Le marché de la détection radio se lit sur trois étages, et il est utile de dire lequel est le nôtre. En haut, la surveillance d'espace. Bastille Networks en est la référence : couverture continue de la dizaine de mégahertz à plusieurs gigahertz, réseaux de capteurs passifs alimentés par le réseau filaire, localisation d'un émetteur à quelques mètres près, historique des déplacements. C'est un produit de sécurité d'installation, vendu à des clients gouvernementaux et à de grandes entreprises, et son prix correspond à sa couverture. Au milieu, les systèmes de détection d'intrusion Wi-Fi intégrés aux infrastructures réseau des grands équipementiers. Efficaces sur leur périmètre, aveugles sur tout le reste : Bluetooth, sub-GHz, propriétaire. En bas, l'outillage libre , largement suffisant pour construire un capteur honnête : Kismet, rtl_433, OpenMQTTGateway, le sniffer Nordic nRF52840 avec Wireshark, et KrakenSDR pour la radiogoniométrie. Notre objet n'est pas de surveiller un espace mais de corroborer une décision d'accès, localement, sans réseau, à côté d'une machine. Un système de surveillance d'espace vous dit qu'un téléphone est entré dans le bâtiment ; il ne coupe pas l'alimentation de la presse. Ce sont deux métiers, et ils peuvent parfaitement coexister sur le même site. La boîte à outils, ouverte comme toujours BLE — sniffer Nordic nRF52840 avec le firmware officiel et Wireshark ; OpenMQTTGateway pour la passerelle d'écoute. Wi-Fi — Kismet, adaptateur en mode moniteur, analyse des trames de gestion. Sub-GHz — rtl_433 et ses décodeurs, sur RTL-SDR ou Airspy. Large spectre — HackRF One pour couvrir 2,4 et 5 GHz, GNU Radio pour le traitement. Radiogoniométrie — KrakenSDR, logiciels d'acquisition et de traitement en open source, sur Raspberry Pi. Support d'exécution — Raspberry Pi sous Linux durci pour l'effecteur d'écoute. Rien de tout cela n'est secret, et c'est encore une fois l'intérêt. Le sur-mesure reste là où il crée de la valeur : la corrélation entre ces signaux, la décision locale qui en découle, et le journal signé qui l'atteste. Pour finir : la différence entre entendre et comprendre Un atelier bien instrumenté entend énormément de choses. Ce qui est difficile, ce n'est pas d'entendre (un récepteur à trente euros y suffirait) c'est de savoir ce qu'on a le droit d'en conclure. Une annonce reçue ne prouve pas une présence. Une présence ne prouve pas une identité. Une identité ne prouve pas une autorisation. Et un silence ne prouve pas une absence : il peut aussi vouloir dire qu'on nous a mis un coussin sur les oreilles.

Principes de sécurité OT

23/08/2026

Démonstration de sécurité d'un contrôle d'accès d'atelier On nous demande généralement si « c'est chiffré ». La question est légitime, mais elle ne suffit pas car il y a de nombreux mécanismes pour mettre en défaut une installation de contrôle d'accès des équipements électriques. Cet article procède donc d'abord par une affirmation assez précise de ce que nous faisons pour sécuriser l'ensemble du procédé, décrit contre qui la solution est censée tenir, puis passe en revue les manières concrètes de faire démarrer une machine sans en avoir le droit. L'affirmation initiale Voici ce que nous vendons avec la première solution développée par Ops-Devices dans le contexte de machines à allumer ou couper selon les utilisateurs autorisés : Aucune mise sous tension d'un équipement protégé ne peut avoir lieu sans qu'un badge enrôlé soit présent et tant qu'il reste sur place, tout en veillant que son porteur agisse dans le créneau qui lui a été accordé, sur les machines autorisées, et que l'organe de coupure soit intègre et joignable. Toute tentative, réussie ou non, doit laisser une trace datée à l'heure de l'atelier. Le dispositif concerné Quatre machines dans une pièce, aucune intervention de modification sur les équipements protégés : un badge radio porté par l'intervenant, un boîtier de décision autonome à portée de la zone, un module de tête en armoire qui alimente et mesure chacune des voies, quatre prises pilotées sur l'alimentation des machines, et l' application mobile du responsable qui fait la navette entre la salle machine et les bureaux (pour garder un lien quotidien avec le serveur d'administration par exemple). Le boîtier n'a aucun accès réseau. Toute décision est prise localement, ce qui a une conséquence directe sur la démonstration : couper Internet ne change strictement rien au comportement du dispositif, mais par conséquent les alertes sont restreintes au local technique. Il faut donc que les règles d'accès soient bien appliquées, et parfois même très strictes si aucune confirmation d'un responsable ne peut être donnée à distance. L'adversaire contre lequel elle est faite Nous nous plaçons ici face à quelqu'un qui a un accès physique légitime ou toléré à la zone : sous-traitant, intérimaire, prestataire, visiteur laissé seul. Il dispose d'outils courants et de quelques minutes, et sa motivation est la commodité : mettre en route une machine et passer à autre chose, quite à contourner une procédure jugée lourde, pour gagner du temps. Nous ne nous plaçons pas face à un adversaire qui monterait un relais radio, clonerait une annonce après l'avoir analysée, ou substituerait un module par un clone matériel. Ces menaces sont réelles, elles relèvent d'un autre budget et d'un autre dispositif que nous avons conçu, et elles feront l'objet d'un second article. Le socle : trois frontières et une position de repli L'affirmation ci-dessus repose donc sur trois frontières distinctes, dont aucune ne peut couvrir le travail des deux autres, et sur un comportement par défaut qui rend chaque défaillance inoffensive. Frontière Question à laquelle elle répond L'humain → la décision Qui est là, et a-t-il le droit maintenant ? La décision → l'exécution Cet ordre vient-il de l'autorité, et est-il valable ? L'exécution → la machine Que peut faire cet organe, et que ne doit-il jamais faire ? On fait souvent le parallèle avec les détrompeurs sur les prises des onduleurs : tout admin système a fait la chasse aux collègues qui branchent une machine à café ou leur batterie de vélo sur les prises rouges, parce que "de toute façon on a nos priorités". Nous remplaçons donc les détrompeurs en plastique par des équipements qu'on ne pourra pas bypasser : fini la tige du stylo bic ! mais surtout, fini la production qui s'arrête, les heures d'usinage ou d'impression 3D perdues, les serveurs éteints qui n'enregistrent plus les expériences en cours, etc.. La position de repli est le refus. Les prises sont coupées tant qu'une décision positive n'a pas été prise, et non l'inverse. Panne du boîtier, perte de liaison, badge illisible, planning absent, radio brouillée : chacun de ces cas ramène au même état éteint. Ce choix a un coût d'exploitation réel : il faut que le dispositif fonctionne pour que la production tourne, et nous l'assumons, parce qu'un contrôle d'accès qui échoue en position ouverte n'est pas un contrôle dégradé mais une absence de contrôle avec un voyant vert. La sécurité est donc physique (débrancher un câble, intervertir deux appareils, leurrer les capteurs) avant même de parler de protocoles. La démonstration, attaque par attaque 1. Se présenter devant la machine et appuyer sur le bouton L'attaque. La plus fréquente, et de loin. Personne ne pirate quoi que ce soit : on se met devant une prise connectée et on appuie sur l'interrupteur. Forcément, on pensait tout piloter à distance mais même sur un matériel premier prix, il y a toujours une alternative physique. Ce qui s'y oppose. Le bouton physique des prises que nous recommandons est désolidarisé du relais par configuration. L'appui ne commande plus la sortie ; seule la couche de décision peut mettre sous tension. C'était simple mais nécessaire, et ça justifie d'y mettre 30 € au lieu de 10. Pourquoi cela tient. Parce que le lien entre le bouton et le relais n'existe plus dans le firmware de la prise - sur lequel on a gardé la main, et non pas juste parce qu'une règle logicielle le refuserait après coup. Il n'y a rien à contourner : la fonction a disparu. Sans ce réglage, tout le reste du dispositif serait décoratif, puisque n'importe qui debout devant la prise reprendrait la main sur l'équipement. Ce qui reste. Une remise à zéro d'usine du module rétablirait son comportement d'origine. Elle exige un accès physique prolongé et se signale d'elle-même — le module réapparaît sous son identité par défaut et cesse de répondre au boîtier, ce qui déclenche le mécanisme décrit au point 3 (on a un second rempart !). 2. Débrancher la prise et rebrancher la machine ailleurs L'attaque. La parade du bon sens, et celle que nous voyons le plus souvent oubliée dans les dispositifs concurrents : puisque la prise refuse, on la retire. Et la solution n'est pas d'ajouter de la colle. Ce qui s'y oppose. Chaque prise est alimentée par une voie du module de tête, dans l'armoire électrique. Si le boîtier perd la liaison avec une prise pendant plusieurs cycles consécutifs, il coupe la voie qui l'alimentait et inscrit l'événement au journal comme critique. Mais seulement après avoir tenté de la retrouver, pour ne pas réagir à une simple gêne radio : on a sélectionné des composants fiables mais abordables, le but étant de pouvoir passer à l'échelle et équiper toutes les prises. Pourquoi cela tient. Parce que la coupure se produit en amont de l'organe retiré, donc à un endroit que l'attaquant n'a pas en main lorsqu'il manipule la prise. Le contournement le plus simple se paie par une coupure et laisse une trace. Ce qui reste. D'abord, la protection ne couvre que ce qui est alimenté par le module de tête : brancher la machine sur une prise murale située hors du périmètre sort du dispositif, et relève de l'installation électrique, pas du contrôle d'accès. 3. Rejouer un ordre capturé L'attaque. Enregistrer les échanges radio pendant qu'un porteur légitime obtient l'accès, puis les rejouer plus tard pour obtenir le même effet. C'est l'attaque classique contre tout dispositif qui se contente de chiffrer. Il y a encore deux ans, c'était un contournement lourd nécessitant des connaissances. Depuis la diffusion des Flipper Zero et autres dispositifs, même votre grand-mère pourrait apprendre à le faire. Ce qui s'y oppose. Quand l'application se connecte au boîtier, celui-ci tire un aléa de trente-deux octets et attend en retour une attestation signée par l'autorité, accompagnée de la signature de cet aléa par la clé de l'appareil. L'aléa est consommé quoi qu'il arrive , que la tentative réussisse ou échoue. C'est notre contribution spécifique, cela n'existait pas dans les équipements sur étagère. Trois contrôles complètent la vérification des mises à jour de droits : une mise à jour destinée à un autre boîtier est refusée ; une mise à jour dont le numéro de séquence n'est pas supérieur au dernier appliqué est ignorée ; et la liste des porteurs autorisés est remplacée intégralement , jamais fusionnée. Pourquoi cela tient. Parce que le rejeu ne devient pas seulement inefficace, il devient impossible à répéter et il est détectable : chaque tentative brûle l'aléa en cours, et chaque paquet ancien se heurte à une séquence qui ne recule pas. Sans le remplacement intégral, un attaquant pourrait rejouer un ancien paquet pour ressusciter un porteur révoqué : c'est précisément la faille que ferme ce détail d'apparence anodine. Le refus est par ailleurs motivé : le boîtier répond en nommant la raison : aléa absent, autorité non reconnue, preuve de possession invalide, attestation périmée, porteur hors liste, de sorte qu'un rejet se distingue d'une panne, dans le journal comme sur l'écran du superviseur. On a également mis au point un code couleur qui permet en entrant dans une salle de voir d'un seul coup d'oeil ce qui est coupé, ce qui est actif et ce qui a été trafiqué. 4. Se faire passer pour l'autorité L'attaque. Fabriquer une fausse mise à jour de droits pour s'ajouter à la liste des porteurs autorisés, ou pour élargir un créneau. Ce qui s'y oppose. Le boîtier vérifie la signature de l'autorité avec une clé publique inscrite dans son firmware , que le porteur du message ne peut ni fournir ni remplacer. La vérification porte sur les octets exactement tels qu'ils ont été reçus, avant toute interprétation. Pourquoi cela tient. L'ordre des opérations n'est pas un détail : vérifier les octets reçus puis les analyser, plutôt que l'inverse, élimine toute une classe de failles où l'écriture du message diffère d'un octet de ce qui a été signé. Falsifier le contenu casse la signature, sans exception. Quant à l'ancrage de la clé dans le firmware, il impose une mise à jour logicielle pour en changer. C'est un inconvénient que nous préférons largement au risque de voir un attaquant remplacer l'autorité elle-même. Les dispositifs d'OTA (over-the-air) sans avoir à ouvrir le Cube ou ses satellites est désormais très accessibles pour un grand nombre d'équipements, et nous sélectionnons toujours des composants sur lesquels les principes de cybersécurité IT sont applicables, afin de se concentrer sur le spécifique OT. Ce qui reste. Cet ancrage ne vaut que si l'on ne peut pas reprogrammer le composant. Le verrouillage matériel du démarrage et le chiffrement de la mémoire de programme sont donc la suite logique de cette mesure. 5. Faire croire que la vérification fonctionne L'attaque. Elle n'est pas menée par un adversaire, et c'est ce qui la rend redoutable : une vérification cryptographique en panne est silencieuse. Soit elle refuse tout, ce qui se remarque immédiatement, soit bien pire elle accepte tout, et aucun essai fonctionnel du produit ne distingue une signature valide d'un code de contrôle cassé qui répondrait toujours oui. Ce qui s'y oppose. À chaque démarrage, le boîtier exécute un auto-test sur des vecteurs de référence publiés, en contrôlant qu'il accepte une signature authentique et qu'il rejette une signature falsifiée comme un message altéré. Le décodage des données et l'analyse des dates de péremption sont testés de la même manière, y compris sur des cas limites. Pourquoi cela tient. Parce que le test échoue en position sûre : si l'auto-test ne passe pas, le boîtier refuse d'ouvrir son canal d'administration plutôt que de le servir sans contrôle. Un dispositif dont la cryptographie serait défaillante ne se contente pas de le signaler, il cesse d'accepter des ordres. 6. Remonter l'horloge pour s'ouvrir un créneau L'attaque. Le planning autorise un porteur de sept heures à vingt-deux heures. Il est vingt-trois heures. Il suffit de convaincre le boîtier qu'il est quinze heures. Ce qui s'y oppose. Le réglage de l'heure est traité comme une opération modifiante , au même titre qu'une mise à jour de droits : il exige une session authentifiée. Sans elle, la demande est refusée avec son motif. Pourquoi cela tient. Parce que l'horloge n'est pas une commodité technique mais un paramètre de sécurité : elle conditionne les créneaux, la péremption des attestations et la datation du journal. La laisser librement modifiable revenait à offrir un contournement de tout le reste, et à permettre de dater n'importe quoi. Dans le monde de l'OT, c'est une arlésienne : on ne compte plus les systèmes qui sont décalés de 12h, qui sont toujours à l'heure d'hiver en plein été, qui ne connaissent pas les jours fériés. Et c'est souvent une des premières causes d'abandon, en particulier en GTB, GTC, CVC, etc... Ce qui reste. Un cas limite mérite d'être connu : au tout premier démarrage, avant qu'une heure sûre n'ait été fournie, la péremption des attestations ne peut pas être évaluée. Le boîtier laisse alors passer ce contrôle précis : la signature de l'autorité restant, elle, exigée et l'exception est inscrite au journal . C'est un compromis assumé, visible en audit, et resserrer ce comportement figure au registre selon vos exigences à venir. 7. Effacer une ligne gênante du journal L'attaque. Bricoler le système, obtenir l'accès (ou pas, c'est ce qu'on prétend) puis faire disparaître la trace. Ou, plus subtil, se servir de la navette pour égarer une remontée (une app mobile permet de récupérer les logs locaux pour les amener en zone de couverture réseau : couper l'app mobile coupe l'accès sur le serveur d'administration). Ce qui s'y oppose. La purge du journal exige une session authentifiée, et le boîtier refuse d'acquitter des entrées qui n'existent pas encore. Chaque session porte par ailleurs un identifiant tiré au démarrage, ce qui permet à l'application de détecter qu'un accusé provient d'une session antérieure et de ne pas le relayer. Sur le fond, rien n'est considéré comme transmis tant que le destinataire ne l'a pas confirmé : une entrée n'est purgée du boîtier qu'une fois l'autorité l'ayant enregistrée, et le journal des transferts affiché à l'intervenant n'inscrit une ligne qu'après l'accusé du destinataire, jamais après l'envoi. Pourquoi cela tient partiellement. Ces mécanismes empêchent la perte accidentelle et le décalage entre sessions, qui sont les causes réelles de journaux trompeurs. 8. Copier l'annonce du badge L'attaque. Écouter l'annonce d'un badge, la reproduire, se faire détecter comme son porteur. Ou tout simplement passer un badge à son collègue, parce que "c'est plus simple, le principal c'est que le travail soit fait non ?". Ce qui s'y oppose au niveau du badge. Rien. L'annonce circule en clair, elle est identique d'une fois sur l'autre, et quelqu'un qui l'écoute peut la reproduire. Nous ne présentons donc jamais le badge comme un facteur d'authentification : il répond à la question « un porteur déclarant cet identifiant est-il à proximité ? », et à aucune autre. Ce qui s'y oppose ensuite. Le badge n'est pas la barrière, il est le déclencheur. Restent en travers du chemin le planning du porteur usurpé, la persistance de la présence (l'accès se coupe dès que l'annonce disparaît) l' intégrité de l'organe de coupure, et le journal , qui enregistrera l'accès au nom du porteur légitime, à une heure où celui-ci pourra dire où il était. Pourquoi c'est acceptable ici. Parce qu'un adversaire qui analyse un format d'annonce pour le reproduire a quitté le profil de l'opportuniste. La mesure du risque n'est pas « est-ce faisable ? » puisque ça l'est, mais « est-ce que cela correspond à quelqu'un qui se présente réellement dans cet atelier ? ». C'est un jugement, il est révisable, et il change dans les contextes traités plus tard par un autre article sur les cas les plus sensibles. Ce qui reste. Le point le plus faible de l'assemblage, identifié comme tel, peut être traité sans changer de matériel par une charge d'annonce qui varie à chaque émission. Mais pour ceux qui le souhaitent, il existe de très bons badges qu'on pourrait intégrer. Ou doubler le badge dans la poche d'une carte d'identification sécurisée qu'on passe sur le Cube en NFC, mais là encore il y a le problème de prêter son badge : autant passer à la solution de confirmation sur app mobile qu'on a déjà intégrée en plus du badge déclencheur. 9. Relayer la présence d'un porteur légitime L'attaque. Retransmettre la conversation entre un porteur resté au vestiaire et la machine visée, de façon à fabriquer une présence parfaitement authentique. Ici on ne vole pas le badge, on crée une passerelle entre les deux (le retour de notre ami Flipper Zero qui a ouvert la boite de Pandore de la sécurité des systèmes cyberphysiques). Ce qui s'y oppose. Rien de cryptographique, et il faut le dire sans détour : aucune signature ne voit ce type d'attaque, puisqu'aucun message n'est falsifié. Ce qui est falsifié, c'est la proximité, et la proximité n'est pas une propriété que l'on signe. Ce qui augmente le coût, en revanche : la présence doit être maintenue pendant toute la durée d'usage, le créneau du porteur doit être ouvert au même moment, et l'accès est journalisé à son nom. Ce qui reste. Une vulnérabilité réelle, structurelle, et que seule une mesure de distance par temps de vol referme. Nous ne prétendons pas la couvrir dans notre solution actuelle, mais on peut vous expliquer les solutions à base d'UWB, pour une V2 si vous nous apportez la nécessité et le budget associé. 10. Voler le téléphone d'un intervenant L'attaque. Récupérer l'appareil qui porte l'attestation et s'en servir pour déposer de faux réglages ou purger un journal. Ce qui s'y oppose. L'application exige une validation biométrique avant les opérations sensibles, et systématiquement en mode urgence. L'attestation de l'appareil a une durée de vie limitée, et la révocation d'un appareil prend effet dès la première mise à jour de droits appliquée, le porteur en session étant alors déconnecté logiquement séance tenante. Pourquoi cela tient. Parce que le téléphone ne décide rien : il transporte des objets signés par l'autorité et vérifiés par le boîtier. Le voler donne le droit de porter , pas celui d' émettre . Ce qui reste. La révocation ne se propage qu'au passage suivant d'un appareil autorisé car c'est le prix du fonctionnement sans réseau. Et la clé de l'appareil, si elle réside dans un stockage protégé, n'est pas encore générée dans une enclave matérielle : elle est protégée du reste de l'appareil, elle n'est pas non extractible. On rentre alors dans la cybersécurité IT classique. Break-glass : une porte de sortie, scellée et tracée. Un responsable désigné peut forcer l'accès en urgence par une procédure hors ligne : un code à usage unique, imprimé et scellé dans une enveloppe inviolable déposée dans chaque zone, scanné puis validé par biométrie sur son téléphone. Le code est consommé à l'usage : une enveloppe ouverte est une enveloppe à remplacer. L'accès est accordé immédiatement, horodaté, signé, et remonté au premier rapport, avec obligation de remise en service explicite du dispositif. Nous ne plaçons jamais ce code de manière permanente sur ou dans un équipement : ce serait rendre le contournement disponible en permanence à la personne contre laquelle le dispositif est installé. 11. Couper le courant du boîtier, ou brouiller la radio L'attaque. Ne pas chercher à obtenir l'accès, mais à faire tomber le dispositif en espérant qu'il s'ouvre. Ce qui s'y oppose. Un Cube hors tension ne commande plus rien, et les prises restent dans l'état de refus si c'était votre choix ; une radio brouillée fait disparaître la présence, ce qui coupe. Il n'existe pas de chemin par lequel une dégradation ouvre un accès non prévu. Pourquoi cela tient. Parce que la direction de la panne a été choisie à la conception, et non subie. C'est la propriété la plus importante de tout le dispositif, et celle que nous vérifions en premier. Ce qui reste. Le revers, qu'il faut assumer devant l'exploitant : ce dispositif est déniable de service . Quelqu'un qui veut empêcher la production plutôt qu'obtenir un accès y parviendra en brouillant la bande, et la réponse à cela n'est pas technique mais organisationnelle — procédure de dérogation, mode urgence, supervision de la disponibilité radio. On n'est plus dans sécurité, on est à la lutte contre la pince coupante, ce qui doit être résolu par un contrôle d'accès au bâtiment et une bonne gestion des ressources humaines. 12. Attaquer le serveur d'administration L'attaque. Ne pas se battre avec le terrain, mais viser la clé qui signe les droits distribués à tout un parc. Ce qui s'y oppose. Chaque objet signé porte l'identifiant de la clé qui l'a signé, ce qui rend une rotation possible sans réaprovisionner l'ensemble des équipements ; et le serveur refuse de signer si sa clé n'est pas présente, plutôt que d'improviser une clé volatile qui invaliderait silencieusement tout ce qui a déjà été distribué. Ce qui reste. C'est aujourd'hui le point le plus sensible de la chaîne, et il serait malhonnête de le présenter autrement : la compromission de cette clé vaut compromission de tout le parc. Sa conservation hors ligne, dans un module matériel dédié, avec une cérémonie documentée, est la mesure qui ferme ce risque. Mais là encore, c'est de la cybersécurité IT qui se traite par les moyens adéquats déjà prouvés. Ce que chaque mécanisme prouve, et ce qu'il ne prouve pas C'est le tableau que nous jugeons le plus utile à garder sous les yeux, parce qu'un dispositif solide n'est pas celui qui empile le plus de mécanismes, mais celui dont chaque mécanisme est employé pour ce qu'il prouve réellement. Mécanisme Ce qu'il prouve Ce qu'il ne prouve pas Annonce du badge Qu'un émetteur portant cet identifiant est à proximité L'identité car la charge est copiable Filtre de puissance et fenêtre de maintien Une proximité radio plausible et durable Une distance réelle : le signal se relaie Aléa à usage unique Que l'échange est frais et non rejoué Que l'interlocuteur est physiquement là Signature de l'autorité L'origine et l'intégrité des droits distribués Que la clé d'autorité est bien gardée Séquence croissante et destinataire lié Qu'un ordre ancien ou détourné ne s'applique pas — Auto-test au démarrage Que la vérification fonctionne réellement Que le firmware n'a pas été remplacé Bouton désolidarisé Que le geste local ne commande plus le relais Qu'un retour aux réglages d'usine soit impossible Surveillance de l'organe Qu'un retrait est détecté et tracé Que la machine ne soit pas rebranchée hors périmètre Journal remonté par navette Ce que le dispositif a décidé, et quand Qu'aucune entrée n'ait été retirée en chemin Position de repli au refus Qu'aucune panne n'ouvre un accès Que le dispositif reste disponible Comment le vérifier plutôt que nous croire Le problème du chiffrement déclaré Il existe, dans ce domaine, un écart entre ce que les fiches techniques annoncent et ce que les équipements font et cet écart n'est pas toujours de la mauvaise foi. Une suite cryptographique peut être déclarée dans un format de données sans être employée sur le canal ; un appairage peut être supporté sans être exigé ; une donnée peut être lisible sans authentification alors que le produit est vendu comme chiffré. Nous avons pris le parti de traiter cette question comme un problème de test plutôt que comme un problème de communication : énoncer les propriétés que le lien devrait tenir, les mesurer une par une, et faire échouer bruyamment celles qui ne le sont pas. C'est ce banc qui a produit le registre ci-dessus, et non l'inverse. Notre démarche d'accompagnement à la mise en place vise donc à reproduire sur votre installation ces mesures d'exécution des dispositifs de sécurité avant la mise en service. Pourquoi cela suffit dans la grande majorité des ateliers Reprenons les douze attaques. Sept sont fermées par construction : le bouton, l'ordre rejoué, l'autorité usurpée, la vérification défaillante, l'horloge remontée, le téléphone volé, la panne provoquée. Une est détectée et tracée en attendant d'être bloquée. Quatre restent ouvertes. Or ces quatre-là (copier une annonce après l'avoir analysée, monter un relais, écouter le canal pour en tirer parti, substituer un module) ont un point commun : elles exigent toutes de quitter le profil de l'opportuniste . Elles supposent du matériel, du temps, une intention, et le plus souvent un retour sur les lieux. C'est là que se joue notre jugement pour distinguer deux solutions, et nous vous les présentons comme telles : dans un atelier, une salle machine, un entrepôt où la menace réaliste est le raccourci de personnes légitimes mais non autorisées, il suffit que tous les raccourcis coûtent plus cher que la procédure normale, et si c'est votre cas, vous serez client. Dans un site où quelqu'un accepte de mettre le prix financier et technique pour réussir à entrer, ce raisonnement ne tient plus et il faut alors un autre dispositif, avec les solutions matérielles, procédurales et logicielles adéquates, à hauteur du préjudice potentiel. Le reste est une affaire de proportion. Quatre modules du commerce, aucune intervention sur les équipements, aucune requalification de procédé, aucune dépendance réseau, et un registre de douze lignes que l'on peut mettre sur la table. Voilà ce que nous pouvons déjà mettre en place chez vous dès à présent !

Retrofit OT : ajouter plutôt que modifier

23/08/2026Pascal Flamand

On s'est régulièrement frotté à la question de « sécuriser » une machine industrielle, et la première idée qui venait consiste à chercher les moyens prévus par le constructeur pour modifier un module ou modifier le logiciel des cartes électroniques. Nous avons fini par faire un choix différent parce qu'une fois mis bout à bout ses effets sur le coût, la conformité et la sécurité, il nous a semblé le plus raisonnable. Voici le cheminement qui nous y a conduits. Une machine industrielle ne se gère pas comme un serveur Des équipements pensés pour durer Là où l'informatique de gestion se met à jour, se redémarre et se remplace à un rythme de quelques années, un automate des années 2000, un frigo ou une presse hydraulique ont été conçus pour durer quinze ou vingt ans. Ils l'ont été à une époque où personne n'imaginait qu'il faudrait un jour leur adjoindre une authentification forte. Aucune prise naturelle pour la cybersécurité Ces équipements ne sont pas obsolètes pour autant : ils font exactement ce qu'on attend d'eux. Mais ils n'offrent aucune fonctionnalité propre aux mécanismes de sécurité modernes. Et les remplacer n'est, le plus souvent, ni souhaitable ni finançable. C'est précisément à partir de ce constat que, selon nous, le retrofit reste possible et mérite d'être repris avec des composants additionnels dédiés. Modifier l'existant : un coût rarement anticipé La tentation est de mettre la machine « à niveau » en intervenant directement dessus. Or toucher au cœur d'un équipement industriel entraîne une série de conséquences que l'on sous-estime souvent au moment de la décision purement financière ("il ne faut pas que ça coûte plus cher que racheter une machine récente") ou technique ("si déjà on peut y arriver, ce sera bien suffisant"). La conformité remise en cause Une machine porte un marquage CE et une évaluation de sûreté qui reposent sur une configuration précise. Ouvrir l'armoire, recâbler ou insérer un module dans le circuit peut suffire à remettre cette conformité en cause, voire à imposer une nouvelle analyse de risque. La responsabilité déplacée Intervenir sur l'équipement d'un fabricant revient fréquemment à endosser une part de sa garantie. Ce qui relevait de sa responsabilité devient, dès l'ouverture du capot, un peu de la vôtre. La disponibilité mise à mal Une intervention sur un équipement en production se traduit par un arrêt, un planning et un risque. Sur un site critique, cela n'a rien d'anodin. La dette de maintenance Chaque modification finit par devenir un cas particulier, qu'il faudra documenter, maintenir et comprendre pendant toute la durée de vie de la machine. Additionnées, ces contraintes font qu'on hérite bien souvent du problème que l'on cherchait à résoudre. Le module « dans l'armoire » ne résout rien, il déplace le problème Une variante paraît plus habile : plutôt que de reprendre la machine, on y ajoute un module intelligent. Entrer dans la machine, c'est la modifier Mais dès l'instant où l'on pénètre dans l'équipement, on le modifie — avec exactement les mêmes conséquences que précédemment. Deux maîtrises que l'on abandonne Ce faisant, on renonce en prime à deux formes de maîtrise. Celle du coût, d'abord, puisque chaque intégration devient un travail sur mesure, difficilement réplicable d'un site à l'autre . Celle de la sécurité, ensuite, puisqu'on greffe un composant à l'intérieur d'un système que l'on ne connaît jamais entièrement. Sur le terrain le plus exigeant qui soit, cela fait beaucoup d'inconnues. Notre choix : des équipements annexes, à la frontière de la machine Nous avons donc préféré une autre voie, qui consiste à déposer des boîtiers autonomes venant s'intercaler à la frontière de l'équipement — sur le câble d'alimentation, sur la liaison radio, sur le bus série ou sur le port réseau — plutôt qu'en son sein. Une ancre, des satellites Le modèle que nous suivons tient en une image : une ancre et des satellites. Un boîtier de décision, que nous appelons le Cube, tient lieu d'ancre de confiance pour une zone. Des effecteurs, les satellites, appliquent la décision, à raison d'un par interface. On n'entre jamais dans la machine L'équipement existant, lui, n'est jamais touché. Sa conformité demeure intacte, son fabricant reste seul responsable de son cœur, et l'ensemble du dispositif peut être retiré sans laisser la moindre trace. Un parti pris, pas une loi universelle Ce n'est pas une règle absolue, et d'autres approches se défendent. C'est un choix — mais un choix que nous assumons, parce qu'il préserve ce qui fonctionne déjà. Le moins de développement spécifique possible Ce choix n'aurait qu'un intérêt limité s'il nous obligeait à réinventer chaque brique. Nous nous imposons donc une règle complémentaire : réduire au strict minimum les développements spécifiques, en assemblant des modules déjà éprouvés plutôt qu'en concevant du sur-mesure. L'exemple Shelly : beaucoup de fonctions dans un très petit boîtier Le module Shelly illustre bien pourquoi nous préférons assembler plutôt que concevoir. Dans un composant minuscule et peu coûteux se trouvent déjà réunis le WiFi, le Bluetooth Low Energy, des protocoles dédiés comme Matter, la mesure de puissance et un relais de coupure. Le tout est capable de tenir dans un boîtier étanche muni de deux simples presse-étoupes — l'un pour l'arrivée, l'autre pour le départ — ce qui suffit à protéger un équipement en extérieur ou en milieu humide. Le rapport entre le prix et les fonctions embarquées est, très honnêtement, difficile à égaler avec un développement maison. Les protocoles de sécurité que l'on peut empiler dessus Ce petit module ne se contente pas d'être polyvalent : il offre déjà plusieurs couches de sécurité sur lesquelles s'appuyer, et d'autres que l'on peut activer ou ajouter par-dessus. Nous les résumons ici, car ils mériteront un article à part entière. Au niveau réseau, le WiFi en WPA2 / WPA3 et le MQTT protégé par mTLS chiffrent et authentifient les échanges. Matter apporte son propre modèle, avec une attestation de l'appareil fondée sur des certificats et un appairage sécurisé lors de la mise en service. Le firmware d'origine, lui, se met à jour par un canal signé, ce qui limite le risque d'altération à distance. L'accès local — interface web, appels RPC — peut être authentifié, et l'entrée physique découplée du relais, de sorte que le bouton signale sans jamais commander directement. Par-dessus cet existant, nous ajoutons enfin notre propre couche : des capacités éphémères signées, une décision prise localement, et un comportement à l'arrêt par défaut en cas de doute. L'essentiel, à ce stade, est de constater qu'un module standard peut porter une sécurité sérieuse sans développement spécifique lourd. Nous détaillerons ces protocoles, et la manière de les combiner, dans un prochain article. Ce que nous en gardons De ce module, nous ne conservons que le comportement souhaité : la commande passe par notre boîtier, l'entrée physique se contente de signaler, et le relais n'obéit qu'à la décision locale. Nous pouvons désactiver toutes les fonctionnalités annexes, notamment le Cloud propriétaire ou la commande par une application sur smartphone. Le matériel est éprouvé, son fabricant documenté, et son protocole ouvert nous évite de repartir d'une feuille blanche. Nous pouvons appliquer la même logique avec beaucoup de composants, issus de l'IoT parfois même en accès grand public, en les réduisant à notre contexte industriel hors réseaux et en y ajoutant notre savoir-faire. Des briques open source, logicielles et matérielles Pour le reste, nous privilégions les briques open source , aussi bien logicielles que matérielles. Les firmwares que nous développons sont publiés sous licence libre et reposent sur des cadres ouverts et audités, comme le ESP-IDF d'Espressif ou le Zephyr RTOS de la Linux Foundation. Côté matériel, nous bâtissons sur des plateformes ouvertes — cartes à microcontrôleur documentées, conceptions partagées, modules cellulaires open hardware comme Walter , dont les schémas et l'empreinte KiCad sont publiés — qui nous permettent de comprendre exactement ce que nous déployons. Le développement propre se limite à la chaîne de confiance Le travail que nous conservons en propre se concentre alors sur ce qui fait réellement notre valeur : la chaîne de confiance qui relie ces briques entre elles, et non la plomberie qui les fait fonctionner. Le double effet : coût et sécurité Ce parti pris a un double effet, et c'est pour cela que nous y tenons. Il maîtrise le coût , puisqu'un module standard a un prix connu d'avance et réplicable d'un site à l'autre. Il maîtrise également la sécurité , puisqu'un composant que nous avons choisi, dont nous connaissons le firmware et le comportement, se laisse auditer et durcir. S'interfacer avec un maximum de matériels Un même schéma, interface par interface L'autre mérite de l'approche annexe est qu'elle reste largement agnostique quant à la machine protégée, un même schéma se déclinant interface par interface : couper une alimentation 230 V, filtrer un clavier ou une souris USB, proxifier un périphérique sans fil, segmenter un port Ethernet, ou s'intercaler sur un bus série RS-485 / Modbus. Enrôler du legacy sans le modifier Dans chaque cas, on enrôle un équipement ancien sans le modifier : on l'observe, on l'entoure, et l'on agit à sa frontière. Ce qui fonctionne aujourd'hui, ce qui vient Précisons que l'effecteur aujourd'hui pleinement opérationnel est la coupure d'alimentation. Les autres interfaces figurent sur notre feuille de route et reposent sur le même principe. La primeur aux clients qui nous solliciteront sur un nouveau cas particulier ! Des briques concrètes, et où les trouver Pour rendre tout cela tangible, voici quelques exemples de ce que l'on peut faire sans toucher à la machine, et les solutions — commerciales ou open source — sur lesquelles s'appuyer. Quelques exemples Couper l'alimentation d'un variateur récalcitrant au moyen d'un Shelly Pro 1PM posé sur le rail DIN de l'armoire, sans jamais ouvrir le variateur lui-même. Repérer un traceur BLE isolé, ou une télécommande 433 MHz suspecte, à l'aide d'une passerelle radio d'écoute. Isoler un segment automate derrière une passerelle réseau, sans avoir à reconfigurer l'automate. Dialoguer en lecture seule avec un automate Modbus ancien pour l'inventorier, sans jamais y écrire. Une petite boîte à outils Coupure et mesure d'énergie — Shelly (modules du commerce, du rail DIN à la prise), avec pour firmware libre alternatif ESPHome ou Tasmota . Embarqué open source — ESP-IDF et Zephyr RTOS pour le logiciel ; Walter et ses dépôts QuickSpot pour un matériel cellulaire ouvert. Racine de confiance matérielle — l'élément sécurisé STSAFE-A120 de STMicroelectronics, sur une plateforme certifiée Critères Communs EAL5+, complété par le cadre IoT SAFE de la GSMA. Écoute BLE et sub-GHz — OpenMQTTGateway (BLE et 433 / 868 MHz) et les décodeurs rtl_433 . Réseau et bus de terrain — OpenWrt pour segmenter un port Ethernet, libmodbus pour s'interfacer avec un bus RS-485 / Modbus. Conception des satellites — l'outil de CAO électronique libre KiCad , qui nous sert d'ailleurs à publier nos propres schémas. Aucune de ces briques n'est un secret, et c'est précisément l'intérêt. Le sur-mesure, nous le réservons à ce qui fait vraiment la différence : la chaîne de confiance qui les relie. Un retrofit réussi tient plus de la couche que de la greffe Réversible plutôt que définitif Greffer un organe, c'est toujours prendre le risque du rejet. Ajouter une couche, c'est au contraire rester réversible, chiffrable et maîtrisé. Sans prétendre rendre la machine neuve Nous ne prétendons pas, ce faisant, rendre la machine « neuve ». Un accès physique prolongé demeure un accès physique, et nous préférons le documenter plutôt que de le nier. La façon la plus honnête de sécuriser un parc installé Cette approche a le mérite de ramener de la confiance là où il n'y en avait pas, sans rien imposer à ce qui fonctionne déjà. C'est, à nos yeux, la manière la plus honnête de sécuriser un parc installé que l'on ne peut pas remplacer. Envie de voir le principe en fonctionnement ? Lors d'une démonstration, vous prenez la place de l'intrus : vous tentez de mettre le système en échec, il réagit sous vos yeux, et vous repartez avec le journal d'audit signé de vos propres essais.

IAM pour vos équipements électriques - Part 1

18/08/2026Pascal Flamand

Pourquoi le dernier point d'application de la politique de sécurité qui vous reste à implémenter est la prise de courant. Article destiné aux praticiens de l'IAM. Vous y trouverez la transposition dans un domaine où votre discipline est indispensable et presque totalement absente. Une scène qui parlera au plus grand nombre Vendredi, 22 h 40. Dans un atelier d'usinage, une machine cinq axes se met en route. Elle tourne quarante minutes, produit onze pièces, puis s'arrête. Posez maintenant les questions que vous poseriez pour n'importe quelle ressource de votre système d'information. Qui a démarré cette machine ? Quelle source d' identité a été présentée, et authentifiée comment ? Cette identité disposait-elle d'une autorisation valide à cet instant, sur cette ressource ? Où est la trace ? Qui révoque cet accès quand l'intervenant quitte le prestataire ? Quand a eu lieu la dernière campagne de recertification sur le droit « démarrer la cinq axes » ? Sur la plupart des sites industriels où l'on prend la peine de poser ces six questions, on obtient six fois la même réponse : rien. Pas une réponse imparfaite : rien, car il n'existe ni objet, ni journal, ni politique. La machine ne sait pas qui l'utilise (à la rigueur un planning d'interventions et une présence dans les locaux) et personne n'a jamais eu de moyen de le lui demander. C'est une conséquence d'architecture et un héritage important du clivage OT/IT. C'est exactement le genre de trou pour lequel l'IAM a été inventé : sauf que l'IAM, tel qu'on le pratique, ne sait pas l'atteindre. Où votre chaîne IAM s'arrête, physiquement Rappelons la chaîne, dans le vocabulaire que nous partageons tous : une identité est établie et provisionnée, un authentifiant en prouve la détention, un PDP évalue une politique, un PEP applique la décision sur le chemin d'accès, une session est ouverte puis réévaluée, un journal produit la preuve, et une revue ferme la boucle. Cette chaîne repose sur une hypothèse que nous ne formulons plus tellement elle est acquise : il existe un chemin numérique entre le sujet et la ressource, et nous pouvons nous y insérer. Un proxy inverse, un agent, un connecteur SCIM, un broker PAM, un contrôleur de domaine, une passerelle applicative. Le PEP est un morceau de logiciel posé sur ce chemin. Retirez le chemin numérique, et la chaîne entière devient inapplicable. C'est pourtant la situation de l'écrasante majorité des équipements industriels sensibles en service aujourd'hui : Un automate installé en 2003 dont le seul contrôle d'accès est un commutateur à clé sur la face avant, avec trois clés en circulation et une quatrième perdue depuis six ans. Une armoire électrique dont l'ouverture est protégée par une clé triangle qu'on achète en ligne pour le prix d'un café. Un banc d'essai, un four, un autoclave, une presse, une machine d'électroérosion : des équipements dont l'usage non autorisé n'est pas un risque de confidentialité mais un risque de sécurité physique, de contrefaçon, de sabotage ou de détournement d'usage. Un équipement raccordé au réseau électrique du site, mais délibérément non raccordé au réseau informatique, précisément parce que son exploitant a jugé et souvent à juste titre que la connexion créerait plus de risque qu'elle n'en traiterait. Face à ce parc, la réaction réflexe du monde IT est d'exiger la connexion au réseau informatique : « connectez-le, et nous le gouvernerons ». C'est une réponse coûteuse, lente, et souvent contre-productive. Connecter une machine (et surtout chaque machine !) conçue parfois à une époque où la sécurité réseau ne figurait dans aucun cahier des charges, pour pouvoir la superviser, revient à créer une surface d'attaque... afin de pouvoir surveiller la surface d'attaque que l'on vient justement de créer ! Il existe une autre voie. Notre thèse : l'alimentation est le seul point d'application universel Tous ces équipements ont un point commun, sans exception. Ils sont alimentés en électricité. Une machine sans courant ne produit pas, ne chauffe pas, ne tourne pas, ne communique pas et ne se laisse pas reprogrammer. L'alimentation électrique est le préalable absolu à tout usage. Elle possède, du point de vue d'un architecte IAM, des propriétés remarquables : Elle est universelle. Aucune hypothèse sur le protocole, le firmware, l'âge, le constructeur ou la présence d'une pile IP. Le contrôle s'applique de la même façon à un automate Schneider de 1998 et à une machine livrée le mois dernier. Elle est antérieure à la couche logique. Un PEP logiciel s'exécute après le démarrage de la cible et dépend de son intégrité. Un PEP électrique s'applique avant que la cible n'existe fonctionnellement. Aucune vulnérabilité du firmware de l'équipement ne permet de contourner l'absence de courant. C'est un deny non contournable par la ressource elle-même, donc une propriété rare que nous ne savons obtenir dans presque aucune architecture logicielle. Elle est binaire et sans état. Pas de session à négocier, pas de contexte à maintenir dans l'équipement, pas de client à installer. Le corollaire est direct : dans une installation sensible, la prise de courant est le point d'application de politique de premier et dernier recours. Cette idée n'est pas neuve mais elle est actuellement non gouvernée. Trois précédents devraient rassurer un lecteur IAM sur le fait qu'il ne s'agit pas d'une bizarrerie conceptuelle : La consignation électrique. La procédure de consignation (en France, cadre NF C18-510) est un contrôle d'accès physique parfaitement structuré : séparation, condamnation, identification, vérification d'absence de tension, puis mise à la terre et en court-circuit. Et dans la pratique du lockout/tagout qui l'accompagne sur la plupart des sites, le cadenas personnel de l'intervenant, avec son étiquette nominative posée sur un moraillon multi-cadenas, est littéralement un jeton d'autorisation mono-porteur appliqué à l'alimentation. Avec, en prime, une sémantique de verrouillage collectif que peu de systèmes IAM savent exprimer. La discipline OT a donc inventé un IAM électrique en quelque sorte... mais cet IAM est sans annuaire, sans expiration automatique, sans journal exploitable et sans révocation à distance. C'est de l'IAM des années 1970, et il fonctionne toujours ainsi. Les PDU commutables. Dans n'importe quel datacenter, l'autorisation par prise (ou unité de distribution d'énergie, PDU) existe depuis un quart de siècle : on coupe et on rétablit un port électrique à distance. Mais le sujet de cette autorisation est un compte d'administration technique, jamais une identité métier porteuse d'une habilitation, c'est donc de l'actionneur sans politique. ISO 15118 et le « Plug & Charge ». C'est le précédent le plus intéressant, et celui que tout praticien IAM devrait apprendre à connaître. Pour la recharge des véhicules électriques, l'industrie a spécifié une authentification des deux extrémités par certificats X.509, échangés sur le câble de charge lui-même , en courant porteur sur la ligne pilote et adossée à une hiérarchie de confiance dédiée : racine V2G, certificats de contrat côté opérateur de mobilité, certificats de borne, certificats de provisionnement embarqués en usine par le constructeur. La première version (ISO 15118-2) n'authentifiait la borne qu'au niveau transport et le véhicule au niveau applicatif ; ISO 15118-20 impose désormais un TLS mutuel. Autrement dit : une PKI complète, avec son cycle de vie, dont la finalité est de décider si l'électricité doit couler, et à qui la facturer. Le monde automobile a donc déjà admis que le câble électrique est un canal d'identité . Le monde industriel, lui, en est resté au cadenas.

IAM pour vos équipements électriques- Part 2

18/08/2026Pascal Flamand

Les cinq réflexes IAM qu'il faut désapprendre C'est ici que le transfert d'application du domaine IT au notre devient délicat : cinq principes que vous appliqueriez sans les repenser deviendraient faux, ou dangereux. 1. « En cas de doute, on refuse » n'est plus une règle universelle En IT, l'échec fermé est la position par défaut et l'arbitrage est presque toujours tranché en faveur de la sécurité. En OT, refuser peut tuer . Couper l'alimentation d'un système de ventilation, d'un groupe de refroidissement, d'un circuit de sécurité ou d'un équipement en phase critique de cycle est une décision de sûreté avant d'être une décision de sécurité. Conséquence pratique : la sémantique du refus doit être définie équipement par équipement , et cet arbitrage n'appartient pas à l'équipe sécurité. Il appartient conjointement à la sécurité, à l'exploitation et au HSE. Certains équipements seront en fail-secure (on coupe), d'autres en fail-safe (on laisse, on trace, on alerte), d'autres en fail-degraded (on autorise une fonction réduite). Un modèle de politique OT qui ne sait pas exprimer ces trois issues est inutilisable. C'est une nuance que le Zero Trust, dans sa formulation IT canonique, n'a jamais eu à traiter. 2. La connectivité n'est pas une hypothèse Vous concevez vos architectures en supposant que le fournisseur d'identité IdP est joignable. En environnement industriel ou de défense, l'hypothèse s'effondre : sites isolés par conception, coupures WAN de plusieurs jours, locaux blindés, air-gap, contextes où la connectivité est activement indésirable. Un PDP qui appelle un service distant pour décider est un PDP qui refuse de décider quand ça compte. La décision doit être rendue localement, hors ligne, et rester nominale, pas dégradée. Vous connaissez déjà ce compromis sous une autre forme : la validation locale d'un jeton signé sans introspection auprès de l'émetteur. Mêmes questions, mêmes réponses : politique signée et versionnée, durée de vie bornée, liste de révocation à fraîcheur maximale explicite, source de temps de confiance, réconciliation à la reconnexion. Ce qui change dans notre contexte, c'est l'enjeu : ici, un jeton périmé accepté à tort ne donne pas accès à une API, il donne accès à une machine capable de blesser quelqu'un. 3. L'identité de l'équipement ne peut pas être déclarative En IT, nous faisons confiance à ce que la ressource déclare d'elle-même, parce qu'un agent atteste. En OT, l'équipement ne sait pas qui il est et ne peut rien attester. Pire : il est parfaitement remplaçable. Rien n'empêche de débrancher la machine autorisée et d'en brancher une autre à sa place. D'où un renversement contre-intuitif mais fécond : on n'identifie pas l'équipement, on identifie le point d'alimentation, et on caractérise en continu ce qui y est raccordé. La signature électrique et radioélectrique d'un équipement branché est un attribut observable — et sa modification devient un événement d'identité à part entière. Cela crée une primitive qui n'existe pas en IAM classique : la détection de recâblage comme signal de sécurité. Un intervenant légitime, avec une habilitation valide et un ordre de travail conforme, qui branche un équipement non prévu sur un point contrôlé, produit un événement que votre politique doit savoir qualifier. 4. La preuve doit survivre à l'auditeur, pas au SIEM Votre journalisation est conçue pour la détection : volume élevé, valeur unitaire faible, rétention courte, chemin réseau vers un collecteur. Ici, c'est l'inverse. Le volume est faible : quelques dizaines d'événements par machine et par mois. La valeur unitaire est très élevée. Et l'usage n'est presque jamais la détection temps réel : c'est la preuve rétrospective , examinée dix-huit mois plus tard par un assureur, un client donneur d'ordre, une autorité ou un juge d'instruction, pour répondre à une question simple : qui a mis cette machine sous tension le 14 mars à 22 h 40, et sur quel fondement ? Un journal qui transite par le réseau vers un SIEM ne répond pas à ce besoin, parce que le réseau était justement coupé le 14 mars. Il faut un journal local, horodaté, chaîné, signé, non répudiable et exportable indépendamment de toute infrastructure. 5. Le sujet n'est ni forcément humain, ni forcément votre Vous vivez déjà la vague des identités non humaines : comptes de service, charges de travail, secrets qui prolifèrent, agents autonomes. Le monde OT ajoute une couche que l'IT connaît peu : une part majoritaire des sujets légitimes n'appartient pas à l'organisation . Intérimaires, sous-traitants de rang 2, techniciens du constructeur en déplacement depuis un autre continent, prestataires de maintenance mandatés par le mainteneur lui-même. Vous devez donc fédérer une identité, vérifier un attribut d'habilitation et l'associer à un ordre d'intervention, sans jamais avoir provisionné la personne, souvent sans annuaire côté fournisseur, et sans réseau au moment de la décision. Ce n'est pas un problème résolu ailleurs et recopié ici. C'est un problème IAM ouvert, et il est passionnant. Ce que les textes disent déjà, et que peu de gens ont lu L'idée que l'IAM appartiendrait au monde IT et la sûreté de fonctionnement au monde OT ne résiste pas à la lecture des normes. IEC 62443. Le référentiel de sécurité des systèmes d'automatisation industrielle est structuré autour de sept exigences fondamentales. La première s'intitule Identification and Authentication Control . Elle distingue explicitement trois catégories de sujets : human user , software process et device , et décline des exigences de gestion des comptes, des identifiants, des authentifiants, de la robustesse des secrets, et de l'usage de certificats à clé publique. En clair : la norme OT de référence place l'IAM en tête de ses priorités, et le fait depuis des années. Ce n'est pas une importation du monde IT ; c'est un chapitre que l'industrie n'a jamais réellement appliqué faute de moyen technique sur le parc existant. Cyber Resilience Act. Le règlement européen est entré en vigueur le 10 décembre 2024. Les obligations de notification des vulnérabilités activement exploitées et des incidents graves s'appliquent depuis le 11 septembre 2026, et l'application pleine interviendra le 11 décembre 2027. Son annexe I demande, sur la base de l'analyse de risque et lorsque cela est pertinent, que les produits comportant des éléments numériques soient protégés contre les accès non autorisés « par des mécanismes de contrôle appropriés, incluant sans s'y limiter l'authentification, les systèmes de gestion des identités ou des accès », et qu'ils rendent compte des accès non autorisés éventuels. La formulation mérite d'être lue deux fois : le régulateur européen écrit « identity or access management systems » dans le corps d'un règlement produit. Le CRA cible le produit et son fabricant — mais l'exploitant qui met en service un parc hétérogène hérite de la question. NIS2 et la loi Résilience. En France, la transposition suit un chemin nettement plus lent que prévu : projet de loi adopté par le Sénat le 12 mars 2025, texte modifié adopté en commission spéciale à l'Assemblée nationale le 10 septembre 2025, mais passage en séance publique repoussé à la rentrée parlementaire de septembre 2026 au plus tôt. Ce retard a fini par coûter cher : la Commission européenne a saisi la Cour de justice de l'Union européenne contre la France, avec l'Irlande, l'Espagne et les Pays-Bas, pour défaut de transposition, en demandant des sanctions financières. L'ANSSI, elle, n'a pas attendu le législateur : elle a diffusé en mars 2026, en document de travail, son Référentiel Cyber France (ReCyF), qui structure une vingtaine d'objectifs de sécurité attendus des entités essentielles et importantes. L'agence évalue à environ 15 000 le nombre d'entités qui basculeront dans le périmètre, contre quelque 250 opérateurs de services essentiels sous NIS1 soit un facteur soixante. Mais le point important n'est pas le calendrier parlementaire. La pression réelle vient des donneurs d'ordre. Les questionnaires de sécurité et les clauses cyber des grands comptes de l'automobile, de l'aéronautique, de l'énergie et de la défense descendent déjà la chaîne de sous-traitance, et ils posent des questions auxquelles la table de correspondance ci-dessus permet de répondre ou pas. Or ces trois textes convergent sur un même point, et c'est le point aveugle : ils demandent tous une preuve. Preuve du contrôle d'accès, preuve de la traçabilité, preuve de la gestion des habilitations. Et la preuve d'un accès physique à un équipement industriel n'existe aujourd'hui presque nulle part.

IAM pour vos équipements électriques- Part 3

18/08/2026Pascal Flamand

Que faire si vous dirigez un programme IAM Inventoriez les ressources critiques dépourvues de toute politique d'accès. Pas les serveurs, pas les applications : les machines, armoires, bancs et équipements dont l'usage non autorisé aurait un impact matériel, humain ou réglementaire, et pour lesquels vous ne pouvez produire ni liste d'ayants droit ni journal d'usage. Dans bien des organisations industrielles, cette liste rivalise en longueur avec celle des applications gouvernées. Elle n'a simplement jamais été dressée, parce qu'elle ne relevait du périmètre de personne : trop physique pour la DSI, trop numérique pour la maintenance. Définissez la sémantique du refus, équipement par équipement, avec la sûreté. C'est le livrable le plus difficile et le plus structurant. Il conditionne toute l'architecture, et il ne peut pas être produit par la seule équipe sécurité. Exigez un point d'application capable de décider hors ligne. C'est le critère qui élimine le plus vite les approches inadaptées. Toute solution qui suppose une liaison permanente vers un service central ne tiendra pas la première coupure — c'est-à-dire précisément le moment où le risque est le plus élevé. Et une chose à ne pas faire : ne connectez pas un équipement au réseau dans le seul but de pouvoir le gouverner. Le contrôle d'accès physique n'a pas besoin que la machine soit intelligente. Il a besoin que le point d'alimentation le soit. Élargir le périmètre, pas la pile L'IAM a passé quinze ans à étendre son domaine : des employés aux clients, des clients aux partenaires, des humains aux charges de travail, des charges de travail aux agents. À chaque étape, la même objection est revenue — « ce n'est pas vraiment de l'identité » — et à chaque étape, elle s'est révélée fausse. L'étape suivante est celle des ressources qui n'ont pas d'adresse IP et n'en auront jamais. Elles constituent le cœur productif des installations sensibles européennes, elles sont soumises aux mêmes exigences réglementaires que le reste, et elles sont gouvernées aujourd'hui par un trousseau de clés et un registre papier. La bonne nouvelle est que votre modèle mental fonctionne : identité, authentification, politique, application, preuve, revue. Il faut seulement accepter que le point d'application ne soit plus un morceau de logiciel sur un chemin réseau, mais un dispositif matériel sur un circuit électrique — et que la décision doive être prise localement, y compris quand plus rien ne répond. C'est ce raisonnement qui a donné naissance à Trust-Buster : un moteur de politique local qui établit l'identité et la légitimité d'une intervention à partir de son environnement physique et radioélectrique, des effecteurs qui appliquent la décision sur l'alimentation de l'équipement, et un journal de preuve exploitable en audit — le tout en fonctionnement nominal, réseau ou pas. L'IAM de l'électricité, en somme. Le même métier que le vôtre, avec un disjoncteur au bout de la chaîne. Vous travaillez sur l'IAM et vous voyez d'autres correspondances — ou d'autres ruptures — entre les deux mondes ? Le sujet est ouvert, et le dialogue entre praticiens de l'identité et gens de l'atelier est exactement ce qui nous pousse à agir aujourd'hui.

Conformité NIS2 : par où commencer concrètement

18/08/2026Pascal Flamand

Tout démarre par un inventaire. Et il s'arrête presque toujours à la porte de l'atelier. Se mettre en conformité avec la directive NIS 2 est devenu incontournable pour les entreprises européennes, en particulier celles qui exploitent des infrastructures critiques. La première étape est un inventaire complet de vos actifs informatiques et industriels , pour savoir où vous êtes exposé. C'est précisément à cette seconde étape que la plupart des programmes prennent un mauvais départ, non parce que l'inventaire est mal fait, mais parce qu'il s'arrête là où le réseau s'arrête. Les actifs qui n'ont jamais figuré sur aucune liste Menez l'inventaire jusqu'au bout et vous produirez deux listes. La première est familière : serveurs, applications, postes, identités, équipements réseau. Chaque élément a un propriétaire, un cycle de correctifs et, en général, une politique d'accès. La seconde, personne ne l'a jamais dressée. Machines. Armoires électriques. Bancs d'essai. Fours, presses, autoclaves, variateurs. Des équipements dont l'usage non autorisé n'est pas un problème de confidentialité mais un problème de sécurité physique, de contrefaçon ou de sabotage. Pour la plupart d'entre eux, vous ne pouvez produire ni la liste de ceux qui ont le droit de les mettre en route, ni le journal de ceux qui l'ont effectivement fait. Cette liste n'est pas absente par négligence. Elle ne relevait du périmètre de personne : trop physique pour la DSI, trop numérique pour la maintenance. Et dans une entreprise de production, d'énergie ou de traitement de l'eau, mais aussi chez un industriel agroalimentaire ou un laboratoire pharmaceutique, etc.. elle est fréquemment plus longue que la liste d'applications gouvernées à côté de laquelle elle se trouve. La dresser est la chose la plus utile que vous puissiez faire pour commencer sainement, parce que tout ce qui suit (analyse de risque, politique de contrôle d'accès, classification des incidents, clauses fournisseurs) est cadré par elle. Ce que l'article 21(2) demande réellement NIS 2 énumère dix catégories de mesures de gestion des risques. Trois d'entre elles concernent directement l'atelier, et méritent d'être relues en pensant à une presse plutôt qu'à un serveur : c) continuité des activités et gestion des crises. Un démarrage non autorisé en plein cycle est un événement de continuité, pas seulement de sécurité. i) sécurité des ressources humaines, politiques de contrôle d'accès et gestion des actifs. Notez l'association. Politique d'accès et gestion des actifs sont nommées dans le même souffle et c'est exactement cette association qui se rompt quand l'actif est une presse munie d'un simple interrupteur, ou même d'un commutateur à clé. j) authentification à plusieurs facteurs ou authentification continue. Écrite pour l'accès logique, certes. Mais rien dans le texte ne l'y confine, et l'authentification continue est précisément ce dont une machine sous tension aurait besoin et ne dispose presque jamais. La directive présente par ailleurs l'ensemble de l'article 21(2) comme une approche tous risques , visant à protéger les systèmes d'information et l'environnement physique de ces systèmes . Cette formule travaille plus dur que la plupart des programmes de conformité ne le reconnaissent. Le mot « physique » est quasi absent de l'article 21 d'où l'angle mort Lisez l'article 21 en cherchant la sécurité physique : vous ne la trouverez presque pas. Cette absence a conduit beaucoup de programmes à conclure, assez raisonnablement, que NIS 2 traite des réseaux et laisse les portes et les machines à quelqu'un d'autre. La Commission ne le lit pas ainsi. Son règlement d'exécution (UE) 2024/2690, adopté en octobre 2024, décline l'article 21(2) en plus d'une centaine d'exigences techniques auditables et l'une des treize sections de son annexe est consacrée à la sécurité physique et environnementale : sécurisation des services support, contrôles d'accès périmétriques et physiques, surveillance, et révision périodique de ces mesures. Le règlement rattache cela aux points c), e) et i) de l'article 21, alors même que la sécurité physique n'y est pas nommée. Soyons précis sur le périmètre, parce que c'est là que les commentaires deviennent approximatifs. Ce règlement d'exécution ne lie qu'un sous-ensemble d'entités : fournisseurs DNS, registres de noms de domaine de premier niveau, services d'informatique en nuage, centres de données, réseaux de diffusion de contenu, fournisseurs de services gérés et de services de sécurité gérés, places de marché en ligne, moteurs de recherche, plateformes de réseaux sociaux, prestataires de services de confiance. Si vous exploitez une usine, il ne s'applique pas à vous. Ce qu'il vous donne en revanche, c'est la lecture que fait la Commission elle-même de l'article 21(2), écrite noir sur blanc et directement applicable quelque part dans l'Union. Le guide technique de mise en œuvre publié par l'ENISA en juin 2025 en reprend la structure et détaille le type de preuve qu'un auditeur s'attendra à voir. Quand votre autorité nationale ou l'auditeur de votre client vous demandera à quoi ressemblent des « mesures appropriées » en matière de contrôle d'accès et de gestion des actifs, c'est la réponse la plus autorisée actuellement disponible par écrit, et elle traite l'alimentation électrique et le périmètre physique comme faisant partie du sujet. Planifier en supposant que l'accès physique aux machines est hors du champ de NIS 2, c'est parier contre le sens du courant. Mais certains veulent encore espérer une simple déclaration d'incompétence sur le sujet et être exonéré. Le plan de réponse à incident, à l'épreuve de l'atelier Un plan de réponse à incident solide est une pierre angulaire de la conformité NIS 2. Il doit décrire des procédures claires de détection, de notification et de traitement et la directive y attache un chronomètre. La cascade 24 h / 72 h / un mois L'article 23 impose une alerte précoce sous 24 heures à compter de la connaissance d'un incident important, une notification plus complète sous 72 heures incluant une évaluation initiale de la gravité et de l'impact, puis un rapport final sous un mois . Ce sont les exercices réguliers qui rendent ces fenêtres tenables ; un plan jamais répété est un document, pas une capacité. On ne peut pas notifier ce qu'on ne sait pas attribuer C'est ici que les actifs industriels font céder le plan, et il vaut mieux le découvrir à froid qu'en situation. Notre cas d'école qu'on reprendra dans nos prochains articles de mise en oeuvre de Trust-Buster est très simple à visualiser. Vendredi, 22h40 . Une machine cinq axes tourne quarante minutes et produit onze pièces : ressources consommées, peut être une douzième emportée, et aucune explication fournie dans les cahiers de production. Lundi, quelqu'un s'en aperçoit et a un doute. Le chronomètre démarre. Sous 24 heures, vous devez une alerte précoce. Sous 72 heures, une évaluation initiale de la gravité et de l'impact transfrontalier. Pour produire l'une ou l'autre, il faut répondre à : qui l'a démarrée, au titre de quelle habilitation, et s'agit-il d'un usage non autorisé ou d'une erreur de planning ? Si le seul enregistrement disponible est le compteur horaire de la machine (non attribué, non signé, remis à zéro à la dernière révision) vous ne pouvez pas répondre. Vous déposerez une notification indiquant qu'un événement s'est produit et que vous investiguez, et vous direz encore la même chose un mois plus tard dans le rapport final. Ce n'est pas un échec de processus, c'est surtout un échec de principe, causé par un journal qui n'a jamais été conçu pour exister. À quoi ressemble une trace exploitable en OT Les exigences sont l'inverse de celles de votre SIEM. Le volume est faible : quelques dizaines d'événements par machine et par mois. Mais la valeur unitaire est très élevée, et le destinataire n'est presque jamais un moteur de détection temps réel : c'est un responsable, un assureur, un donneur d'ordre ou une autorité, qui lira bien plus tard. D'où quatre propriétés : Locale. Le réseau était très probablement coupé, ou absent par conception, au moment qui compte. Horodatée sur une source de temps de confiance. Une horloge OT décalée de douze heures ou restée à l'heure d'hiver en plein été rend toutes les autres propriétés sans valeur (la bise aux tenants de la GTB-GTC qui connaissent bien ce problème). Chaînée et signée , pour qu'une entrée manquante soit visible et non simplement absente. Exportable sans dépendre d'une infrastructure centrale. L'attribution est la partie difficile, et c'est un problème d'identité avant d'être un problème de journalisation. Un journal ne peut enregistrer que l'identité que le point d'application a réellement établie, raison pour laquelle contrôle d'accès et preuve doivent être conçus ensemble, et non l'un après l'autre. La chaîne de sous-traitance : la pression qui arrive avant le régulateur L'article 21(2) d) fait de la sécurité de la chaîne d'approvisionnement une obligation explicite. Traduction : les obligations de vos clients deviennent votre questionnement. En pratique, c'est cette pression-là qui atteint un directeur d'usine en premier. Les donneurs d'ordre de l'automobile, de l'aéronautique, de l'énergie et de la défense envoient déjà des clauses cyber à leurs fournisseurs de rang 2 et 3, et ces clauses demandent de plus en plus des éléments que l'atelier ne sait pas produire : la liste de qui peut exploiter tel équipement, la preuve que les habilitations étaient à jour, la trace des interventions physiques de techniciens tiers. Répondre « nous ne suivons pas cela » est donc d'abord un problème commercial bien avant d'être un problème réglementaire. Trois endroits où les réflexes habituels ne se transposent pas Brièvement, chacun mériterait son propre traitement et nous le détaillerons dans nos autres publications, sur la solution Trust-Buster ou à titre d'illustration de la problématique : L'échec fermé n'est pas automatique. En informatique de gestion, refuser en cas de doute est la position par défaut. Couper l'alimentation d'un système de ventilation ou d'un groupe de froid est une décision de sûreté avant d'être une décision de sécurité. Le sens du refus doit être défini équipement par équipement, conjointement avec l'exploitation et le HSE. Encore plus de journal et de règles mais c'est vital. La connectivité n'est pas une hypothèse. Un point de décision qui appelle un service distant est un point de décision qui s'abstient pendant une coupure c'est-à-dire exactement quand le risque culmine. La décision doit être rendue localement et rester nominale, pas dégradée. La plupart des sujets légitimes ne sont pas les vôtres. Intérimaires, sous-traitants de rang 2, techniciens constructeur venus d'un autre continent. Vous devez vérifier une habilitation et l'associer à un ordre d'intervention sans avoir jamais provisionné la personne, souvent sans annuaire côté fournisseur. Et tout ça pour laisser des interrupteurs et des prises électriques libres sans contrôle. Où en est la France, et pourquoi cela ne repousse pas votre échéance La situation française mérite d'être posée précisément, parce qu'elle est régulièrement mal résumée. Cocorico, sport national. La directive imposait une transposition pour le 17 octobre 2024. Le véhicule législatif retenu est le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité , qui transpose d'un seul tenant trois textes européens : NIS 2, la directive REC sur la résilience des entités critiques, et des dispositions relatives à DORA. Il a été présenté en Conseil des ministres le 15 octobre 2024, deux jours avant l'échéance européenne puis adopté par le Sénat en première lecture les 11 et 12 mars 2025, puis adopté en commission spéciale à l'Assemblée nationale les 9 et 10 septembre 2025. Depuis, l'examen en séance publique n'a pas eu lieu. Le texte ne figurait pas à l'ordre du jour de la session extraordinaire de juillet 2026, ce qui reporte son examen à la rentrée parlementaire au plus tôt. Le 8 juillet 2026, la Commission européenne a saisi la Cour de justice de l'Union européenne contre la France (ainsi que l'Irlande, l'Espagne et les Pays-Bas) pour défaut de notification de la transposition complète, en demandant une somme forfaitaire et une astreinte journalière. On passe d'un retard administratif à une procédure contentieuse assortie de sanctions financières. L'ANSSI, de son côté, n'attend pas : elle a ouvert le portail Mon Espace NIS2 et encourage les entités concernées soit environ quinze mille, contre quelque deux cent cinquante opérateurs de services essentiels sous NIS 1, à s'y enregistrer. Elle précise en même temps, sans ambiguïté, que son Référentiel Cyber France reste à ce stade un document de travail et que les obligations NIS 2 ne deviendront juridiquement opérantes qu'une fois les mesures de transposition adoptées. Justement on a un bel article sur 2027 et ses joyeusetés pour les machines. Il est tentant de lire tout cela comme un répit. C'en est un sur le plan strictement juridique, et c'en est un piège sur le plan opérationnel, pour trois raisons : Les clauses de vos clients n'attendent pas un parlement. Elles arrivent déjà, et elles posent les questions de la section précédente. Si vous opérez dans plusieurs États membres, vous êtes déjà dans le périmètre ailleurs. Vingt-deux des vingt-sept ont adopté leur loi de transposition ; la Belgique, l'Italie ou l'Allemagne sont opérationnelles depuis un moment. Les obligations qui arriveront en France sont, par construction, les mêmes. Le délai ne change pas le contenu, seulement la date à laquelle vous serez interrogé dessus. À noter aussi, parce que c'est une spécificité française qui surprend : le projet de loi étend le périmètre aux collectivités territoriales : régions, départements, communes de plus de trente mille habitants et leurs groupements pour une extension nationale que la directive laissait à l'appréciation des États membres. Les organisations qui auront profité du retard pour dresser l'inventaire OT seront prêtes. Celles qui en auront profité pour attendre feront le même travail, mais au calendrier d'un superviseur impatient plutôt qu'au leur. Une séquence de travail Étendez l'inventaire aux actifs OT dépourvus de toute politique d'accès. Pas toutes les machines : celles dont l'usage non autorisé a une conséquence matérielle, humaine ou réglementaire. Définissez le sens du refus pour chacune d'elles , avec l'exploitation et le HSE autour de la table. C'est le livrable le plus difficile et il conditionne tout le reste. Exigez un point d'application capable de décider hors ligne. Ce seul critère élimine les approches inadaptées plus vite que n'importe quelle comparaison de fonctionnalités. Concevez la trace de preuve en même temps que le contrôle d'accès , pas après. Vous ne pourrez journaliser que l'identité que vous aurez réellement établie. Répétez le chronomètre des 24 heures sur un scénario OT , pas sur un scénario informatique. C'est là que le plan cassera, et mieux vaut que ce soit pendant un exercice. Et une chose à ne pas faire : ne raccordez pas un équipement au réseau dans le seul but de pouvoir le gouverner. Créer une surface d'attaque pour surveiller la surface d'attaque qu'on vient de créer est un mauvais échange. Le contrôle d'accès physique n'a pas besoin que la machine soit intelligente. Il a besoin que la prise le soit. Oui, il est temps de reparler de ce qu'on propose avec Trust-Buster. Ce que cela ne vous donne pas Le travail de conformité invite à la surenchère, alors soyons clairs sur les limites : contrôler et journaliser l'accès au niveau de l'alimentation répond aux volets contrôle d'accès, gestion des actifs et preuve de l'article 21(2). Cela ne répond ni à la segmentation réseau, ni au traitement des vulnérabilités, ni aux sauvegardes et à la reprise, ni à la politique de cryptographie, ni à l'évaluation des fournisseurs. C'est une colonne de la matrice, pas la matrice. Il se trouve simplement que c'est la colonne vide sur presque tous les sites et ce qui explique pourquoi il est utile de commencer par là, et pourquoi il est tout aussi utile de dire où cela s'arrête. Dernière révision : août 2026. Les statuts de transposition et d'application de NIS 2 évoluent ; vérifiez auprès de l'ANSSI avant de vous appuyer sur une date de cet article.

Législation cyber : ce qui vous attend en 2027

18/08/2026Pascal Flamand

Deux échéances proches, aucune période de transition, et une clause que vous n'avez peut être pas lue Le paysage législatif de la cybersécurité a décollé depuis 2023 avec plusieurs départs : en 2027, il atterrit. Deux règlements européens entrent en application à onze mois d'intervalle, aucun des deux ne prévoit de période de transition, et ensemble ils changent ce que le marquage CE d'une machine industrielle certifie réellement. Si vous exploitez des machines en Europe, ou si vous en vendez, 2027 n'est pas une année à surveiller en attendant les élections, mais à avoir préparée avec grand soin. Vous pouvez rêver à un assouplissement pour cause de chaos mondial, ou prendre vos précautions. 2027 est une année d'échéances, pas une année de tendances La plupart des panoramas législatifs prennent des précautions et on a connu des déboires dans des secteurs connexes (Smart City, bâtiment, énergie). Celui-ci n'en a pas besoin : les deux dates qui comptent sont fixées dans des règlements publiés, et aucune ne semble plus s'accompagner d'un délai de grâce. Date Texte Ce qui change 20 janvier 2027 Règlement Machines (UE) 2023/1230 Remplace purement et simplement la directive Machines. La cybersécurité devient une exigence essentielle de santé et de sécurité pour le marquage CE. 11 décembre 2027 Règlement sur la cyberrésilience (UE) 2024/2847 Entrée en application pleine. Tout produit comportant des éléments numériques mis sur le marché de l'Union porte des obligations de sécurité sur l'ensemble de son cycle de vie. C'est l'absence de fenêtre de transition qui surprend. Une machine mise sur le marché le 19 janvier 2027 relève de l'ancienne directive ; la même machine mise sur le marché le lendemain relève du règlement. Il n'y a ni régime mixte, ni période d'option. 20 janvier 2027 : la cybersécurité devient une exigence de sécurité Le règlement Machines remplace la directive 2006/42/CE, cadre qui gouverne le marquage CE des machines depuis les années 2000. La couverture médiatique se concentre sur l'apprentissage automatique et les organismes notifiés. Pour qui travaille sur la sécurité des systèmes industriels, le changement le plus lourd de conséquences est plus discret. La cybersécurité entre dans les exigences essentielles de santé et de sécurité. L'annexe III introduit une section intitulée protection contre la corruption (§ 1.1.9), aux côtés d'exigences renforcées sur la sécurité et la fiabilité des systèmes de commande (§ 1.2.1). En substance : la connexion à d'autres systèmes ou l'accès à distance ne doivent pas créer de situation dangereuse, et les composants matériels, logiciels et données relatifs à la sécurité doivent être identifiés comme tels et protégés contre la corruption, accidentelle ou délibérée. C'est un vrai changement de nature juridique. Sous la directive, protéger une machine contre l'altération relevait de l'appréciation du fabricant. À partir de janvier 2027, c'est une condition de mise sur le marché. Les associations d'acteurs industriels ont demandé que les exigences de cybersécurité soient reportées à la date du CRA mais ce report n'a pas été accordé. La clause que presque personne n'a lue : la modification substantielle Voici la disposition qui devrait être sur le bureau de chaque responsable maintenance et méthodes d'Europe, et qui y est rarement. Le règlement Machines définit la modification substantielle dans le droit de l'Union pour la première fois. La conséquence est courte et sévère : celui qui effectue une modification substantielle devient le fabricant pour les aspects concernés — avec l'évaluation de la conformité, la documentation technique et la responsabilité qui vont avec. C'est lui qui "porte le chapeau" (pour ceux qui n'avaient pas compris l'illustration). Rapprochez cela de la manière dont les retrofits de sécurité OT se font habituellement. On ouvre l'armoire, on insère un module dans le circuit de commande relatif à la sécurité, on recâble, on referme. En 2026, c'est ("juste") une conversation sur la garantie et une question d'analyse de risque. À partir de 2027, c'est la question de savoir si votre équipe de maintenance vient de devenir fabricant de machines, dans un domaine dont les exigences incluent désormais la cybersécurité des fonctions de sécurité. Nous pourrons revenir dans un futur article sur les retrofits de sécurité, qui pour nous devraient se placer à la frontière d'une machine plutôt qu'en son sein, pour des raisons de coût et de responsabilité. Le règlement Machines ne fait pas cet argument à notre place : il fait quelque chose de plus utile, qui est d'inscrire la moitié « responsabilité » de cet argument dans un texte européen directement applicable. Tout plan de retrofit pour 2027 devrait comporter une réponse explicite à la question cela constitue-t-il une modification substantielle ? , et la réponse la plus sûre est celle où l'on n'a touché à rien à l'intérieur de la machine. Gardez vos machines non modifiables et ajoutez y les éléments de sécurité nécessaires à la conformité, et facilement remplaçables par vos équipes de maintenance lors des prochaines évolutions. 11 décembre 2027 : le CRA entre pleinement en application Le règlement sur la cyberrésilience est entré en vigueur le 10 décembre 2024. Ses obligations de notification (vulnérabilités activement exploitées et incidents graves) s'appliqueront au 11 septembre 2026. L'application pleine intervient le 11 décembre 2027, et elle est large : exigences essentielles de l'annexe I, documentation technique, traitement des vulnérabilités sur une période de support définie, et une procédure de conformité qui varie selon la classe de produit. Deux points comptent plus que les grandes lignes déjà connues (quoi que, pas très médiatique). Le texte est extraterritorial. Le CRA lie tout fabricant mettant un produit comportant des éléments numériques sur le marché de l'Union, où qu'il soit établi. Un industriel américain, japonais ou taïwanais qui vend dans l'Union est dans le périmètre et doit désigner un mandataire ou s'appuyer sur un importateur portant les obligations. Les lecteurs non européens qui ont classé le CRA au rayon « problème européen » l'ont mal classé. Les fabricants de machines relèvent des deux régimes à la fois. Les considérants du CRA indiquent clairement que les fabricants de machines doivent se conformer aux deux textes ; la Commission et les organismes européens de normalisation sont appelés à favoriser la cohérence dans la manière d'évaluer le risque cyber au titre des deux régimes. Cette cohérence reste un chantier en cours plutôt qu'un fait acquis — voir plus bas. Et sur le contrôle d'accès précisément, l'annexe I est d'une netteté inhabituelle pour un règlement produit : les produits doivent être protégés contre les accès non autorisés par des mécanismes de contrôle appropriés, incluant sans s'y limiter l'authentification, les systèmes de gestion des identités ou des accès , et doivent rendre compte des accès non autorisés éventuels. Un règlement produit qui écrit « systèmes de gestion des identités ou des accès » dans son dispositif. Normalisation : ce qu'il faut en attendre, et quand Le règlement sur la cyberrésilience instaure bien un cadre unifié d'exigences de cybersécurité, et la normalisation est effectivement la tendance à suivre mais autant être honnête sur l'état réel du chantier plutôt que de le décrire comme achevé. Les normes harmonisées sont ce qui transforme une exigence essentielle en spécification testable et donne au fabricant une présomption de conformité. Pour la cybersécurité des machines, cette couche est encore en construction : la norme EN 50742, qui traite de la protection contre la corruption dans les machines, est en cours d'élaboration, et les travaux sectoriels comme la révision 2025 d'ISO 10218-2 pour les robots industriels, commencent à intégrer des exigences de cybersécurité dans les normes de sécurité. Côté CRA, la demande de normalisation est considérable et le calendrier serré face à décembre 2027. La conséquence pratique pour un fabricant est inconfortable mais gérable : vous atteindrez peut-être une date d'application avant que la norme harmonisée sur laquelle vous comptiez ne soit citée au Journal officiel. Cela ne suspend pas l'exigence. Cela signifie démontrer la conformité par d'autres moyens, analyse de risque documentée, normes internationales reconnues comme IEC 62443, et éléments de preuve présentables à un évaluateur. La conséquence pour un exploitant est différente et plus intéressante. Les machines mises sur le marché à partir de 2027 arriveront avec une protection contre l'altération, une identité logicielle et une journalisation dont le parc actuel ne dispose tout simplement pas. Votre parc devient à deux vitesses : une minorité croissante d'actifs dotés de primitives de sécurité exploitables, et une large majorité (presses, variateurs, bancs et armoires mis en service entre les années 90 ou avant même et 2026) qui n'en aura jamais et qu'on ne peut pas équiper de l'intérieur sans se poser la question de la modification substantielle. Gouverner cette exigence n'est pas un problème qui débute en 2027 : c'est le problème que 2027 rend visible. Ce qui arrive aussi, et qu'il faut suivre Règlement IA, 2 août 2027. Les obligations relatives aux systèmes d'IA à haut risque qui sont des composants de sécurité de produits couverts par une législation sectorielle et surtout machines incluses commencent à s'appliquer. Si vous intégrez un composant de sécurité fondé sur l'apprentissage automatique, vous relevez à la fois de la procédure avec organisme notifié du règlement Machines et du règlement IA pour ce composant. NIS 2 et Directive REC (Résilience des Entités Critiques). La phase de transposition s'achève et la phase de supervision commence. La Commission est passée des procédures d'infraction aux renvois devant la Cour de justice ; les autorités nationales qui ont passé 2025 et 2026 à enregistrer les entités passeront 2027 à les contrôler. Royaume-Uni. Le Cyber Security and Resilience Bill reste un projet de loi, en examen à la Chambre des Lords à l'heure où nous écrivons. Il modifiera les NIS Regulations de 2018 et fera entrer dans le périmètre les fournisseurs de services gérés et certains fournisseurs critiques désignés. États-Unis. Tableau moins flatteur que le tableau européen, et autant le dire franchement : la règle finale de CIRCIA a largement dépassé son échéance légale, et la proposition de règle de la TSA de 2024 pour le transport de surface n'est pas finalisée. Hors du secteur électrique couvert par NERC CIP, les obligations américaines contraignantes sont plus minces que ne le laissent penser les titres. Que faire du temps qui reste Cartographiez votre gamme ou votre parc par rapport à la coupure du 20 janvier 2027. Fabricants : quels produits changent de catégorie à l'annexe I, et lesquels perdent la voie de l'autocertification. Exploitants : quelles machines vous comptez acheter après cette date, et avec quelles primitives de sécurité elles arriveront. Intégrez la question de la modification substantielle à votre processus d'approbation des retrofits avant l'ingénierie, pas après. C'est une ligne à ajouter, et elle peut éviter une erreur de catégorie coûteuse. Examinez comment l'identité logicielle et les preuves d'altération seront captées et conservées. Les deux régimes le demandent, et aucun n'accepte le compteur horaire de la machine comme réponse. Dressez l'inventaire des actifs OT si ce n'est pas déjà fait. Toutes les obligations ci-dessus sont cadrées par une liste que la plupart des organisations n'ont jamais produite. N'attendez pas les normes harmonisées pour commencer. Concevez contre IEC 62443 et documentez le raisonnement ; la norme, quand elle arrivera, sera un exercice de correspondance et non une refonte. Ce que nous ne prétendons pas Deux limites, énoncées parce que les écrits sur la conformité ont tendance à les estomper. Nous décrivons des dates publiées, nous ne prédisons pas l'intensité des contrôles. L'agressivité des autorités nationales de surveillance du marché durant la première année d'application du règlement Machines est réellement inconnue. Les dates sont certaines mais l'intensité ne l'est pas. D'où certains appels au chaos européeo-juridiques dans l'espoir de tout bazarder avant d'avoir payé pour s'adapter. Mais franchement ce serait une belle erreur. Rien de ceci ne constitue un avis juridique , et les deux règlements interagissent d'une manière que la Commission s'est elle-même engagée à clarifier par des lignes directrices. Si votre produit se situe près d'une frontière de catégorie (composant de sécurité, machine intégrant de l'apprentissage automatique, produit qui est à la fois une machine et un produit comportant des éléments numériques ) cette frontière mérite l'avis d'un spécialiste plutôt que celui que nous vous donnons. Certes ça nous arrangerait que tout le monde ait besoin de nous mais on a assez subi d'autres réglementations similaires pour être franc sur ces sujets.. Ce que nous pouvons affirmer sans réserve est plus étroit et, nous semble-t-il, plus utile : à partir de 2027, la cybersécurité des fonctions de sécurité d'une machine relève du marquage CE + ouvrir une machine pour la sécuriser emporte une conséquence juridique qu'elle n'emportait pas auparavant + le parc installé qui ne sera jamais conforme par lui-même est la part du parc qu'il faut gouverner depuis l'extérieur. Voilà notre petit vademecum estival pour bien entamer vos COMEX de septembre. Dernière révision : août 2026. Les calendriers réglementaires et l'état d'avancement de la normalisation évoluent ; vérifiez sur EUR-Lex et auprès de votre organisme notifié avant de vous appuyer sur une date de cet article.

Dans les coulisses de TB

18/08/2026Pascal Flamand

Notre chaîne de confiance matérielle était intégralement européenne : carte, modem, IP d'enclave sécurisée. Puis les deux composants qui la portaient ont été rachetés par le même groupe américain, à quelques mois d'intervalle. La technologie n'a pas cessé de fonctionner. C'est l'argument que nous écrivions qui a cessé d'être vrai. Comment nous prenons les décisions La plateforme Ops-Devices - le cœur technologique qui sert à Trust-Buster - a été conçue pour traiter des besoins opérationnels quotidiens puis pour répondre aux exigences juridiques qui arrivent avec NIS 2, le CRA et les différents règlements industriels. Beaucoup d'options s'offraient à nous, mais les technologies étant nombreuses, il était assez facile d'obtenir rapidement une solution conforme, mais comment savoir si on a fait le bon choix ? Ce qui suit présente une partie plus difficile mais primordiale sur le long terme : comment les décisions se prennent, ce que nous devons refuser d'affirmer sans une démarche pérenne, et l'engagement d'architecture initiale que nous avons dû défaire quand le sol s'est dérobé sous lui. Nous tenons un registre des alternatives que nous avons écartées La plupart des équipes d'ingénierie documentent uniquement ce qu'elles ont construit. Depuis le début de cette aventure, nous documentons aussi ce que nous n'avons pas construit, et pourquoi. C'est une pratique désormais courante, et à ce sujet lisez et utilisez des ressources bien faites comme les Architecture Decision Records . Chaque choix d'architecture significatif entre dans un registre qui consigne quatre éléments : l'option retenue, les options écartées, le raisonnement au moment de la décision, et la partie qui compte le plus : le déclencheur de réévaluation . Ce dernier champ énonce par écrit ce qui devrait changer dans le monde pour que la décision soit rouverte, et pour ma part c'est ce qui me manquait le plus et faisait enchainer des revues d'architecture interminables. Cela a commencé comme une discipline de R&D ordinaire. Il s'est avéré que cela avait deux autres intérêts que nous n'avions pas anticipés. Le premier est réglementaire. Le CRA comme le règlement Machines demandent au fabricant de démontrer que la sécurité a été prise en compte dès la conception, et non affirmée après coup. Un registre daté d'alternatives écartées, avec leur raisonnement, est une bien meilleure réponse à cette question qu'une politique rédigée le mois précédant l'audit. Le second est une contrainte d'honnêteté. Écrire un déclencheur de réévaluation est inconfortable, parce qu'on s'engage à l'avance sur la condition dans laquelle il faudra reconnaître qu'une décision ne tient plus. Ce qui nous amène à celui qui s'est déclenché juste avant la commercialisation du Cube. La décision que nous avons dû défaire Notre première architecture matérielle reposait sur une chaîne de confiance européenne. La plateforme cellulaire retenue associait un microcontrôleur à un modem intégrant une enclave sécurisée dont l'IP venait de Tiempo Secure : société fondée en 2007 à Montbonnot, près de Grenoble, cocorico, dont l'élément sécurisé TESIC à cœur RISC-V a passé une évaluation Critères Communs EAL5+ auprès du laboratoire français SERMA, et qui avait été retenue pour un programme de microprocesseur de sécurité post-quantique souverain soutenu par l'État français. La ligne de modems venait de Sequans , fournisseur français, cocorico, de semi-conducteurs cellulaires. Carte européenne, modem européen, IP d'enclave européenne : une chaîne que nous pouvions décrire de bout en bout et défendre devant un acheteur de la défense. Puis les deux pièces ont changé de mains. En août 2024, Qualcomm a conclu un accord pour acquérir les actifs technologiques 4G IoT de Sequans : employés, actifs et licences, dont la gamme Monarch, une transaction finalisée le mois suivant pour environ 200 millions de dollars, Sequans conservant une licence perpétuelle lui permettant de continuer à utiliser et commercialiser la technologie. Tiempo Secure a ensuite été rachetée par Qualcomm également : opération confirmée publiquement par son cofondateur et aujourd'hui reflétée sur le site de Tiempo lui-même. Ce que cela a changé, et ce que cela n'a pas changé. Il faut être précis, parce que la version approximative de cette histoire serait plus spectaculaire que la vraie, toute proportion gardée sur les conséquences pour nous. La technologie n'a pas cessé de fonctionner et Sequans continue d'opérer et détient une licence perpétuelle. L'équipe d'ingénierie de Tiempo est toujours à Montbonnot. Aucune puce ne s'est transformée en porte dérobée pendant la nuit ! Esprit-ssif, es-tu là ? Ce qui a changé est plus étroit mais, pour nous, décisif : la phrase que nous écrivions n'était plus vraie. Nous décrivions une chaîne de confiance matérielle intégralement européenne. Après les acquisitions, l'IP d'enclave et une part substantielle de la technologie modem relevaient d'une propriété capitalistique américaine. Pour un client industriel, c'est une note de bas de page mais pour un client sensible qui évalue de plus en plus la provenance de sa chaîne d'approvisionnement, c'est toute la question. Après tout, les déboires du secteur automobile à l'été 2022 (salut TI !) sont passés par là. Ce que nous avons fait. Nous avons déprécié cette plateforme comme ancre de souveraineté et déplacé l'ancre ailleurs : un microcontrôleur STM32, un porteur cellulaire Nordic, et un élément sécurisé discret approvisionné séparément plutôt qu'hérité via un modem. Le chemin de prototypage passe désormais par une plateforme de développement Nordic associée à un élément sécurisé STSAFE, avec un composant de niveau d'assurance supérieur prévu sur le chemin de production. Ce que nous en avons appris , et c'est la partie qui mérite d'être généralisée : la souveraineté n'est pas une propriété d'un composant, c'est la propriété d'une affirmation qu'il faut maintenir vraie. La propriété de l'IP semi-conducteur change de mains à un rythme bien plus court que la durée de vie d'une machine industrielle. Toute architecture qui adosse sa différenciation à la nationalité d'un fournisseur a besoin d'un déclencheur de réévaluation explicite, parce que ce déclencheur finira par se déclencher, et l'alternative à s'en apercevoir soi-même... est qu'un client s'en aperçoive à votre place ! Notre registre porte désormais ce déclencheur sur chaque décision d'approvisionnement qui soutient une affirmation de provenance. Trois affirmations que nous refusons de faire Le marketing adjacent à la conformité a une pente naturelle vers la surenchère. Voici les trois endroits où nous avons décidé à l'avance de ne pas la suivre, écrits pour qu'un lecteur puisse nous y retenir le moment venu. EAL5+ est hérité, pas obtenu. Quand nous - pour ops-devices surtout - mentionnons une évaluation Critères Communs EAL5+, elle appartient à un composant élément sécurisé et au laboratoire qui l'a évalué. Ops-Devices ne détient aucune certification de ce type et n'en revendique aucune. Un produit contenant un composant certifié n'est pas un produit certifié, et la distinction compte précisément pour les clients qui s'intéressent à la certification. La force du signal radio est un portail, pas une preuve. Notre système utilise le niveau de signal reçu comme condition d'entrée du processus de contrôle d'accès : sous un certain seuil, l'échange ne s'engage pas. Ce n'est pas un facteur d'authentification. Un signal RSSI s'amplifie, se relaie et se falsifie, et aucun filtrage ne le transforme en mesure de distance. La mesure par temps de vol en ultra-large bande (UWB) le ferait correctement mais nous n'en disposons pas aujourd'hui, et nous le disons plutôt que de laisser entendre qu'un seuillage soigneux serait équivalent. Espérons qu'on puisse intégrer les prototypes rapidement, et un cas client y aidera certainement (car pour le moment, ça fonctionne tellement bien que la demande sera certainement sur une niche). Nous ne pouvons pas revendiquer une détection exhaustive. Aucun système de surveillance radioélectrique ne peut démontrer l'absence d'un signal qu'il n'a pas vu. La détection est un signal de corroboration dans une décision, pas le point d'ancrage. Tout fournisseur annonçant une couverture de détection complète dans un environnement radio non maîtrisé décrit une ambition, pas une mesure. Chacune de ces trois phrases rend la diapositive un peu moins impressionnante dans notre "deck" mais... chacune survit très bien à l'évaluation technique d'un client, ce que la version impressionnante ne fait pas. Collaboration et innovation Notre processus de développement suppose un dialogue continu avec l'extérieur. Nous concevons contre des normes publiées et nous ne siégeons pas dans les organismes qui les écrivent. IEC 62443 structure notre architecture, le CRA et le règlement Machines structurent notre documentation, IEEE 802.1AR, ISO 15118 et les travaux de l'IETF sur les environnements contraints éclairent des choix de conception précis. Nous sommes lecteurs de ces normes et, quand c'est pertinent, nous préparons des réponses structurées pour les équipes achats qui les citent. Nous ne détenons pas de sièges en commission de normalisation ni auprès d'autorités réglementaires. C'est bien dommage, car entre retard et annulation pur et simple, difficile de savoir si les entreprises auront finalement un bâton ou une carotte. Et les carottes en cybersécurité ne rendent pas aimables les DAF, qui ne vont pas débourser autant et aussi vite. Nous construisons sur l'open source, délibérément et par défaut. Firmwares sur des cadres ouverts, schémas publiés dans un format de CAO électronique libre, modules du commerce à protocole documenté plutôt que matériel sur mesure chaque fois qu'un composant standard suffit. Ce n'est pas de l'idéologie : c'est la seule façon pour une petite équipe de conserver une chaîne d'approvisionnement réellement auditable, et c'est ce qui rend la question de provenance ci-dessus tout simplement posable. L'innovation se limite à une seule couche. Assembler des composants éprouvés et des cadres ouverts n'est pas de l'innovation, et nous ne le présentons pas comme tel. Ce que nous gardons en propre, c'est la chaîne de confiance qui relie ces composants : décision locale sans connectivité, capacités éphémères signées, trace de preuve conçue pour la démonstration rétrospective plutôt que pour la détection temps réel, et application de la décision à la frontière de la machine plutôt qu'en son sein. C'est une couche étroite, celle que personne d'autre n'occupe sur la carte concurrentielle, et c'est pour cela que c'est la seule partie qui vaille la peine d'être construite par nous. Ce que la plateforme traite, et ce qu'elle ne traite pas Une plateforme ne délivre pas une conformité. La conformité est un résultat organisationnel ; un produit ne peut fermer que des exigences précises à l'intérieur d'un cadre réglementé. La plateforme Ops-Devices traite donc une colonne définie de cette matrice : le contrôle d'accès et la gestion des actifs pour des équipements dépourvus de chemin numérique (OT pas IT pour simplifier), la preuve d'intervention physique qui survit à un site hors ligne et à dix-huit mois d'écart, et l'application de la décision sans modifier la machine. Elle ne traite ni la segmentation réseau, ni le traitement des vulnérabilités, ni les sauvegardes et la reprise, ni la politique de cryptographie sur votre parc, ni l'évaluation de vos fournisseurs, ni la formation, ni le processus de réponse à incident. Ce sont de véritables obligations au titre de l'article 21(2) de NIS 2, et quiconque vous affirme qu'un seul produit les couvrirait vous vend un récit de conformité plutôt qu'une mesure (des jours de conseil plutôt qu'une solution déployable, classique non ?) La raison pour laquelle nous commençons là n'est pas que notre périmètre soit le plus important. C'est que sur presque tous les sites où nous nous sommes rendus dans nos carrières et surtout quand nous avions une responsabilité pénale au-dessus de la tête, c'est celui qui est complètement vide : aucune liste de qui peut exploiter l'équipement, aucune trace de qui l'a fait, et aucun mécanisme capable de produire l'une ou l'autre. Pourquoi nous écrivons tout cela Il existe un argument commercial simple contre le fait de publier une décision d'architecture défaite, une réserve sur une certification héritée et une liste de ce qu'un produit ne fait pas. Cela rend l'histoire moins nette. Nous le faisons à cause de ceux qui évaluent cette catégorie de solutions. Les personnes qui achètent du contrôle d'accès pour des sites industriels et de défense sont, par métier, des personnes qui cherchent l'écart entre l'affirmation et l'objet. Un fournisseur qui nomme ses propres limites en premier ne fait pas preuve de modestie : il retire de l'évaluation la ligne d'interrogation la plus improductive et ne laisse que la substance. Et à cause du registre... donc vous aussi vous y viendrez ! Une fois qu'on a écrit la condition dans laquelle une décision cesse d'être vraie, il faut faire quelque chose quand elle survient. C'est une discipline inconfortable, et c'est ce que nous avons de plus proche. La garantie que ce que nous vous dirons l'an prochain sera encore défendable même si le contexte aura largement évolué.