PowerSolver — argumentaires des démos

Un argumentaire par démo de powersolver-demos/, pour présenter les démos, préparer une présentation ou échanger avec un client. Chaque chiffre provient des fichiers de la démo elle-même (documentation/demos/<démo>/SCENARIO.md, EXPECTED_RESULTS.md, solutions de référence revérifiées par le vérificateur indépendant). Les temps de résolution ont été mesurés sur un ordinateur portable de développement, avec les réglages de chaque fichier problème. Ils sont indicatifs et varient selon la machine. Toutes les données des démos sont fictives mais réalistes.

Comment le planning est construit, en termes simples

Le moteur de planification de PowerSolver est Timefold Solver, un moteur d'optimisation open source éprouvé. Il n'essaie pas tous les plannings possibles : pour 1 000 interventions, 120 techniciens et 10 demi-journées, il existe bien plus de combinaisons qu'aucun ordinateur ne pourrait en énumérer. Il travaille plutôt comme un planificateur très rapide et très patient, en deux phases.

1. Construire un premier planning (construction). Le moteur prend les éléments un par un, par exemple des cours, des interventions ou des postes, dans l'ordre où ils sont listés. Il place chacun au meilleur endroit encore libre à ce moment-là. C'est le First Fit : rapide et raisonnable, mais pas parfait, car les premiers choix peuvent en bloquer de meilleurs plus tard. Lister d'abord les éléments les plus difficiles aide, par exemple les pannes urgentes ou les groupes de langue qui doivent avoir cours en parallèle. Les démos le font.

2. L'améliorer, coup après coup (recherche locale). Le moteur fait ensuite des millions de petites modifications et garde ou rejette chacune :

• confier cette intervention à un autre technicien ;
• déplacer ce cours à une autre heure ;
• échanger deux postes ;
• déplacer d'un coup tout un groupe de cours.

Il n'accepte pas seulement les modifications qui améliorent immédiatement le planning. Sinon, il resterait bloqué sur un planning « bon localement » mais loin du meilleur. Les démos utilisent deux stratégies reconnues, l'une après l'autre :

• Late Acceptance (acceptation différée) : une modification est acceptée si le planning n'est pas pire qu'il y a peu de temps. La recherche peut reculer brièvement pour trouver un meilleur chemin. Elle sert jusqu'à ce que toutes les règles impératives soient respectées.
• Tabu Search (recherche tabou) : les éléments modifiés récemment ne peuvent pas être modifiés à nouveau pendant un court moment, pour que la recherche continue d'explorer de nouvelles options au lieu de tourner en rond. Elle sert à améliorer les souhaits.

Le recuit simulé (Simulated Annealing), Great Deluge, Hill Climbing et la descente à voisinage variable sont aussi disponibles et peuvent être choisis selon le problème.

Comment le moteur juge un planning (le score). Chaque planning reçoit un score en deux parties :

• hard : le nombre de règles impératives non respectées, multiplié par leur poids. 0hard signifie que le planning est utilisable.
• soft : le coût des souhaits non satisfaits (préférences, garder le planning de la semaine passée, moins de sous-traitance…). Plus il est proche de zéro, mieux c'est.

Le moteur préfère toujours moins de règles impératives non respectées, puis moins de souhaits non satisfaits. Le score est mis à jour de façon incrémentale après chaque petite modification, ce qui lui permet d'évaluer des dizaines de milliers de modifications par seconde.

Quand il s'arrête. À la limite de temps choisie, par exemple 60 ou 120 secondes, ou plus tôt s'il ne s'améliore plus. Il renvoie le meilleur planning trouvé. Avec les mêmes données et les mêmes réglages, la recherche suit les mêmes étapes. Comme elle s'arrête au bout d'un temps donné, une machine plus rapide peut aller un peu plus loin. Chaque démo indique le temps au bout duquel un planning valide a été trouvé.

La replanification. Les décisions publiées peuvent être épinglées : le moteur ne les déplace jamais. Les éléments qui peuvent bouger se souviennent de leur place, et les déplacer coûte quelque chose dans le score soft. Le moteur ne change donc que ce qu'il doit changer, ce qui explique qu'une crise soit absorbée en quelques secondes avec seulement quelques dizaines de changements.

Une preuve indépendante. Après la résolution, un vérificateur distinct, écrit indépendamment du moteur, recalcule chaque règle sur le planning final. Dans chaque démo, les deux concordent, règle par règle.

Où l'IA aide, et où elle n'intervient pas

Le planning lui-même n'est jamais produit par l'IA. Il est calculé par le moteur d'optimisation à partir de vos données et de vos règles, selon les étapes ci-dessus. Chaque règle est vérifiée, le résultat est vérifiable de façon indépendante, et il est le même pour les mêmes données et les mêmes réglages. L'IA (via PowerAI) aide les personnes autour du planning :

