Optimisation de planning : Pourquoi le LLM est une erreur (cas pratique)

Le cas concret : 5 infirmiers, 7 jours, 3 shifts, des dizaines de règles

On va traiter un cas client fictif (très proche d'une demande réelle récente) : on veut un système automatisé qui soit capable de produire le planning complet d'un service d'hôpital, avec 5 personnes dans l'équipe soignante.

On a évidemment simplifié pour l'article, parce qu'un système de ce genre devrait gérer des contraintes supplémentaires, en prenant notamment le rôle et ou la spécialité de chaque personne.

Préparation : modélisation du process et des contraintes

Contraintes légales

Évidemment, puisqu'on gère des données personnelles, ça va être compliqué de rester RGPD-compliant et d'envoyer le tout à un LLM. On devra au minimum anonymiser les données, ou utiliser un LLM qu'on fera tourner sur une machine locale. C'est techniquement tout à fait possible, mais ça demanderait des budgets inaccessibles pour notre mini-appli.

Idéalement, il faudrait donc qu'on trouve une solution embarquée, qui tourne directement dans un logiciel dédié (type "client lourd", donc un logiciel à installer sur le poste de la personne en charge de la gestion), ou sur un serveur web, qui pourrait être appelé via un dashboard personnalisé par exemple. En clair, on pourrait faire un mini-site qui gère le planning en question : les données restent au chaud chez le client, et les coûts d'usage restent sous contrôle.

Modéliser le process

Avant d'appeler un expert ou une agence pour automatiser votre tâche, cartographiez-là. C'est une étape très importante, que je ne peux pas faire à votre place (sinon, le logiciel produit tapera à côté, c'est presque garanti).

Cette étape sert aussi à assainir votre entreprise : avec des process carrés et documentés, il devient plus facile de gérer les absences et les embauches : les remplaçants ou les nouveaux utiliseront les documents fournis comme base pour se former en interne.

Pour modéliser un process, il existe des méthodes, comme SIPOC, qu'on ne détaillera pas ici. Globalement, il s'agit de lister ce qu'on aura comme données en entrées, la liste des salariés, et en sortie, un planning hebdomadaire avec 7 jours, 3 shifts (matin, après-midi et nuit).

Mini-checklist concrète :

Organisez un atelier de 2h avec les personnes qui font le planning manuellement
Posez les questions qui fâchent : "Quand refusez-vous une demande de congé, et pourquoi ?"
Listez TOUTES les exceptions (même celles qui vous semblent évidentes)

Contraintes métier

C'est là qu'il faut lister les règles que l'algorithme devra suivre :

l'hôpital doit être ouvert en permanence : au moins une personne devra travailler à tout moment
pas plus de deux personnes par shift
deux jours de repos plein par personne
35 heures de travail effectif
une nuit ne peut pas être suivie par un matin

Ça, c'est pour "la base". On peut ensuite rajouter des contraintes plus précises, comme des souhaits individuels :

Alice a des enfants, elle ne bosse pas le mercredi
Bob fait du kung-fu (comme les robots) le jeudi soir, il ne travaille pas le vendredi matin

La modélisation complète du process, avec ses entrées, sorties, et contraintes, c'est à peu près tout ce qu'il nous faut comme "cahier des charges" pour monter une automatisation efficace.

On teste avec un LLM

... et c'est une catastrophe.

On a essayé avec GPT5.1, Gemini 3 et Claude Sonnet 4.5 : mêmes résultats, inexploitables. C'est normal : le boulot d'un LLM, c'est de compléter une phrase en prévoyant statistiquement le mot le plus probable à chaque itération (ça marche par "tokens" mais le principe est le même).

L'effet "Whack-a-Mole" en action

Voici un exemple réel de ce que produit ChatGPT sur ce cas :

Tentative 1 : Bob n'a aucun jour de repos ❌
Tentative 2 (corrigée) : Charlie fait deux nuits consécutives ❌
Tentative 3 (re-corrigée) : Bob n'a qu'un seul jour de repos ❌
Tentative 4 : Le modèle propose... de négocier les 35 heures 🤦

À la 5ème itération, ChatGPT finit par avouer : "Il est difficile de satisfaire toutes les contraintes simultanément. Puis-je assouplir la règle des nuits ?"

Non, ChatGPT. Une contrainte, ce n'est pas censé être négociable.

Sur 100 générations, seulement 8 étaient correctes en moyenne, avec une mention spéciale pour Gemini 3 qui monte à 11% de réussite. À ce niveau de fiabilité, on pourrait tirer aux fléchettes, ça ne serait pas beaucoup moins bon.

Les LLMs excellent dans la créativité, la rédaction, la synthèse. Mais leur demander de résoudre un problème de contraintes strictes, c'est comme demander à un poète d'auditer vos comptes : ce n'est tout simplement pas leur métier.

Notre solution

Recherches académiques

Chez LVLUP, on n'aime pas réinventer la roue. Avant de se mettre à coder, on a une étape en interne, incontournable : on vérifie ce qui existe déjà dans la recherche académique. Si 1000 chercheurs se sont déjà penchés sur le problème, ce n'est pas votre serviteur qui fera mieux en quelques journées de boulot.

Et là, banco : le Nurse Scheduling Problem (exactement ce qu'on cherche à faire), étudié depuis 1976.

À l'époque, dans son papier "Nurse Scheduling Models: A State of the Art Review" (publié dans le Journal of The Operational Research Society), William Pierskalla identifie que la complexité des plannings infirmiers dépasse l'entendement humain simple, et pose les bases de leur modélisation mathématique.

Plus récemment (au début des années 2000), les travaux de Edmund Burke et de Greet Vanden Berghe ont confirmé que le "Nurse Rostering" appartient à la classe des problèmes NP-complets : quand on ajoute des contraintes, la difficulté explose de manière exponentielle. Pour faire simple, si on ajoute une seule personne, ou que Sylvie demande juste son lundi, c'est déjà dix fois plus compliqué de monter un planning au carré.

Tout ça, ça fait partie d'un domaine d'étude qu'on appelle la recherche opérationnelle : prendre la meilleure décision possible sous contrainte.

Choix de la techno

Assez simple dans notre cas : on est partis sur du Python, langage très répandu, beaucoup utilisé dans le monde académique, et facile à interfacer avec autre chose (on peut très simplement transformer notre script en API pour brancher un ERP/CRM dessus, ou motoriser notre mini-site).

Dans la ligne directe des travaux cités plus haut, Google maintient une librairie qui s'appelle OR-Tools : elle est écrite en C++ (choisi pour sa vitesse d'exécution et sa faible empreinte mémoire - c'est compilé) et on peut s'en servir en Python (ou autres). Cette librairie gratuite contient un solveur appelé CP-SAT :

CP pour Constraint Programming : programmation par contraintes
SAT pour Satisfiability* : recherche de solutions qui satisfont toutes les contraintes simultanément

Le principe est simple : on définit un modèle vide, on y ajoute toutes nos contraintes, puis on lance le solveur.

Imaginez un Sudoku : vous ne devinez pas les chiffres au hasard (comme le ferait un LLM), vous éliminez systématiquement les impossibilités jusqu'à trouver LA solution. C'est exactement ce que fait CP-SAT.

Ajouter une nouvelle contrainte, c'est 2 ou 3 lignes de code.

Le plus compliqué (même si ça ne l'est pas vraiment ici), c'est de trouver un moyen mathématique de décrire chaque contrainte.

Le résultat : Moins d'une seconde pour générer un planning parfait. Toutes les règles sont respectées à la lettre : Alice ne travaille jamais le mercredi, Bob a son vendredi matin libre, personne n'enchaîne deux nuits, tout le monde fait exactement 35 heures avec deux jours de repos minimum. Zéro hallucination, zéro négociation sur les contraintes. C'est du déterministe pur.

On a même été obligés de rajouter une couche de hasard pour ne pas tomber toujours sur le même planning.

"Ça marche pour 5 personnes, mais pour 200 ?"

OR-Tools a été utilisé par Google pour des problèmes à des millions de variables, notamment sur Google Maps. Un planning de 200 personnes, ça reste dans sa zone de confort.

C'est de l'IA symbolique (oui, c'est bien de l'IA !)

L'IA n'est pas née avec ChatGPT. Selon la définition de l'OCDE (2019), notre système de planning est une Intelligence Artificielle, de la famille symbolique :

IA probabiliste (type LLM/ChatGPT)

Fonctionne par prédictions statistiques
Créative et flexible
Peut halluciner (inventer des infos)
Cas d'usage : rédaction, traduction, brainstorming

IA Symbolique (OR-Tools, systèmes experts)

Fonctionne par règles mathématiques
Déterministe et fiable à 100%
Ne peut pas "inventer"
Cas d'usage : planification, logistique, optimisation

Pour un poème, choisissez la probabiliste. Pour la paie de vos infirmiers, exigez la déterministe.

Et si on veut à tout prix utiliser de l'IA probabiliste ?

On pourrait utiliser les TRM (Tiny Recursive Models) d'Alexia Jolicoeur-Martineau (pour Samsung) : dans son papier "Less is More: Recursive Reasoning with Tiny Networks", qui date d'octobre 2025 et à lire sur Arxiv, elle explique comment des réseaux de neurones minuscules peuvent être entraînés sur de la résolution de tâches, et peuvent même comprendre les contraintes eux-mêmes à partir de leur dataset d'entraînement.

Pour constituer le dataset en question, on pourrait numériser tous les anciens plannings, ou utiliser des données synthétiques, issues d'un système déterministe, comme celui présenté ci-dessus. Sans optimisation supplémentaire, il faudrait une dizaine de jours pour générer un million de plannings valides. Ensuite, on cache quelques shifts dans chaque planning, on donne la version complète et la version à trou à un réseau de neurones pour l'entraîner à retrouver les parties manquantes.

L'avantage des TRM, c'est ce que ces mini-modèles peuvent, sur des tâches précises, largement rivaliser avec des modèles bien plus gourmands en ressources. L'objectif, pour Samsung, c'est d'arriver à donner des capacités IA à des téléphones, sans passer par un upload de données et un traitement sur un serveur centralisé (dont la maintenance reste de leur responsabilité).

Pour aller plus loin : l'expérience collaborateur

(Je suis peut-être un très mauvais commercial, mais j'aime bien proposer des features à nos clients)

On a déjà envisagé de créer un mini-dashboard qui s'occuperait de la génération et de l'affichage des plannings. Sur la base de notre algorithme, on pourrait développer des interfaces simples (Web ou Mobile) où :

les salariés disposent d'un compte (on peut brancher un SSO d'entreprise pour lui déléguer la gestion des droits d'accès),
chaque salarié déclare ses indisponibilités ou ses souhaits jusqu'au dimanche soir.
l'algorithme valide instantanément la faisabilité (s'il existe une solution, on accepte),
le planning est généré et signé numériquement le lundi matin, sans qu'aucun manager n'ait eu à passer son week-end sur Excel.