Au-delà du signalement des événements
pour les exploitants aériens.

Voir l’encadré au-dessus du sommaire. La suite de cet article présente la définition opérationnelle qui sous-tend ce résumé.

Il y a vingt ans, le SGS d’une compagnie aérienne était un classeur. Le formulaire de signalement était sur papier. Le registre des dangers était une feuille de calcul. La matrice de risque était sur un tableau blanc. L’ordre du jour du comité d’examen de la sécurité reposait sur les meilleurs souvenirs du responsable de la sécurité concernant le mois précédent. L’Annexe 19 de l’OACI a changé cela en formalisant les quatre piliers ; le marché l’a changé en produisant des logiciels capables de porter ces documents.

Le logiciel SGS a résolu le problème de l’enregistrement. Il saisissait les événements sous une forme structurée, les classait selon une taxonomie définie, pilotait un flux de travail de CAPA, conservait la piste d’audit et rendait les données exportables pour l’autorité. Cette capacité est aujourd’hui le minimum attendu. Toute compagnie aérienne raisonnable au-delà d’une certaine taille exploite une plateforme SGS ; la question d’en avoir une est réglée.

La question qui s’est imposée en 2026 est celle de la suite. Le logiciel SGS saisit des faits isolés ; les responsables de la sécurité doivent lire des tendances, des trajectoires et des signaux de surveillance. La forme de plateforme qui répond à cette question est ce que nous appelons l’intelligence en sécurité aérienne.

Le signalement des événements est le fondement d’un système de gestion de la sécurité. C’est aussi la limite de ce qu’une plateforme fondée sur les événements peut apprendre au responsable de la sécurité.

Un dossier d’événement répond à : ce qui s’est passé, quand, qui était impliqué, quelle catégorie, quelle gravité. Il ne répond pas à lui seul aux questions suivantes :

• Quelles barrières ont tenu et lesquelles ont cédé ? L’analyse en nœud papillon fait le pont entre un événement et la structure de défense en profondeur sous-jacente.
• Est-ce un cas isolé ou une tendance ? Les tableaux de bord SPI font le pont entre un événement et la tendance.
• À quoi ressemble le profil de risque de sécurité cette semaine ? Le SRP fait le pont entre les événements et le signal de surveillance que lit le dirigeant responsable.
• Les CAPA que nous avons clôturées sont-elles réellement efficaces ? La vérification de l’efficacité fait le pont entre la clôture d’une action et la certitude que le système de sécurité s’est amélioré.

Chacun de ces ponts est un élément différent de l’exploitation connectée. Les plateformes fondées sur les événements présentent généralement chacun d’eux dans un module séparé ; l’intégration entre modules se limite au mieux au partage de dossiers. Le responsable de la sécurité doit assembler la vue d’ensemble à coups de requêtes.

La plupart des compagnies aériennes exploitent aujourd’hui plusieurs systèmes liés à la sécurité : une plateforme SGS, une plateforme SGQ (parfois du même éditeur, parfois non), un système de gestion documentaire (souvent Web Manuals ou un outil de l’écosystème Microsoft), un système de dossiers de formation, un système de gestion des audits, et une couche de rapports ou d’informatique décisionnelle par-dessus.

Chaque système détient une partie de la vue d’ensemble. Chacun a été acheté pour résoudre un problème précis. Chacun s’intègre aux autres par des exportations planifiées, des synchronisations périodiques ou une nouvelle saisie manuelle. Cette fragmentation n’est pas une incompétence technique ; c’est le résultat naturel de deux décennies de solutions ponctuelles répondant à des besoins tactiques.

Le coût se paie à chaque réunion du comité d’examen de la sécurité. Le dossier est assemblé à partir de cinq exportations. Les chiffres du tableau de bord SGS ne concordent pas tout à fait avec ceux du SGQ, car les requêtes ont été exécutées à des moments différents. Le pourcentage de conformité de la formation dans le système de gestion de l’apprentissage date de trois semaines. Un auditeur demande les éléments probants reliant une constatation à une CAPA et l’équipe les produit en 90 secondes, à partir des courriels, et non d’une plateforme.

Les plateformes d’intelligence en sécurité aérienne existent pour mettre fin à cette fragmentation chez les exploitants qui le souhaitent.

La définition minimale de l’intelligence en sécurité aérienne est le lien entre quatre éléments : l’événement, la CAPA, le SPI et le SRP.

Événement → CAPA. Chaque événement classifié fait apparaître un nouveau danger ou renforce un danger existant. Le danger déclenche une nouvelle action corrective ou se rattache à une action existante. La CAPA est la couche d’action.