• Décrire le problème. Dans le parcours assisté par l'IA, vous décrivez votre situation avec vos propres mots et l'IA prépare les éléments, les options et les règles dans l'assistant. Vous relisez et modifiez tout avant de planifier.
• Conseiller avant un changement. Quand vous supprimez ou modifiez quelque chose dans l'assistant, l'IA explique quelles règles et quelles données en dépendent, pour ne pas casser le modèle par mégarde.
• Relire un planning. Sur la page Résultats, le critique IA commente le planning et peut proposer une modification du problème, par exemple le poids d'une règle. Rien ne se passe tant que vous ne l'acceptez pas. Le moteur replanifie alors, et la page indique si le nouveau planning est meilleur, identique ou moins bon.
• Résumer les différences. Sur la page Comparer, « Décrire avec l'IA » transforme les différences déjà calculées (ce qui a bougé, quelles règles ont changé) en un court résumé en langage clair pour un responsable ou un comité de pilotage.

En bref, le moteur décide et prouve ; l'IA explique, conseille et résume, et une personne garde toujours la main.

Pourquoi PowerSolver

Les problèmes de planification sont partout : emplois du temps, plannings du personnel, semaines de maintenance, plans de projet, programmes d'événements. Dans la plupart des organisations, une ou deux personnes expérimentées les résolvent avec des tableurs. Cela prend des jours. Le résultat est fragile. Quand quelque chose change un lundi matin, le planning est refait à la main, dans l'urgence.

Des moteurs d'optimisation comme Timefold Solver résolvent très bien ces problèmes, mais les utiliser directement est un projet logiciel. Des développeurs écrivent le modèle métier en code (entités de planification, variables, domaines de valeurs) et traduisent chaque règle métier en code. Ils doivent ensuite le compiler, le déployer et le maintenir, et construire autour les écrans dont les planificateurs ont besoin.

PowerSolver est une couche de planification construite sur Timefold Solver 2.0. Il conserve le moteur d'optimisation de Timefold et ajoute ce qu'il faut pour l'utiliser comme un produit :

Quand utiliser Timefold directement reste le bon choix. Une équipe qui a besoin d'une règle hors du catalogue, ou qui veut régler le moteur par le code, travaille au niveau de Timefold, ou ajoute une règle intégrée à PowerSolver. C'est le cas aujourd'hui des tournées de livraison avec capacité des véhicules, créneaux de livraison et distances (voir la démo 06).

Démo 01 — Emploi du temps scolaire : Fessenden Upper School

60 cours, 3 niveaux, 6 enseignants, 5 salles, rotation sur 6 jours. Le modèle s'enrichit pas à pas (salle et horaire, puis enseignant, puis type de séance), puis un imprévu en cours d'année : « Dr Chen absent le jour 3 ».

A. Pourquoi PowerSolver plutôt que Timefold directement. La démo montre le même problème qui passe de 2 à 4 décisions. Chaque étape est une modification de la description JSON et de la liste des règles, pas une nouvelle version du code. L'imprévu est traité par des fonctions génériques (la règle resource_unavailable et les épingles), sans code spécifique. Pour un établissement, cela veut dire que l'emploi du temps peut être maintenu par ceux qui connaissent l'établissement, sans équipe de développement.

B. Pourquoi planifier avec PowerSolver. Les règles qu'un responsable d'emploi du temps jongle de tête sont toutes explicites et appliquées ensemble :

• aucune classe, aucun enseignant, aucune salle réservé deux fois ;
• laboratoires et gymnase pour les matières qui en ont besoin, et uniquement des enseignants qualifiés ;
• pas deux fois la même matière dans la journée, et une pause déjeuner protégée ;
• occupation des salles et charge d'enseignement équilibrées.

Quand un enseignant est absent, tout le reste est épinglé et seuls les cours concernés bougent.

C. Les difficultés qu'il supprime.

• Emploi du temps construit à la main pendant des jours → généré à partir des règles → du temps rendu à la pédagogie.
• Une absence casse la semaine publiée → replanification au moindre changement (planning de base épinglé) → les familles et le personnel gardent leur semaine.
• Règles appliquées de façon inégale → chaque règle vérifiée sur chaque cours → un emploi du temps qui résiste à l'examen.

Périmètre : cette démo fournit des fichiers problème et un script de présentation ; c'est l'introduction guidée à l'assistant, pas un test à grande échelle (voir la démo 12 pour l'échelle).

Démo 02 — Emploi du temps : Northbridge University, School of Computing

Promotions (années 1 à 3), modules, responsables de module qui enseignent plusieurs modules, du lundi au vendredi × 8 créneaux, environ 33 séances. Fournie sous forme de réponses en langage courant pour le parcours assisté par l'IA.

A. Pourquoi PowerSolver plutôt que Timefold directement. Le même modèle school-timetabling couvre un département universitaire. Promotions et modules remplacent niveaux et matières, et rien n'est recodé. Les réponses sont rédigées en langage courant, prêtes pour le parcours assisté par l'IA.

B. Pourquoi planifier avec PowerSolver. Un département a des responsables de module partagés entre promotions, peu de salles informatiques et un créneau de déjeuner fixe. PowerSolver vérifie tout cela ensemble et donne à chaque responsable une semaine sans conflit.

C. Les difficultés qu'il supprime.

• Chaque département réinvente son tableur → un modèle réutilisé d'un établissement à l'autre → déploiement plus rapide au département suivant.
• Responsables réservés deux fois entre promotions → absence de conflit d'enseignant garantie → moins d'échanges de dernière minute.

