Le verrou de clôture,
pas la case à cocher.

Voir l’encadré mis en évidence au-dessus du sommaire. La suite de cet article explique ce qu’est un verrou de clôture appliqué, la chaîne qu’il forme, et pourquoi il fait la différence entre un dossier qui a l’air clos et un dossier défendable lors d’un audit.

Dans la plupart des outils de sécurité traditionnels, la clôture est un champ de statut. Un utilisateur ouvre le dossier, décide que l’affaire est réglée et passe le statut à clos. Le statut est un texte libre ou une liste déroulante. Rien ne vérifie que le risque sous-jacent a réellement été traité. Un utilisateur peut saisir à la main un statut vert « clos » que personne n’a vérifié.

Cela paraît efficace, et c’est l’habitude la plus coûteuse de la tenue des dossiers de sécurité aérienne. Le problème n’est pas que les gens sont négligents. Le problème est que l’outil consigne le clic, pas le travail. Une case à cocher vous dit que quelqu’un l’a marquée comme faite. Elle ne vous dit pas que la barrière qui a cédé a été rétablie, ni que l’action corrective a été efficace, ni qu’une personne habilitée a examiné les éléments probants.

Le coût arrive plus tard. Trois ans après, un auditeur extrait le dossier et pose une question simple : montrez-moi pourquoi il était sûr de le clore. Un statut vert saisi à la main n’est pas une réponse. Aucun lien imposé ne relie l’événement à la barrière qui s’est dégradée, à l’action qui l’a corrigée, à la vérification qui a confirmé la correction. La trace n’a jamais été exigée, donc la trace n’existe pas. Une case à cocher n’est pas une clôture, et un statut vert saisi à la main n’est pas défendable.

• Le statut indique clos ; rien ne prouve que le risque a été fermé.
• Aucun lien exigé entre la barrière qui a cédé et une action corrective.
• Aucune vérification que l’action corrective a réellement fonctionné.
• Aucune trace de qui a décidé, ni des éléments probants consultés.

eAviora remplace la case de clôture par une chaîne de verrous. Un verrou est une condition que le flux de travail vérifie avant de laisser le dossier avancer. Le dossier ne peut pas atteindre l’état clos tant qu’un verrou de la chaîne n’est pas satisfait. La clôture cesse d’être quelque chose qu’un utilisateur affirme et devient quelque chose que le système n’autorise que lorsque les conditions sont remplies.

La chaîne se déroule dans l’ordre :

• Une barrière dégradée exige une action corrective. Lorsqu’une barrière du dossier est évaluée comme dégradée, le flux de travail ouvre une exigence : une action corrective liée (une CAPA) doit être rattachée à cette barrière. Le dossier ne peut pas progresser vers la clôture avec une barrière dégradée et aucune action à son encontre. Le lien est structurel, pas une note dans une zone de commentaire.
• L’action corrective ne peut pas être marquée comme terminée tant qu’elle n’a pas passé une vérification d’efficacité. Marquer une action corrective comme achevée est également soumis à un verrou. L’action reste ouverte jusqu’à ce qu’une vérification d’efficacité confirme que la correction a atteint le résultat visé. D’ici là, elle ne peut pas être marquée comme terminée, et le dossier auquel elle appartient ne peut pas se clore.
• Accepter plutôt le risque exige une dérogation consignée dans la piste d’audit. Si l’exploitant décide non pas de corriger le risque mais de l’accepter, cette voie ne contourne pas le verrou, elle passe par un autre. L’acceptation du risque résiduel exige une dérogation nominative avec une justification écrite, inscrite dans le dossier (voir la section 05).

Et la chaîne s’inscrit dans un flux de travail qui ne peut sauter aucune étape. Le dossier d’événement suit un flux de travail en dix étapes, et les étapes se déroulent dans l’ordre : le flux de travail ne saute pas d’étape pour atteindre la fin. Ainsi, avant même que les verrous liés aux barrières et aux actions s’appliquent, le dossier ne peut pas passer outre la réception, la classification, l’enquête de sécurité et l’examen pour atterrir sur clos. Les deux mécanismes se renforcent : un flux de travail ordonné qui tient la séquence, et des verrous de clôture qui tiennent le fond.

La vérification de l’efficacité est le verrou qui distingue une action corrective d’un élément de liste de tâches. Clore une action corrective sans elle, c’est le problème de la case à cocher en miniature : quelqu’un a fait quelque chose, l’a marqué comme fait, et personne n’a confirmé que ce quelque chose a fonctionné.

Ce qu’elle exige. L’action corrective ne peut pas être marquée comme terminée sur simple affirmation. Une vérification d’efficacité doit confirmer que l’action a atteint le résultat visé, c’est-à-dire que la barrière qu’elle devait rétablir est réellement rétablie, jugée à l’aune d’éléments probants opérationnels plutôt que du seul fait que le travail a été tenté.

