Plan de besoins

L’écran Plan de besoins répond à la question que se pose tout gestionnaire d’approvisionnement : « de quoi vais-je manquer, et quand ? ». C’est le premier livrable du module Approvisionnement (supply) — un écran en lecture seule : il ne crée aucune commande, aucune réservation, aucun engagement.

Sa valeur : le besoin se déduit du plan d’entretien. L’écran croise le plan de maintenance de chaque aéronef et équipement, la nomenclature de chaque opération (pièces et consommables requis) et le stock réel — y compris sa péremption. Un ERP achat générique ne peut pas faire ce calcul, car il ne connaît ni le plan d’entretien ni sa nomenclature.

Les trois compteurs d’honnêteté

En tête d’écran, trois tuiles cliquables ne sont pas décoratives — elles disent de combien le plan se trompe, et dans quel sens :

  • Besoins non datables — des besoins réels, de quantité connue, mais dont la date ne l’est pas (échéance pilotée par un compteur d’usage). Ils nécessitent le module Missions de vol pour être datés ; en attendant, ils sont comptés, jamais omis en silence.
  • Échéances à borne supérieure — une échéance mixte (calendaire ou compteur, la première atteinte) est datée « au plus tard » : le besoin réel peut survenir avant la date affichée. C’est le seul sens dangereux de l’incertitude — sous-estimer le délai fait manquer la commande.
  • Articles sans délai connu — en V1, tous les articles utilisent le délai d’approvisionnement par défaut de l’instance (pas encore de délai par article ou par fournisseur, prévu en phase 2). Ce compteur vaut donc toujours le nombre total d’articles du périmètre demandé — c’est la réponse honnête, pas un bug.

Cliquer une tuile filtre la table aux articles concernés.

La table

Une ligne par article, triée par défaut sur la date de déclenchement (rupture moins délai d’approvisionnement) — la date qui intéresse l’acheteur. Colonnes : article (RA:CE + désignation), stock net disponible aujourd’hui, besoin daté total sur l’horizon, besoin non datable (badge distinct si présent), date de rupture, date de déclenchement, et criticité.

Criticité (aucune si tous les besoins de l’article sont non datables — pas de faux calcul) :

Niveau Sens
À commander maintenant Date de déclenchement déjà atteinte ou dépassée
À commander bientôt Déclenchement dans les 30 jours
À surveiller Rupture prévue sur l’horizon, mais déclenchement au-delà de 30 jours
OK Aucune rupture prévue sur l’horizon

Filtres

  • Horizon — 3, 6, 12 (défaut) ou 24 mois de projection.
  • Portée d’affichage — trois niveaux, « À commander » par défaut :
    • À commander — les articles nécessitant une action : en rupture datée sur l’horizon (à commander ou à surveiller) ou porteurs d’un besoin non datable (affiché, badgé « non datable » — un besoin réel n’est jamais masqué). Répond directement à « quoi traiter ».
    • Avec besoin — tous les articles ayant un besoin, même déjà couverts (criticité « OK »). Le stock dormant reste masqué.
    • Tout (incl. stock dormant) — ajoute les articles qui ont du stock mais aucun besoin : de l’inventaire inerte, exclu par défaut car ce n’est pas un besoin.
  • Criticité — chips multi-sélection.
  • Périmètre — toute l’instance, un site (avec option « inclure les descendants ») ou un stockage précis. Un seul actif à la fois.
  • Inclure les interchangeables — agrège le disponible net avec les articles interchangeables du référentiel (cf. socle disponibilité).
  • Ventiler par site — au lieu d’une ligne par article agrégée sur tout le périmètre, une ligne par (article, site) : le stock net, la date de rupture et la criticité deviennent propres à chaque site. Un même article en rupture sur deux bases apparaît alors sur deux lignes — on voit d’un coup d’œil où commander, et combien. Les besoins dont le site n’est pas résolvable sont regroupés sous « Site non résolu » (jamais masqués). Disponible en vue large (pas sur un stockage précis) ; exclusif avec « Inclure les interchangeables » (V1). Auto-découpage : quand tu génères des demandes d’achat depuis une sélection ventilée, elles sont découpées automatiquement par (fournisseur, site) — une DA par fournisseur et par site, aucune destination à saisir. Les lignes « Site non résolu » ne sont pas sélectionnables (pas de destination).
  • Rechercher un article — l’API de cet écran n’expose pas de recherche texte libre ; la recherche se fait par sélection directe d’article(s) au catalogue (typeahead serveur). Une recherche explicite prime sur la portée : les articles choisis sont affichés quel que soit leur état.

