L’intervention de crise selon l’Annexe 13 de l’OACI
dans votre système de référence.

Voir l’encadré au-dessus du sommaire. La suite de cet article explique pourquoi les classeurs et les discussions de groupe échouent sous pression, ce que fait réellement la déclaration d’un événement et le choix de son type, comment fonctionne le tableau de tâches par rôles et séquencé par dépendances, et pourquoi il repose sur les mêmes dossiers que le reste de votre exploitation sécurité.

La plupart des exploitants disposent d’un plan d’intervention d’urgence. C’est généralement un classeur imprimé, parfois un document partagé, qui décrit qui appeler et quoi faire lorsqu’un événement grave survient. Il est rédigé avec soin, revu chaque année, et presque jamais ouvert au seul moment où il compte : la première heure après l’événement, lorsque plusieurs personnes réagissent en même temps et que la situation évolue encore.

Pendant cette heure, le classeur et la discussion de groupe qui surgit à côté partagent les trois mêmes défaillances :

• Rien n’est séquencé. Le classeur énumère des tâches ; il n’impose pas l’ordre dans lequel elles doivent se faire. Les enregistreurs et les autres données devraient être préservés avant que les lieux ne soient perturbés, mais une liste de vérification sur papier ne peut pas empêcher une étape ultérieure de commencer avant qu’une étape antérieure soit terminée.
• Rien n’est attribué à un rôle. Une discussion de groupe est un flux unique que tout le monde lit et dont personne n’est responsable. « Quelqu’un a-t-il appelé l’autorité ? » est posé trois fois et ne reçoit aucune réponse, parce qu’aucune tâche n’appartient à un rôle nommé avec un responsable clair.
• Rien n’est consigné. Lorsque l’événement est examiné plus tard, le seul historique est un fil de discussion et la mémoire des gens. Il n’existe aucun enregistrement fiable de qui a fait quoi et quand, ce que précisément une enquête et un examen de surveillance demanderont.

Rien de tout cela n’est une défaillance des personnes. C’est une défaillance de l’outil. Un classeur ne peut pas séquencer, une discussion ne peut pas attribuer, et aucun des deux ne peut consigner. Sous pression, c’est là que des étapes sont sautées, faites en double ou dans le mauvais ordre, exactement l’inverse de ce qu’une intervention alignée sur l’Annexe 13 est censée garantir.

Dans eAviora, l’intervention commence par une seule action délibérée : déclarer un événement et choisir son type. Le type n’est pas un champ de texte libre. Il est choisi dans une liste fondée sur une taxonomie de l’Annexe 13 de l’OACI, un ensemble normalisé de catégories d’événements plutôt que les mots qui viennent à la personne au clavier au pire moment possible.

C’est le choix du type qui indique à la plateforme quelle intervention déployer. La déclaration et le plan d’intervention ne forment qu’une seule action, pas deux. Dès que l’événement est déclaré et typé, le tableau de tâches correspondant apparaît, déjà rempli, déjà réparti par rôle, déjà séquencé. Il n’y a aucune étape intermédiaire où quelqu’un doit trouver le bon classeur, photocopier une liste de vérification ou lancer une discussion en espérant que les bonnes personnes la voient.

C’est important parce que la première décision dans une crise, de quel type d’événement s’agit-il, est celle qui risque le plus d’être prise à la hâte. L’ancrer dans une taxonomie normalisée garantit que l’intervention qui suit est celle qui convient à l’événement, et non celle dont se souvenait la voix la plus forte de la salle.

Le tableau que déploie la plateforme fait les deux choses qu’un classeur et une discussion ne peuvent pas faire : il répartit les tâches par rôle et il les séquence par dépendances.

Réparti par rôle. Chaque tâche appartient à un rôle : qui fait quoi. Chaque personne voit son propre couloir et sa propre liste, et non un flux unique que tout le monde doit parcourir. La question « à qui revient cette tâche ? » trouve sa réponse avant même d’être posée, si bien que deux personnes ne courent pas après le même appel pendant qu’une troisième tâche reste en plan.

Séquencé par dépendances. Les tâches sont ordonnées de sorte qu’une étape ultérieure ne puisse pas devancer celle dont elle dépend. Les premières actions essentielles d’une intervention alignée sur l’Annexe 13 arrivent dans l’ordre où elles doivent se produire :

• Notification à l’État : informer l’autorité de l’État concernée de l’événement, dans les délais que cette obligation impose.
• Préservation des enregistreurs et des données : sécuriser les enregistreurs et les autres éléments probants avant que les lieux ne soient perturbés, pour que rien de ce dont l’enquête a besoin ne se perde pendant l’intervention.
• Assistance aux familles : mettre en place le soutien dû aux personnes touchées, comme une responsabilité à part entière dans son propre couloir plutôt qu’après coup.
• Enquête : ouvrir l’enquête que l’équipe sécurité poursuivra une fois l’intervention immédiate stabilisée.

Parce que l’ordre est intégré au tableau plutôt qu’imprimé sur une page, la séquence tient même lorsque plusieurs personnes travaillent en parallèle. Un flux de travail qui ne peut pas sauter d’étape, c’est tout l’intérêt : sous pression, la structure porte la discipline pour que les personnes n’aient pas à la garder en tête.

Ce qui fait du poste de pilotage de crise plus qu’une meilleure liste de vérification, c’est l’endroit où il se trouve. L’événement et son enquête sont déjà des dossiers liés dans la même exploitation connectée. Lorsque vous déclarez un événement de crise, l’intervention repose sur ces mêmes dossiers, pas dans un classeur séparé, pas dans un outil séparé, pas dans une discussion qui disparaît quand le fil défile.

Concrètement, cela signifie :

• Une seule enquête, pas deux. L’enquête que vous ouvrez pendant l’intervention est la même que celle que votre équipe sécurité poursuit ensuite, avec un historique continu. Il n’y a aucun transfert d’un classeur de crise vers un système de sécurité, parce que l’intervention n’en a jamais été séparée.
• La même piste d’audit. Chaque tâche accomplie sur le tableau d’intervention est consignée sur les mêmes dossiers liés que vos données de sécurité : qui a fait quoi, quand, dans quel ordre. Lorsque l’événement est examiné plus tard par l’équipe d’enquête ou par la surveillance, l’historique est déjà là, et non reconstitué de mémoire.
• Pas de seconde source de vérité. L’intervention, l’événement et l’enquête forment une seule exploitation connectée. Rien ne doit être recopié d’un document de crise vers les dossiers de sécurité, parce qu’il s’agissait des mêmes dossiers depuis le début.

Le contraste résume tout l’argument. Un classeur imprimé accompagné d’une discussion de groupe improvisée vous donne un plan qui n’est ni séquencé, ni attribué, ni consigné. Un poste de pilotage d’intervention relié à la même exploitation vous en donne un qui est les trois à la fois, et qui se prolonge directement dans l’enquête et l’examen de surveillance sans une seule ressaisie.

Les surfaces concernées : module SGS, module réglementaire. Découvrez comment nous traitons vos données ou écrivez-nous pour parler de votre exploitation.