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

Le point de départ Excel

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

Ça fonctionne. Pour 20-30 personnes, un planificateur expérimenté peut construire un planning mensuel en 3 à 5 jours. Il connaît son équipe, il connaît les schémas, il fait défiler de haut en bas et de gauche à droite jusqu'à ce que chaque cellule soit remplie et chaque règle respectée. Le tableur est à la fois l'outil et la documentation.

Au-delà de 50 employés, ça casse. Pas soudainement, mais progressivement. Le planificateur rate une violation de repos cachée en ligne 47. Un poste non couvert le mardi passe inaperçu parce que la colonne est hors écran. Une plainte d'un employé révèle qu'une personne a travaillé 5 jours de plus que son collègue. Le tableur ne signale rien de tout cela. Il ne stocke que ce que le planificateur saisit.

Les contraintes cachées

Un planning Excel contient bien plus de règles que ce qui apparaît dans les cellules. Le planificateur suit des contraintes implicites qui n'existent que dans sa tête :

• "Jean travaille toujours le matin parce qu'il récupère ses enfants à l'école à 15h30."
• "Ne jamais mettre Ahmed et Sophie sur le même shift. Ils ne travaillent pas bien ensemble."
• "Le shift de nuit nécessite au moins un senior avec 3+ ans d'expérience."
• "Marc ne travaille pas le mercredi. Il n'a jamais travaillé le mercredi. Tout le monde le sait."
• "Pendant les vacances scolaires, Claire préfère les shifts d'après-midi."

Aucune de ces règles n'est écrite. Elles vivent dans la mémoire du planificateur, construites au fil des mois ou des années d'expérience. Quand le planificateur est malade ou en vacances, son remplaçant produit un planning techniquement correct mais opérationnellement faux. Les plaintes suivent.

C'est le premier problème qu'une migration vers un solveur résout : rendre les règles implicites explicites. Chaque contrainte doit être écrite, catégorisée et priorisée. C'est un travail inconfortable. Mais une fois fait, la logique de planification devient transférable, auditable et indépendante d'une seule personne.

Parser les données

La première étape technique est d'extraire des données structurées des fichiers Excel. Une migration typique nécessite 5-6 fichiers de données :

Liste des employés

Nom, type de contrat (fixe, auxiliaire, étudiant), heures cibles mensuelles, qualifications détenues, appartenance à un groupe. Ces informations sont généralement dispersées sur plusieurs feuilles ou même dans des fichiers séparés. Les consolider dans un format structure unique (JSON ou base de données) constitue la fondation.

Définitions des shifts

Chaque code de shift (ex : A10-GS, N01-GS) correspond à une heure de début, une heure de fin, une structure de pause et une fonction. Dans le tableur, ce mapping vit dans la tête du planificateur ou dans une feuille de référence qui peut être obsolète. L'extraire force une définition propre et actuelle de chaque shift.

Besoins journaliers

Combien de personnes sont nécessaires par fonction par jour. Le lundi peut nécessiter 5 agents de sécurité et 3 logisticiens, tandis que le dimanche en nécessite 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 (congés, vacances, jours de repos fixes), préférences et règles spéciales. Chacune devient un enregistrement type : employé X, type de contrainte HOLIDAY, dates 15-22 mars. Les contraintes cachées dans la tête du planificateur deviennent des entrées 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 étape de parsing prend typiquement 1-2 semaines pour une opération de taille moyenne. Les données existent, mais elles sont dispersées, incohérentes et incomplètes. L'effort n'est pas dans l'écriture du code. Il est dans les conversations avec le planificateur pour extraire et valider chaque information.

Construire le modèle

Chaque règle du monde Excel se traduit en une contrainte CP-SAT. La correspondance est étonnamment directe :

Règle Excel	Contrainte CP-SAT
Un code shift par cellule (par employé 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 = sécurité)	Respect des qualifications : variable créée uniquement pour les paires employé-shift valides
"Jean travaille toujours le matin"	Contrainte : restreindre assign[Jean, d, s] aux shifts du matin uniquement
"Jamais Ahmed + Sophie sur le même shift"	Pour chaque jour d, chaque shift s : assign[Ahmed, d, s] + assign[Sophie, d, s] <= 1
Heures cibles par employé	Objectif souple : pénaliser l'écart par rapport à target_minutes[e]
Répartition équitable dans l'équipe	Objectif d'équité : minimiser max_jours - min_jours par groupe

