Ce qu’un SGS Part 135 attend
vraiment de son logiciel.

Voir l’encadré au-dessus du sommaire. La suite de cette page détaille ce que l’échéance de 2027 exige réellement d’un exploitant d’affrètement, les quatre fonctions que votre logiciel doit assurer, les fonctionnalités que vous pouvez ignorer pour une petite flotte, une liste d’évaluation simple, et la façon dont eAviora est conçu pour l’exploitant de 2 à 20 aéronefs qui n’a pas de service sécurité dédié.

La règle finale SGS de la FAA a été publiée le 26 avril 2024 et est entrée en vigueur le 28 mai 2024. Elle a révisé la 14 CFR Part 5 et étendu les exigences relatives au système de gestion de la sécurité au-delà des compagnies aériennes Part 121 à un ensemble bien plus large d’exploitants : tous les titulaires de certificat Part 135, les exploitants de vols touristiques commerciaux qui volent sous lettre d’autorisation 91.147 et certains titulaires de certificat Part 21. Si vous détenez un certificat Part 135, vous êtes concerné, et la Part 5 révisée est désormais votre référence.

Le calendrier comporte deux dates importantes pour un exploitant d’affrètement. Les plans de mise en œuvre devaient être remis à la FAA le 28 novembre 2024. Le SGS doit ensuite être pleinement mis en œuvre, avec une déclaration de conformité soumise à la FAA, au plus tard le 28 mai 2027. Une phrase change la manière dont un petit exploitant doit lire tout cela : l’exigence s’applique quelle que soit la taille de l’exploitant, y compris explicitement aux titulaires exploitant un seul aéronef ou avec un seul pilote. Il n’existe aucune exemption pour les petits exploitants. Un exploitant d’affrètement de deux avions fait face à la même échéance qu’un transporteur régional.

Ce que demande la Part 5 s’articule en quatre composantes : politique de sécurité, gestion des risques de sécurité, assurance de la sécurité et promotion de la sécurité. Les révisions de 2024 exigent aussi un système de signalement confidentiel des employés et la déclaration de conformité elle-même. Ces quatre composantes portent les mêmes noms que dans une compagnie aérienne, et c’est précisément cette similitude qui met les petits exploitants en difficulté : ils supposent que les quatre composantes signifient le même volume de paperasse. Ce n’est pas le cas. Les composantes sont obligatoires ; leur profondeur s’adapte à votre exploitation.

Une fois le jargon écarté, un SGS Part 135 demande à son logiciel d’assurer quatre fonctions reliées. Il suffit d’en manquer une pour fragiliser la déclaration, car chacune correspond à une composante de la Part 5 que vous devez étayer.

• La réception de signalements confidentiels. Tout pilote, régulateur de vol ou technicien de maintenance doit pouvoir signaler un danger ou un événement sans craindre que cela se retourne contre lui. Cela suppose un canal dépersonnalisé, pas un courriel au chef pilote. Un véritable système de signalement confidentiel est une exigence explicite de la règle révisée, pas un simple atout.
• L’évaluation des risques. Chaque compte rendu nécessite une évaluation structurée de la gravité et de la probabilité, afin de trier les deux sujets qui comptent vraiment cette semaine au lieu de traiter de la même façon un impact d’oiseau et un café renversé. C’est la composante gestion des risques de sécurité en pratique.
• Le suivi des actions correctives. Un danger n’est pas clôturé parce que quelqu’un a acquiescé en réunion. Il est clôturé lorsque la correction est attribuée, réalisée et que son efficacité est démontrée. Le logiciel doit mener chaque action jusqu’à sa clôture et refuser que le registre prétende le contraire.
• La piste d’éléments probants. Lorsqu’un examinateur de la FAA ou votre inspecteur principal le demande, vous devez montrer la chaîne : compte rendu, évaluation des risques, action, clôture, le tout relié et horodaté, sans passer un week-end à faire des captures d’écran. Cette piste fait la différence entre une déclaration acceptée et une constatation ouverte.

Transversal à ces quatre fonctions, il y a l’outil d’évaluation des risques avant vol (FRAT). Un FRAT est une notation numérique des risques avant vol, largement utilisée en Part 135, en aviation d’affaires et dans les exploitations d’hélicoptères, et la FAA comme les associations professionnelles publient des modèles de référence. L’intérêt de placer le FRAT dans le même système est que la note quotidienne de décision de départ d’un équipage n’est pas un formulaire jetable : une série de notes FRAT élevées sur une route ou un appareil donné est un indicateur avancé qui a sa place dans la même image des risques que vos événements signalés.

Savoir ce que l’on peut ignorer est tout aussi important que l’indispensable. Un petit exploitant d’affrètement qui achète en vue de la déclaration de 2027 n’a pas besoin, et devrait même activement éviter, plusieurs éléments que mettent en avant les catalogues pour grandes entreprises :

