Ce que l’UE 376/2014 attend
de chaque organisme déclarant.

Voir l’encadré au-dessus du sommaire pour la version courte. La suite de ce guide présente les deux flux de comptes rendus et leurs délais, les protections de culture juste, un processus conforme de bout en bout, et l’écart d’analyse et de suivi qui sépare une boîte aux lettres d’un véritable programme de données de sécurité.

Le règlement s’applique à toute l’aviation civile européenne et atteint à la fois les organismes et les personnes qui y travaillent. Son but n’est pas de sanctionner, mais de garantir que les événements susceptibles de nuire à la sécurité sont recueillis, analysés et traités avant qu’ils ne s’alignent en accident. Pour y parvenir, il normalise quatre choses : ce qui fait l’objet d’un compte rendu, dans quel délai, comment c’est conservé et comment cela circule.

Il existe deux flux de comptes rendus. Le flux obligatoire couvre des catégories définies d’événements qui doivent faire l’objet d’un compte rendu ; les catégories exactes figurent dans les règles de mise en œuvre de l’UE applicables, alors travaillez toujours à partir de la liste en vigueur plutôt que d’une vieille copie. Le flux volontaire couvre tout ce qu’une personne estime susceptible de constituer un danger, même hors catégorie obligatoire. Les deux flux portent les mêmes obligations en aval, et tous deux relèvent de la même protection.

Le délai dont on se souvient est la fenêtre de 72 heures : une personne rend compte d’un événement dans les 72 heures suivant sa prise de connaissance. À partir de là, les obligations passent à l’organisme, qui doit :

• Recueillir et conserver chaque compte rendu dans une base de données d’événements structurée.
• L’évaluer, et mener une enquête ou un suivi quand le contenu le justifie.
• Analyser les informations qu’il détient pour identifier les dangers et les tendances.
• Engager et suivre des actions correctives ou préventives.
• Transmettre le compte rendu à l’autorité nationale compétente.

C’est l’exigence de stockage qui surprend les équipes. Les données d’événements doivent résider dans une base de données compatible ECCAIRS et être classées selon la taxonomie ADREP, le vocabulaire codé et structuré de l’OACI pour décrire ce qui s’est passé. L’échange s’appuie sur le format E5X, un fichier XML compressé qui transporte des comptes rendus codés ADREP, et la plateforme de destination est ECCAIRS 2. Pour la mécanique de ces trois noms en langage clair, l’article associé sur ECCAIRS 2, ADREP et E5X les passe en revue avec ce qu’ils impliquent pour votre système interne.

Une règle de compte rendu ne fonctionne que si les gens signalent, et les gens ne signalent que s’ils ont confiance que leur parole ne sera pas retournée contre eux. Cette confiance est inscrite dans le règlement, pas laissée à la bonne volonté. L’article 16 fixe les protections de culture juste qui font fonctionner les flux de comptes rendus.

Deux idées font l’essentiel du travail :

• L’information sert la sécurité, pas la recherche de coupable. Les éléments tirés des comptes rendus d’événements servent à maintenir ou à améliorer la sécurité, et ne visent pas à attribuer une faute ou une responsabilité.
• Les auteurs sont protégés. Les personnes sont protégées contre les conséquences disciplinaires, administratives ou liées à l’emploi fondées sur un événement qu’elles signalent, avec des exceptions étroites pour des cas tels que la négligence grave ou la faute intentionnelle. L’identité de l’auteur est protégée et les comptes rendus sont traités de façon confidentielle.

Sur le plan opérationnel, la dépersonnalisation est donc une exigence de conception, pas une réflexion après coup. La personne qui reçoit, code et analyse un compte rendu doit pouvoir travailler son contenu de sécurité sans jamais avoir à révéler qui l’a déposé, et le reste de l’organisme doit voir des résultats dépersonnalisés. Pour la version pratique, notre article sur la culture juste en cinq questions trace la frontière entre l’erreur de bonne foi et le comportement inacceptable, et la boucle de culture juste fermée montre comment une saisie confidentielle peut tout de même aboutir à un bulletin dépersonnalisé et à un retour à l’auteur sans rompre cette protection.

Mettez les obligations dans l’ordre et un processus conforme de comptes rendus d’événements devient un cycle de vie clair, pas une pile de tâches. Chaque étape existe parce que le règlement la demande, et chacune produit l’enregistrement dont la suivante a besoin.

• Saisir. L’événement fait l’objet d’un compte rendu dans la fenêtre de 72 heures par un canal accessible et confidentiel, et arrive sous forme de dossier structuré plutôt que de courriel dans la boîte de réception de quelqu’un.
• Accuser réception et protéger. L’auteur reçoit un accusé de réception, et son identité est séparée du contenu de sécurité pour que le compte rendu puisse être traité de façon dépersonnalisée.
• Classer. Les attributs clés sont codés selon la taxonomie ADREP dès la saisie : le dossier est prêt à l’échange et comparable à tous les autres comptes rendus, au lieu d’être une note isolée en texte libre.
• Évaluer et enquêter. L’événement fait l’objet d’une évaluation des risques, et une enquête de sécurité est ouverte quand la gravité ou la tendance le justifie.
• Agir. Des actions correctives et préventives sont ouvertes, attribuées et suivies jusqu’à leur clôture, pour qu’un danger ne soit pas simplement consigné puis oublié.
• Transmettre. Le compte rendu est transmis à l’autorité nationale compétente sous une forme compatible ECCAIRS, dans le délai fixé par le règlement.
• Analyser et faire un retour. Les comptes rendus sont agrégés pour dégager dangers et tendances, et les auteurs voient qu’il s’est passé quelque chose en conséquence, ce qui maintient le flux de signalements.

