IA dans l’évaluation des risques machines : aide ou mirage ?

L’IA dans l’évaluation des risques machines s’est installée exactement là où, pendant des années, régnaient Excel, les listes de contrôle et les tableaux recyclés d’un projet à l’autre. La tentation est énorme : on saisit le type de machine, quelques informations générales, et quelques secondes plus tard on obtient un document propre, dense, crédible. Dangers, conséquences, mesures de protection, niveau de risque, risque résiduel : tout semble en place. Sauf qu’un tableau qui a l’air sérieux n’est pas encore une évaluation des risques conforme à ISO 12100.

Le point clé est là, et il est souvent raté : la valeur d’une évaluation des risques ne vient pas du nombre de lignes ni du style technique des phrases. Elle vient de la capacité à reconstituer le raisonnement qui a conduit à une décision de conception. En clair : pourquoi ce danger a été retenu, dans quelle situation dangereuse, pour quelle tâche, avec quel événement dangereux, et pourquoi la réduction du risque choisie est réellement adaptée. Sans cette logique, on n’a pas une analyse. On a un décor.

IA dans l’évaluation des risques machines : un vieux travers en plus rapide

Le problème n’a jamais été Excel. Excel n’est qu’un outil. Le vrai problème, c’est qu’il était très facile d’en faire une imitation de processus : quelques dangers génériques, quelques conséquences standard, un protecteur fixe, une consigne, une formation, un peu de couleur, et le document avait déjà l’air professionnel.

Aujourd’hui, l’IA permet de faire la même erreur plus vite, plus proprement, et de manière bien plus convaincante. Avant, un mauvais tableau se trahissait souvent tout seul : répétitions, phrases creuses, copier-coller visible. Maintenant, le résultat peut être fluide, cohérent, bien rédigé, avec le bon vocabulaire métier. Et c’est justement pour cela que le risque augmente. L’apparence d’analyse devient plus crédible que l’analyse elle-même.

Il faut le dire sans détour : confondre le document avec le processus est déjà dangereux quand c’est fait à la main. Avec l’IA, c’est plus dangereux encore, parce que la machine rédactionnelle produit une illusion bien finie. Or ISO 12100 ne décrit pas l’art de remplir un tableau. Elle décrit une démarche de sécurité intégrée à la conception, qui relie les limites de la machine, ses phases de vie, les tâches humaines, les situations dangereuses, les événements dangereux et les choix de réduction du risque.

Autrement dit, la question n’est pas : « est-ce que le tableau a l’air juste ? » La question est : « est-ce qu’on peut défendre chaque décision si quelqu’un demande pourquoi ? »

ISO 12100 ne commence pas par une liste de dangers

Une erreur très répandue consiste à démarrer par : « Quels dangers a la machine ? » La question paraît logique. En pratique, elle est trop courte. Une machine a des organes en mouvement, donc des dangers mécaniques. Elle a une alimentation, donc des dangers électriques. Elle peut avoir des surfaces chaudes, de l’air comprimé, des arêtes vives, du bruit, des efforts manuels. Très bien. Mais ce catalogue, à lui seul, n’est pas encore une évaluation des risques.

Un danger ne décrit pas encore un risque. Le risque apparaît quand une personne, dans une phase de vie donnée de la machine, pendant une tâche précise, dans des conditions concrètes, peut se retrouver dans une situation dangereuse. Et c’est ensuite qu’un événement dangereux peut conduire au dommage.

La bonne séquence de réflexion ressemble beaucoup plus à ceci :

• Qui est exposé : opérateur, maintenance, réglage, nettoyage, logistique, service ?
• À quel moment : installation, mise en service, production, changement de format, nettoyage, dépannage, maintenance, fin de vie ?
• Pour quelle tâche réelle : réglage, débourrage, inspection, essai en mode manuel, accès de service ?
• Dans quelles conditions : machine arrêtée, machine en mouvement, énergie maintenue, protecteur ouvert, visibilité réduite, pression de temps, travail seul ?
• Quelle situation dangereuse peut apparaître ?
• Quel événement dangereux peut déclencher le dommage : démarrage inattendu, perte de stabilité, relâchement d’énergie, erreur de commande, chute d’objet, accès à une zone de mouvement ?

