Un SGS à la mesure d’un pilote
et de trois aéronefs.

Voir l’encadré mis en évidence au-dessus du sommaire. Les sections suivantes expliquent pourquoi la règle atteint les plus petits exploitants, ce que signifie le fait qu’un SGS s’adapte par sa profondeur plutôt que par son existence, pourquoi un manuel de compagnie aérienne emprunté se retourne contre vous, à quoi ressemble un système bien dimensionné pour un à trois aéronefs sans service de sécurité, et comment un logiciel léger porte la charge sans en ajouter.

La règle finale de la FAA sur le SGS, publiée le 26 avril 2024 et entrée en vigueur le 28 mai 2024, a révisé la 14 CFR Part 5 et étendu les exigences relatives au système de gestion de la sécurité bien au-delà des compagnies aériennes Part 121. Elle a inclus tous les titulaires de certificat Part 135, les exploitants de vols touristiques commerciaux titulaires d’une lettre d’autorisation 91.147 et certains titulaires de certificat Part 21. La phrase que les petits exploitants doivent le plus lire est explicite dans la Part 5 révisée : elle s’applique quelle que soit la taille de l’exploitant, y compris aux titulaires de certificat exploitant un seul aéronef ou avec un seul pilote.

Le calendrier est celui que suit tout exploitant Part 135. Les plans de mise en œuvre devaient être remis à la FAA le 28 novembre 2024, et le SGS doit être entièrement mis en œuvre, avec une déclaration de conformité soumise au plus tard le 28 mai 2027. Il n’existe aucun seuil en dessous duquel l’obligation disparaît, ni aucune version de la règle qui permette à une exploitation d’un seul aéronef de s’en soustraire. La même échéance de 2027 autour de laquelle un transporteur régional planifie est celle autour de laquelle planifie un titulaire de certificat à pilote unique.

Ce n’est pas un excès de rigueur de la FAA. Cela découle du cadre de l’OACI dans l’Annexe 19, où le SGS à quatre composantes et douze éléments est décrit comme adaptable à la taille et à la complexité de l’exploitation, et du Doc 9859 de l’OACI (Manuel de gestion de la sécurité), qui, dans son édition en vigueur, consacre un réel effort à la manière de dimensionner un système. L’intention a toujours été qu’un petit exploitant fasse fonctionner un petit SGS, pas aucun SGS.

L’idée la plus utile pour un petit exploitant est celle-ci : l’évolutivité s’applique à la profondeur, pas à l’existence. Tous les exploitants font fonctionner les mêmes quatre composantes d’un SGS. Ce qui change avec la taille, c’est la part de chacune que vous faites fonctionner, et à quelle fréquence.

Voyez ce qui change réellement d’échelle. Un grand transporteur peut suivre des centaines de dangers ouverts, faire fonctionner plusieurs comités permanents qui se réunissent chaque semaine, publier des dizaines d’indicateurs de performance de sécurité et tenir une bibliothèque documentaire qui se mesure en classeurs. Un exploitant de trois aéronefs suit une courte liste de dangers actifs, tient une seule revue de sécurité mensuelle, surveille une poignée d’indicateurs utiles à son exploitation et conserve un manuel de quelques pages. Les deux pratiquent la gestion des risques de sécurité. Chez l’un, c’est un processus de comité ; chez l’autre, une revue structurée de quinze minutes avant la fin du mois.

Voyez maintenant ce qui ne disparaît pas avec l’échelle. Les quatre composantes elles-mêmes sont obligatoires à toute taille. Le canal de signalement confidentiel est exigé, que vous employiez deux cents personnes ou deux. La discipline consistant à évaluer le risque de ce qui est reçu, puis à mener une action corrective jusqu’à une clôture démontrée, est la même à toute échelle. Lorsqu’un exploitant reçoit une constatation au titre de la Part 5, ce n’est presque jamais parce que son SGS était trop petit. C’est parce qu’une composante manquait entièrement, le plus souvent un canal confidentiel qui n’a jamais existé ou une étape de clôture qui n’a jamais eu lieu. La profondeur est un choix ; l’existence ne l’est pas.

L’erreur la plus courante d’un petit exploitant pressé par l’échéance consiste à se procurer le manuel SGS d’un grand exploitant, à changer le nom sur la couverture et à le soumettre. Cela paraît efficace. C’est le moyen le plus rapide de récolter une constatation.

Un manuel de compagnie aérienne emprunté décrit une exploitation que vous ne menez pas. Il mentionne un groupe d’action sécurité (SAG) et un comité d’examen de la sécurité (SRB) qui se réunissent à une cadence que vous ne pouvez pas assurer, des titulaires de poste que vous n’employez pas et des procédures pour des services que vous n’avez pas. Un auditeur ne note pas le manuel comme une dissertation. Il lit ce qu’il affirme, puis observe ce que vous faites, et l’écart entre le système écrit et le système réel est précisément l’endroit où tombe la constatation. Un épais manuel rempli de promesses que vous ne pouvez pas tenir est pire qu’un mince manuel exact, car chaque promesse non tenue est une non-conformité documentée que vous avez rédigée vous-même.

