Le règlement Machines de l'UE au 20 janvier 2027 : ce qu'il exige du logiciel de vos machines

Cellule de production automatisée avec un bras robotisé, des modules de commande et un écran opérateur

Le 20 janvier 2027, la directive Machines est remplacée par le règlement (UE) 2023/1230, le règlement Machines. L'essentiel paraîtra familier à quiconque construit des machines marquées CE. Une partie, non. Pour la première fois, le droit des machines impose des obligations directement au logiciel : la machine doit indiquer de quels logiciels elle a besoin pour fonctionner en toute sécurité, détecter quand ces logiciels ou leur configuration changent, résister à la corruption, et conserver pendant cinq ans une trace des mises à jour des logiciels de sécurité.

Cet article s'adresse aux directeurs techniques et aux responsables automatisme des constructeurs de machines. Si vous livrez des machines dans l'UE après cette date, ces exigences atterrissent dans vos programmes d'automates, votre IHM, votre accès à distance et votre back-end de mises à jour.

Ce que dit réellement le texte

La Commission européenne indique que le règlement « s'applique à titre obligatoire à partir du 20 janvier 2027 » et qu'il « intègre des dispositions de cybersécurité pour les logiciels et données pertinents pour la conformité et pour les systèmes de commande de sécurité ». Le texte publié en 2023 indiquait le 14 janvier ; un rectificatif a déplacé la date.

Les obligations logicielles figurent dans deux exigences essentielles de santé et de sécurité de l'annexe III du règlement.

Section 1.1.9, protection contre la corruption. En résumé :

Le raccordement d'un autre dispositif à la machine, directement ou à distance, ne doit pas créer de situation dangereuse.
Les logiciels et les données essentiels pour la conformité aux exigences de sécurité « sont identifiés comme tels » et protégés contre la corruption accidentelle ou intentionnelle.
Le matériel qui transmet des signaux ou des données donnant accès à ces logiciels (pensez à un port de programmation ou à une interface réseau vers l'automate de sécurité) doit lui aussi être protégé, et la machine doit recueillir la preuve des interventions sur ce matériel.
La machine ou le produit connexe « identifient les logiciels installés sur ceux-ci dont ils ont besoin pour fonctionner en toute sécurité, et ils sont en mesure de fournir ces informations à tout moment sous une forme aisément accessible ».
La machine ou le produit connexe « recueillent la preuve d'une intervention légitime ou illégitime dans les logiciels ou d'une modification des logiciels installés sur ceux-ci ou de sa configuration ».

Section 1.2.1, sécurité et fiabilité des systèmes de commande. Les systèmes de commande doivent résister aux « tentatives malveillantes raisonnablement prévisibles de tiers conduisant à créer une situation dangereuse ». Le point f) ajoute l'obligation de journalisation : le journal de suivi des données générées dans le cadre d'une intervention, et des versions des logiciels de sécurité téléchargés après la mise sur le marché de la machine, doit être « activé pendant cinq ans après ce téléchargement ». Le journal sert à démontrer la conformité lorsqu'une autorité nationale en fait la demande motivée, et à rien d'autre.

Également sur la liste : la documentation technique doit pouvoir produire « le code source ou la logique de programmation des logiciels dédiés à la sécurité » si une autorité le demande (annexe IV).

Quelles machines sont concernées

Les règles s'appliquent aux machines mises sur le marché à partir du 20 janvier 2027. Les machines mises sur le marché sous l'ancienne directive avant cette date peuvent continuer à être commercialisées (article 52), et le parc déjà en service n'est pas touché par les nouvelles règles logicielles.

Le piège tient au sens de « mise sur le marché ». Le Guide bleu de la Commission précise que la notion « se rapporte à chaque produit individuel, et non à un type de produit ». Chaque unité qui quitte votre usine pour un client de l'UE à partir du 20 janvier 2027 doit satisfaire aux nouvelles exigences, logiciel compris. Une gamme livrée en continu a besoin que son logiciel de commande soit prêt avant la première unité de 2027, pas au prochain changement de modèle.

