Planification interactive avec ReasoningLayer : un cas d'usage de planning infirmier

C'est mardi matin. Aisha demande son vendredi.

Son responsable ouvre le planning et fixe l'écran. Le vendredi tiendra-t-il toujours sans elle ? Quelqu'un d'autre dispose-t-il de l'habilitation soins intensifs et d'un créneau libre ? Si Aisha s'absente, qui assure la garde de nuit deux jours plus tard — celle pour laquelle elle était la seule infirmière formée aux urgences encore disponible ? Et si le vendredi tient, qu'est-ce que cela impose partout ailleurs ?

Aujourd'hui, la réponse demande dix minutes de calcul mental, un « je vous recontacte » embarrassé, ou l'attente d'une pause-café pendant que le logiciel régénère tout le planning et que le responsable cherche ce qui a changé.

Cela devrait prendre une fraction de seconde. Et la réponse ne devrait pas être un planning de plus — elle devrait indiquer au responsable quelles cases sont désormais imposées, lesquelles sont désormais impossibles, et lesquelles relèvent encore de son choix.

C'est ce que nous avons construit.

Voyez-le avant d'en lire le récit

Chaque recoloration est la réponse complète du moteur — pas un échantillon, pas une supposition. Aucun traitement par lots. Aucun « régénération en cours, veuillez patienter ». Aucune boîte noire qui dit « l'IA l'a décidé ». Le responsable agit, le planning répond, et ce qui reste sur la grille est exactement ce qui demeure réalisable.

Ne nous croyez pas sur parole pour la recoloration — testez-la vous-même. ▶ Ouvrez la grille en direct et commencez à épingler des infirmières : chaque clic lance une vraie résolution et repeint le tableau sous vos yeux.

Trois états, pour chaque case

Chaque case (infirmière, jour, vacation) de la grille se trouve dans exactement l'un de ces trois états :

• 🟢 Confirmé — cette infirmière doit assurer ce créneau. Tout planning respectant vos règles l'y place. La retirer briserait l'ensemble du planning.
• 🔴 Impossible — cette infirmière ne peut pas assurer ce créneau. Aucun planning respectant vos règles ne l'y place, compte tenu de tout ce qui est déjà épinglé.
• 🟡 Libre — cette infirmière pourrait assurer ce créneau. Certains plannings valides l'y placent, d'autres non. Le choix reste ouvert.

Voilà le tableau complet : non pas un planning parmi des millions de possibilités, mais une carte nette en trois couleurs montrant où le responsable a de la liberté, où il n'a aucun choix, et où il n'a aucune chance.

Lorsque le responsable clique sur Aisha pour le vendredi matin, toute la grille se recalcule. Des cases qui étaient jaunes le jour 12 peuvent virer au rouge parce qu'Aisha était la seule à pouvoir couvrir les urgences cette nuit-là. Des cases qui étaient jaunes le mardi après-midi peuvent virer au vert parce qu'épingler Aisha oblige désormais Bob à occuper un créneau pour lequel elle était auparavant éligible.

Chaque clic est un instantané de « ce qui reste possible, compte tenu de cela ». Aucun engagement. Pas besoin de générer d'abord un planning complet pour ensuite défaire ce qui ne convient pas. Le planning émerge des choix du responsable, le moteur confirmant à chaque étape que tout reste cohérent.

Lorsque le responsable survole une case verte indiquant « doit travailler », il sait que ce n'est pas l'avis du moteur — c'est un fait valable pour tout planning respectant ses règles.

Cette forme se retrouve aussi sur le réseau. Chaque case de la réponse est un enregistrement unique et sans ambiguïté :

{
  "agentId": "aisha",
  "day": 0,
  "shift": 0,
  "status": "confirmed_true",
  "roles": ["intensive_care"]
}

status vaut exactement confirmed_true, confirmed_false ou free — les trois couleurs, nommées.

Cette réponse en trois couleurs, c'est la forme même de Reasoning Layer, le moteur qui sous-tend la démonstration. Posez-lui une question structurée et il ne renvoie pas une réponse que vous devriez remettre en question ; il renvoie l'espace complet des réponses qui résistent à vos règles, réparties entre ce qui est acquis, ce qui est exclu, et ce qui reste ouvert. La grille de planning n'en est qu'une facette.

Et lorsque vous avez des préférences

Les règles strictes — « chaque vacation requiert une infirmière de soins intensifs », « personne ne fait plus de quatre nuits » — définissent ce qui est possible. Les préférences souples — « Anna préfère les matins », « on préférerait n'affecter personne le vendredi si possible » — définissent ce qui est souhaitable.

