Logiciel SGS aviation pour l’aviation d’affaires,
à la taille d’un service aviation.

Voir l’encadré au-dessus du sommaire. La suite de cet article explique pourquoi un service aviation adopte un SGS, comment fonctionne le modèle par étapes de l’IS-BAO, comment dimensionner le système sans bureau sécurité, ce qu’il faut vérifier dans le logiciel et quand le mandat de la Part 5 s’applique aussi.

L’aviation d’entreprise et d’affaires présente un profil de risque particulier. Les vols suivent la demande : les voyages surgissent à bref délai vers des aéroports que l’équipage connaît parfois mal. Les dirigeants fixent le programme, ce qui exerce une pression discrète sur les décisions de partir ou non. Le service est petit : un départ, un report de maintenance ou un équipage fatigué représente une large part de l’exposition de la semaine. Un système de gestion de la sécurité permet à un service de rendre ces pressions visibles et de les gérer délibérément plutôt qu’à l’instinct.

Deux forces amènent la plupart des services à un véritable SGS. La première est l’IS-BAO, la norme internationale pour l’exploitation des aéronefs d’affaires, que beaucoup d’exploitants adoptent comme gage d’un service bien tenu et que les assureurs et les clients charter recherchent de plus en plus. La seconde est un lien avec la Part 135 : dès qu’une partie des vols est effectuée sous un certificat charter, le mandat de la Part 5 de la FAA s’applique à cette exploitation. Dans les deux cas, le service a besoin d’un système utilisé, pas d’un manuel sur une étagère.

L’IS-BAO, publiée par le Conseil international de l’aviation d’affaires (IBAC), repose sur un SGS adaptable et s’évalue en trois étapes progressives :

• Étape 1 : le SGS est établi, la structure, la politique et les processus existent.
• Étape 2 : le SGS fonctionne, les activités de gestion de la sécurité sont intégrées aux opérations quotidiennes et les données donnent lieu à des actions.
• Étape 3 : le SGS est ancré, la gestion de la sécurité fait partie de la culture du service et se maintient dans la durée.

La norme est volontairement adaptable, d’un seul aéronef sur des vols intérieurs à une flotte qui vole d’un continent à l’autre. Ce qui fait passer un service d’une étape à la suivante n’est pas davantage de paperasse, c’est la preuve d’usage : des comptes rendus qui arrivent, des évaluations des risques consignées sur de vrais voyages, des actions ouvertes puis closes et une revue de direction tenue à intervalles réguliers qui laisse une trace. Un logiciel qui conserve ces éléments probants au même endroit transforme chaque évaluation : on ne court plus, on exporte.

Un service de 2 à 5 aéronefs a rarement un gestionnaire de la sécurité à temps plein. Le rôle est généralement assumé par le directeur des opérations aériennes, le chef pilote ou un commandant de bord en plus d’une autre fonction. Cette réalité doit façonner le SGS, pas être masquée par lui. Les quatre composantes doivent toujours exister (politique, gestion des risques de sécurité, assurance de la sécurité et promotion de la sécurité), mais elles sont menées à une profondeur qui correspond à une petite exploitation.

Le piège classique consiste à copier le manuel SGS d’une compagnie aérienne et à hériter d’un système qu’aucun petit service ne peut alimenter. Un manuel de 200 pages décrivant des comités que le service n’a pas est pire qu’un manuel court qui décrit ce que le service fait vraiment. Bien dimensionner, c’est laisser le logiciel porter la routine (acheminer un nouveau compte rendu vers la bonne personne, relancer le responsable d’une action avant l’échéance, assembler le dossier pour la revue) afin que la seule personne qui porte la casquette sécurité consacre son temps au jugement, pas à l’administration.

Jugez une plateforme sur les tâches qu’un petit service accomplit chaque semaine, pas sur une liste de fonctionnalités :

• Un signalement que tout le monde utilisera. Un pilote, un planificateur ou un mécanicien doit pouvoir signaler un danger ou un événement depuis un téléphone en moins d’une minute, avec la possibilité de rester confidentiel. Le volume de signalements est le premier signe d’un SGS en bonne santé ; la friction le tue.
• Un outil d’évaluation des risques avant vol. Un FRAT qui cote un voyage avant son départ et soumet une cote élevée à un second regard est l’habitude quotidienne qui change le plus les comportements. Sa valeur se multiplie quand les cotes arrivent dans le même système que les événements et deviennent des données de tendance.
• Une évaluation des risques consignée, pas mémorisée. Les dangers et leurs évaluations existent sous forme de dossiers avec un responsable et une date de revue, défendables devant un évaluateur.
• Un suivi des actions jusqu’à la clôture. Les mesures d’atténuation ont un responsable, une échéance et la preuve qu’elles ont fonctionné, si bien que rien n’est abandonné en silence.
• Une seule exploitation connectée. Comptes rendus, dangers, risques, actions et documents partagent un même graphe : un événement est lié au danger qui le concerne et compte pour lui, au lieu de rester dans un silo.

C’est là qu’une plateforme aéronautique connectée se distingue d’une application d’incident générique. Dans eAviora, un événement est évalué au regard des barrières du nœud papillon (bow-tie) de sa famille de risque, compte dans les indicateurs qui suivent cette famille et alimente la vue d’ensemble du risque calculée, des agents IA assistant la classification sous approbation humaine et chaque modification étant journalisée. Le service part aussi d’un modèle de risque aéronautique préconstruit (85 modèles bow-tie, 682 barrières nommées, 183 scénarios et une bibliothèque de 516 indicateurs SPI) plutôt que d’une page blanche qu’il n’a pas le temps de remplir.

Pour les aspects de la question d’achat communs à tous les exploitants, le guide de l’acheteur et les critères de logiciel pour la Part 135 traitent le même sujet plus en profondeur.

Un service qui vole uniquement sous la Part 91 pour sa propre entreprise n’entre pas directement dans le mandat de la Part 5 de la FAA de 2024. Mais une large part de l’aviation d’affaires est exploitée sous la Part 135 par une société de gestion, et tout titulaire d’un certificat Part 135 doit avoir un SGS pleinement mis en œuvre et une déclaration de conformité déposée d’ici le 28 mai 2027, quelle que soit la taille de la flotte, exploitations à un seul aéronef comprises. Si votre aéronef est un jour exploité sous un certificat charter, la règle atteint cette exploitation, et la société de gestion aura besoin des éléments probants qui appuient sa déclaration.

En pratique : un service qui vise l’IS-BAO et un service qui se prépare à la Part 5 ont besoin du même système opérationnel. Adopter un seul SGS qui produit de vrais enregistrements sert à la fois la norme volontaire et le mandat contraignant, sans mener deux efforts en parallèle. Pour le détail du mandat, voir la règle finale de la Part 5 expliquée et dimensionner un SGS pour les petits exploitants.