Les mises à jour ultérieures demandent aussi réflexion. Une modification apportée « par des moyens physiques ou numériques » que le fabricant n'avait pas prévue, et qui crée un nouveau danger ou augmente un risque, peut constituer une modification substantielle. Le considérant 32 indique que l'évaluation des risques devrait porter sur les mises à jour logicielles prévues au moment de la mise sur le marché : décrivez donc dès maintenant votre chemin de mise à jour dans cette évaluation.

Ce que cela signifie pour chaque couche de la machine

Automate de sécurité et API

Décidez de ce qui est pertinent pour la sécurité. C'est généralement le programme de sécurité, mais cela peut inclure du code d'automate standard qui alimente une fonction de sécurité, les paramètres de sécurité des variateurs et la configuration des scrutateurs laser ou des barrières immatérielles. Consignez-le par gamme de machines ; tout le reste en dépend.
Référence et comparaison. Pour chaque configuration publiée, enregistrez une somme de contrôle ou une signature de chaque élément pertinent pour la sécurité. Au démarrage et à intervalles réguliers, la machine compare ce qui tourne à cette référence et enregistre toute différence. Cela détecte l'intervention qui a contourné votre contrôle d'accès, comme un ordinateur portable branché directement sur l'automate.
Verrouillez l'accès d'ingénierie. Mots de passe sur le programme de sécurité, ports et services inutilisés désactivés, et accès d'ingénierie uniquement par un chemin qui authentifie la personne et journalise ce qu'elle a fait.

IHM

Un écran d'identification des logiciels qui liste les logiciels pertinents pour la sécurité avec leurs versions et sommes de contrôle. Lisez les valeurs en direct sur les équipements. Une page saisie au moment de la publication s'éloigne de la réalité, et l'exigence dit « à tout moment ».
Les écrans de paramètres. Le point 1.2.1 d) exclut les modifications des réglages ou des règles qui pourraient entraîner des situations dangereuses. Les paramètres liés à la sécurité doivent se trouver derrière des niveaux d'accès, avec des limites imposées dans l'automate et pas seulement dans l'IHM, et chaque modification doit être enregistrée avec l'auteur, la date, l'ancienne valeur et la nouvelle.

L'accès à distance

La section 1.1.9 cite explicitement les dispositifs distants. En pratique :

Les fonctions de sécurité restent locales. Une session à distance peut lire, diagnostiquer et préparer une modification. Elle ne peut pas passer outre un arrêt, un protecteur ou un dispositif de validation.
Les sessions sont authentifiées personne par personne, pas par un compte de service partagé, et le client peut voir quand une session est ouverte.
Chaque ouverture, fermeture et modification de session est inscrite dans le même journal de preuves que les interventions locales.

Back-end et chaîne de mise à jour

Si vous livrez des mises à jour après l'expédition, votre serveur de mise à jour fait partie du chantier. Pour chaque numéro de série, vous devez savoir quelle version du logiciel de sécurité a été téléchargée, quand et par qui. Signez les mises à jour, et faites vérifier la signature par la machine avant toute installation.

Le journal de suivi lui-même

Le règlement ne dit pas où se trouve le journal. Notre avis : la copie qui fait foi se trouve sur la machine, car beaucoup de clients n'autoriseront pas de connexion permanente. Un miroir dans le cloud est utile, mais il ne peut pas être la seule copie.

Le volume est faible : des interventions et des téléchargements de logiciels de sécurité, pas des données de process. Cinq ans tiennent dans un stockage local si vous le dimensionnez délibérément. Protégez-le contre la suppression et assurez-vous qu'il survit à un remplacement d'automate. Si les entrées nomment un technicien, ce sont des données personnelles sur le site du client : journalisez ce que l'exigence demande, et rien de plus.

Ce que vous fournit le fabricant de votre automate, et ce qu'il ne vous fournit pas