Périmètre : réponses seules (pas de fichier solution de référence) ; la démo montre l'étendue des usages plutôt que des résultats mesurés.

Démo 03 — Emploi du temps : St. Aldric's College (lycée privé)

Années 10 à 12, environ 75 cours, trois laboratoires de sciences distincts, un laboratoire de langues et une salle de sport, deux enseignants par matière principale. Fournie sous forme de réponses en langage courant.

A. Pourquoi PowerSolver plutôt que Timefold directement. Plusieurs salles spécialisées aux équipements différents ne sont que des données (« cette salle offre lab-chimie »). La règle d'adéquation des salles du catalogue fait le reste. Aucune logique propre aux salles n'est écrite.

B. Pourquoi planifier avec PowerSolver. Les établissements à dominante scientifique sont limités par leurs laboratoires. PowerSolver place chaque cours pratique dans un laboratoire adapté, et répartit sur la semaine les enseignants partagés de chaque matière principale.

C. Les difficultés qu'il supprime.

• Laboratoires surréservés ou utilisés pour des cours théoriques → adéquation des salles garantie → les cours pratiques toujours au bon endroit.
• Deux enseignants par matière coordonnés à la main → affectation optimisée → des semaines cohérentes pour chaque classe.

Périmètre : réponses seules (pas de fichier solution de référence).

Démo 04 — Affectation de tâches : backlog de développement

Un petit modèle de référence : 10 tâches, 4 développeurs, 6 créneaux ; chaque tâche reçoit un développeur, un créneau, une classe de priorité et un lieu (7 règles : tout est affecté, compétences, pas de double réservation, charge équilibrée).

A. Pourquoi PowerSolver plutôt que Timefold directement. Le même backlog peut être modélisé avec 1 à 4 décisions (qui, quand, file de priorité, lieu). Ajouter une décision, c'est ajouter une ligne, pas une nouvelle classe. C'est une façon rapide de montrer à un public technique le peu qu'il faut pour passer d'un problème à un optimiseur qui fonctionne.

B. Pourquoi planifier avec PowerSolver. Chaque tâche va à un développeur qui a la compétence requise, personne n'est réservé deux fois sur un créneau, et la charge est répartie au lieu de retomber sur les deux mêmes personnes.

C. Les difficultés qu'il supprime.

• Affectation par habitude qui surcharge quelques développeurs → équilibrage de la charge et adéquation des compétences → des livraisons plus régulières.

Périmètre : un petit exemple de référence (certifié faisable de façon indépendante) ; les démos 11 et 16 montrent le même type de planification à l'échelle d'un projet.

Démo 05 — Planning du personnel : plan des postes (modèle de référence)

Un petit modèle de référence : 10 postes, 4 employés ; chaque poste reçoit un employé, un créneau, un rôle et un lieu (7 règles : tout est affecté, compétences, pas de double réservation, charge équilibrée).

A. Pourquoi PowerSolver plutôt que Timefold directement. C'est un point de départ compact pour tout projet de planning du personnel. Personnel, postes, rôles et disponibilités sont des données, et les mêmes règles passent à l'échelle d'un hôpital (démo 15).

B. Pourquoi planifier avec PowerSolver. Chaque poste est tenu par une personne qualifiée, personne n'est réservé deux fois sur un créneau, et les postes sont répartis équitablement.

C. Les difficultés qu'il supprime. Plannings faits à la main et vérifiés à l'œil → chaque règle vérifiée → moins de postes non couverts ou non conformes.

Périmètre : petit exemple de référence ; voir la démo 15 pour un planning hospitalier complet et sa replanification.

Démo 06 — Tournées de véhicules : tournées de livraison (périmètre actuel)

3 véhicules, 9 visites. La décision est la tournée ordonnée de chaque véhicule ; les heures d'arrivée sont déduites le long de la tournée.

A. Pourquoi PowerSolver plutôt que Timefold directement. L'ordre des visites (variables de liste) et les heures d'arrivée déduites sont décrits en JSON avec des expressions, sans code.

B. Pourquoi planifier avec PowerSolver. Aujourd'hui, il place chaque visite dans une tournée et ordonne les tournées.

C. Périmètre honnête. Les règles de tournée de PowerSolver couvrent aujourd'hui « chaque visite est placée » et « garder un nombre bas ». Elles ne couvrent pas encore la capacité des véhicules, les créneaux de livraison des clients ni les distances de trajet, qui sont le cœur d'une vraie planification de livraisons. Présentez cette démo comme un aperçu. Un client dont le besoin principal est la tournée de livraison doit en être informé clairement. Les règles de tournée sont un chantier prévu, pas une capacité actuelle.

Démo 07 — Planification de la maintenance : usine (modèle de référence)

Un petit modèle de référence : 10 interventions de maintenance, 4 techniciens, 6 créneaux, des caisses à outils et des classes de priorité (6 règles : tout est affecté, pas de double réservation, charge équilibrée).

A. Pourquoi PowerSolver plutôt que Timefold directement. Elle montre quatre décisions par intervention (technicien, créneau, caisse à outils, niveau de priorité) configurées sans code. C'est une façon compacte d'expliquer le modèle à un public technique avant la grande démo de maintenance (13).

