Cas d'usage digitalisation industrie

Replanifier la production quand l’ERP ne le fait pas

BC Badr Chentouf 1 juin 2026

Retour d’experience

Comment on a monté un planificateur en no-code avec Vision, avec juste ce qu’il faut de JavaScript là où ça compte.

No-code industrie

Un client industriel nous a posé une question simple : son ERP lui sort un planning d’OF, mais dès qu’une machine tombe en panne ou qu’un composant manque, il est faux et son ERP ne permet pas de le recalculer ni de faire des simulations selon tel ou tel cas d’approvisionnement. On a construit l’outil. Voici comment, et ce qu’on en retient

Replanification en direct3 postes · horizon 6 jours · une panne

1 · Planning initial

OF planifié OF decalé / en retard Poste indisponible

Tour CN

Fraiseuse ⚠

Assemblage

J1J2J3J4J5J6

OF-101

OF-102 retard

OF-103

⚠ Panne : la Fraiseuse est indisponible en J3-J4. L’OF-102 est decalé après la remise en route.

La Fraiseuse tombe en panne ; l’OF-102 glisse en J5-J6 sur le même poste, signale en retard. Le responsable valide la proposition.

1.Le problème

L’ERP fait bien son travail : il transforme les commandes en ordres de fabrication via le calcul des besoins. Mais ce calcul est fait à capacité infinie, sur un horizon figé. Il suppose que les machines tournent toujours et que la matière est là. Le planning est juste le lundi matin ; dès le premier alea, c’est une fiction.Et des aléas, il y en a tous les jours : une rupture de composants, un retard fournisseur, une panne machine, une absence, une urgence client, un lot au rebut. A chaque fois, le responsable reouvre Excel, passe des coups de fil, déplace des étiquettes sur un planning mural – sans visibilité sur l’effet en cascade.

Le besoin reel : repartir du planning de l’ERP, vérifier en continu la matière et la capacité réelle, et reproposer un ordonnancement en quelques secondes quand un aléa tombe – avec l’impact chiffré sur les dates.

2.Les écrans et les workflows, en no-code

Avec Vision, on ne dessine pas des maquettes : on décrit le besoin, la plateforme génère l’application, et on l’ajuste en no-code. On commence toujours par le modèle de données – c’est lui qui structure tout le reste.

Entite	Champs principaux
`Ordre de fabrication`	article, quantite, date_due, priorite, statut, poste, debut / fin planifies
`Article` / `Nomenclature`	reference, type ; + composant (vers Article), quantite_par
`Stock`	article, quantite_dispo, quantite_reservee
`Poste de charge`	nom, capacite_jour (h), calendrier, statut
`Alea`	type, OF / poste / article concerne, impact, date

Cote ecrans, on a genere l’essentiel : le Gantt par poste (ci-dessus), la liste des OF filtrable, la fiche OF, le tableau de charge, le formulaire de déclaration d’alea et le dashboard des retards. Le cycle de vie d’un OF se décrit comme une suite d’états :

Planifie→ Lancable→ Lance→ En cours→ Termine

Le passage en “Lançable” n’est pas manuel : une règle vérifie que tous les composants sont en stock. Et déclarer un alea déclenche la replanification, que le responsable valide. Tout ça se décrit a Vision en quelques lignes :

Ce qu’on a decrit à Vision (Vibe-code)

DonnéesOF, Articles et Nomenclatures, Stock, Postes de charge, Aleas – avec leurs relations et champs métier

ObjectifReplanifier les OF selon la matière disponible et la capacité réelle, et réordonnancer sur chaque aléa déclaré

EcransGantt par poste · liste d’OF · fiche OF · tableau de charge · déclaration d’aléa · dashboard des retards

RèglesStatuts Planifié → Lançable (si composants OK) → Lancé → Terminé · aléa = replanification à valider

Prompt Vibe-code

## Modele de donnees
Ordre de fabrication : article, quantite, date_due,
  priorite (normale / urgente), statut (planifie / lancable / lance / termine / suspendu),
  poste, debut_planifie, fin_planifiee
