ECCAIRS 2, ADREP et E5X,
en langage clair.

Le bloc mis en évidence au-dessus du sommaire donne la version courte : plateforme, taxonomie, format. La suite de cet article définit chacun des trois, suit un compte rendu depuis le premier écran jusqu’à ECCAIRS 2, puis en vient à ce qui touche réellement votre quotidien : ce que tout cela implique pour le système de signalement que vous exploitez en interne.

Les trois termes décrivent trois couches différentes, et les garder séparées rend tout le sujet limpide.

• ECCAIRS 2, la plateforme. C’est la génération logicielle européenne actuelle de collecte, de stockage et d’analyse des données d’événements de l’aviation civile. Quand on dit qu’un compte rendu va dans ECCAIRS, c’est cette destination que l’on désigne. Des générations antérieures d’ECCAIRS l’ont précédée ; ECCAIRS 2 est celle avec laquelle exploitants et autorités travaillent aujourd’hui.
• ADREP, la taxonomie. ADREP est un vocabulaire codé et structuré, publié par l’OACI, pour décrire les événements. Plutôt que de la prose libre, il fournit des valeurs contrôlées pour les attributs d’un événement, afin que la même chose soit décrite de la même façon partout. C’est la langue, pas le logiciel.
• E5X, le format de transfert. E5X est un fichier XML compressé qui transporte un ou plusieurs comptes rendus codés en ADREP d’un système à l’autre. C’est l’enveloppe normalisée pour déplacer les données d’événements, lisible par machine afin que le destinataire puisse intégrer chaque champ sans ressaisie.

C’est ici que la réglementation rejoint la tuyauterie. Le Règlement (UE) n° 376/2014 exige que les bases de données d’événements soient compatibles avec ECCAIRS et classées selon ADREP, et E5X est le format qui fait fonctionner l’échange en pratique. Pour une vue complète des obligations de compte rendu que servent ces noms, des deux filières de signalement au délai de 72 heures en passant par les protections de la culture juste, le guide associé sur les comptes rendus d’événements selon le Règlement (UE) n° 376/2014 les couvre de bout en bout.

Suivez un seul événement depuis le moment où quelqu’un le remarque, et le rôle de chaque nom devient évident.

• Quelqu’un le signale. Une personne prend connaissance d’un événement et le dépose auprès de son organisation, idéalement par un canal confidentiel et sous forme d’enregistrement structuré plutôt que de courriel.
• L’organisation le code. Les attributs clés du compte rendu sont classés selon la taxonomie ADREP, si bien qu’il devient un enregistrement comparable et prêt à l’échange au lieu d’une note isolée.
• L’organisation le transfère. Le compte rendu est transmis à l’autorité nationale compétente. Si le système interne le permet, cela se fait sous forme de paquet E5X ; sinon, cela se fait à la main.
• Il arrive dans le système européen. Les données sont versées dans ECCAIRS 2, où les autorités agrègent et analysent les événements dans une vue d’ensemble, bien au-delà de ce que voit un seul exploitant.

La mécanique de cette troisième étape se décline de deux façons. Soit un système compatible produit un fichier E5X qui transporte les comptes rendus codés dans un seul paquet structuré, soit une personne ouvre un portail Web et saisit les comptes rendus un par un. Les deux satisfont l’obligation de transfert. Elles diffèrent énormément en coût, en cohérence et en tenue lorsque le volume de signalement augmente, ce qui est le véritable sujet des deux sections suivantes.

Voici la partie qui arrive réellement sur votre bureau. Les noms ECCAIRS 2, ADREP et E5X décrivent l’échange, mais le travail qui rend cet échange simple ou pénible se fait bien plus tôt, dans la façon dont votre propre système saisit un événement au départ. Trois propriétés en décident.