B. Pourquoi planifier avec PowerSolver. Aucun technicien réservé deux fois, et une charge répartie sur l'équipe.

C. Les difficultés qu'il supprime. Affectations faites au téléphone sans vue d'ensemble → un seul planning avec toutes les interventions et tous les techniciens → moins de conflits.

Périmètre : petit exemple de référence ; la démo 13 montre 1 000 interventions et une replanification du lundi matin.

Démo 08 — Capacité cloud : placement de services

Un petit modèle de référence : 10 charges de travail, 4 serveurs, 6 fenêtres horaires ; chaque charge reçoit un serveur, une fenêtre horaire, une zone de baie et un niveau de priorité (6 règles : tout est affecté, pas de double réservation, charge équilibrée).

A. Pourquoi PowerSolver plutôt que Timefold directement. Elle montre que le modèle ne se limite pas aux personnes et au temps. Une équipe plateforme décrit serveurs, fenêtres et zones comme des données et obtient un optimiseur de placement sans écrire de solveur ; des limites de capacité (règle capacity) peuvent être ajoutées comme règle supplémentaire.

B. Pourquoi planifier avec PowerSolver. Aucun serveur n'héberge deux charges dans la même fenêtre horaire, et la charge est équilibrée entre les serveurs.

C. Les difficultés qu'il supprime. Placement à l'intuition → placement explicite, vérifié et équilibré → moins de serveurs surchargés.

Périmètre : petit exemple de référence (certifié faisable de façon indépendante) ; la démo 17 montre le placement cloud à l'échelle, avec une replanification après incident.

Démo 09 — Atelier de production : ordres de fabrication

Un petit modèle de référence : 10 opérations, 4 machines, 6 créneaux ; chaque opération reçoit une machine, un créneau, un opérateur et une caisse à outils (7 règles : tout est affecté, capacité de la machine, pas de double réservation, charge équilibrée).

A. Pourquoi PowerSolver plutôt que Timefold directement. Machines, opérateurs et caisses à outils sont des données. La capacité des machines et l'absence de double réservation viennent du catalogue plutôt que d'un code sur mesure.

B. Pourquoi planifier avec PowerSolver. Chaque opération passe sur une machine capable de la réaliser, aucune machine n'est réservée deux fois sur un créneau, et la charge est équilibrée entre les machines.

C. Les difficultés qu'il supprime. Plannings d'atelier refaits à la main après chaque commande urgente → nouvelle résolution dans le même modèle → moins de gestion de crise.

Périmètre : petit exemple de référence (certifié faisable de façon indépendante) ; la démo 18 montre une semaine d'usinage complète, avec une replanification après panne.

Démo 10 — Affectation d'ordres de travail : techniciens terrain

Un petit modèle de référence : 10 ordres de travail, 4 chefs d'équipe, 6 créneaux ; chaque ordre reçoit un chef, un créneau, une équipe et une classe de priorité (7 règles : tout est affecté, compétences, pas de double réservation, charge équilibrée).

A. Pourquoi PowerSolver plutôt que Timefold directement. C'est le même schéma que la maintenance (qui, quand, quelle équipe, quelle priorité), configuré plutôt que codé.

B. Pourquoi planifier avec PowerSolver. Chaque ordre va à un chef qualifié, personne n'est réservé deux fois sur un créneau, et le travail est réparti entre les chefs.

C. Les difficultés qu'il supprime. Répartition décidée par celui qui décroche le téléphone → des règles cohérentes → une répartition plus équitable et plus prévisible.

Périmètre : petit exemple de référence ; la démo 13 couvre l'intervention terrain à grande échelle.

Démo 11 — Portail projet : projet logiciel de 4 mois

260 tâches, 6 développeurs, 84 créneaux journaliers à partir du 7 septembre, 3 files de priorité, 3 lieux ; 17 règles (compétences, congés, jours fériés, phases du projet, prérequis, une file urgente plafonnée, équipements, lieux fermés, répartition du travail).

A. Pourquoi PowerSolver plutôt que Timefold directement. Le projet a été décrit à partir du JSON d'un client. Congés, jours fériés, phases, prérequis et file urgente plafonnée sont tous des règles du catalogue avec des paramètres. Construire le même optimiseur directement sur Timefold demanderait de coder chacune de ces 17 règles.

B. Pourquoi planifier avec PowerSolver. Un planning sur quatre mois qui respecte congés et jours fériés, garde les tâches dans leur phase, fait passer les prérequis en premier et maintient la file urgente sous son plafond de 80 tâches. Il est affiché jour par jour dans la vue calendrier.

C. Les difficultés qu'il supprime.

• Diagrammes de Gantt mis à jour à la main → planning déduit des règles → un planning qui reste cohérent quand les tâches changent.
• File urgente détournée → plafonnée par une règle → les vraies priorités restent visibles.

Périmètre : fichier problème seul (pas de solution de référence dans le dossier) ; lancez-le en direct pour montrer le résultat.

Démo 12 — Collège Jean-Moulin : emploi du temps hebdomadaire de chaque trimestre, avec les changements en cours d'année

