Réparer ou ré-optimiser ? Choisir l'intensité de la réaction quand un planning casse
Quand une perturbation touche un planning en cours, deux réflexes s'opposent : rapiécer ou tout reconstruire. Les deux ont raison dans certains cas. Tout l'enjeu est de savoir lequel la situation exige — et de le décider vite.


Tout planificateur connaît ce moment : une machine tombe en panne, une équipe est en retard, une livraison glisse, et le planning correct il y a une heure ne l'est plus. Il existe globalement deux réponses. Réparer le planning — décaler les opérations touchées et laisser le reste intact. Ou le ré-optimiser — rendre tout le problème au solveur avec la nouvelle contrainte et accepter ce qu'il produit.
Aucune n'est toujours la bonne. Les réparations sont rapides et prévisibles mais peuvent laisser beaucoup de valeur sur la table. La ré-optimisation complète trouve un meilleur plan mais prend plus de temps, peut remanier un travail que des équipes préparent déjà, et produit parfois un planning très différent de celui que suit l'atelier.
§ 01Ce que fait bien une réparation
Une réparation par décalage repousse les opérations touchées, et tout ce qui en dépend, plus tard dans le temps. Elle change le moins possible. Sur un grand planning, elle est quasi instantanée et garde le plan reconnaissable pour ceux qui l'exécutent : la séquence de la plupart des machines ne bouge pas.
Sa faiblesse : elle ne cherche jamais de meilleur arrangement. Si un long arrêt touche une machine goulot, attendre simplement qu'il passe peut propager des retards sur des dizaines d'opérations en aval, alors qu'une autre séquence aurait absorbé le choc.
§ 02Ce que fait bien la ré-optimisation
Relancer le solveur avec la nouvelle contrainte lui permet de reconsidérer séquences et affectations partout. Pour une longue perturbation, ou une perturbation sur une ressource critique, l'écart de retard ou de coût peut être important.
Les coûts sont le temps et la stabilité. Sur de grandes instances, une résolution complète prend des secondes, voire des minutes, plutôt que des millisecondes, et chaque nouvelle résolution risque de rendre le planning nerveux : des opérations qui bougent pour des gains marginaux, ce qui érode la confiance sur le terrain.
§ 03Trois questions pour trancher
En pratique, trois éléments comptent. D'abord, quelle est la durée de la perturbation par rapport à la marge déjà présente dans le planning ? Un retard qui tient dans la marge relève de la réparation ; un retard plusieurs fois plus long, en général non. Ensuite, touche-t-elle un goulot ? Les perturbations sur des ressources non critiques s'absorbent généralement localement ; celles sur des goulots, rarement. Enfin, êtes-vous sûr de la perturbation elle-même ? Si le signalement est vague — « ça devrait être réparé bientôt » — agir automatiquement dans un sens ou dans l'autre est prématuré, et une personne doit d'abord confirmer l'interprétation.
C'est la règle de décision qu'utilise GenOR-Twin. Il compare la durée de la perturbation à la marge moyenne du planning, vérifie si la ressource est un goulot, et exige une confiance de 0,85 dans sa lecture du signalement avant d'agir seul. En dessous, il demande à une personne de vérifier une seule interprétation au lieu de reconstruire quoi que ce soit.
§ 04Rendre le choix explicite
Le pire n'est pas de choisir la mauvaise réponse, mais d'en choisir une par habitude. Les équipes qui réparent toujours laissent de la valeur sur la table lors des grandes perturbations. Celles qui relancent toujours le solveur agitent leurs plans lors des petites. Écrire la règle — même sous forme d'un simple seuil sur la marge et le statut de goulot — transforme un réflexe en quelque chose que l'on peut examiner, ajuster et, à terme, automatiser.
Pas encore prêt pour un projet ? Posez votre question à un ingénieur, par e-mail, sans rendez-vous.
Poser une question