C’est là que beaucoup de tableaux s’effondrent. Ils contiennent le mot « écrasement », mais ne disent pas qui, quand, comment, ni pourquoi l’exposition existe. Ils affichent une baisse du risque après ajout d’une consigne, mais sans démontrer que la mesure change vraiment la situation.

IA dans l’évaluation des risques machines : ce qu’elle doit demander, pas inventer

L’IA peut être utile si elle pousse l’ingénieur à poser les bonnes questions. A-t-on couvert le nettoyage ? Le débourrage ? Le mode manuel ? Les accès de service ? Les usages raisonnablement prévisibles qui s’écartent de l’usage prévu ? Très bien. Là, elle aide.

En revanche, si elle répond elle-même à ces questions sans données fiables sur la machine, elle n’analyse pas. Elle suppose. Et en sécurité machine, supposer avec élégance reste une mauvaise idée.

IA dans l’évaluation des risques machines : utile seulement avec du contexte

Demandez à un modèle de préparer une évaluation des risques pour « une machine d’emballage », et il vous donnera probablement quelque chose de plausible. Dangers mécaniques, dangers électriques, bruit, ergonomie, pneumatique, brûlure éventuelle, protecteurs, arrêts d’urgence, formation, LOTO. Sur le papier, rien de choquant.

Le problème, c’est qu’il ne s’agira pas de votre machine. Ce sera la description statistiquement probable d’une machine typique. Et entre une machine typique et une machine réelle, il y a souvent un fossé.

La machine réelle a des limites réelles, des accès réels, des séquences réelles, des points de coincement réels, des habitudes réelles d’exploitation. L’IA ne sait pas spontanément :

• que l’opérateur doit passer la main plus loin que prévu pour dégager un matériau ;
• que le pupitre est mal placé et oblige à observer le mouvement depuis une position non prévue ;
• qu’un protecteur est si lourd qu’il reste ouvert après deux semaines ;
• qu’une opération dite « maintenance » dans la notice est en réalité faite quinze fois par poste par l’opérateur ;
• qu’une panne jugée rare au bureau arrive tous les lundis en production.

Et c’est exactement là que l’évaluation des risques se joue : dans le détail, pas dans le général. Ce n’est pas le mot « danger » qui protège quelqu’un. C’est la compréhension précise de la tâche, de l’accès, de l’énergie en présence, de la fréquence d’exposition et de la mesure qui supprime réellement la cause du risque.

Assistant d’ingénieur, pas auteur de la responsabilité

Oui, l’IA a sa place. Mais à une condition : garder sa juste fonction. Elle peut aider à structurer l’information, à détecter des oublis, à proposer des questions de contrôle, à reformuler une justification, à vérifier la cohérence d’un dossier. Elle peut faire gagner du temps. Elle peut même faire gagner en qualité rédactionnelle.

En revanche, elle ne doit pas devenir l’auteur de la responsabilité. La responsabilité reste du côté du fabricant, du concepteur, de l’intégrateur, de l’équipe qui signe, et de l’entité qui met la machine sur le marché ou la met en service.

L’IA peut écrire : « installer un protecteur avec interverrouillage et verrouillage ». Très bien. Mais qui justifie pourquoi ce choix est adapté à cet accès précis, avec ce temps d’arrêt, pour cette fonction de sécurité, avec cette fréquence d’entrée, sans créer un nouveau risque ni encourager le contournement ?

L’IA peut écrire : « former l’opérateur ». Mais si l’opérateur doit chaque jour approcher une zone en mouvement pour faire son travail normal, le problème n’est pas d’abord la formation. Le problème, c’est la conception.

L’IA peut écrire : « appliquer une procédure LOTO ». Mais si l’opération concernée est un débourrage répété plusieurs fois par poste, il faut avoir l’honnêteté de demander si cette procédure sera réellement appliquée à chaque fois. Sinon, on n’a pas une réduction du risque. On a un souhait saisi dans une cellule.

