Exemple d’évaluation des risques selon l’ISO 12100 : commençons par une vérité qui dérange un peu. Le pire type d’évaluation des risques n’est pas brouillon. Le pire, c’est celui qui a l’air impeccable. Une belle grille, une cotation propre, des références ISO, quelques commentaires, un PDF final, et toute l’équipe respire comme si le sujet était réglé. Sauf que l’ISO 12100 ne note pas l’esthétique d’un document. Elle demande autre chose : prouver qu’un vrai processus d’analyse et de réduction du risque a été conduit, avec une logique claire, des décisions traçables et des mesures de protection choisies dans le bon ordre.
Et c’est précisément là que beaucoup de dossiers se fissurent. Pas parce qu’il manque des cases. Parce qu’il manque la logique. Un fichier peut contenir des dangers, des scores, des normes et des conclusions, sans pour autant constituer une documentation d’évaluation des risques solide. Entre un tableau et une démarche d’ingénierie, il y a un monde.
Exemple d’évaluation des risques selon l’ISO 12100 : pourquoi Excel ne suffit pas
Posons la question franchement : peut-on faire une évaluation des risques dans Excel ? Oui, bien sûr. On peut aussi y fabriquer un document qui semble crédible pendant dix minutes. La vraie question n’est pas là. La vraie question est la suivante : Excel peut-il garantir un processus défendable techniquement, logiquement et en audit ?
Dans la pratique, Excel peut être utile. Comme bloc-notes. Comme support d’atelier. Comme outil de collecte. Comme brouillon partagé. Mais ISO 12100 ne demande pas un fichier tableur. Elle demande une documentation d’évaluation des risques. Et ce n’est pas la même chose.
Une documentation d’évaluation des risques digne de ce nom doit montrer bien plus que le résultat final. Elle doit permettre de comprendre :
- quelles étaient les limites de la machine ;
- à quoi elle est destinée et qui l’utilise ;
- quelles tâches réelles ont été analysées ;
- quelles situations dangereuses ont été identifiées ;
- quels événements dangereux ont été retenus ;
- comment le risque a été estimé au départ ;
- quelle mesure de protection a été choisie ;
- dans quel ordre les mesures de protection ont été appliquées ;
- si un risque secondaire est apparu ;
- comment le risque résiduel a été évalué ;
- qui a décidé quoi, quand, et sur quelle base.
C’est là que le malentendu est total. Le problème d’Excel n’est pas qu’il serait « trop simple ». Le problème est pire : il permet trop facilement de donner l’illusion qu’une documentation existe déjà, alors qu’on a seulement un tableau bien présenté.
Or la documentation d’évaluation des risques n’est pas une collection de rubriques. C’est l’enregistrement d’un raisonnement qu’il faut pouvoir reconstruire, vérifier et défendre après coup. Si votre fichier ne permet pas ça, vous n’avez pas encore une documentation d’évaluation des risques. Vous avez des données de travail. Parfois rangées. Parfois élégantes. Parfois convaincantes en première lecture. Mais toujours des données de travail.
Et quand il s’agit de conformité CE au sens de 2006/42/CE, ce n’est pas un détail. Un beau PDF ne protège ni la machine, ni l’utilisateur, ni l’entreprise.
Le risque secondaire : là où beaucoup d’évaluations décrochent
Une mesure de protection peut-elle créer un nouveau danger ? Oui. Évidemment. Et c’est exactement pour cette raison qu’une évaluation des risques sérieuse ne s’arrête pas au moment où quelqu’un écrit : « protecteur ajouté », « interverrouillage ajouté » ou « procédure ajoutée ».
Une mesure de protection ne ferme pas automatiquement le sujet. Elle modifie l’équilibre du risque. Si vous ne regardez pas ce qu’elle change dans le système homme-machine-processus, vous ne voyez qu’une moitié de la réalité.
Exemple mécanique : le protecteur mobile interverrouillé qui complique le débourrage
Sur un poste de conditionnement, l’équipe identifie un accès possible à une zone en mouvement lors du débourrage. La réponse paraît propre : ajout d’un protecteur mobile interverrouillé. Sur le papier, c’est rassurant. L’accès pendant le fonctionnement automatique est réduit.
Mais une fois le protecteur en place, le débourrage change complètement :
- l’opérateur doit atteindre plus loin à l’intérieur ;
- la main travaille dans un volume plus contraint ;
- la posture devient moins naturelle ;
- la visibilité de la zone d’intervention se dégrade ;
- la fréquence des gestes contournés peut augmenter.
Conclusion ? Le risque mécanique principal baisse peut-être, mais un risque secondaire apparaît sur l’accès, l’ergonomie et la maîtrise du geste. Si le dossier ne le montre pas, il raconte un monde plus sûr que le terrain réel.
Exemple automatisme : une bonne fonction de sécurité qui pousse au contournement
Autre cas très courant : ajout d’une fonction de sécurité avec interverrouillage, réarmement manuel et logique de redémarrage empêchant tout redémarrage automatique après ouverture du protecteur. Techniquement, l’idée peut être bonne. Le piège est ailleurs.
Si la nouvelle séquence :
- allonge chaque intervention ;
- multiplie les étapes de reprise ;
- casse le rythme opérateur ;
- ne correspond pas à la réalité du poste ;
alors vous créez un risque secondaire organisationnel et comportemental :
- réarmement manuel fait machinalement ;
- absence de vraie vérification de zone avant redémarrage ;
- tentation de neutraliser un dispositif ;
- pression de production qui pousse au raccourci.
La fonction de sécurité n’est pas forcément mauvaise. Ce qui est mauvais, c’est de l’implanter sans vérifier comment elle modifie le travail réel. Une logique de redémarrage pensée sans le terrain finit souvent contournée par le terrain.
Exemple électrique : améliorer localement et dégrader l’ensemble
Dans une armoire de commande, l’équipe veut réduire le risque de choc électrique pendant le diagnostic. Elle améliore la séparation des circuits, formalise la consignation, ajoute une séquence de vérification d’absence de tension et réserve l’accès aux personnes habilitées. Très bien. Mais si le diagnostic devient plus long, plus séquentiel et plus dépendant du respect exact des étapes, le risque de faute procédurale peut augmenter.
Même logique avec une liaison équipotentielle ajoutée de manière fragmentaire sur une seule partie de la machine. L’intention est bonne. Le résultat peut être mauvais si l’ensemble du système n’est pas considéré. Une correction locale mal pensée peut créer un scénario de différence de potentiel plus sévère qu’avant la « correction ».
C’est exactement ça, le risque secondaire : la mesure censée améliorer la sécurité modifie autre chose, et ce « autre chose » devient à son tour critique.
La piste d’audit n’est pas un bonus
Dans beaucoup de dossiers, on trouve le résultat final. Le niveau de risque est là. La mesure de protection aussi. Le risque résiduel aussi. Tout a l’air propre. Puis, quelques semaines plus tard, quelqu’un pose une question très simple : pourquoi cette décision a-t-elle été prise ? Et là, plus personne ne sait.
C’est précisément le rôle de la piste d’audit. Pas pour faire joli. Pas « au cas où ». Pas pour cocher une exigence informatique. Pour prouver que le raisonnement a existé.
Une bonne piste d’audit permet de savoir :
- qui a modifié une estimation de risque ;
- à quelle date ;
- sur la base de quelle nouvelle information ;
- si une réévaluation a été faite après ajout d’une mesure de protection ;
- si un risque secondaire a été détecté ;
- pourquoi un risque a été jugé acceptable ;
- pourquoi une fonction de sécurité a été fixée à un niveau donné, par exemple PL d.
Trois situations classiques montrent tout de suite l’intérêt de cette piste d’audit.
Premier cas : un niveau de risque passe de moyen à faible. Dans le tableau, on ne voit que l’état final. Mais la baisse vient-elle d’une vraie réduction du risque, d’une correction de scénario, d’une précision sur la fréquence d’exposition, ou d’un simple lissage de fin de projet ? Sans piste d’audit, impossible de le distinguer.
Deuxième cas : un risque est déclaré acceptable. Très bien. Mais sur quelle base ? Exposition rare ? Gravité faible ? Personnel formé ? Conditions contrôlées ? Ou simple confort de clôture ? Là encore, sans piste d’audit, le dossier n’est pas défendable.
Troisième cas : on lit « ISO 13849, PL d » dans la documentation. Cela sonne sérieux. Mais quelle fonction de sécurité est visée exactement ? Que surveille-t-elle ? Que coupe-t-elle ? Pourquoi PL d ici et pas autre chose ? Si la logique n’est pas tracée, on ne sait plus si la décision est technique ou simplement habituelle.
Excel gère assez bien un état final. Il gère très mal l’histoire de la décision. Une cellule est écrasée, un commentaire est retouché, une valeur est corrigée, et très vite on ne distingue plus l’évolution de l’analyse d’un simple maquillage du résultat. C’est là que la documentation perd sa mémoire technique.
Exemple d’évaluation des risques selon l’ISO 12100 : cas concret sur un poste de conditionnement automatisé
Restons sur du concret. Prenons un poste de conditionnement automatisé, avec mouvements dangereux, interventions opérateur, débourrage, maintenance, accès aux énergies électrique et pneumatique, et plusieurs fonctions de sécurité dépendantes de la logique de commande.
Dans un cas réel de ce type, on ne s’est pas arrêté à trois lignes génériques du style « risque mécanique », « risque électrique », « risque de redémarrage ». L’analyse a été découpée en seize situations distinctes : treize scénarios liés aux tâches réelles et trois événements dangereux au sens de l’ISO 12100.
Parmi les situations dangereuses analysées, on retrouvait notamment :
- les micro-interventions pendant le fonctionnement ;
- le débourrage ;
- le réglage d’un protecteur ;
- les tests fonctionnels ;
- la coupure et le rétablissement des énergies ;
- le remplacement de pièces d’usure ;
- le diagnostic de défaut ;
- l’accès à l’armoire de commande ;
- le redémarrage non intentionnel ;
- la projection d’objet ;
- la libération d’énergie pneumatique.
C’est seulement à ce niveau de détail que l’image réelle du risque apparaît. On n’évalue pas « la machine en général ». On évalue la relation entre une personne, une tâche, une zone, une énergie, une condition d’accès et un scénario précis.
Ce cas a montré plusieurs choses très nettes.
D’abord, le risque le plus critique ne venait pas de la simple présence d’un mouvement dangereux. Il venait du moment d’accès à cette zone pendant l’intervention. C’est une nuance essentielle. Et c’est précisément la nuance que les évaluations trop générales ratent presque toujours.
Ensuite, certaines situations pouvaient être classées en risque faible et acceptées. Mais pas par automatisme, et pas parce qu’un chiffre était bas. Elles n’étaient acceptables que parce que le dossier démontrait :
- une exposition peu fréquente ;
- un effet prévisible limité ;
- des conditions d’exécution maîtrisées ;
- une tâche clairement définie ;
- un utilisateur identifié et formé.
En revanche, plusieurs scénarios ne tenaient pas avec un simple « protecteur + consigne ». C’était le cas, par exemple, du débourrage, des petites interventions en zone protégée, du diagnostic de défaut sur partie électrique, et du risque de redémarrage non intentionnel. Là, il a fallu décrire précisément :
- quelle fonction de sécurité réduit le risque ;
- quand elle bloque le mouvement ;
- comment fonctionne la logique de redémarrage ;
- quand un réarmement manuel est imposé ;
- quelles conditions d’accès doivent être respectées ;
- comment le risque résiduel est justifié.
Et surtout, le dossier a montré qui avait validé les hypothèses, qui avait demandé une réduction supplémentaire, et pourquoi certains scénarios avaient été acceptés alors que d’autres avaient été renvoyés vers une modification technique. Sans cette piste d’audit, on aurait eu un joli résultat. Pas une démonstration.
Exemple d’évaluation des risques selon l’ISO 12100 : ce qu’un bon dossier doit contenir
Un bon dossier n’est pas celui qui empile des tableaux. C’est celui qui permet à un tiers compétent de relire la logique sans devoir deviner ce qui s’est passé.
Concrètement, une documentation d’évaluation des risques robuste doit contenir au minimum :
- la destination de la machine et ses limites ;
- les utilisateurs visés et les tâches réellement exécutées ;
- les zones dangereuses et les sources d’énergie concernées ;
- la liste des situations dangereuses et des événements dangereux ;
- l’estimation initiale du risque ;
- la décision d’acceptation ou de réduction ;
- les mesures de protection retenues selon la séquence exigée par l’ISO 12100 ;
- la vérification de l’apparition éventuelle d’un risque secondaire ;
- l’estimation du risque résiduel ;
- la justification des fonctions de sécurité et, si nécessaire, du niveau requis comme PL d ;
- une piste d’audit lisible.
Autrement dit : si votre document ne permet pas de comprendre le passage entre le danger initial, la décision de réduction, la mesure de protection retenue et le risque résiduel final, alors il manque l’essentiel.
La question utile aujourd’hui n’est donc pas : « Peut-on faire cela dans Excel ? » Oui, on peut. Ce n’est pas le sujet. La vraie question est : votre documentation d’évaluation des risques peut-elle être relue, vérifiée et défendue sans trou logique ?
Si la réponse est non, vous n’avez pas un dossier solide. Vous avez un tableau. Et en sécurité des machines, un tableau qui rassure sans prouver, c’est exactement le genre de faux confort qui finit mal.