La grille gère les deux. Activez les préférences et le moteur ne se contente plus de vous dire quels plannings respectent les règles ; il vous dit quels plannings obtiennent le meilleur score, et quelles cases sont remplies de la même manière dans tous les plannings les mieux notés. Le nom d'Anna se verrouille en vert plein le mercredi matin même lorsque dix plannings alternatifs étaient techniquement valides, parce qu'elle figure dans chacun des meilleurs.

Côté intégrateur, l'appel a la même forme, que vous ayez des préférences ou non — vous transmettez simplement la liste supplémentaire au moteur. (Vous ne mettez pas cela en place vous-même ? Sautez le bloc de code — la seule ligne à retenir est l'enseignement juste après.)

// Qui peut travailler, sur quoi chacun est formé, nombre max de vacations dans le planning
const agents = [
  { id: 'aisha', roles: ['intensive_care', 'emergency'], maxAssignments: 4 },
  { id: 'anna',  roles: ['intensive_care'],              maxAssignments: 4 },
  { id: 'bob',   roles: ['general'],                     maxAssignments: 4 },
];
 
// Demande par (jour, vacation) : effectif total + minimums par rôle
const demands = [
  { day: 0, shift: 0, total: 3, roleMinimums: { intensive_care: 1 } },
  // la garde de nuit requiert aussi une infirmière formée aux urgences
  { day: 0, shift: 2, total: 3, roleMinimums: { intensive_care: 1, emergency: 1 } },
  // ... une entrée par créneau qui vous importe
];
 
// Engagements fermes — cases que le responsable a déjà verrouillées
const pins = [
  { agentId: 'aisha', day: 4, shift: 0 }, // Aisha épinglée au vendredi matin
];
 
// Préférences souples — orientent l'optimum sans changer ce qui est possible
const preferences = [
  { agentId: 'anna', day: 2, shift: 0, score:  5 },  // Anna aime les mercredis matin
  // Bob préférerait éviter le vendredi — une entrée par vacation, car les
  // préférences sont transmises par case (jour, vacation)
  { agentId: 'bob',  day: 4, shift: 0, score: -3 },
  { agentId: 'bob',  day: 4, shift: 1, score: -3 },
  { agentId: 'bob',  day: 4, shift: 2, score: -3 },
];
 
const report = await client.scheduling.optimize({
  agents,
  days: 7,
  shiftsPerDay: 3,
  demands,
  pins,
  preferences,
});

Vous obtenez l'optimum sans jamais avoir à choisir un optimum. Vous voyez ce qu'imposent vos préférences de la même manière que ce qu'imposent vos règles — sur la même grille, au même instant.

Les formats complets de requête et de réponse, les règles de désambiguïsation des rôles pour les épingles, et les compromis entre feasibility() et optimize() sont documentés dans le guide Planification de la référence du SDK TypeScript.

Deux responsables, un seul planning

Ouvrez le planning, cliquez sur quelques infirmières, copiez l'URL, envoyez-la à un collègue. Il ouvre le lien et voit la même grille — mêmes épingles, mêmes couleurs, mêmes chiffres — et reprend là où vous en étiez.

Cela fonctionne parce que le planning n'est pas un document privé sur la machine du responsable ; c'est un enregistrement vivant que vous regardez tous les deux, partagé par URL comme vous partageriez un Google Doc. Épinglez une case sur votre écran, changez d'onglet, revenez : le moteur a déjà intégré la dernière modification de votre collègue, et la grille devant vous la reflète.

La sensation conversationnelle, ce « essayons ceci » de la démonstration, ne vient pas d'une interface soignée plaquée sur un tableur statique. Elle vient du fait que le planning est un objet partagé unique — infirmières, demandes, épingles, préférences, affectations dérivées — que vous deux, et le moteur, regardez et modifiez en temps réel.

Ce que ReasoningLayer fait différemment

La plupart des outils de planification se rangent dans l'une de trois catégories. Chacune est bien adaptée à ce pour quoi elle a été conçue ; ReasoningLayer est conçu pour une autre question — qu'est-ce qui reste possible ? — et y répond à chaque clic.

Les tableurs et les plannings manuels — contrôle humain total, propagation nulle. Le responsable doit garder chaque règle en tête. Les erreurs s'accumulent en silence jusqu'à ce que le planning soit diffusé et que quelqu'un découvre que la garde de nuit n'a aucune couverture en soins intensifs.

