La plupart des registres d'incidents commencent dans un tableur, et pour de bonnes raisons. Il existe déjà, tout le monde sait s'en servir, il ne demande ni achat ni projet, et il peut être adapté en un après-midi à la façon dont un site fonctionne réellement. Très peu de systèmes dédiés peuvent en dire autant.
La vraie question n'est donc pas de savoir si le tableur est une mauvaise façon de gérer les incidents. C'est de savoir quelle partie lâche en premier, à quel moment, et ce qu'on peut faire à chaque étape sans forcément changer d'outil.
Quand le tableur reste le bon outil
Il vaut la peine d'être direct sur ce point, car beaucoup de ce qui s'écrit sur le sujet ne l'est pas.
Un tableur reste un registre d'incidents efficace tant que toutes ces conditions sont réunies :
- Un seul site, ou une exploitation assez petite pour qu'une personne en ait toute la vision en tête
- Une seule personne qui tient le fichier, tous les autres contribuant par son intermédiaire
- Un volume assez faible pour que rien ne soit oublié entre deux revues
- Des mesures correctives clôturées en quelques semaines, tant que les personnes concernées sont encore en poste
- Aucune obligation de produire rapidement des preuves de suivi à un tiers
Si cela décrit votre exploitation, le registre n'est pas votre problème et en changer ne rendra rien plus sûr. La suite de cet article vous sera tout de même utile comme liste de points de vigilance, mais il n'y a pas d'urgence.
Ce qui lâche en premier
Les défaillances n'arrivent pas toutes en même temps. Elles arrivent dans un ordre assez constant, et reconnaître celle où vous en êtes indique quoi corriger.
1. Le suivi, avant le registre
La première chose à remarquer, c'est que le registre lui-même reste généralement exact. Les incidents sont enregistrés, les dates sont bonnes, les descriptions sont correctes. Ce qui se dégrade, c'est tout ce qui vient ensuite : la mesure corrective, son responsable, sa date d'échéance, et le fait que quelqu'un ait confirmé qu'elle a fonctionné.
La raison est structurelle plutôt que culturelle. Un tableur enregistre bien des événements et mal des obligations. Une ligne peut contenir ce qui s'est passé. Elle n'a aucun moyen de relancer qui que ce soit, et une date d'échéance dans une cellule ne vaut que par la personne qui pense à trier dessus. Le registre devient donc un compte rendu fidèle des événements et un mauvais compte rendu des réponses, soit l'inverse de sa raison d'être.
C'est à ce moment que la plupart des organisations découvrent que la distinction compte, généralement parce que quelqu'un demande ce qui a été fait à propos d'un incident vieux de huit mois. Garder l'action, l'incident dont elle découle et la vérification comme un seul enregistrement relié, plutôt que trois endroits qu'il faut recouper, est le problème précis qu'il vaut la peine de résoudre, et c'est ainsi qu'ENSURE est construit.
2. L'exemplaire unique
La deuxième défaillance arrive avec la deuxième personne. Deux personnes doivent écrire dans le fichier la même semaine, ou quelqu'un doit signaler depuis un téléphone, debout devant ce qui vient de se produire.
La suite est bien connue : une copie sur le bureau de quelqu'un, une version dans un fil d'e-mails, une copie sur le disque partagé qui est peut-être à jour, et une phase de réconciliation dont personne n'a le temps. Le registre cesse d'être une source unique et devient plusieurs récits du même mois.
3. Les preuves autour de l'enregistrement
Un incident est rarement une simple ligne. Il s'accompagne de photographies, d'un témoignage, d'un permis, d'une note de passation de poste, d'un dossier médical, parfois du rapport d'un fournisseur.
Rien de tout cela ne tient dans une cellule : cela part donc dans les e-mails et dans un dossier, relié à l'incident par un numéro de référence et par la mémoire de quelqu'un. Cela fonctionne tant que cette personne est là. Cela ne survit pas à son départ, et c'est la partie la plus difficile à reconstituer après coup, car les documents existent toujours et personne ne peut dire avec certitude quelle version a été celle prise en compte à l'époque. Garder les preuves attachées à l'enregistrement auquel elles appartiennent, plutôt que classées à côté, est ce qui rend cela récupérable des années plus tard.
4. L'historique des modifications
La quatrième défaillance est celle qui compte le plus après un événement grave, et c'est la moins visible au quotidien.
La question n'est pas de savoir qui a modifié le fichier. Elle est plus précise : qui a fait passer la gravité de majeure à mineure, à quelle date, et sur quelle base. Qui a déplacé la date de clôture. Qui a marqué l'action comme terminée, et qu'a-t-il constaté pour s'en satisfaire.
Un tableur ne peut répondre à rien de tout cela après coup, et cette absence n'est pas neutre. Elle se lit comme une lacune précisément dans les circonstances où un compte rendu clair a le plus de valeur, que le lecteur soit un auditeur, un assureur ou une autorité d'enquête.
5. Comparer, pas compter
L'analyse est la dernière à lâcher, et elle lâche plus discrètement que le reste.
La plupart des registres savent produire un décompte. Ce qu'ils ne produisent pas facilement, c'est une comparaison : ce poste par rapport à cet autre, ce site par rapport au groupe, le taux de presqu'accidents de ce trimestre corrigé du fait qu'un site déclare tout et un autre presque rien. Des décomptes bruts entre des sites aux cultures de déclaration différentes n'ont quasiment aucun sens, et le travail de correction à la main explique qu'on le fasse rarement deux fois.
Deux conséquences qui méritent d'être nommées
La sous-déclaration due à la friction. Si déclarer un événement mineur suppose de trouver le fichier, de demander un accès en écriture et de saisir dans une feuille partagée, les événements mineurs cessent d'être déclarés. Les événements graves passent toujours, parce que quelqu'un les fait remonter. Ce sont les presqu'accidents et les soins bénins qui disparaissent discrètement, et ce sont précisément les indicateurs proactifs dont tout le système dépend. Une baisse des presqu'accidents déclarés est généralement un problème de déclaration avant d'être une amélioration de la sécurité.
La question à laquelle on ne peut pas répondre vite. Après un événement significatif, quelqu'un demandera tous les incidents similaires des trois dernières années et ce qui a été fait pour chacun. C'est une question légitime, et y répondre à partir d'un tableur, d'une boîte mail et d'un disque partagé prend des jours de travail difficiles à justifier après coup.
Ce qu'il faut corriger avant de changer quoi que ce soit
Plusieurs de ces problèmes peuvent être fortement réduits sans acheter de système, et il vaut la peine de commencer par là, ne serait-ce que pour clarifier lesquels relèvent vraiment de l'outil.
- Séparez le registre de la liste d'actionsGardez l'enregistrement de l'incident comme le récit de ce qui s'est passé, et donnez aux mesures correctives leur propre liste, avec un responsable et une date chacune. L'essentiel de la dégradation décrite plus haut vient du fait que ces deux choses partagent une ligne.
- Un fichier, un propriétaire, tous les autres en lecture seuleLes contributions passent par un formulaire ou par le propriétaire. C'est moins pratique et cela met fin au problème de versions.
- Adoptez une convention de dossiers et utilisez le numéro de référenceUn dossier par incident, nommé par sa référence, contenant chaque pièce jointe. Peu glorieux, et c'est ce qui rend l'enregistrement retrouvable dans trois ans.
- Écrivez les décisions, pas seulement les résultatsQuand une gravité ou une date de clôture change, ajoutez une ligne datée indiquant qui l'a changée et pourquoi. C'est un piètre substitut à une véritable piste d'audit, et bien mieux que rien.
- Faites une revue mensuelle, brèveVingt minutes par mois sur les actions ouvertes rattrapent plus qu'une revue annuelle approfondie, parce que les personnes concernées sont encore là et s'en souviennent encore.
Ce qu'exige réellement l'ISO 45001
La norme ne prescrit pas d'outil, et il vaut la peine de savoir précisément ce qu'elle demande.
Le chapitre 7.5 exige que les informations documentées soient maîtrisées, identifiables et récupérables. Le chapitre 10.2 exige des preuves de la nature des incidents, des actions menées et des résultats de toute action corrective, y compris son efficacité. Rien là-dedans n'exclut un tableur.
Signes que le seuil est franchi
En franchir un est généralement gérable. Trois à la fois, c'est le moment où l'effort pour contourner l'outil commence à dépasser l'effort pour le remplacer.
- Plus d'un site ou d'un poste déclarant dans le même registre
- Plus d'une personne devant le mettre à jour la même semaine
- Des mesures correctives qui survivent à la personne qui les a ouvertes
- Des preuves à conserver avec l'enregistrement et à produire sur demande
- Des questions sur des tendances pluriannuelles, posées dans des délais courts
- Des presqu'accidents déclarés en baisse alors que rien d'autre n'a changé
Si vous changez d'outil, migrez moins que vous ne le pensez
L'erreur courante consiste à traiter la migration comme un projet d'archivage. Cinq ans d'historique sont importés, en grande partie incomplets, et le nouveau système s'ouvre dès le premier jour rempli d'enregistrements auxquels personne ne fait confiance.
Une meilleure approche consiste à ne migrer que les éléments ouverts : les incidents encore en cours d'analyse et les actions encore en attente. Les enregistrements historiques restent où ils sont, conservés et récupérables, ce qui est tout ce que la norme leur demande. Le nouveau système démarre alors sur une base saine, et sa première année complète est réellement comparable à elle-même.
Un point de départ concret
Prenez le dernier incident clôturé dans votre registre. Essayez de réunir en un seul endroit quatre choses : l'enregistrement de ce qui s'est passé, l'analyse, les preuves prises en compte à l'époque, et la confirmation que la mesure corrective a fonctionné.
Si cela prend quelques minutes, l'organisation actuelle tient. Si cela prend un après-midi et une conversation avec quelqu'un qui est parti, voilà la réponse, et elle est plus utile que n'importe quel argument général sur les tableurs.
Quand le tableur ne tient plus
ENSURE garde l'incident, son analyse, les preuves et la mesure corrective comme un seul enregistrement, avec l'historique de ce qui a changé et de qui l'a changé. Si vous souhaitez comparer cela à votre propre registre, nous organisons volontiers une courte session.