Comment Astry aide un acteur majeur du BTP à gérer les crises sur ses chantiers
Astry a été conçu pour joindre la bonne personne au bon moment, qu'un serveur tombe ou qu'un accident survienne sur un chantier. Un accident du travail, une évacuation, un incident de sécurité impliquant un ouvrier : ce sont exactement les mêmes problèmes à résoudre que pour une panne IT : remonter l'information vite, à la bonne personne, avec une procédure claire de ce qui doit être fait.
C'est un usage pour lequel Astry a été pensé dès le départ, et qu'un acteur majeur du BTP met en œuvre aux États-Unis : Astry sert d'outil de gestion de crise sur des chantiers physiques, pour tout ce qui touche à la sécurité (au sens large) des équipes sur site. Cet article détaille, fonctionnalité par fonctionnalité, ce que permet le module Crises d'Astry, en prenant ce déploiement comme fil conducteur.
Le constat : la crise n'est pas toujours un problème IT
La plupart des outils de gestion de crise du marché sont pensés pour l'informatique : ils partent d'une alerte de monitoring, remontent vers une équipe technique, et s'arrêtent là. Le processus de gestion d'un accident corporel sur un chantier se rapproche de cette vision : quelqu'un constate un problème, doit prévenir les bonnes personnes immédiatement, suivre une procédure connue, et laisser une trace de ce qui a été fait.
C'est aussi ce qui a motivé le choix de ce client. Aujourd'hui, les astreintes IT et les procédures de sécurité peuvent être gérées au même endroit, avec la même traçabilité.
Une organisation par chantier, des équipes par périmètre
Chez ce client, chaque chantier est une Organisation Astry à part entière. Au sein de chaque chantier, l'organisation est découpée en plusieurs Équipes, en fonction des responsabilités de chacun et des périmètres sur lesquels chacun travaille. Les Équipes peuvent être rattachées à une Ressource de catégorie « Lieu », positionnée par ses coordonnées GPS sur une carte (de quoi représenter fidèlement un chantier physique, distinct d'un site industriel ou d'un bureau).
Lorsqu'une crise est déclarée, elle est assignée à l'équipe concernée au sein de l'organisation du chantier. Toute la mécanique de résolution se déroule alors dans le périmètre de cette équipe, et la communication autour de la crise peut être faite de façon plus large (par exemple vers des personnes extérieures à l'équipe).
Des postes, pas seulement des rôles
Astry distingue depuis longtemps trois rôles techniques (Propriétaire, Intervenant, Partie prenante), qui gèrent les droits d'accès à l'outil. Mais un rôle technique ne dit rien de la hiérarchie réelle d'un chantier.
C'est l'objectif des Postes : des titres métier définis par l'organisation (chef de chantier, responsable HSE, conducteur de travaux, ...) et assignés aux membres d'une équipe, indépendamment de leurs droits Astry. Une même personne peut être « Chef d'équipe » dans une équipe et « Manager » dans une autre.
Exemple de définition d'une hierarchie de postes.
Chaque poste peut porter sa propre escalade : si une action assignée à un poste n'est pas traitée dans un délai défini (de 5 minutes à 7 jours), elle se réassigne automatiquement à un autre poste. Sur un chantier, cela permet par exemple qu'une alerte non traitée par le chef d'équipe remonte automatiquement au responsable HSE régional, sans intervention manuelle.
Déclarer une crise en quelques écrans, depuis le terrain
Sur le terrain, personne ne veut remplir un formulaire de dix champs pour signaler un problème. La déclaration se fait donc depuis l'application mobile, en cinq écrans volontairement réduits au strict nécessaire : Localisation, Équipe, Type, Sous-type, puis Description.
Aperçu du parcours de déclaration mobile
Un détail fait la différence sur un chantier : la description peut être dictée plutôt que tapée, le champ correspondant se remplit automatiquement à partir de l'enregistrement vocal fait au moment de la déclaration (appréciable avec un casque de chantier et les mains prises). L'horodatage, lui, se remplit automatiquement, sans action de l'utilisateur.
Les champs affichés et les actions à réaliser sont configurés en amont (voir la section suivante).
Configurer une fois : Types et Modèles de crise
C'est le cœur du système, et ce qui permet à une déclaration en 30 secondes de déclencher un processus complet en coulisses.
Un Modèle de crise définit à l'avance :
- un message de statut et un message de clôture, avec des champs dynamiques (texte ou date) que l'intervenant n'a plus qu'à compléter ;
- une liste de contacts et équipes à notifier automatiquement (email, SMS, appel vocal, notification push, Microsoft Teams) ;
- une checklist d'actions à réaliser, dans l'ordre ou en parallèle.
Exemple de configuration de messages de statut et de clôture sur un modèle de crise.
Les Types de crise (Accident corporel, Incident de sécurité, Évacuation, ...) sont de simples étiquettes qui permettent de filtrer et retrouver le bon Modèle au moment de déclarer une crise (la personne sur le chantier n'a pas à deviner quelle procédure suivre, elle choisit le bon type et le bon modèle s'affiche).
Pour ce client, cela signifie transformer une procédure interne d'accident du travail (habituellement un document PDF que personne ne relit sous le coup du stress) en un Modèle réutilisable, testé, et systématiquement appliqué de la même façon sur tous les chantiers.
Actions : transformer une procédure interne en checklist opérationnelle
Chaque étape d'une procédure interne devient une Action dans le Modèle de crise : un libellé, une description, obligatoire ou non, assignée à un Poste plutôt qu'à une personne nommée (c'est le titulaire du poste, dans l'équipe concernée du chantier, qui est notifié). Les actions obligatoires doivent être complétées avant de pouvoir clôturer la crise.
Ces actions peuvent s'enchaîner séquentiellement (« après la précédente ») ou se dérouler en parallèle, pour représenter fidèlement un processus réel : prévenir la sécurité et appeler les secours en même temps, mais n'informer la direction régionale qu'une fois la situation stabilisée, par exemple. Chaque action peut aussi porter sa propre méthode de notification et sa propre fréquence de rappel, indépendamment du message général envoyé à tous les contacts de la crise.
Astry n'intègre pas ces actions à un système externe : elles restent des étapes internes, cochées et tracées dans l'outil. Il n'y a donc pas d'intégration à développer pour commencer à utiliser ces actions.
Une équipe mixte US/ES, un seul modèle
Les équipes de chantier de ce client ne parlent pas toutes la même langue : une partie du personnel s'exprime en anglais, une autre en espagnol. La traduction automatique intervient à deux niveaux.
Côté configuration, chaque action d'un Modèle de crise peut porter une traduction proposée automatiquement (détection de la langue source puis traduction vers l'anglais, l'espagnol ou le français), toujours modifiable avant validation (jamais appliquée silencieusement). Celui qui construit le Modèle rédige ainsi une seule fois chaque action ; l'intervenant qui la consulte sur le terrain la voit dans sa propre langue.
Côté déclaration, quand un collaborateur signale une crise à la voix depuis l'application mobile, sa description orale est automatiquement traduite en anglais (la version d'origine étant systématiquement conservée à côté de la traduction). Le collaborateur peut donc parler dans sa langue. Côté siège, la crise est suivie en anglais, tout en conservant la formulation originale.
C'est un détail, mais c'est précisément le genre de friction qui, en temps normal, fait qu'une procédure bien écrite finit par ne plus être suivie à la lettre par une partie de l'équipe (ou qu'une information cruciale se perd dans la traduction improvisée d'un appel téléphonique).
Piloter toutes les crises d'un chantier
Avec plusieurs équipes actives sur un même chantier, il faut aussi une vue d'ensemble. Astry affiche une bannière de crise persistante dans toute l'application dès qu'une crise est ouverte quelque part dans l'organisation. Le tableau de bord centralise également les crises ouvertes aux côtés des incidents techniques, pour une vision unique de la situation sur le chantier.
L'objet, les contacts, les actions et les événements relatifs à la crise sont tracés et visibles au sein de la page de suivi d'une crise.
Le module de reporting dédié aux crises permet ensuite de prendre du recul : nombre de crises déclarées, durée moyenne et médiane de résolution, crises les plus longues (autant d'indicateurs utiles pour identifier un chantier ou un type d'incident qui mériterait une procédure révisée).
Après la crise : le compte-rendu (REX)
Une fois la crise résolue, Astry génère un Compte-Rendu de Crise (REX) exportable en PDF : description, messages de statut et de clôture, contacts notifiés, chronologie complète des événements (changements de statut, escalades, actions réalisées), actions en attente, et les photos partagées en commentaires pendant la crise.
Pour un secteur comme le BTP, où la traçabilité d'un accident du travail a une valeur autant opérationnelle que juridique, ce document généré automatiquement (plutôt que reconstitué a posteriori à partir de mails et de notes éparses) est un gain de temps direct pour les équipes HSE.
Une seule plateforme, tous les terrains
Ce déploiement illustre ce pour quoi Astry a été conçu : à la fois un outil d'astreinte IT et un moteur de gestion de crise générique (équipes, postes, modèles, actions, escalade, traçabilité) que chaque organisation configure pour son propre domaine. Que ce domaine soit une salle serveur ou un chantier de travaux publics ne change rien à la mécanique.
Si votre organisation gère des situations exceptionnelles en dehors du seul périmètre IT (sécurité physique, environnement, continuité d'activité) contactez-nous pour échanger sur votre cas d'usage, ou démarrez gratuitement pour configurer votre premier Modèle de crise.
Mots-clés : crise, sécurité chantier, BTP, escalade, traduction automatique, REX.