L'idée clé : le planificateur Excel résout déjà un problème de satisfaction de contraintes. Il le fait simplement à la main, cellule par cellule, en utilisant l'intuition au lieu de la recherche. Le solveur fait la même chose, mais il explore l'espace de solutions de façon systématique.

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

Premier lancement du solveur

Le planificateur lance le solveur pour la première fois, importe le résultat dans une grille familière et compare. Les réactions sont prévisibles :

• "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 donné le shift de nuit à un junior arrivé le mois dernier." (Contrainte manquante : les shifts de nuit exigent une ancienneté minimum.)
• "Il y a trois personnes en logistique le jeudi mais on n'en a besoin que de deux." (Erreur de données : le fichier des besoins indique 3, ça devrait être 2.)
• "Le planning a l'air correct mais il sonne faux." (Préférence implicite pas encore capturée.)

Chacune de ces réactions révèle un écart entre le modèle et la réalité. Le planificateur identifie le problème, la contrainte est ajoutée ou les données sont corrigées, et le solveur tourne à nouveau. Cette boucle de retour est le coeur du processus de migration.

Après 3-4 itérations, le modèle capture typiquement 95% des règles. Les 5% restants sont des cas limites et des préférences souples que le planificateur gère avec de petits ajustements manuels après que le solveur a produit son résultat. C'est attendu et acceptable. L'objectif n'est pas d'éliminer le planificateur. C'est d'éliminer la construction manuelle du planning de base.

Comparer les résultats

Une comparaison côte à côte du planning manuel et du planning solveur révèle typiquement des différences mesurables :

Couverture

Le solveur atteint 100% de couverture des besoins déclarés. Le planning manuel a souvent 2-5 postes non couverts que le planificateur résout le jour même par des appels téléphoniques et des échanges de dernière minute. Le solveur élimine cette gestion réactive.

Conformité des repos

Le solveur produit zéro violation de repos (règle des 11 heures). Les plannings manuels contiennent fréquemment 3-8 violations par mois, découvertes uniquement quand un employé se plaint ou quand un audit les détecte.

Équité

Le solveur distribue la charge de travail avec un écart de 1-2 jours par groupe. Les plannings manuels montrent des écarts de 3-5 jours entre les employés les plus et les moins chargés. Sur plusieurs mois, cet écart se cumule et devient une source de tension.

Heures totales

Le solveur utilise le même nombre ou moins d'heures totales pour atteindre une meilleure couverture. Il trouve des combinaisons que le planificateur n'envisagerait pas parce qu'elles nécessitent de déplacer 4-5 employés simultanément, 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 séquence délibérée et à faible risque :

• Mois 1-2 : Faire tourner le solveur en parallèle du planning manuel. Le planificateur construit le planning comme d'habitude, puis le compare avec la sortie du solveur. Les écarts révèlent 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 dernière minute et les demandes des employés. La construction manuelle n'est plus nécessaire.

Le planificateur doit faire confiance au résultat avant de s'y fier. La confiance vient de la compréhension, et la compréhension vient de la comparaison. Sauter la phase parallèle est tentant mais contre-productif. Chaque écart trouvé pendant la phase parallèle est une contrainte qui aurait été manquée en production.

Ce qui change

Le rôle du planificateur change fondamentalement. L'allocation du temps passe de l'exécution à la supervision :

Tâche	Avant (Excel)	Après (solveur)
Construire le planning de base	3-5 jours	Minutes (lancement solveur + relecture)
Vérifier la conformité des repos	2-4 heures (scan manuel)	0 (garanti par les contraintes)
Équilibrer la charge de travail	1-2 heures (tâtonnement)	0 (optimisé par l'objectif)
Gérer les plaintes d'équité	Fréquent	Rare (répartition prouvée par les données)
Gérer les changements de dernière minute	Ad hoc, stressant	Relancer le solveur avec les contraintes mises à jour
Former un nouveau planificateur	Mois de formation	Jours (les règles sont dans le modèle)

Le planificateur ne disparaît pas. Il devient plus stratégique. Au lieu de placer des codes de shifts dans des cellules pendant 3-5 jours, il consacre son temps à ce qui nécessite réellement un jugement humain : traiter les demandes inhabituelles, s'adapter aux événements imprévus et améliorer les règles de planification au fil du temps.

Le modèle devient la mémoire institutionnelle. Quand le planificateur change, les règles restent. Quand un employé demande "pourquoi m'a-t-on affecté à ce shift ?", la réponse est dans le journal des contraintes, pas dans la tête de quelqu'un.