Un collège public français : 520 cours hebdomadaires, 20 classes, 35 enseignants, 33 salles, 32 créneaux. Des groupes de langue (LV2) issus de plusieurs classes ont cours en parallèle. Trimestre 2 : un congé maternité et un laboratoire fermé. Trimestre 3 : l'enseignante revient, des heures de révision sont ajoutées et un enseignant part en formation.

A. Pourquoi PowerSolver plutôt que Timefold directement. Des particularités comme les groupes de LV2 en parallèle, les « élèves » d'un cours formés de plusieurs demi-classes, et les enseignants fixés par la répartition des services du principal sont traitées par des règles génériques avec paramètres. Aucun code propre au collège n'est écrit. La période du trimestre (vacances, jours fériés) est portée par les créneaux eux-mêmes, si bien que le calendrier et l'export Excel montrent chaque jour de classe du trimestre.

B. Pourquoi planifier avec PowerSolver. Mesuré sur l'exécution de référence :

• Trimestre 1 : un emploi du temps complet valide après environ 85 s (0hard/-9soft), avec chacune des 9 règles impératives à 0.
• Trimestre 2 : valide après environ 4 s, avec 178 cours épinglés. Seuls 14 cours changent d'horaire et 37 de salle, surtout à cause du laboratoire fermé.
• Trimestre 3 : valide après environ 1,5 s, avec 400 cours épinglés et 8 cours qui changent d'horaire.

L'onglet Changements liste chaque déplacement.

C. Les difficultés qu'il supprime.

• Des semaines de travail estival sur l'emploi du temps → quelques minutes de résolution → le responsable vérifie au lieu de construire.
• Un changement en cours d'année impose de tout refaire → épingles plus souhaits « garder l'horaire et la salle du trimestre précédent » → familles et enseignants gardent leur semaine (459 cours sur 520 inchangés au trimestre 2).
• « Est-ce vraiment sans conflit ? » → le vérificateur indépendant concorde avec le moteur sur chaque règle → un emploi du temps que le principal peut défendre.

Démo 13 — Maintenance sur site : 1 000 interventions, puis une crise du lundi matin