Il y a un second coût. Un manuel emprunté enfouit les quelques routines qui comptent vraiment pour votre exploitation sous des dizaines de pages de procédures qui ne se produiront jamais, si bien que le document cesse d’être un outil utilisé par votre équipage et devient un objet d’étagère. La solution consiste à dimensionner la structure du manuel selon votre exploitation : décrivez ce que vous faites réellement, qui le fait et à quelle fréquence. Si une section décrit un comité qui n’existe pas, supprimez-la. Le manuel et l’exploitation doivent concorder, et dans une petite exploitation, le manuel honnête le plus court est le plus solide.

À quoi ressemble donc un système bien dimensionné lorsque toute l’exploitation compte un à trois aéronefs et qu’il n’existe aucun service de sécurité ? Il s’organise autour de quelques routines honnêtes, et il permet aux rôles de se cumuler partout où cela ne compromet pas l’indépendance.

• Les rôles se cumulent, une limite tient. Le dirigeant responsable peut être le propriétaire, et le responsable de la sécurité peut être le chef pilote. C’est acceptable à cette taille, tant que la seule limite que vous ne brouillez jamais est le canal de signalement confidentiel : un compte rendu doit pouvoir parvenir au système et être dépersonnalisé sans que son auteur soit exposé.
• La cadence suit le volume. Au lieu de comités hebdomadaires, une seule revue de sécurité mensuelle de ce qui a été signalé, du niveau de risque observé et des actions ouvertes. Courte, consignée dans un procès-verbal et réelle.
• Le FRAT est l’outil de tous les jours. Un outil d’évaluation des risques avant vol, rempli avant chaque vol, est la routine la plus précieuse dont dispose un petit exploitant. Il transforme le jugement quotidien de départ ou de non-départ en données notées, et une série de notes élevées est un signal avancé qui mérite d’être examiné.
• Le signalement confidentiel s’applique toujours, et compte davantage. Dans une exploitation de deux personnes, tout le monde sait qui a piloté quoi, ce qui rend un canal de signalement réellement dépersonnalisé plus difficile et plus important, pas facultatif. Une vraie boucle fermée, où l’auteur du compte rendu reçoit un retour sans jamais être nommé, est ce qui rend les gens disposés à signaler le danger suivant.

Remarquez que rien de tout cela n’est une idée plus modeste qu’un SGS de compagnie aérienne. Ce sont les mêmes quatre composantes, dimensionnées selon l’exploitation. Le travail qu’exige leur fonctionnement est toutefois là où un petit exploitant est le plus exposé, car aucune équipe ne peut l’absorber. C’est un problème logiciel.

La plupart des petits exploitants commencent avec une feuille de calcul, et une feuille de calcul fait un bon premier registre des dangers. Elle devient un handicap précisément au moment où cela compte. Une feuille de calcul ne peut pas empêcher qu’un danger soit marqué comme clôturé alors que son action corrective est encore ouverte. Elle ne peut pas dépersonnaliser un compte rendu confidentiel. Elle ne laisse aucune piste reliée de l’événement à l’évaluation des risques puis à l’action qui l’a corrigé, de sorte que lorsqu’un examinateur vous demande de prouver que la boucle a été fermée, vous la reconstruisez à la main. Et elle se corrompt discrètement dès que deux personnes la modifient en même temps.

Le réflexe est alors de se tourner vers une grosse plateforme, avec la crainte qu’un logiciel signifie plus de travail. Pour un petit exploitant, c’est l’inverse lorsque l’outil est bien conçu, car l’essentiel de la charge d’un SGS sur feuille de calcul consiste à construire et à maintenir le contenu à la main. eAviora supprime cette charge à la source : le modèle de risque est fourni dès l’installation, une bibliothèque préconstruite de 85 modèles en nœud papillon (bow-tie), 682 barrières nommées, 183 scénarios et une bibliothèque de 516 indicateurs de performance de sécurité. Un exploitant d’un seul aéronef n’a pas à rédiger un catalogue de dangers. Il est là dès le premier jour, et vous le restreignez à votre exploitation.

À partir de là, la même discipline qui protège une compagnie aérienne protège un exploitant à pilote unique, sans ajouter de personnel. Le module SGS gère les événements, les dangers, les évaluations des risques et les actions correctives sur un seul graphe opérationnel, de sorte que la piste d’éléments probants est un sous-produit du travail accompli. Le contrôle de clôture imposé signifie qu’un registre ne peut pas être clôturé tant qu’un risque reste ouvert : une barrière dégradée exige une action corrective liée, dont l’efficacité est démontrée, avant que quoi que ce soit apparaisse comme clôturé. C’est la discipline de clôture qu’un propriétaire-pilote très occupé pourrait sinon oublier, rendue structurelle. L’IA aide à porter la paperasse : des agents spécialisés préparent la classification et une première évaluation des risques, et chaque proposition est soumise à validation humaine, de sorte qu’une personne l’accepte, la modifie ou la rejette et que la décision est journalisée. La consommation est mesurée en simples crédits avec des plafonds fermes, eAviora n’entraîne aucun modèle sur vos données, et l’isolation entre clients est imposée par la base de données, pas seulement par le code de l’application. Pour le voir dimensionné selon votre exploitation, vous pouvez demander une présentation.