Événement → SPI. Chaque événement classifié incrémente un ou plusieurs compteurs SPI : approches non stabilisées, sorties de piste, dommages au sol, écarts par rapport au TCAS, etc. Le SPI est la couche de mesure.

Barrière du nœud papillon → SPI. Lorsqu’un événement révèle une barrière dégradée, l’efficacité de la barrière baisse et le SPI qui suit l’événement redouté correspondant le reflète. Le SPI est aussi un signal d’efficacité des barrières, pas seulement un compteur d’événements.

SPI → SRP. Le profil de risque de sécurité agrège l’état des SPI, la santé des barrières, les CAPA ouvertes et les événements récents en une vue opérationnelle que le dirigeant responsable lit chaque semaine. Le SRP est la couche de surveillance.

Lorsque ces quatre éléments partagent une seule exploitation connectée, le comité d’examen de la sécurité lit une seule vue. Sinon, il lit cinq exportations. La plateforme qui livre ces dossiers liés est ce que nous appelons l’intelligence en sécurité aérienne.

L’intelligence en sécurité aérienne est la vue opérationnelle qu’une compagnie aérienne lit au-dessus de son système de gestion de la sécurité. Cette vue repose sur quatre ingrédients :

1. Une seule exploitation connectée qui relie SGS, SGQ, SeMS, conformité IOSA, CAPA, SPI, SRP, maîtrise documentaire, formation et veille réglementaire.
2. Des agents IA sous contrôle humain qui assistent la classification, la rédaction des CAPA, la détection des signaux faibles et la synthèse des rapports. Chaque résultat de l’IA peut être examiné, rejoué et audité.
3. Des signaux dérivés en temps réel : efficacité des barrières, tendances des SPI, état du SRP, mis à jour par les dossiers sous-jacents plutôt qu’affirmés en atelier.
4. Une seule piste de niveau audit de la politique aux éléments probants jusqu’au résultat, traçable pour l’autorité trois ans plus tard.

L’intelligence en sécurité aérienne n’est pas l’IA pour l’IA, et ce n’est pas un module SGS rebaptisé. C’est une autre forme de plateforme, conçue autour de la vue opérationnelle plutôt que du dossier.

eAviora est construit selon cette forme : un seul graphe opérationnel à travers SGS, SGQ, SeMS, conformité IOSA, CAPA, SPI et maîtrise documentaire, avec un profil de risque de sécurité calculé à partir des dossiers plutôt que saisi dans une diapositive. Les sections ci-dessous expliquent ce que cela change pour l’équipe sécurité.

eAviora est la plateforme d’intelligence en sécurité aérienne conçue pour livrer exactement les quatre ingrédients ci-dessus. Elle s’adresse aux compagnies aériennes, aux autorités de l’aviation civile, aux organismes de réglementation, aux organismes de maintenance, aux prestataires d’assistance en escale et aux organismes de formation agréés dont la prochaine décision de plateforme doit rendre visible la situation opérationnelle, et pas seulement saisir le dossier.

La surface d’intelligence est livrée, pas seulement décrite. Le copilote eAvy lit la vue opérationnelle en temps réel, suit les liens entre les dossiers et fait ressortir les cas semblables à un nouveau compte rendu ; derrière lui fonctionne une flotte d’agents IA spécialisés liés à des étapes précises du flux de travail. Et cette même vue gouvernée est ouverte à vos propres outils par une API REST versionnée, un serveur MCP (la norme ouverte qui permet à un assistant IA d’interroger vos données) et un connecteur OAuth, avec une limite stricte : une IA ou l’API peut proposer, mais ne peut jamais fixer l’état de gouvernance. Une machine ne valide rien d’elle-même.

Surfaces concernées :

• Module SGS : signalement des événements, dangers, matrice de risque, analyse en nœud papillon.
• Module SGQ : audits, constatations, gestion de la qualité, dans la même exploitation connectée que le SGS.
• Module CAPA / Actions : la couche d’action, avec la vérification de l’efficacité comme condition stricte.
• Analyse de la sécurité : une bibliothèque de SPI évaluée chaque jour, des tableaux de bord de tendances, le profil de risque de sécurité.
• Module Conformité : alignement sur l’Annexe 19 de l’OACI, l’AESA (EASA), la FAA et l’IOSA avec des éléments probants traçables.

Consultez le Guide de l’acheteur ou écrivez-nous pour parler de votre exploitation.