Les planificateurs « générer puis éditer » — le modèle dominant. On appuie sur un bouton, on attend, on obtient un planning. Vous voulez basculer Aisha sur le mardi ? Modifiez la case, espérez que rien n'a cassé, lancez la validation, corrigez ce qui a cassé, recommencez. L'outil ne vous dit jamais à l'avance quelles autres cases votre modification vient de rendre impossibles — vous le découvrez quand la validation les signale après coup.

Les optimiseurs lourds — ils peuvent produire un planning sous un nombre quelconque de règles, à terme. Ils ne sont pas conçus pour répondre à « parmi tous les plannings valides, quelles cases sont imposées ? » — et quand vous le demandez, vous attendez. Assez longtemps pour que « cliquer et regarder la grille se mettre à jour » cesse d'être possible.

Ce que nous avons construit relève d'une autre nature : un outil dont le rôle n'est pas de rédiger le planning à votre place, mais de garder visible l'espace entier des plannings valides, en temps réel, pendant que vous décidez une case à la fois. Le planning est le sous-produit ; la visibilité est le produit.

Ce que cela change pour votre équipe

Pour le responsable, le changement est concret. Le « je vous recontacte » disparaît. Le doute aussi — « est-ce que je viens de casser le mercredi ? » — parce que la grille le lui a dit dès le clic. Les erreurs qui n'apparaissaient qu'une semaine après le début du planning apparaissent désormais au clic. Les négociations qui exigeaient autrefois le tableur du planificateur (« attendez, je regarde si ça passe ») se font en direct, avec le membre du personnel dans la pièce, avec une confiance partagée.

Pour l'équipe, le planning n'est plus un verdict en boîte noire qu'il faut accepter sur parole. C'est une conversation continue entre des personnes et un outil transparent sur le pourquoi une demande peut ou non être satisfaite. Cela change la texture de la semaine de travail.

Pour ceux qui pilotent le service, le temps de réponse aux questions « et si ? » passe de plusieurs heures à quelques secondes. Le personnel expérimenté cesse d'être le goulot d'étranglement de chaque changement mineur. Le planning devient quelque chose que l'unité peut faire évoluer tout au long de la semaine, et non un artefact fragile qu'il faut régénérer de bout en bout au moindre mouvement.

Et parce que le moteur est exact, ce qui s'affiche sur la grille est ce qui tiendra. Aucune infaisabilité surprise au moment de la transmission. Aucun planning fantôme qui semble correct jusqu'à ce que le validateur de second passage s'exécute.

Construit autour de vos règles

Chaque hôpital, chaque unité, chaque clinique a sa propre version des « règles ». Ratios obligatoires. Combinaisons de compétences. Temps de repos exigés. Accords locaux. Variations saisonnières de la demande. Des rôles que personne, hors de vos murs, ne reconnaîtrait. Nous avons conçu Reasoning Layer pour accepter ces règles au niveau où vous les pensez réellement, et non au niveau où un schéma de base de données les pense.

Si votre problème de planification a une forme un peu différente de celui de l'hôpital voisin — et c'est toujours le cas — nous voulons en entendre parler. Le chemin le plus rapide vers un outil adapté à votre équipe, c'est d'engager la conversation avec nous sur ce qui rend votre planning difficile. Nous apportons le moteur ; vous apportez les règles ; ensemble, nous vous montrerons le planning que vous cherchiez à atteindre depuis le début.

Au-delà du planning

Une fois que vous avez vu la grille se recolorer pour des infirmières, vous repérez la même forme partout ailleurs. Un centre d'appels qui associe des agents à des créneaux horaires et à des files de compétences. Une équipe logistique qui affecte des véhicules à des tournées sous contraintes de capacité. Un service de radiologie qui répartit les blocs de garde entre sous-spécialités. Une unité d'essais cliniques qui place des patients dans des sites sous contraintes d'éligibilité. En dessous, c'est le même problème : une capacité qui rencontre une demande, avec des règles.

Reasoning Layer est le moteur pour chacun de ces cas — pas seulement les plannings. Le planning est la démonstration que nous avons choisie parce qu'elle rend la valeur visible d'un coup d'œil, mais la même mécanique répond au même type de question partout où on la pose à votre équipe.

Essayez

Vous n'avez pas à nous attendre. ▶ Manipulez la grille en direct dès maintenant — épinglez des infirmières, regardez les cases se verrouiller ou se griser, et ressentez le recalcul à chaque clic.

Quand vous serez prêt à le confronter à votre planning — vos rôles, vos ratios, vos règles locales — 👉 demandez une démonstration. Quinze minutes, vos chiffres, vos règles.

La planification en temps réel ne devrait pas tenir de la magie. Elle devrait simplement être la réponse, quand vous la demandez.