Votre plateforme d'automatisme fournira une partie de tout cela. Avant de construire quoi que ce soit, vérifiez ce qu'elle propose : une signature ou une somme de contrôle sur le programme de sécurité, une protection par mot de passe, une gestion des utilisateurs, un journal des modifications, une lecture des versions. Utilisez tout ce qui existe.

Ce sont des briques. Le fabricant ne sait pas lesquels de vos variateurs et scrutateurs sont pertinents pour la sécurité, ne voit ni votre passerelle d'accès à distance ni votre serveur de mise à jour, et ne peut pas décider comment les preuves survivent cinq ans et un remplacement d'automate. Configurer ces fonctions, les relier sur l'ensemble de la machine et documenter le résultat est le travail du constructeur, et c'est le constructeur qui signe la déclaration de conformité.

Le lien avec le Cyber Resilience Act

Le Cyber Resilience Act suit son propre calendrier. Ses obligations de signalement s'appliquent depuis le 11 septembre 2026, et l'ensemble de ses exigences à partir du 11 décembre 2027. Le règlement Machines arrive entre les deux.

Le CRA reconnaît le chevauchement. Le considérant 53 du règlement (UE) 2024/2847 prévoit que les fabricants de machines qui sont aussi des produits comportant des éléments numériques doivent satisfaire aux deux textes, et que le respect du CRA « pourrait faciliter » le respect des sections 1.1.9 et 1.2.1. C'est au fabricant de démontrer cette synergie. L'annexe I du CRA demande de protéger l'intégrité « des commandes, des programmes et de la configuration » et de signaler les corruptions, ce qui est proche de ce que demande la section 1.1.9.

Une différence compte pour la conception de votre journal. L'exigence du CRA d'enregistrer et de surveiller les activités internes s'accompagne de la possibilité, pour l'utilisateur, de désactiver le mécanisme. Le journal de suivi du règlement Machines doit, lui, rester activé pendant cinq ans. Construisez un seul mécanisme de journalisation si vous le souhaitez, mais ne laissez pas la désactivation prévue par le CRA éteindre le journal exigé pour la machine.

Construisez dès maintenant pour le règlement Machines, puisqu'il arrive en premier, et concevez-le de façon que le même magasin de preuves, la même signature et les mêmes enregistrements de mises à jour servent au CRA en décembre 2027.

Les normes et le report qui n'a pas eu lieu

Ne comptez pas sur la citation, d'ici le 20 janvier 2027, d'une norme harmonisée couvrant ces exigences. La page de la Commission sur les normes harmonisées, mise à jour en septembre 2026, indique que la première liste au titre du règlement Machines est en préparation. Elle reprendra la plupart des normes citées au titre de la directive et les précisera là où elles « ne couvrent pas encore entièrement » les nouvelles exigences, et elle « peut être attendue avant la fin de cette année ».

En janvier 2026, CEMA, CECE, CECIMO, EGMF et FEM ont demandé, dans une position commune de l'industrie, le report des points 1.1.9 et 1.2.1 f) au 11 décembre 2027, en cohérence avec le CRA. Elles chiffraient les coûts de mise en conformité à « plus de 1 million d'euros par architecture de plateforme » et indiquaient que les normes attendues restent très générales sur le journal de données du point 1.2.1 f).

Cette demande n'a pas été retenue. Le règlement Machines a été modifié en juillet 2026 par le règlement (UE) 2026/1744, mais cette modification porte sur les systèmes d'IA à haut risque intégrés aux machines et ne touche pas à la date d'application. Planifiez sur le 20 janvier 2027.

Vous n'aurez donc peut-être, le premier jour, aucune norme conférant une présomption de conformité pour ces deux exigences. Votre dossier technique doit alors décrire la solution appliquée pour chacune (annexe IV). Rédigez-le pendant que vous construisez, pas après. Pour les machines énumérées à l'annexe I, partie B, il y a une étape de plus : l'auto-évaluation n'est ouverte que si des normes harmonisées ou des spécifications communes couvrent toutes les exigences pertinentes ; à défaut, un organisme notifié intervient (article 25). Les machines non énumérées à l'annexe I s'auto-évaluent dans tous les cas.