• La qualité de la correspondance taxonomique. Votre classification interne doit correspondre proprement à ADREP. Quand c’est le cas, coder un compte rendu est une étape unique et cohérente, et les données sont prêtes à l’échange. Sinon, quelqu’un doit traduire chaque événement en ADREP plus tard, et deux personnes traduiront différemment le même événement.
• Des champs structurés à la saisie. Les attributs clés d’un événement doivent être saisis comme des champs codés et contrôlés dès le premier écran, et non reconstitués après coup à partir d’un paragraphe de prose. Toute structure que vous omettez à la saisie, vous la payez plus tard, avec intérêts.
• Aucune ressaisie. Le même événement doit être saisi une seule fois et traverser l’enquête, l’action et le transfert comme un seul enregistrement. Chaque fois qu’un compte rendu est retapé, du courriel au tableur puis au portail, c’est une occasion d’introduire une erreur et une ponction sur le temps de l’équipe.

Le fil conducteur est simple : saisissez la structure une seule fois, à la réception, et tout ce qui suit, l’analyse, le fichier de transfert, la piste d’audit, lit le même enregistrement propre. Un système de signalement qui recueille du texte libre en espérant le coder plus tard a inversé l’effort, et cela se traduit par des transferts lents, des données incohérentes et des comptes rendus que personne ne peut agréger. C’est l’une des raisons concrètes pour lesquelles le passage de la gestion de la sécurité à l’intelligence en sécurité commence à la saisie, et non au tableau de bord.

Il existe deux modes de fonctionnement pour faire entrer les comptes rendus dans le système européen, et l’écart entre eux se creuse à chaque compte rendu que vous déposez.

L’export natif compatible. Le système détient déjà les événements sous forme d’enregistrements structurés alignés sur ADREP, si bien que produire un paquet de transfert compatible revient presque à appuyer sur un bouton. Le codage est cohérent parce qu’il a été fixé à la saisie, l’erreur de transcription est éliminée dès la conception parce que personne ne retape rien, et l’approche passe à l’échelle : un mois chargé en comptes rendus coûte la même poignée de clics qu’un mois calme.

La saisie manuelle sur le portail. Une personne ouvre un portail Web et saisit chaque compte rendu à la main. Pour quelques comptes rendus occasionnels, c’est tout à fait praticable. Mais cela entraîne trois coûts qui s’additionnent à mesure que le volume augmente : un réel temps de personnel par compte rendu, des erreurs de transcription, et une dérive du codage, parce que chacun interprète les valeurs un peu différemment. Pire encore, quand le signalement devient une corvée, les gens signalent moins, sans bruit, ce qui est l’inverse de la raison d’être de tout le système.

Il ne s’agit pas de dire qu’un modèle a toujours raison. Les petites exploitations peuvent vivre longtemps avec la saisie sur portail. Il s’agit de choisir en connaissance de cause, et de savoir que, dès que le signalement devient routinier, l’export natif à partir d’un système structuré cesse d’être un simple atout et devient ce qui garde vos données cohérentes et vos déclarants disposés à signaler.

Un système de signalement conçu pour ce monde fait la partie difficile au début : il saisit chaque événement une seule fois, comme un enregistrement structuré, avec une classification tirée d’une taxonomie contrôlée, afin que tout ce qui suit soit propre. eAviora est conçu ainsi.

Les événements entrent dans un seul graphe opérationnel sous forme d’enregistrements structurés et restent liés à leurs enquêtes, actions correctives, audits, constatations, documents et aux indicateurs de sécurité qu’ils font bouger. Saisi une seule fois, le même enregistrement traverse chaque étape, si bien qu’il n’y a ni ressaisie du tableur vers le portail, ni perte de structure entre les outils. Le signalement commence de façon confidentielle, avec une boucle de culture juste fermée, de sorte que protéger le déclarant et produire des données propres ne s’opposent pas.

Comme les données sont structurées dès la saisie, ce qui compte le plus pour le Règlement (UE) n° 376/2014 devient atteignable plutôt qu’aspirationnel : les événements peuvent être agrégés et suivis en tendance avec une véritable maîtrise statistique des procédés au lieu d’une flèche colorée, et des barrières de clôture imposées font qu’un enregistrement ne peut pas être clos sur un risque ouvert : le suivi est une règle que le flux de travail fait respecter, pas une promesse que l’équipe doit tenir. La taxonomie est le socle de l’ensemble : réussissez la correspondance à la saisie, et l’analyse, le transfert et l’audit lisent tous le même enregistrement propre. Consultez le module SGS et le module Conformité pour voir où vivent cette saisie et cette analyse.