Les étapes qui ouvrent et ferment des actions sont celles où beaucoup de programmes fuient : c’est pourquoi la boucle des actions correctives, gérée dans le module Actions, compte autant que la saisie gérée dans le module SGS. Une saisie sans clôture, c’est un classeur, pas un système de sécurité.

L’écart le plus courant est celui que relève chaque audit : les organismes construisent la saisie et s’arrêtent là. Un formulaire de signalement soigné, un décompte mensuel des comptes rendus reçus et le sentiment que la case est cochée. Mais le règlement ne demande pas seulement que les événements soient recueillis. Il demande qu’ils soient analysés pour identifier les dangers et que des actions de suivi soient menées. La saisie est la partie facile de l’obligation. L’analyse, la clôture et le retour d’information en sont le reste, et ce sont eux qui réduisent réellement le risque.

Les modes d’échec se regroupent en quelques schémas :

• Des actions qui ne se ferment jamais. Les actions correctives sont ouvertes mais pas suivies, si bien que le risque ouvert persiste sans que personne n’en réponde.
• Aucune analyse d’ensemble. Chaque compte rendu est traité isolément : la tendance que révéleraient trois événements presque identiques n’est jamais vue.
• Des auteurs sans retour. Les gens signalent et n’entendent plus rien. Le volume de signalements baisse, et la boucle de culture juste se rompt en silence.
• Un codage taxonomique faible. Les événements sont conservés en texte libre, si bien que rien ne peut être comparé, agrégé ou échangé proprement.
• Une transmission par tableur. Les données ne peuvent pas produire de fichier compatible : le personnel ressaisit chaque compte rendu à la main dans un portail, ce qui est lent, sujet aux erreurs et ne passe pas à l’échelle.

Chacun de ces cas est un endroit où la lettre du règlement est respectée sur la page de saisie et manquée partout ensuite. La solution n’est pas davantage de signalements ; c’est de relier le compte rendu à ses conséquences. Quand un événement est lié à son enquête, à ses actions correctives et aux indicateurs qu’il fait bouger, l’obligation d’analyse et de suivi cesse d’être une corvée manuelle et devient une propriété du système, comme l’expose notre article sur le lien entre événement, CAPA, SPI et profil de risque de sécurité.

Un système conçu pour le Règlement (UE) n° 376/2014 n’est pas un formulaire plus intelligent. C’est un système de référence qui mène un événement du premier écran confidentiel jusqu’à la clôture et à l’analyse, sans perdre le fil ni la protection. eAviora est construit comme ce système.

Le signalement commence en toute confidentialité, avec une boucle de culture juste fermée : la saisie reste dépersonnalisée, le compte rendu est traité sans révéler qui l’a déposé, et la boucle peut tout de même se fermer par un bulletin dépersonnalisé et un retour à l’auteur. Dès la saisie, l’événement entre dans un seul graphe opérationnel, lié à son enquête, à ses actions correctives, aux audits et constatations qui le concernent, aux documents dont il dépend et aux indicateurs de sécurité qu’il fait bouger. Comme il s’agit d’un seul dossier structuré plutôt que d’une ligne copiée d’un outil à l’autre, il est saisi une fois et jamais ressaisi pour passer d’une étape à la suivante.

Deux choix de conception font la différence sur les points que les exploitants manquent habituellement. D’abord, des barrières de clôture imposées : un dossier ne peut pas être clos sur un risque ouvert, si bien qu’une barrière dégradée doit porter une action corrective liée dont l’efficacité a été prouvée avant que l’événement soit considéré comme résolu. C’est l’obligation d’analyse et de suivi transformée en règle que le flux impose, et non en discipline dont l’équipe doit se souvenir. Ensuite, une véritable maîtrise statistique des procédés sur les indicateurs de sécurité, fondée sur les règles de la Western Electric plutôt que sur une flèche de tendance colorée, pour que le signal d’ensemble que le règlement vous demande de trouver soit réellement détectable. Des agents IA assistent en chemin, mais chaque proposition passe par une validation humaine et est journalisée, et la consommation est mesurée en crédits simples, si bien que l’assistance ne devient jamais une boîte noire sans gouvernance.

La question de la taxonomie suit le même principe. L’objectif est qu’un événement soit saisi dans des champs structurés et contrôlés dès la saisie, alignés sur le vocabulaire dont l’échange a besoin, afin que produire une transmission compatible soit une propriété de données propres plutôt qu’un projet de ressaisie. Saisissez la structure une fois, et la transmission, l’analyse et la piste d’audit lisent toutes le même dossier. Voir le module SGS et le module Conformité pour voir comment la saisie, l’analyse et les éléments probants se trouvent au même endroit.