Une entreprise de maintenance multitechnique autour de Lyon. Vendredi : planifier les 1 000 interventions de la semaine suivante pour 120 techniciens (compétences, zones, absences, créneaux d'accès des clients, délais de réparation, visite technique avant installation). Lundi 7 h 30 : 6 techniciens malades pour la semaine, 2 absents le lundi, 4 intérimaires appelés, 15 pannes signalées pendant le week-end.

A. Pourquoi PowerSolver plutôt que Timefold directement. Les huit règles impératives sont toutes des règles du catalogue : compétences, zones, absences, créneaux, dépendances et une intervention par demi-journée. La replanification du lundi est générée à partir du planning du vendredi par un court script qui ajoute des données et des épingles ; la configuration du solveur ne change pas. La démo a aussi révélé, puis permis de corriger, un problème de performance dans la règle de dépendance. Cette règle place désormais 1 000 interventions en quelques secondes, alors qu'elle n'atteignait pas un planning valide en 300 s. Un client bénéficie de ce type de consolidation sans avoir à posséder le code du moteur.

B. Pourquoi planifier avec PowerSolver. Mesuré sur l'exécution de référence :

• Vendredi : un planning valide pour 1 000 interventions après environ 23 s, avec chaque panne réparée avant mardi soir.
• Lundi : une replanification valide après environ 16 s. 712 interventions sont garanties inchangées (épinglées) et 146 changent, dont 64 qui le devaient (technicien absent). Les 4 intérimaires prennent 32 interventions.

C. Les difficultés qu'il supprime.

• Le vendredi après-midi perdu à faire le planning de la semaine → généré en moins d'une minute → le planificateur traite les exceptions au lieu de remplir des grilles.
• Les appels de malades du lundi créent le chaos → replanification avant le départ des camionnettes, en gardant la feuille de route de tous les autres → moins d'appels et de rendez-vous manqués.
• Sous-traitants appelés par défaut → souhait « d'abord nos propres équipes » (13 interventions sous-traitées le vendredi) → coûts maîtrisés.
• Pannes noyées dans le préventif → délais en règles impératives, « avant mardi » en souhait → engagements de niveau de service tenus.

Démo 14 — Conférence tech : le programme, puis la veille de l'événement

Une conférence de 3 jours à Lyon : 153 sessions (3 keynotes, 130 talks, 10 ateliers en deux parties), 10 parcours, 12 salles, 120 intervenants. La veille de l'événement (18 h) : les vols de deux intervenants annulés, un intervenant malade, un projecteur en panne, les PC d'un atelier livrés avec un jour de retard, trois sessions ajoutées.

A. Pourquoi PowerSolver plutôt que Timefold directement. Une keynote plénière est modélisée comme « une session qui appartient à tous les parcours », avec la même règle de non-chevauchement que les parcours. Taille et équipement des salles forment une seule règle de capacité. Aucun code propre à la conférence n'est écrit.

B. Pourquoi planifier avec PowerSolver. Mesuré sur l'exécution de référence :

• Programme : valide après environ 3 s.
• Replanification de la veille : valide après environ 0,3 s. 139 des 153 sessions imprimées sont inchangées ; 13 sont touchées (6 changent d'horaire, 9 de salle), 3 sont ajoutées et 1 est annulée.

L'onglet Changements donne la liste exacte pour l'application, les écrans et la signalétique des salles.

C. Les difficultés qu'il supprime.

• Des jours de jonglage dans un tableur entre disponibilités des intervenants, chevauchements de parcours et équipement des salles → quelques secondes → du temps pour le contenu et les sponsors.
• Les changements de dernière minute cassent un programme imprimé → épingles plus souhaits « garder l'horaire et la salle imprimés » → les agendas des participants tiennent pour l'essentiel.
• Des conflits cachés découverts le jour même → chaque règle vérifiée → aucun intervenant dans deux salles, aucun atelier sans PC.

Démo 15 — Planning hospitalier, Paris : le planning de la quinzaine, puis une vague de grippe

4 services (Urgences, Réanimation, Cardiologie, Médecine interne), postes de jour et de nuit de 12 heures, 532 postes, 120 médecins, infirmiers et aides-soignants. Samedi 6 h : cinq infirmiers et un médecin urgentiste en arrêt maladie, un congé maternité anticipé, un enfant malade, deux lits de réanimation supplémentaires, quatre infirmiers intérimaires en attente.

A. Pourquoi PowerSolver plutôt que Timefold directement. Les règles de temps de travail sont configurées avec des briques génériques :

• 11 h de repos entre deux postes, 48 h par semaine au plus, 3 jours d'affilée au plus (nuits consécutives possibles) ;
• qualification en réanimation ;
• limites du contrat ;
• jours de présence.

Le planning peut être ajusté par le bureau des plannings, pas seulement par des développeurs.

B. Pourquoi planifier avec PowerSolver. Mesuré sur l'exécution de référence :

• Planning : valide en moins de 2 s, chaque règle légale prouvée. 95 des 96 demandes de jour de repos sont accordées et personne n'ayant demandé des journées ne travaille de nuit.
• Replanification du samedi : valide en moins d'1 s. Les postes déjà travaillés sont intacts, et 28 des 351 postes restants changent : 13 le devaient, 15 s'ajustent autour. Aucun intérimaire n'est nécessaire.

C. Les difficultés qu'il supprime.

• Marathons téléphoniques au petit matin après les appels de malades → une replanification valide en quelques secondes, avec la liste des personnes à appeler → effectifs sûrs rétablis avant la prise de poste.
• Règles de repos enfreintes sous la pression → 11 h de repos, 48 h par semaine et jours d'affilée sont des règles impératives → des plannings plus sûrs sur les plans légal et clinique.
• Intérimaires appelés par réflexe → souhait « d'abord le personnel de l'hôpital » → dépenses d'intérim seulement quand c'est vraiment nécessaire.
• Demandes de repos oubliées → souhaits intégrés au modèle → des plannings plus équitables et une meilleure fidélisation.

Démo 16 — Déploiement international d'un ERP et d'un site e-commerce : 14 équipes dans 6 pays

172 lots de travail d'une semaine répartis sur 7 chantiers et 2 vagues pays, 14 équipes à Paris, Lisbonne, Cracovie, Casablanca, Bangalore et Montréal, 26 semaines, jours fériés locaux, une date fournisseur et 22 jalons. Comité de pilotage de la semaine 9 : une équipe réaffectée chez un autre client, une livraison en retard, un glissement de 3 semaines chez un fournisseur, et un nouveau périmètre réglementaire à livrer avant la semaine 20.

A. Pourquoi PowerSolver plutôt que Timefold directement. Fuseaux horaires (horaires européens pour le travail au contact des utilisateurs), jours fériés, dépendances, dates fournisseur et jalons sont des règles du catalogue. Cette démo a aussi conduit à une amélioration du moteur : une dépendance non respectée coûte désormais d'autant plus qu'elle est en retard, si bien que la recherche sait dans quel sens aller. Sans ce changement, aucun réglage de recherche n'atteignait un planning valide. La correction a été faite une seule fois, dans le moteur, dans le détail du score et dans le vérificateur indépendant ensemble, et profite à tous les clients.

B. Pourquoi planifier avec PowerSolver. Mesuré sur l'exécution de référence :

• Planning initial : valide après environ 50 s, avec tous les jalons tenus.
• Replanification de la semaine 9 : valide après environ 4 s. Les 53 lots terminés sont intacts, 11 des 123 lots restants bougent (10 dans le temps, 1 vers une autre équipe) et tous les jalons tiennent toujours.

C. Les difficultés qu'il supprime.

• Des plans de programme périmés dès le comité de pilotage suivant → replanifiés en quelques secondes à partir de la situation réelle → des décisions prises sur un planning valide, pas sur un espoir.
• Des dépendances entre pays suivies de tête et dans des tableurs → garanties → aucune équipe ne démarre avant que ses entrées existent.
• Des jours fériés de six pays oubliés → intégrés aux données → pas de semaines creuses ou surchargées par surprise.
• « Que nous coûte vraiment le retard du fournisseur ? » → la page Comparer montre ce qui a bougé et quelles règles ont changé → des arbitrages clairs pour le comité de pilotage.

Démo 17 — Cloud privé : placer 390 VM, puis un incident la nuit du Black Friday

Le centre de données d'une entreprise d'e-commerce : 390 machines virtuelles de 20 services (web, panier, paiement, bases de données, recherche, apprentissage automatique, CI…) sur 48 serveurs dans 9 baies, avec des serveurs standard, à grande mémoire, GPU et certifiés PCI-DSS. Mardi 2 h 14, Black Friday : une baie perd son alimentation (6 serveurs), un autre serveur tombe en panne, et le trafic double (24 réplicas ajoutés).

A. Pourquoi PowerSolver plutôt que Timefold directement. Capacité processeur et mémoire, exigences matérielles, « réplicas d'un service sur des serveurs différents » et « jamais sur un serveur à l'arrêt » sont toutes des règles du catalogue avec des paramètres. Le même modèle qui planifie des cours ou des techniciens place des VM, sans code de placement à écrire. L'incident se traite en modifiant des données : serveurs marqués à l'arrêt, réplicas ajoutés, bases de données épinglées.

B. Pourquoi planifier avec PowerSolver. Mesuré sur l'exécution de référence :

• Placement : valide en moins d'1 s, sans aucun serveur surchargé ni service avec deux réplicas sur le même serveur.
• Incident : valide après environ 3 s. Seules les 64 VM dont le serveur est tombé sont migrées : aucune autre VM ne bouge. Les 24 nouveaux réplicas sont placés, et les bases de données restent en place.

C. Les difficultés qu'il supprime.

• Placement au tableur et à l'intuition → chaque règle de capacité et de sécurité vérifiée → aucun serveur surchargé découvert en pleine charge.
• Un incident à 2 h du matin traité à la main sous pression → un placement valide en quelques secondes → l'ingénieur d'astreinte exécute au lieu de calculer.
• Migrations à chaud massives après une panne → souhait « rester sur son serveur » → seules les migrations inévitables, moins de risque en production.
• Serveurs spéciaux utilisés pour n'importe quoi → souhait « traitements par lots sur les serveurs standard » → la capacité GPU et PCI réservée à ce qui en a besoin.

Démo 18 — Atelier d'usinage : le planning de la semaine, puis une panne le mercredi matin

Un sous-traitant en usinage de précision (aéronautique, automobile, médical, pompes industrielles) : 60 commandes, 235 opérations sur 19 machines, deux équipes, des blocs de 2 heures. Mercredi 6 h : la broche d'une fraiseuse casse jusqu'à jeudi après-midi, une commande urgente de vis osseuses arrive, et deux livraisons de barres glissent à jeudi.

A. Pourquoi PowerSolver plutôt que Timefold directement. Gammes, capacités des machines, fenêtres de maintenance, arrivée de la matière et dates promises sont des règles du catalogue. Construire cette démo a aussi conduit à une amélioration du moteur. Quand un élément a deux décisions (machine et horaire), la recherche essaie désormais aussi de changer les deux en un seul mouvement, si bien qu'une opération peut quitter une machine qui ne sait pas la faire sans d'abord casser autre chose. L'amélioration a été faite une seule fois dans le moteur, testée contre le vérificateur indépendant, et accélère aussi d'autres problèmes à deux décisions (démos maintenance et conférence).

B. Pourquoi planifier avec PowerSolver. Mesuré sur l'exécution de référence :

• Semaine : valide après environ 42 s, avec toutes les dates promises tenues.
• Replanification du mercredi : valide après environ 0,5 s. Les opérations déjà réalisées sont intactes, et seules 5 opérations changent : les trois prévues sur la fraiseuse en panne et deux décalages qui en découlent. La commande urgente est terminée le mercredi, un jour avant sa date due. Aucune date promise n'est manquée.

C. Les difficultés qu'il supprime.

• Le planning de la semaine refait au tableau blanc → généré à partir des gammes et des données machines → le chef d'équipe vérifie au lieu de jongler.
• Une panne oblige à tout replanifier → seul ce que la panne touche bouge → les opérateurs gardent leur plan, les réglages ne sont pas perdus.
• Commandes urgentes acceptées à l'aveugle → le planning montre tout de suite si et où la commande tient → des promesses réalistes aux clients.
• Matière en retard découverte à l'atelier → dates earliest dans les données → aucune machine n'attend des pièces absentes.

Démo 19 — Session d'examens universitaire : 3 décisions par examen, puis un jour de neige

La session de janvier d'une faculté : 99 examens pour 18 promotions de 50 à 260 étudiants, 13 salles de 30 à 450 places, 40 surveillants, deux semaines. Pour chaque examen, PowerSolver décide le créneau, la salle et le surveillant. Jeudi 7 h : la neige ferme le campus deux jours (21 examens à déplacer), un amphithéâtre est en panne de chauffage, trois surveillants sont malades.

A. Pourquoi PowerSolver plutôt que Timefold directement. Une troisième décision, c'est une ligne de plus dans la description du problème, pas un nouveau modèle à coder. Nombre exact de places, disponibilité des surveillants, salles fermées et « un examen par jour et par promotion » sont des règles du catalogue.

B. Pourquoi planifier avec PowerSolver. Mesuré sur l'exécution de référence :

• Session : valide après environ 10 s, chaque salle assez grande, chaque surveillant disponible, la charge de surveillance répartie au mieux.
• Jour de neige : valide après environ 11 s. Les examens déjà passés sont intacts, et 60 examens gardent leur créneau, leur salle et leur surveillant.

La démo montre aussi l'honnêteté sur les données : sans l'amphithéâtre B, il n'y avait pas assez de grandes salles en semaine 2, et la faculté a ouvert deux samedis.

C. Les difficultés qu'il supprime.

• Des semaines à jongler entre salles, promotions et surveillants → un planning à trois décisions par examen en quelques secondes → le service des examens vérifie au lieu de construire.
• Un jour de neige ruine le calendrier publié → replanifié avant le premier examen de la journée → étudiants et personnel informés tout de suite.
• Salles trop petites ou surveillants en double découverts le jour de l'examen → places exactes et disponibilités en règles impératives → aucune surprise dans la salle.

Démo 20 — Bloc opératoire : 4 décisions par intervention, puis une crise le mardi

Le bloc opératoire d'un hôpital : 110 interventions dans 8 salles (cardiaque, orthopédie à flux laminaire, robotique, pédiatrique, polyvalentes), 21 chirurgiens de six spécialités, 10 anesthésistes. Pour chaque intervention, PowerSolver décide la salle, l'horaire, le chirurgien et l'anesthésiste. Mardi 7 h : la ventilation d'une salle tombe en panne, un chirurgien est malade, trois urgences arrivent.

A. Pourquoi PowerSolver plutôt que Timefold directement. Quatre décisions par intervention, quatorze règles impératives (équipement, spécialité, anesthésie pédiatrique et cardiaque, disponibilités, délais oncologiques), toutes configurées. Écrire ce modèle directement sur Timefold, c'est coder à la main le domaine et chaque règle.

B. Pourquoi planifier avec PowerSolver. Mesuré sur l'exécution de référence :

• Semaine : valide après environ 37 s, avec chaque patient opéré par son propre chirurgien.
• Mardi : valide après environ 30 s. Les interventions du lundi sont intactes, seules 4 interventions changent d'horaire, et les trois urgences sont opérées le mardi. Aucun délai oncologique n'est manqué.

Ce n'est pas instantané : avec quatre décisions, l'essentiel du temps sert à construire le premier planning. La démo le dit.

C. Les difficultés qu'il supprime.

• Le programme opératoire monté au téléphone entre chirurgiens, anesthésistes et cadres de bloc → un planning où chaque contrainte est vérifiée → moins d'interventions annulées.
• Des urgences casées en déprogrammant le plus simple → seul ce qui doit bouger bouge → les patients à qui un horaire a été annoncé le gardent pour la plupart.
• Un enfant anesthésié par un anesthésiste non pédiatrique, une prothèse de hanche posée sans flux laminaire → règles impératives → la sécurité par construction.

Démo 21 — Caisses de supermarché : les heures de début des postes à partir de la demande horaire

Un supermarché lyonnais ouvert de 8 h à 21 h tous les jours, 14 caissiers (temps plein, temps partiel, étudiants du week-end) et le nombre de caisses à ouvrir chaque heure de la semaine, d'après les caisses de l'an dernier : 329 heures-caissier, de 1 à 9 en même temps.

A. Pourquoi PowerSolver plutôt que Timefold directement. La demande horaire est une simple colonne de la liste des heures ; la règle « Effectif minimum par créneau » compte chaque heure, même celles que personne ne couvre, donc le planning place les postes là où est la demande. Jours de repos, un poste par jour et heure de fermeture sont configurés, pas codés.

B. Pourquoi planifier avec PowerSolver. Mesuré sur l'exécution de référence : valide après environ 10 à 15 s, chacune des 91 heures couverte, et 27 des 28 préférences matin/après-midi respectées.

C. Les difficultés qu'il supprime.

• Pics de midi et du samedi toujours en sous-effectif dans le tableur → chaque heure vérifiée contre sa demande → des files d'attente plus courtes.
• « Faut-il recruter ? » tranché à l'intuition → retirer un caissier et voir quelles heures manquent → une décision d'embauche chiffrée.

Conclusion

D'une démo à l'autre, le schéma est le même :

• Le problème de planification est décrit par des données et des règles métier en clair.
• PowerSolver, avec le moteur d'optimisation de Timefold, produit un planning dont chaque règle est vérifiée et vérifiable de façon indépendante.
• Quand la réalité change, un nouveau planning valide arrive en quelques secondes. Ce qui était déjà publié reste en place, sauf si cela doit vraiment bouger.

Pour une organisation, la valeur n'est pas seulement un meilleur planning. C'est une planification qui ne dépend plus du week-end d'une seule personne, une replanification qui se mesure en secondes au lieu d'heures, et des décisions explicables, règle par règle et changement par changement. Quand le catalogue de PowerSolver ne couvre pas encore un besoin, les tournées aujourd'hui, nous le disons ; cette honnêteté contribue à rendre le reste crédible.