Article : reference, designation, type (fabrique / achete), delai_jours
Nomenclature : article_parent, composant, quantite_par
Stock : article, quantite_dispo, quantite_reservee
Poste de charge : nom, capacite_jour_h, calendrier, statut (ouvert / maintenance)
Alea : type (rupture / retard / panne / absence / urgence / rebut),
  of_concerne, poste_concerne, impact, date

## Objectif
Replanifier les OF issus de l'ERP selon la matiere disponible et la capacite
reelle des postes, et reordonnancer quand un alea est declare.

## Ecrans
Gantt par poste . liste d'OF filtrable . fiche OF . tableau de charge .
declaration d'alea . dashboard des retards.

## Regles
- Statuts : Planifie -> Lancable -> Lance -> En cours -> Termine
- "Lancable" seulement si tous les composants sont en stock
- Un alea declenche une replanification a valider par le responsable

3.Le cerveau : un peu de JavaScript

Le no-code couvre les écrans, les données et les enchainements. Mais ordonnancer a capacite finie sous contrainte matière, c’est un vrai problème d’optimisation – ca ne se configure pas dans un menu. On l’a écrit en JavaScript, dans un bloc appelé par le workflow “Déclarer un alea”.Pas d’usine a gaz : une heuristique de liste en 4 étapes, simple a expliquer au responsable.

Trier les OF par priorité Urgences client d’abord, puis date due la plus proche, puis marge la plus faible.

Verifier la matiere disponible Pour chaque OF, comparer la nomenclature au stock disponible avant de planifier.

Placer sur le premier créneau libre En sautant jours non ouvrés et postes en maintenance. Poste le moins charge en priorité.

Marquer les retards et alerter Tout OF dont la fin dépasse la date due est signalé, avec l’écart chiffre sur les commandes concernées.

JavaScript

const trierOFs = (ofs, aujourdhui) => [...ofs].sort((a, b) => {
  if (a.priorite !== b.priorite)
    return a.priorite === "urgente" ? -1 : 1;  // urgences devant
  if (a.dateDue !== b.dateDue) return a.dateDue - b.dateDue;  // EDD
  const marge = o => (o.dateDue - aujourdhui) - o.dureeRequise;
  return marge(a) - marge(b);
});

Le coeur du sujet pour le responsable : quand un aléa tombe, on applique l’effet, on relance le moteur, et on lui présente l’écart chiffré entre l’ancien et le nouveau planning. La décision reste humaine.

JavaScript – réaction a l’alea

const replanifierSurAlea = (alea, etat) => {
  const avant = etat.planning;
  switch (alea.type) {                         // 1) appliquer l'alea
    case "panne":   etat.fermerPoste(alea.poste, alea.duree);   break;
    case "retard":  etat.decalerReception(alea.article, alea.jours); break;
    case "rebut":   etat.reinjecterOF(alea.of, alea.quantite);   break;
    case "urgence": etat.forcerPriorite(alea.of, "urgente");    break;
  }
  const apres  = ordonnancer(etat, alea.date);  // 2) relancer le moteur
  const impact = apres.ofs                       // 3) chiffrer l'ecart
    .map(o => ({ of: o.ref, ancienneFin: avant[o.ref]?.fin,
                nouvelleFin: o.fin, retard: o.fin > o.dateDue }))
    .filter(d => d.ancienneFin !== d.nouvelleFin);
  return { planning: apres, impact, aValider: true };
};

Le responsable voit alors une proposition claire – “3 OF décalés, 1 nouveau retard sur la commande X” – qu’il valide, ajuste ou rejette.

4.Ce qu’on en retient

Le bon partage : le no-code pour l’application (90 % du temps gagne), le JS pour le cerveau métier (la logique d’ordonnancement).
Une heuristique simple et explicable bat une optimisation parfaite que personne ne comprend : le responsable doit pouvoir suivre la décision.
L’ERP reste la source des besoins et des donnees maitres ; on ajoute par-dessus la couche de replanification reactive qui lui manque.
Du cadrage a une V1 utilisable : quelques jours, pas un projet de 18 mois – et les profils métier font évoluer l’app eux-memes ensuite.

Un cas d’ordonnancement, de planification ou de suivi atelier de votre coté ? On peut en discuter, et partager le code complet de l’algo sur demande – visionsoft.tech.