Propositions de configuration

Cette page répond à une question différente du catalogue et de la fiche aéronef : compte tenu de ce que je veux emporter, quelle configuration autorisée est la plus rapide à mettre en œuvre à partir de maintenant ? Elle s’adresse au préparateur / bureau technique — pas à la piste, qui n’a pas besoin d’arbitrer entre plusieurs configurations possibles.

Exprimer un besoin : un aéronef, et zéro à N références voulues

Le besoin ne décrit pas une mission — il n’y a pas encore d’objet « mission » dans Envergure. Il se limite à deux choses :

• un aéronef, obligatoire — la proposition compare toujours à l’état RÉEL de CET appareil ;
• des références voulues, optionnelles — « je veux voir accrochés ce bidon et ce pod ».

Sans référence cochée, l’écran montre tout le champ des configurations autorisées applicables à cet aéronef (famille, variante, version, plage de numéros de série, indice de modification). Cocher des références filtre ce champ : une configuration n’est retenue que si toutes les références demandées y figurent — cocher deux références revient à dire « je veux emporter ceci ET cela », pas « ceci OU cela ». Une référence peut aussi être couverte par un équivalent interchangeable déclaré (voir la page Configurations opérationnelles pour la règle d’interchangeabilité) : demander une référence ancienne trouve aussi les configurations qui exigent la référence qui l’a remplacée.

Le mouvement : le seul chiffre qui compte

Mouvement

Un accrochage OU un décrochage — un seul geste physique sur une station. Remplacer un emport sur une même station coûte donc deux mouvements : un décrochage, puis un accrochage.

C’est ce compte, et lui seul, qui classe les propositions. Pas la proximité du code, pas l’ordre du catalogue : le nombre de gestes à faire pour passer de l’état actuel de l’aéronef à la configuration proposée. Entre deux configurations également autorisées, celle qui demande deux gestes bat toujours celle qui en demande six — même si la seconde semble « plus proche » en apparence.

Un emport déjà accroché qui satisfait une exigence par interchangeabilité ne coûte aucun mouvement. C’est la règle la plus facile à rater en la lisant vite : si l’aéronef porte déjà la référence B, et qu’un document d’interchangeabilité approuvé dit que B remplace la référence A exigée par la configuration, alors cette exigence est déjà satisfaite — l’afficher comme un mouvement à faire proposerait de décrocher un emport en bon état pour raccrocher son propre équivalent approuvé, ce qui n’a pas de sens.

Réalisable ne veut pas dire autorisé — ça veut dire qu’il y a du stock

Une configuration peut être parfaitement autorisée et pourtant non réalisable aujourd’hui, si le stock ne suit pas. Pour chaque exigence que l’aéronef ne satisfait pas déjà, il faut un exemplaire disponible :

• sérialisé (les articles en lot ou en quantité ne s’accrochent pas, cf. R2) ;
• en état neuf ou apte au service ;
• réception technique validée ;
• ni accroché ni installé ailleurs ;
• admis sur la station visée (les compatibilités déclarées sur la station).

Réception technique

Le contrôle par lequel le technicien navigabilité valide l’identification et les compteurs d’un exemplaire avant sa première utilisation. Tant qu’il est en attente, l’exemplaire existe en stock mais ne peut être ni posé ni accroché.

C’est le piège le plus facile à ignorer par erreur : POST/stock-items/:stockItemId/carry — l’accrochage d’un emport exige déjà cette validation. Une proposition qui l’ignorerait suggérerait des accrochages que le système refuserait ensuite au moment de les exécuter — une proposition trompeuse est pire qu’une absence de proposition.

Un même exemplaire ne peut évidemment couvrir qu’une seule exigence : s’il n’existe qu’un exemplaire disponible d’une référence et que deux stations différentes en réclament chacune un, une seule des deux peut être satisfaite par le stock actuel.

Pourquoi une configuration non réalisable reste affichée

Une configuration non réalisable n’est jamais masquée. Elle sort après les configurations réalisables, avec la liste précise de ce qui manque (station et référence). La cacher priverait le préparateur d’une information utile : « c’est la meilleure configuration pour ce besoin, il ne manque qu’un pod — vaut-il la peine de le faire venir, ou vaut-il mieux se rabattre sur la suivante ? » C’est une décision humaine, que l’écran doit informer, pas trancher à sa place.

Alertes

Consulter cette page à la demande ne suffit pas : personne ne pense à l’ouvrir tant que rien ne le lui signale. Le système remonte donc de lui-même trois situations, sans qu’on ouvre le moindre écran — dans le bandeau « Actions prioritaires » du tableau de bord, à côté des alertes de conformité navigabilité qui y vivaient déjà :

• aéronef non conforme — ce qu’il porte ne correspond à aucune configuration autorisée qui s’applique à lui ;
• emport accroché à potentiel échu — dès que les compteurs d’un emport tournent (l’accrochage les fait tourner, cf. plus haut), l’échéancier existant sait déjà voir un potentiel dépassé. L’alerte se contente de le restituer, et seulement pour un exemplaire actuellement accroché : un potentiel dépassé en magasin, jamais monté ou décroché depuis, reste une affaire d’échéances d’entretien classiques — pas celle-ci ;
• conformité obtenue sous condition — la même règle d’interchangeabilité décrite plus haut : quand la seule voie vers la conformité passe par une substitution qui porte un texte de condition, l’alerte affiche ce texte tel quel. Il n’est jamais évalué par l’application — c’est à un humain de juger, avant le vol.

Pourquoi CES trois-là, et pas « tout ce qui cloche » : un aéronef sans aucune configuration applicable n’alerte pas — il n’y a rien à quoi le comparer, et faire clignoter toute une flotte pas encore cataloguée rendrait le bandeau inutilisable plutôt qu’utile. Une conformité simple, sans condition invoquée, n’a rien à signaler non plus : c’est l’état normal, pas une exception qui mériterait un bandeau.

Pourquoi une révision supplantée, encore portée, n’alerte pas

Supplantation (R5)

Une révision remplace la précédente. Ce qui a volé sous l’ancienne révision reste vrai : les contrôles passés ne sont pas réécrits.

Seules les configurations actives entrent dans le calcul d’alerte — une révision supplantée n’est jamais chargée, donc jamais comparée à quoi que ce soit. Elle ne peut donc, structurellement, jamais être la cause d’une alerte : ni positive (elle ne rend jamais un aéronef faussement « conforme »), ni négative (elle ne fait jamais basculer un aéronef en « non conforme »). Publier une nouvelle révision d’une configuration ne déclenche donc pas une vague d’alertes sur toute la flotte qui vole encore, légitimement, sous l’ancienne — c’est le même principe que le contrôle de conformité de la fiche aéronef, simplement étendu au tableau de bord : GET/operational-configurations/alerts recalcule à chaque consultation, sur le catalogue en vigueur, jamais sur son historique.

Voir aussi

• Configurations opérationnelles — le catalogue des configurations autorisées que cette page compare entre elles.
• Décomposition — la fiche aéronef, où se lit l’état RÉEL qui sert de point de départ au calcul de mouvements, et où s’accrochent et se décrochent les emports.
• Tableau de bord — où vivent les alertes décrites ci-dessus.