Service & soin

Créer l'outil de planning du service

Un planning partagé en une page web : planning type, onglets par activité, vue mois, synchronisation pour toute l'équipe, publié en ligne. Construit avec Claude, pas à pas.

Claude CodeCoworkGitHub2 à 3 séances, puis une version par mois

Construction du planning en dialogue : conversation, aperçu de la version, compteurs par personne.
Construction du planning en dialogue : conversation, aperçu de la version, compteurs par personne.

Capture d’un outil réel · données fictives, noms floutés

Architecture de l’outil de planning

Figure. Un fichier unique, des onglets par activité, une base partagée, et une chaîne de publication versionnée.

Le problème

Le planning d’un service de cardiologie croise des dizaines d’intervenants (seniors, assistants, docteurs juniors, internes) et des activités très différentes : échographie par box, consultations, épreuves d’effort, IRM, astreintes, staffs, enseignement. Il vit souvent dans un tableur que seule une personne sait modifier, et chaque absence déclenche une chaîne de mails.

La méthode pas à pas

  1. Écrire la spécification avant le code : la liste des intervenants (avec leur catégorie), les activités, les demi-journées, qui peut modifier quoi. Claude la rédige à partir de vos notes et du tableur existant, et liste les ambiguïtés à trancher.
  2. Un planning type, puis des semaines : un onglet « Global » décrit la semaine type de chacun ; les semaines réelles en dérivent et ne modifient jamais le planning type.
  3. Des présences récurrentes par parité de semaine : une présence peut revenir les semaines paires ou impaires seulement, entre une date de début et une date de fin. Les semaines réelles la calculent ; on ne la recopie jamais à la main.
  4. Un onglet par activité : Échographie (par box et par demi-journée), Consultation, Effort, IRM, Astreinte, Staff, Faculté, Absences, et une vue mois qui montre tout le monde. Quand une case est pleine, une ligne « également présents » affiche ceux qui dépassent sa capacité : sans elle, des noms disparaissaient sans prévenir.
  5. Un seul fichier HTML, sans serveur à maintenir : Claude le construit, vous l’ouvrez dans le navigateur pour le tester.
  6. Une base partagée pour que toute l’équipe voie les mêmes données en temps réel, protégée par un mot de passe d’équipe. Le fichier ne doit jamais contenir une copie figée des données : un poste neuf afficherait un état ancien sans prévenir. Un bandeau rouge « non connecté » signale un poste qui ne voit pas les données réelles. Quand deux personnes modifient en même temps, les changements sont fusionnés par identité (qui est affecté), jamais par position dans la liste : sinon l’une efface l’autre.
  7. Appliquer les règles par migrations versionnées : chaque changement de règle (nouvelle présence récurrente, activité renommée) est une migration numérotée, appliquée une seule fois, et seulement après la première synchronisation réussie avec la base. Appliquée trop tôt, elle s’écrirait sur des données vides ou serait écrasée.
  8. Publier en ligne : le fichier vit dans un dépôt GitHub. Chaque changement passe par une branche, puis par une demande de fusion que le responsable fusionne lui-même ; un hébergeur statique publie ensuite automatiquement la branche principale. Deux suites de tests (logique des données, gestes dans le navigateur) passent avant toute fusion.
  9. Versionner : chaque livraison porte un numéro (v38, v39…) visible dans le titre de la page ; l’ancienne version est archivée, jamais écrasée.
  10. En faire une compétence : toutes les règles apprises (bugs, procédure, vérifications) sont compressées dans un skill orchestrateur « planning », pour ne pas les réapprendre à chaque conversation.

Le livrable

Un outil de planning en ligne, partagé, versionné, et un skill qui sait le diagnostiquer, le corriger et le livrer.

Garde-fous

  • Le planning en production n’est jamais modifié directement par l’IA : elle prépare une branche et une demande de fusion, vous fusionnez. Rien n’est publié sans accord, et les corrections sont regroupées en une seule version.
  • Aucune donnée patient dans le planning. Les coordonnées des intervenants restent dans l’annuaire, pas dans le fichier publié.
  • Le mot de passe d’équipe ne figure ni dans les conversations partagées ni dans les documents diffusés.
  • Déployé ne veut pas dire testé : aucun lien n’est donné sans avoir été ouvert ; sinon, il porte la mention « non vérifié ».
  • Le planning n’alimente jamais l’agenda personnel : ce sont deux sources séparées.

Prompt de départ

Voici notre tableur de planning et la liste des intervenants. Rédige la spécification d’un outil de planning en une page web : planning type, onglets par activité, vue mois, absences. Liste ce qui est ambigu avant de coder quoi que ce soit.

← Retour au triptyque