• Une bibliothèque vierge à alimenter. De nombreux outils historiques sont livrés avec un catalogue de dangers vide et un registre des risques vide, et attendent que votre équipe en construise le contenu de zéro. Pour un exploitant sans service sécurité, cela représente des mois de saisie non rémunérée avant toute valeur de sécurité.
• Un projet de paramétrage à l’échelle d’une compagnie aérienne. Si l’outil exige un consultant de mise en œuvre payant et un déploiement de trois mois pour démarrer, il n’est pas à la bonne taille. Une exploitation de deux à vingt aéronefs devrait traiter de vrais comptes rendus en quelques jours, pas en quelques trimestres.
• Des modules que vous n’utiliserez pas avant des années. Les suites d’ingénierie de fiabilité de flotte, l’analytique de sécurité cabine et les outils lourds de planification d’audits existent bel et bien, mais ce n’est pas ce qui vous mène à une déclaration Part 5. Payez pour la boucle qui se referme, pas pour le catalogue qui impressionne.
• Des outils ponctuels déconnectés. Une application de signalement ici, un registre des risques sur feuille de calcul là, et un outil de suivi des actions à part, cela fait trois endroits où la chaîne des éléments probants peut se rompre. La valeur d’un SGS réside dans les liens entre les registres, pas dans les registres eux-mêmes.

La tentation de surinvestir vient généralement de la peur d’échouer à l’audit. Le remède n’est pas d’ajouter des fonctionnalités. C’est un système qui rend impossible de sauter les quatre fonctions ci-dessus, et qui ne vous gêne pas pour tout le reste.

Voici une liste simple à appliquer à tout outil candidat. Vous êtes un exploitant d’affrètement, pas un service des achats : notez donc chaque outil selon sa capacité à vous aider à produire des éléments probants d’ici le 28 mai 2027 avec le personnel dont vous disposez réellement.

• Délai avant le premier vrai compte rendu. Un pilote peut-il déposer un compte rendu confidentiel dès le premier jour, ou le système exige-t-il d’abord des semaines de paramétrage ?
• Le modèle de risque est-il fourni ? Les dangers, scénarios et barrières sont-ils préchargés et propres à l’aviation, ou le registre est-il vide ?
• Un registre peut-il être clôturé malgré un risque ouvert ? Un bon outil refuse de clôturer un danger tant que son action corrective est encore ouverte. Demandez au fournisseur d’essayer d’enfreindre cette règle pendant une démonstration.
• La piste d’éléments probants est-elle exportable ? Pouvez-vous remettre à un examinateur une chaîne reliée du compte rendu à la clôture sans la ressaisir dans un rapport séparé ?
• Le signalement confidentiel est-il réellement dépersonnalisé ? La personne qui signale reçoit-elle un retour sans jamais être exposée ?
• Le FRAT fait-il partie du même système ? La notation avant vol alimente-t-elle votre image des risques, ou vit-elle dans une application séparée ?
• Combien coûte l’IA et qui garde le contrôle ? La consommation d’IA est-elle prévisible et plafonnée, et une personne accepte-t-elle ou rejette-t-elle chaque proposition de l’IA ?
• Où résident vos données ? L’isolation entre clients est-elle imposée par la base de données, et vos données de signalement sont-elles exclues de tout entraînement de modèle ?

Si un outil satisfait à cette liste, il vous mènera à la déclaration sans service sécurité. Notre guide de l’acheteur développe chacun de ces points en questions d’achat que vous pouvez envoyer telles quelles.

eAviora est conçu pour satisfaire à cette liste, précisément pour l’exploitant qui n’a pas de service sécurité. Le point de départ est le modèle de risque fourni : une bibliothèque de risques aéronautiques 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é. Vous ne construisez pas le catalogue des dangers. Il est là dès le premier jour, et vous l’adaptez à votre exploitation au lieu de le rédiger.

Tout repose sur un seul graphe opérationnel. Événements, dangers, enquêtes de sécurité, actions correctives, audits, constatations, documents, formation, conformité, indicateurs, votre profil de risque de sécurité, ainsi que la gouvernance du groupe d’action sécurité et du comité d’examen de la sécurité, sont des registres reliés, et non des feuilles de calcul séparées. C’est ce qui fait de la piste d’éléments probants un sous-produit du travail plutôt qu’un projet de reporting à part entière. Le module SGS est la porte d’entrée, et les mêmes liens mènent un compte rendu jusqu’à une action clôturée.

La règle qui protège le plus un petit exploitant est le contrôle de clôture imposé : un registre ne peut pas être clôturé tant qu’un risque reste ouvert. Une barrière dégradée exige une action corrective reliée, dont l’efficacité est démontrée, avant que quoi que ce soit n’apparaisse comme clôturé. Ce n’est pas une politique écrite dans un manuel qu’un chef pilote débordé pourrait oublier sous la pression d’une échéance ; c’est imposé par le système, et éprouvé par une batterie de scénarios. Votre profil de risque de sécurité est calculé à partir de sept composantes fusionnées en un score unique aligné sur le Doc 9859 de l’OACI, et les indicateurs passent par une véritable maîtrise statistique des procédés, et non par des flèches de tendance colorées, de sorte qu’un véritable signal est distingué de la variation ordinaire.

C’est sur la question de la charge de travail que l’IA compte. eAviora fait fonctionner une flotte d’agents IA spécialisés rattachés aux étapes du flux de travail, et chaque proposition de l’IA est soumise à validation humaine : une personne l’accepte, la modifie ou la rejette, et la décision est journalisée. L’assistant prépare la classification et une première évaluation des risques ; une personne nommée assume la décision. La consommation d’IA est mesurée en simples crédits avec des plafonds stricts, si bien qu’il n’y a pas de coût surprise, et eAviora n’entraîne aucun modèle sur les données d’exploitation. L’isolation entre clients est imposée par la base de données, et pas seulement par le code applicatif, ce qui est la réponse qu’un assureur ou la revue de sécurité d’un client souhaite réellement entendre. Pour le voir appliqué à votre propre exploitation, vous pouvez demander une démonstration.