Un logiciel SGS qu’un organisme Part-145
peut faire tourner à l’atelier.

Voir l’encadré au-dessus du sommaire pour la version courte. La suite de cet article passe les six critères un par un (saisie à l’atelier, taxonomies de maintenance, audit et constatations, CAPA close sur efficacité, maîtrise documentaire et flux de comptes rendus UE 376) et se termine sur la question qui les tranche tous : un seul graphe, ou plusieurs outils.

Acheter un logiciel SGS pour un organisme de maintenance n’est pas le même exercice que pour le service des opérations aériennes d’une compagnie. Les flux doivent résister au contact du hangar, et le système doit satisfaire une autorité de maintenance, pas seulement faire bonne figure en démonstration. Six critères séparent un outil qui sera réellement utilisé d’un outil qui finira sur une étagère :

• Saisie à l’atelier. Un technicien peut-il signaler un événement ou un danger en quelques minutes, sur un terminal partagé ou un téléphone, avec une option confidentielle ?
• Taxonomies de maintenance. Les catégories de dangers, d’événements et de causes sont-elles conçues pour la maintenance, ou s’agit-il d’une liste générique de compagnie aérienne qu’il faut tordre ?
• Audit et constatations. Fait-il tourner des audits planifiés et mène-t-il les constatations jusqu’à leur clôture, c’est-à-dire la fonction de surveillance de la conformité que vous exploitez déjà ?
• CAPA close sur efficacité. Peut-on obliger une action corrective à prouver qu’elle a fonctionné avant sa clôture, ou « close » signifie-t-il simplement que quelqu’un a coché une case ?
• Maîtrise documentaire. Maîtrise-t-il vos procédures de maintenance avec un circuit nommé de revue et d’approbation, un historique des versions et un accusé de lecture ?
• Flux de comptes rendus. Achemine-t-il un événement à déclaration obligatoire vers l’autorité compétente selon l’UE 376/2014, au bon format ?

Notez chaque candidat sur ces six points et les lacunes apparaissent vite. La suite de cet article les reprend un à un.

Le premier mode d’échec d’un logiciel de sécurité en maintenance est que les personnes qui voient les dangers ne l’ouvrent jamais. Un technicien certifié en pleine tâche ne s’arrêtera pas pour remplir un formulaire de dix champs sur un poste de bureau. La saisie doit être rapide, accessible depuis l’endroit où le travail se fait, et disponible sous forme de canal confidentiel pour le compte rendu que quelqu’un ne déposera que si son nom est protégé. Si signaler un danger prend plus de temps que de le décrire à un collègue, il sera décrit à un collègue et perdu.

Le second mode d’échec est la taxonomie. Une liste d’événements générique de compagnie aérienne, construite autour des phases de vol et des événements en cabine, oblige un organisme de maintenance à faire entrer ses vrais dangers dans des catégories qui ne leur conviennent pas, et les données qui en sortent sont inutiles pour repérer une tendance. La maintenance a besoin de ses propres catégories de dangers, d’événements et de facteurs contributifs : erreur d’installation, contrôle de l’outillage, gestion des défauts reportés, relève de quart, et les facteurs humains qui alimentent réellement l’erreur de maintenance. eAviora fournit 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 de performance de sécurité), si bien que la structure pertinente pour la maintenance est là, à adapter plutôt qu’à construire depuis un écran vide. La saisie arrive dans le module SGS sous forme de dossier vivant, pas de ligne dans un tableur.

Un organisme Part-145 exploite déjà une fonction de surveillance de la conformité : audits planifiés au regard du règlement et de l’exposé de l’organisme, constatations quand quelque chose n’est pas conforme et actions correctives pour y remédier. Un bon logiciel SGS ne la remplace pas, il la fait tourner sur le même système que la sécurité, si bien qu’une constatation d’audit et un danger issu d’un compte rendu de sécurité aboutissent dans le même circuit d’actions correctives au lieu de deux.

