Inspections de sécurité au chantier : où le processus entre le terrain et le registre se fragmente

Compléter une inspection de sécurité sur le chantier prend quelques minutes. Intégrer cette inspection dans un registre partagé, la lier à une action corrective et confirmer que l’action a été fermée — ce processus prend souvent plusieurs jours et repose sur des courriels, des formulaires papier et des relances manuelles.

Où le processus se fragmente

Les inspections sont saisies à un endroit et enregistrées à un autre. Le surintendant complète un formulaire papier, une liste de vérification en PDF ou une entrée dans une application de sécurité. Ces données doivent ensuite rejoindre le système de gestion de projet ou le système de gestion de la sécurité — généralement par ressaisie ou par pièce jointe courriel. Les deux registres ne correspondent que rarement de façon exacte.

Les actions correctives sont suivies de manière informelle. Lorsqu’une inspection identifie un danger ou une correction requise, la relance se fait par courriel ou instruction verbale. Il n’existe aucun système de référence indiquant qui est responsable de l’action, quel est le délai, ni si elle a été fermée avant la prochaine inspection.

Les quasi-accidents et les observations sont sous-déclarés. Quand signaler exige de remplir un formulaire, de trouver la bonne personne et d’attendre un accusé de réception, les travailleurs passent outre — surtout pour les observations de faible gravité. Les données qui permettraient d’identifier des tendances récurrentes n’atteignent jamais le système.

La documentation requise par la CNESST est reconstituée après coup. Lors d’un incident à déclarer, le dossier exigé est reconstitué à partir de photos, de formulaires d’inspection, de notes des surintendants et de témoignages — chacun provenant d’un endroit différent. Assembler ces éléments sous pression crée des lacunes.

L’état d’avancement est invisible pour l’équipe de projet. Les résultats d’inspection, les actions correctives ouvertes et les éléments en retard ne sont pas visibles dans le système de gestion de projet que le reste de l’équipe utilise. La performance en sécurité existe dans un système distinct, consulté uniquement par le responsable SST.

Là où la conception du processus aide

Un formulaire d’inspection unique qui alimente un registre partagé. Quand les surintendants soumettent des inspections via un formulaire structuré — sur téléphone ou tablette — la saisie va directement au registre de sécurité sans étape de ressaisie. Photos, localisation et code de projet sont capturés au point d’observation.

Actions correctives assignées et suivies dans le même système. Quand une inspection génère un constat, l’action corrective peut être assignée à une personne précise avec un délai et une étape de confirmation. L’état d’avancement est visible sans avoir à envoyer un courriel de relance.

Un parcours de signalement court et simple pour les quasi-accidents. Un formulaire minimal — trois champs et une photo — réduit suffisamment l’effort pour rendre le signalement praticable pour les travailleurs qui l’omettraient autrement. Les données qui atteignent le système sont plus utiles qu’un formulaire complet jamais soumis.

Des registres structurés prêts avant qu’une déclaration CNESST ne soit nécessaire. Quand chaque inspection, constat et action corrective est enregistré dans un format uniforme, la documentation requise pour un incident déclarable est déjà structurée. L’assemblage sous pression devient une récupération plutôt qu’une reconstruction.

La bonne approche dépend des outils de sécurité, du logiciel de gestion de projet et des systèmes documentaires déjà en place. L’objectif n’est pas de remplacer le processus d’inspection. C’est d’éliminer l’écart entre ce qui a été observé et ce que le système affiche.

À lire aussi : rapports quotidiens de chantier : où les transferts se brisent et suivi des RFI : où les approbations en construction ralentissent.

---

Si vos registres d’inspection de sécurité transitent encore par du papier, des courriels ou des applications distinctes avant d’atteindre le dossier de projet — décrivez-nous comment votre processus fonctionne actuellement. On cartographiera les points de friction et ce qu’une connexion ciblée pourrait éliminer.