La hiérarchie compte. La réduction du risque commence par la conception intrinsèquement sûre, puis les mesures techniques de protection, puis seulement l’information pour l’utilisateur. Trop de tableaux inversent cet ordre parce que c’est plus simple à rédiger. Ce n’est pas plus sûr pour autant.

Une instruction au modèle n’est pas une méthode ISO 12100

On croit souvent qu’il suffit d’écrire une instruction plus détaillée au modèle : prendre en compte ISO 12100, couvrir tout le cycle de vie, intégrer les dangers mécaniques, électriques, thermiques, ergonomiques, ajouter l’estimation du risque initial et le risque résiduel. Le résultat peut être plus propre. Pas forcément plus vrai.

Une instruction détaillée n’ajoute pas les faits qu’on n’a pas collectés. Elle ne remplace ni l’observation de la machine, ni la discussion avec le concepteur, ni le retour de l’exploitant, ni l’analyse des modes de fonctionnement, ni la confrontation avec les opérations réelles sur le terrain.

Une évaluation des risques solide a besoin de matière concrète : limites de la machine, phases de vie, tâches, accès, sources d’énergie, interactions homme-machine, interventions en mode manuel, nettoyage, débourrage, maintenance, accès en hauteur, visibilité, environnement, conditions d’usage raisonnablement prévisibles. Sans cela, le modèle développe des hypothèses. Et un joli développement d’hypothèses n’est toujours pas une analyse de machine.

Exemple terrain : capteur à fourche sur une refendeuse

Prenons un cas simple, très concret. Sur une refendeuse, un capteur à fourche détecte la position de la bande. Lors d’un changement de largeur, l’opérateur doit régler ce capteur. Sauf que le réglage se trouve dans une zone dangereuse : rouleaux, points de happement, bande sous tension, éléments de coupe, parties en mouvement.

Si vous donnez ce cas à une IA avec peu de contexte, elle va souvent répondre avec le kit standard : LOTO, signalisation, formation, équipements de protection, consigne de réglage, arrêt d’urgence, protecteurs. Le texte sonnera juste. Le problème, lui, restera entier.

La vraie question n’est pas : « comment décrire l’accès à la zone dangereuse ? » La vraie question est : « pourquoi l’opérateur doit-il entrer dans la zone dangereuse pour une opération normale de changement de format ? »

C’est là que l’analyse devient utile. Peut-on déplacer le réglage hors de la zone ? Peut-on ajouter une glissière accessible depuis l’extérieur ? Une échelle mécanique ? Un positionnement par recette ? Un autre principe de détection qui évite le réglage manuel dans cette zone ? Si la cause du risque est une mauvaise implantation du capteur, alors la bonne réduction du risque est d’abord une modification de conception.

Ensuite seulement viennent les mesures complémentaires. Selon le cas, un protecteur fixe peut être pertinent pour empêcher un accès qui n’a aucune raison d’exister en production. Si un accès contrôlé reste nécessaire, un protecteur avec interverrouillage et verrouillage peut être envisagé, à condition que la logique de l’accès, le temps d’arrêt et la fonction de sécurité soient correctement définis. Et si le réglage impose un mode spécifique, il faut traiter proprement le mode de réglage, la vitesse limitée, la commande maintenue, la visibilité et l’organisation de la tâche.

Voilà la différence entre un générateur de documentation et une aide réelle à l’ingénierie. Le premier remplit la ligne. Le second oblige à remettre en cause le projet.

La trace de décision vaut plus qu’un beau tableau

Une évaluation des risques sérieuse doit pouvoir être relue des mois plus tard et rester défendable. Pas seulement lisible. Défendable. Cela suppose une trace de décision claire.

Pourquoi cette situation dangereuse a-t-elle été retenue ? Pourquoi cette gravité a-t-elle été estimée ainsi ? Pourquoi l’exposition a-t-elle été jugée fréquente ou occasionnelle ? Pourquoi cette mesure de protection a-t-elle été choisie plutôt qu’une autre ? Pourquoi le risque résiduel a-t-il été considéré comme acceptable ? Pourquoi une instruction utilisateur a-t-elle été jugée suffisante ici, et pas ailleurs ?