Le critère qui compte le plus ici est ce que signifie « close » pour une action corrective. Dans un outil faible, clore une CAPA est un changement de statut : quelqu’un la marque comme faite. C’est ainsi que les constatations reviennent : la correction a été consignée mais jamais vérifiée. Une action corrective et préventive doit comporter une vérification de l’efficacité : l’action est mise en œuvre, puis le système exige la preuve qu’elle a réellement fonctionné avant d’autoriser la clôture du dossier. eAviora l’impose comme barrière de clôture. Un dossier ne peut pas se clore sur un risque ouvert, et une barrière dégradée exige d’abord une action corrective liée dont l’efficacité a été prouvée, une règle prouvée par une suite de scénarios qui réussit 13 sur 13. Les actions correctives fonctionnent dans le module actions, et l’article sur les barrières de clôture imposées explique pourquoi prouver l’efficacité avant la clôture est tout l’enjeu.

Deux autres critères décident si le logiciel convient spécifiquement à un organisme de maintenance : la maîtrise documentaire et le flux de comptes rendus.

Vos procédures de maintenance, l’exposé de l’organisme, les instructions de travail et les formulaires sont des documents maîtrisés. Un logiciel SGS qui les ignore vous laisse gérer un système documentaire séparé et refaire les liens à la main. Une véritable maîtrise documentaire, c’est un circuit nommé de revue et d’approbation (un vérificateur, un approbateur et un publicateur, pour qu’aucune personne ne puisse mettre seule une procédure en ligne), un historique des versions, un accusé de lecture pour savoir que les bonnes personnes ont vu la révision en vigueur, et une cadence de revue qui ramène un document avant qu’il ne devienne obsolète. Quand la maîtrise documentaire repose sur le même graphe que vos audits et constatations, une constatation portant sur une procédure renvoie directement au document maîtrisé qu’elle concerne.

Le flux de comptes rendus est l’autre indispensable propre à la maintenance. Selon l’UE 376/2014, un événement à déclarer doit parvenir à l’autorité nationale compétente, dans le délai prévu et sous une forme que l’autorité peut intégrer : l’univers compatible ECCAIRS, codé ADREP et au format E5X décrit dans le guide des comptes rendus UE 376/2014. Un logiciel qui s’arrête à la saisie interne laisse la transmission réglementaire à faire à la main ; un logiciel conçu pour cela achemine l’événement de la saisie à la classification puis au compte rendu sortant. eAviora assure la maîtrise documentaire dans le module documents et fait passer les comptes rendus d’événements par le même graphe opérationnel.

Chaque critère ci-dessus se ramène à une seule question : s’agit-il d’un seul système connecté, ou de plusieurs outils qui partagent un identifiant de connexion ? C’est la chose la plus importante qu’un organisme Part-145 puisse tester, car toute la valeur d’un système de gestion intégré (la conception qu’encourage l’AESA) est que la sécurité et la qualité cessent d’être deux mondes parallèles.

Sur un seul graphe opérationnel, un événement est lié à son enquête de sécurité, l’enquête à l’action corrective, l’action corrective à la procédure qu’elle modifie et à l’indicateur de sécurité qu’elle fait bouger. La constatation d’audit et le danger issu d’un compte rendu de sécurité alimentent le même circuit de CAPA. Le profil de risque de sécurité est calculé à partir des dossiers sous-jacents (sept composantes fusionnées en une seule note alignée sur le Doc 9859 de l’OACI) plutôt qu’affirmé sur une diapositive de revue de direction. Les indicateurs sont surveillés par une véritable maîtrise statistique des procédés, les règles de la Western Electric qui vous disent quand un chiffre a réellement changé, pas une flèche colorée qui a bougé parce que le mois dernier était calme.

L’IA aide sans prendre la plume : des agents spécialisés rattachés aux étapes du flux rédigent l’étape suivante, et chaque proposition passe par une validation humaine (accepter, modifier ou rejeter) et est journalisée, avec une consommation mesurée en crédits simples plafonnés, et eAviora n’entraîne aucun modèle sur vos données. L’isolation entre clients est imposée par la base de données, pas seulement par le code applicatif, et c’est la réponse que veut réellement entendre l’équipe informatique d’un organisme de maintenance. Quand vous serez prêt à comparer cela avec votre organisation actuelle, le guide de l’acheteur cadre l’évaluation, l’article sur les exigences SGS de la Part-145 traite du volet réglementaire, ou vous pouvez demander une démo sur votre propre agrément.