Un plan sur 15 semaines

Du lundi 5 octobre 2026 à l'échéance, il reste un peu plus de 15 semaines, avec les fêtes au milieu. C'est serré mais faisable si vous priorisez par date d'expédition : les gammes dont des unités partent vers l'UE en janvier passent en premier.

Semaines 1 et 2 (du 5 au 16 octobre) : périmètre. Recensez chaque gamme de machines qui expédiera des unités vers l'UE après le 20 janvier 2027. Pour chacune, listez les logiciels et données pertinents pour la sécurité : programme de sécurité, code standard essentiel à la conformité, paramètres de sécurité des variateurs et des capteurs, IHM, micrologiciels, passerelle d'accès à distance. Nommez un responsable par gamme.
Semaines 3 et 4 (du 19 au 30 octobre) : évaluation des risques et écarts. Mettez à jour l'évaluation des risques pour les raccordements, l'accès à distance, les tentatives malveillantes et le chemin de mise à jour. Vérifiez ce que fournit votre plateforme d'automatisme et ce qui est activé.
Semaines 5 à 9 (du 2 novembre au 4 décembre) : développement. Écran d'identification des logiciels, comparaison avec la référence, contrôle d'accès pour l'ingénierie et l'accès à distance, journal de suivi dimensionné pour cinq ans, mises à jour signées et enregistrements par numéro de série dans le back-end.
Semaines 10 et 11 (du 7 au 18 décembre) : testez comme le feraient un technicien et un attaquant. Modifiez un paramètre de sécurité directement avec l'outil du fabricant et vérifiez que la machine l'enregistre. Remplacez un automate et vérifiez que le journal survit. Coupez l'alimentation pendant une mise à jour.
Semaines 12 et 13 (du 21 décembre au 1er janvier) : fêtes. Ne planifiez aucun travail d'ingénierie ; laissez tourner un test d'endurance qui remplit le journal vers sa taille de cinq ans.
Semaines 14 et 15 (du 4 au 15 janvier) : documentation et publication. Entrées du dossier technique pour les sections 1.1.9 et 1.2.1, notice d'instructions expliquant comment un client lit l'identification des logiciels et ce que l'accès à distance peut et ne peut pas faire, et une étape de production qui charge la référence publiée et l'enregistre par numéro de série.

Si plus d'architectures de plateforme ont besoin de ce travail que cette fenêtre ne peut en absorber, prévenez dès maintenant l'équipe commerciale : une unité qui n'est pas prête ne peut pas être légalement mise sur le marché de l'UE.

À qui cet article ne s'adresse pas

Les machines mises sur le marché avant le 20 janvier 2027 ne sont pas touchées par ces règles logicielles, sauf si quelqu'un les modifie ensuite de manière substantielle. Si vous achetez des machines au lieu de les construire, l'obligation pèse sur votre fournisseur ; votre rôle est de demander l'identification des logiciels et l'accès au journal dans vos cahiers des charges.

Où trouver de l'aide

Nous sommes une société de logiciels, pas un organisme notifié ni un cabinet d'avocats. Nous construisons et modifions les logiciels dans lesquels ces exigences atterrissent : applications d'IHM et de back-end, passerelles d'accès à distance, chaînes de mise à jour et journalisation des preuves, en travaillant aux côtés des automaticiens responsables du programme de sécurité. Les plateformes anciennes, avec des années de code accumulé, sont le cas le plus difficile, et c'est là que commence généralement notre travail de maintenance de systèmes anciens ; le volet CRA est traité dans notre guide du Cyber Resilience Act. Si votre équipe a le plan mais pas les bras pour le terminer d'ici janvier, écrivez à office@c9group.dev.