Quand un audit tombe, quand une modernisation est lancée, quand un incident survient, quand un client demande des comptes, la réponse « l’IA l’a proposé » ne vaut rien. Pas plus que « c’était dans le tableau Excel ». Il faut montrer le raisonnement.

Si le processus est bon, l’IA peut renforcer la qualité de cette trace de décision : formulations plus homogènes, justifications plus complètes, incohérences repérées plus vite. Si le processus est faible, elle ne fait qu’épaissir le brouillard avec de plus belles phrases.

Ne confondez pas aide à l’évaluation et IA en fonction de sécurité

Il faut enfin séparer deux sujets que beaucoup mélangent. Premier sujet : utiliser l’IA pour assister l’ingénieur dans l’évaluation des risques machines. Deuxième sujet : utiliser de l’IA, ou de l’apprentissage automatique, dans la machine elle-même pour assurer une fonction de sécurité. Ce n’est pas le même monde.

Dans le premier cas, on parle d’un outil d’assistance documentaire et analytique. Dans le second, on parle d’un élément dont l’erreur peut directement conduire à un dommage. Et là, le niveau d’exigence change brutalement.

Le règlement (UE) 2023/1230 est très clair sur l’obligation du fabricant : réaliser l’évaluation des risques, déterminer les exigences applicables, puis concevoir et fabriquer la machine de façon à éliminer les dangers ou à réduire les risques. Cette obligation ne se délègue pas à un modèle de langage.

Le même règlement vise aussi explicitement des systèmes de sécurité à comportement totalement ou partiellement auto-modifiant utilisant l’apprentissage automatique lorsqu’ils assurent une fonction de sécurité. À partir de là, on n’est plus dans le confort d’une aide à la rédaction. On entre dans un domaine où l’évaluation de conformité appelle une discipline beaucoup plus forte, avec intervention d’un organisme notifié selon les cas.

L’AI Act pousse dans la même direction. Lorsqu’un système d’IA est utilisé comme composant de sécurité d’un produit soumis à la législation européenne harmonisée et à une évaluation de conformité par un tiers, on est dans la logique des systèmes à haut risque. Et la règle n’est pas « le modèle marche bien en moyenne ». La règle, c’est gestion des risques sur tout le cycle de vie, supervision humaine effective, robustesse, précision, cybersécurité, maîtrise des limites et capacité à mettre le système en état sûr.

En sécurité machine, le vrai sujet n’est jamais la moyenne flatteuse. Le vrai sujet, c’est le cas où ça se passe mal : capteur encrassé, éclairage dégradé, comportement inattendu, environnement modifié, données de terrain différentes des essais, dérive après déploiement. C’est là que l’ingénierie commence. Pas sur la diapositive commerciale.

Ce qu’il faut retenir

L’IA peut être un bon assistant dans l’évaluation des risques machines. Elle peut accélérer, structurer, relire, questionner, clarifier. Très bien. Mais elle ne voit pas la machine à votre place, elle n’observe pas l’opérateur à votre place, elle ne tranche pas la hiérarchie de réduction du risque à votre place, et elle ne porte certainement pas la responsabilité à votre place.

Si vous l’utilisez pour produire directement un tableau, vous risquez surtout d’obtenir une version plus élégante d’un vieux défaut : un document qui ressemble à une évaluation des risques sans être le résultat d’un vrai processus. Si vous l’utilisez pour renforcer la démarche, demander ce qui manque, vérifier la cohérence et consolider la trace de décision, alors oui, elle devient utile.

La ligne de partage est simple. En sécurité machine, le but n’est pas de générer un document. Le but est de comprendre pourquoi une personne peut être exposée, comment le dommage peut arriver, et quelle décision de conception supprime réellement le problème. Le reste, aussi bien présenté soit-il, n’est que mise en scène.