D'Excel a CP-SAT : Migrer un Planning Manuel

Le point de depart Excel

La plupart des planificateurs commencent avec Excel. La mise en page est presque toujours la meme : les employes en lignes, les jours en colonnes, les codes de shifts saisis dans les cellules. Un code couleur distingue les fonctions (jaune pour la securite, bleu pour la logistique, vert pour l'enregistrement). La mise en forme conditionnelle signale les conflits. Des formules comptent les heures par employe, parfois par semaine, parfois par mois.

Ca fonctionne. Pour 20-30 personnes, un planificateur experimente peut construire un planning mensuel en 3 a 5 jours. Il connait son equipe, il connait les schemas, il fait defiler de haut en bas et de gauche a droite jusqu'a ce que chaque cellule soit remplie et chaque regle respectee. Le tableur est a la fois l'outil et la documentation.

Au-dela de 50 employes, ca casse. Pas soudainement, mais progressivement. Le planificateur rate une violation de repos cachee en ligne 47. Un poste non couvert le mardi passe inapercu parce que la colonne est hors ecran. Une plainte d'un employe revele qu'une personne a travaille 5 jours de plus que son collegue. Le tableur ne signale rien de tout cela. Il ne stocke que ce que le planificateur saisit.

Les contraintes cachees

Un planning Excel contient bien plus de regles que ce qui apparait dans les cellules. Le planificateur suit des contraintes implicites qui n'existent que dans sa tete :

• "Jean travaille toujours le matin parce qu'il recupere ses enfants a l'ecole a 15h30."
• "Ne jamais mettre Ahmed et Sophie sur le meme shift. Ils ne travaillent pas bien ensemble."
• "Le shift de nuit necessite au moins un senior avec 3+ ans d'experience."
• "Marc ne travaille pas le mercredi. Il n'a jamais travaille le mercredi. Tout le monde le sait."
• "Pendant les vacances scolaires, Claire prefere les shifts d'apres-midi."

Aucune de ces regles n'est ecrite. Elles vivent dans la memoire du planificateur, construites au fil des mois ou des annees d'experience. Quand le planificateur est malade ou en vacances, son remplacant produit un planning techniquement correct mais operationnellement faux. Les plaintes suivent.

C'est le premier probleme qu'une migration vers un solveur resout : rendre les regles implicites explicites. Chaque contrainte doit etre ecrite, categorisee et priorisee. C'est un travail inconfortable. Mais une fois fait, la logique de planification devient transferable, auditable et independante d'une seule personne.

Parser les donnees

La premiere etape technique est d'extraire des donnees structurees des fichiers Excel. Une migration typique necessite 5-6 fichiers de donnees :

Liste des employes

Nom, type de contrat (fixe, auxiliaire, etudiant), heures cibles mensuelles, qualifications detenues, appartenance a un groupe. Ces informations sont generalement dispersees sur plusieurs feuilles ou meme dans des fichiers separes. Les consolider dans un format structure unique (JSON ou base de donnees) constitue la fondation.

Definitions des shifts

Chaque code de shift (ex : A10-GS, N01-GS) correspond a une heure de debut, une heure de fin, une structure de pause et une fonction. Dans le tableur, ce mapping vit dans la tete du planificateur ou dans une feuille de reference qui peut etre obsolete. L'extraire force une definition propre et actuelle de chaque shift.

Besoins journaliers

Combien de personnes sont necessaires par fonction par jour. Le lundi peut necessiter 5 agents de securite et 3 logisticiens, tandis que le dimanche en necessite 2 et 1. Ces besoins pilotent l'objectif de couverture du solveur. Dans Excel, ils sont implicites dans la mise en page cible du planificateur.

Contraintes

Absences (conges, vacances, jours de repos fixes), preferences et regles speciales. Chacune devient un enregistrement type : employe X, type de contrainte HOLIDAY, dates 15-22 mars. Les contraintes cachees dans la tete du planificateur deviennent des entrees explicites dans ce fichier.

# Exemple de fichiers de donnees pour le solveur :
01_employees.json      # 150 employes avec qualifications et contrats
02_shifts.json         # 50 definitions de shifts avec horaires et pauses
03_daily_needs.json    # Besoins en effectif par fonction par jour
04_constraints.json    # Absences, preferences, affectations fixes
05_groups.json         # Groupes fonctionnels et leurs membres

Cette etape de parsing prend typiquement 1-2 semaines pour une operation de taille moyenne. Les donnees existent, mais elles sont dispersees, incoherentes et incompletes. L'effort n'est pas dans l'ecriture du code. Il est dans les conversations avec le planificateur pour extraire et valider chaque information.

Construire le modele

Chaque regle du monde Excel se traduit en une contrainte CP-SAT. La correspondance est etonnamment directe :

Regle Excel	Contrainte CP-SAT
Un code shift par cellule (par employe par jour)	sum(assign[e, d, s] for s) <= 1
Cellules rouges = conflit (violation de repos)	Paires toxiques : assign[e, d, s1] + assign[e, d+1, s2] <= 1
Fonctions par couleur (jaune = securite)	Respect des qualifications : variable creee uniquement pour les paires employe-shift valides
"Jean travaille toujours le matin"	Contrainte : restreindre assign[Jean, d, s] aux shifts du matin uniquement
"Jamais Ahmed + Sophie sur le meme shift"	Pour chaque jour d, chaque shift s : assign[Ahmed, d, s] + assign[Sophie, d, s] <= 1
Heures cibles par employe	Objectif souple : penaliser l'ecart par rapport a target_minutes[e]
Repartition equitable dans l'equipe	Objectif d'equite : minimiser max_jours - min_jours par groupe

L'idee cle : le planificateur Excel resout deja un probleme de satisfaction de contraintes. Il le fait simplement a la main, cellule par cellule, en utilisant l'intuition au lieu de la recherche. Le solveur fait la meme chose, mais il explore l'espace de solutions de facon systematique.

150 employes × 30 jours × 50 shifts = 225 000 affectations possibles. Aucun humain n'evalue toutes ces combinaisons. Le planificateur en evalue peut-etre quelques centaines avant de se fixer sur une solution. Le solveur en evalue des millions.

Premier lancement du solveur

Le planificateur lance le solveur pour la premiere fois, importe le resultat dans une grille familiere et compare. Les reactions sont previsibles :

• "Pourquoi il a mis Marc le mercredi ? Il ne travaille jamais le mercredi." (Contrainte manquante : Marc a un jour de repos fixe le mercredi.)
• "Il a donne le shift de nuit a un junior arrive le mois dernier." (Contrainte manquante : les shifts de nuit exigent une anciennete minimum.)
• "Il y a trois personnes en logistique le jeudi mais on n'en a besoin que de deux." (Erreur de donnees : le fichier des besoins indique 3, ca devrait etre 2.)
• "Le planning a l'air correct mais il sonne faux." (Preference implicite pas encore capturee.)

Chacune de ces reactions revele un ecart entre le modele et la realite. Le planificateur identifie le probleme, la contrainte est ajoutee ou les donnees sont corrigees, et le solveur tourne a nouveau. Cette boucle de retour est le coeur du processus de migration.

Apres 3-4 iterations, le modele capture typiquement 95% des regles. Les 5% restants sont des cas limites et des preferences souples que le planificateur gere avec de petits ajustements manuels apres que le solveur a produit son resultat. C'est attendu et acceptable. L'objectif n'est pas d'eliminer le planificateur. C'est d'eliminer la construction manuelle du planning de base.

Comparer les resultats

Une comparaison cote a cote du planning manuel et du planning solveur revele typiquement des differences mesurables :

Couverture

Le solveur atteint 100% de couverture des besoins declares. Le planning manuel a souvent 2-5 postes non couverts que le planificateur resout le jour meme par des appels telephoniques et des echanges de derniere minute. Le solveur elimine cette gestion reactive.

Conformite des repos

Le solveur produit zero violation de repos (regle des 11 heures). Les plannings manuels contiennent frequemment 3-8 violations par mois, decouvertes uniquement quand un employe se plaint ou quand un audit les detecte.

Equite

Le solveur distribue la charge de travail avec un ecart de 1-2 jours par groupe. Les plannings manuels montrent des ecarts de 3-5 jours entre les employes les plus et les moins charges. Sur plusieurs mois, cet ecart se cumule et devient une source de tension.

Heures totales

Le solveur utilise le meme nombre ou moins d'heures totales pour atteindre une meilleure couverture. Il trouve des combinaisons que le planificateur n'envisagerait pas parce qu'elles necessitent de deplacer 4-5 employes simultanement, ce qui est impraticable manuellement mais trivial pour un algorithme de recherche.

La transition

La migration n'est pas un big bang. Elle suit une sequence deliberee et a faible risque :

• Mois 1-2 : Faire tourner le solveur en parallele du planning manuel. Le planificateur construit le planning comme d'habitude, puis le compare avec la sortie du solveur. Les ecarts revelent les contraintes manquantes.
• Mois 3 : Le planificateur part de la sortie du solveur au lieu d'une grille vierge. Il revoit, ajuste et valide. Le planning manuel devient le plan de secours.
• Mois 4+ : La sortie du solveur est le planning principal. Le planificateur se concentre sur les exceptions, les changements de derniere minute et les demandes des employes. La construction manuelle n'est plus necessaire.

Le planificateur doit faire confiance au resultat avant de s'y fier. La confiance vient de la comprehension, et la comprehension vient de la comparaison. Sauter la phase parallele est tentant mais contre-productif. Chaque ecart trouve pendant la phase parallele est une contrainte qui aurait ete manquee en production.

Ce qui change

Le role du planificateur change fondamentalement. L'allocation du temps passe de l'execution a la supervision :

Tache	Avant (Excel)	Apres (solveur)
Construire le planning de base	3-5 jours	Minutes (lancement solveur + relecture)
Verifier la conformite des repos	2-4 heures (scan manuel)	0 (garanti par les contraintes)
Equilibrer la charge de travail	1-2 heures (tatonnement)	0 (optimise par l'objectif)
Gerer les plaintes d'equite	Frequent	Rare (repartition prouvee par les donnees)
Gerer les changements de derniere minute	Ad hoc, stressant	Relancer le solveur avec les contraintes mises a jour
Former un nouveau planificateur	Mois de formation	Jours (les regles sont dans le modele)

Le planificateur ne disparait pas. Il devient plus strategique. Au lieu de placer des codes de shifts dans des cellules pendant 3-5 jours, il consacre son temps a ce qui necessite reellement un jugement humain : traiter les demandes inhabituelles, s'adapter aux evenements imprevus et ameliorer les regles de planification au fil du temps.

Le modele devient la memoire institutionnelle. Quand le planificateur change, les regles restent. Quand un employe demande "pourquoi m'a-t-on affecte a ce shift ?", la reponse est dans le journal des contraintes, pas dans la tete de quelqu'un.