Pourquoi c’est un verrou ferme, pas un rappel. Un rappel peut être ignoré ; un verrou, non. L’action corrective reste ouverte jusqu’à ce que la vérification d’efficacité soit réussie. Le dossier qui en dépend reste lui aussi ouvert. C’est le mécanisme qui arrête le mode de défaillance le plus courant : une action corrective close de bonne foi qui n’a pas corrigé le problème sous-jacent, laissant la barrière dégradée derrière un statut vert.

Ce qu’elle produit. Comme la vérification a lieu dans le dossier, elle laisse une trace : l’action, les éléments probants consultés par le vérificateur, le résultat et le moment où elle a eu lieu. Cette trace est ce qui rend la clôture finale lisible lors d’un audit. La vérification d’efficacité n’est pas de la paperasse ajoutée après coup ; c’est l’étape qui mérite le statut clos que le dossier portera ensuite.

Tous les risques ne sont pas corrigés. Parfois, la bonne décision opérationnelle est d’accepter un risque résiduel : la correction est disproportionnée, l’exposition est tolérable, ou un contrôle permanent est planifié et une acceptation provisoire fait la transition. Un système de sécurité doit le permettre. Ce qu’il ne doit pas permettre, c’est une acceptation d’un simple clic dans un champ de texte libre.

Dans eAviora, accepter un risque résiduel ne contourne pas le verrou de clôture : c’est un verrou à part entière. L’acceptation exige une dérogation nominative, consignée dans la piste d’audit : l’approbateur engage son nom sur la décision avec une justification écrite, et la dérogation est inscrite dans le dossier. Personne ne peut accepter discrètement un risque en passant : la décision est un acte délibéré et attribué, pas un statut posé au passage. Lorsque l’acceptation est prise au comité d’examen de la sécurité (SRB), une seconde personne la cosigne, et le comité ne peut pas enregistrer la dérogation sans elle.

Et la dérogation est conçue pour résister à un audit. Elle est enregistrée dans le dossier, horodatée et consignée dans la piste d’audit au moment où elle est prise, et elle peut être révoquée mais jamais supprimée. Lorsqu’un auditeur demande plus tard pourquoi un risque a été conservé plutôt que fermé, la réponse est dans le dossier : qui l’a accepté, pourquoi et quand. La différence entre cela et une note en texte libre « risque accepté » est la différence entre une décision défendable et une décision sans fondement.

• Un approbateur nommé et une justification écrite, pas un clic.
• La dérogation est inscrite dans le dossier, pas dans une note à part.
• Horodatée et consignée dans la piste d’audit au moment où elle a lieu ; révocable, jamais supprimée.
• Une acceptation au niveau du comité porte une seconde signature.
• Lisible des années plus tard comme une décision délibérée et attribuée.

Une application ne vaut que par la preuve qu’elle tient. La boucle de l’événement, de l’événement à la barrière qui s’est dégradée, à l’action corrective engagée contre elle, à la vérification d’efficacité, puis à la clôture, a été testée de bout en bout dans un environnement réel. La suite de scénarios a obtenu treize sur treize au vert. Soit les verrous tiennent et le scénario réussit, soit un verrou cède et le scénario échoue. La suite réussit.

Voilà ce que « défendable par construction » signifie en pratique. La défendabilité n’est pas un rapport que quelqu’un rédige après l’événement pour donner au dossier une apparence complète. Elle découle de la manière dont le dossier est construit. Une autorité de l’aviation civile peut suivre le chemin traçable, de l’événement à la barrière, à l’action corrective, à l’efficacité, et chaque étape est horodatée et consignée dans la piste d’audit au moment même où elle se produit. Il n’y a rien à reconstituer, car la trace a été enregistrée au fil du travail.

Mettez les deux images côte à côte. Dans un outil traditionnel, un auditeur extrait un dossier clos il y a trois ans et y trouve un statut vert que quelqu’un a saisi ; aucun lien imposé ne relie l’événement à la barrière, à l’action, à la vérification, si bien que le statut prouve seulement qu’une case a été cochée. Dans eAviora, le même dossier porte la chaîne : la barrière dégradée, l’action corrective qui l’a traitée, la vérification d’efficacité qui l’a confirmée, ou la dérogation consignée dans la piste d’audit qui a accepté en connaissance de cause le risque résiduel, chaque étape attribuée et horodatée. Une case à cocher n’est pas une clôture. Un statut vert saisi à la main n’est pas défendable. Une chaîne de verrous appliquée est les deux.

Les fonctionnalités concernées : module SGS, Actions (CAPA). Voyez comment la boucle plus large s’articule dans événement, CAPA, SPI et SRP, ou écrivez-nous pour parler de votre exploitation.