La fiche article

Au clic sur une ligne, la fiche détail affiche :

  • La courbe de stock projeté, en escalier : le stock reste constant entre deux événements puis change instantanément à leur date (pas une interpolation continue, qui suggérerait à tort une consommation régulière). La ligne de rupture (zéro) et les dates de rupture/déclenchement y sont repérées. Le point de commande de la politique effective y est tracé en ligne horizontale (cf. Politiques de stock) : on lit d’un coup d’œil le franchissement (signal normal d’exploitation) et la rupture (crise).
  • La liste des événements datés, chacun avec sa source tracée (échéance de plan d’entretien, ligne matière d’un ordre de travail ou de réparation, péremption de lot, réception attendue), un lien direct vers l’exemplaire ou l’aéronef concerné, et le site où le besoin est localisé (site courant de l’aéronef, ou du magasin de l’exemplaire). Un même article peut ainsi être demandé sur plusieurs sites — la colonne le rend visible.
  • Le bloc « Besoins non datables », explicitement séparé de la courbe et des événements datés — jamais fusionné avec un faux calcul de date.

Couverture interchangeable et stock potentiel

Quand l’option « Inclure les interchangeables » est active, la fiche va plus loin que le stock propre de l’article :

  • Une carte « Stock potentiel · à valider » apparaît en tête (à côté du stock net) dès que des équivalents sont en stock : elle somme le stock de l’article et de ses équivalents (des deux référentiels). C’est un chiffre indicatif ; le stock net, lui, reste le chiffre ferme.
  • Une section « Couverture interchangeable technique », placée juste après les événements datés (elle répond au manque qui provoque la rupture), signale qu’un article interchangeable en stock pourrait couvrir le besoin. Elle ne réduit ni le stock net ni la date de rupture.

L’interchangeabilité technique est contextuelle : elle ne vaut que pour une tête produit (avion ou équipement) et un point d’emploi précis. La couverture est donc filtrée par l’aéronef du besoin — A ≈ B sur un RAFALE M peut être faux sur un RAFALE B, ou à un autre point d’emploi. Un besoin sans aéronef affiche l’équivalent en « contexte inconnu ». Dans tous les cas, une substitution technique porte des conditions de montabilité que le système n’évalue pas : elle reste à valider par un humain.

Créer des demandes d’achat depuis le plan

Le plan relie l’analyse du besoin à l’engagement. Deux gestes créent des

demandes d’achat (DA) :

  • Depuis une fiche article — le bouton « Créer une demande d’achat » ouvre l’éditeur pré-rempli (article, quantité manquante, fournisseur préféré).
  • Depuis la liste, en multi-sélection — cochez plusieurs articles en rupture, puis « Créer des demandes d’achat ». Le système résout le fournisseur préféré de chaque article (offre catalogue la mieux classée) et regroupe par fournisseur : une sélection couvrant trois fournisseurs produit trois DA (une par fournisseur — une demande est mono-fournisseur). Un récap montre le regroupement, l’agrément et le montant estimé avant création. Les articles sans fournisseur agréé sont réunis dans une DA « à compléter ».

La destination de livraison (site) se choisit dans la fenêtre de création — pré-remplie si tu as filtré le plan par site ou stockage, à saisir sinon. Le geste est donc disponible même sans filtre (vue « toute l’instance »). Les DA sont créées en brouillon : rien n’est engagé, tout reste modifiable avant soumission.

Hors périmètre (V1)

  • Les campagnes de navigabilité (bulletins, consignes, modifications) ne génèrent pas encore de besoin ici : leur date est connue mais aucun kit de pièces n’est modélisé.
  • Le délai d’approvisionnement est celui de l’instance, pas encore par article ni par fournisseur.

Voir aussi