Service & soin
Livrer, vérifier et publier le planning
Aperçu local, deux suites de tests, double vérification des demi-journées et des noms, puis publication par une branche et une demande de fusion, et contrôle du fonctionnement en ligne.
Capture d’un outil réel · données fictives, noms floutés
Le problème
Une nouvelle version du planning peut effacer des données, casser un onglet ou afficher de vieux noms sur les postes de l’équipe. Et la procédure de publication, faite une fois par mois, s’oublie d’une fois sur l’autre.
La méthode pas à pas
- Repartir de la source en ligne, pas d’une copie locale : l’archiver telle quelle, avec l’état des données du jour.
- Livrer systématiquement quatre choses : un aperçu local à ouvrir tout de suite, les changements sur une branche dédiée (prêts pour une demande de fusion), la source archivée, et les mails éventuels, rédigés dans la conversation.
- Deux suites de tests avant toute publication, toutes deux au vert : une suite sur la logique des données (fusion par identité, présences par parité de semaine, migrations, ligne « également présents »), puis le triple test dans un navigateur piloté :
- aucun script en erreur, tous les modules chargés, avec et sans données réelles ;
- les vues clés : la vue mois montre tous les intervenants, les absences s’affichent ;
- les gestes réels : import d’un mail d’absences, glisser-déposer dans un onglet, affectation d’un joker.
- Double vérification des demi-journées : comparer le planning type et chaque onglet d’activité, et lister les écarts (quelqu’un prévu en échographie dans le planning type mais absent de l’onglet échographie). Rien n’est corrigé sans accord.
- Double vérification des noms avec l’annuaire : orthographe, identifiants, doublons, personnes introuvables signalées comme telles.
- Regrouper et demander l’accord : rien n’est publié sans votre accord explicite. Les corrections de la séance sont regroupées en une seule version, plutôt qu’une publication par correctif.
- Publier par une branche, puis une demande de fusion : Claude pousse la version sur une branche et ouvre une demande de fusion qui résume les changements, les résultats des deux suites de tests et les écarts. Le responsable relit et fusionne lui-même ; la mise en ligne suit automatiquement. Il n’y a plus de dépôt manuel direct sur la version en ligne.
- Contrôler en ligne, car déployé ne veut pas dire testé : rechargement forcé (Ctrl + F5), numéro de version dans le titre, nouveaux boutons présents, et le geste corrigé refait pour de vrai. Aucun lien n’est transmis sans avoir été ouvert ; sinon, il porte la mention « non vérifié ». Un bandeau « non connecté » se lève avec le mot de passe d’équipe.
- Annoncer : un mail court au secrétariat et à la boîte de l’activité concernée, les autres en copie, rédigé dans la conversation et envoyé par vous.
Le livrable
Une version testée, des écarts listés, une publication contrôlée, et une annonce prête.
Leçons apprises
- Une copie figée des données dans le fichier publié fait réapparaître d’anciens noms sur les postes neufs : la supprimer, et signaler tout poste non connecté.
- Déposer une personne sur une case occupée peut créer un doublon : tester ce geste à chaque version.
- Une procédure de publication doit être écrite pour quelqu’un qui ne l’a jamais faite, avec ce qu’il doit voir à la fin.
- Au-delà de la capacité d’une case, des noms « disparaissaient » : une ligne « également présents » affiche désormais tous ceux qui dépassent.
- Deux personnes qui modifient la même case en même temps : fusionner par identité (qui est affecté), jamais par position dans la liste, sinon l’une efface l’autre.
- Le planning n’alimente jamais l’agenda personnel : ce sont deux sources séparées.
Prompt de départ
Voici le dépôt du planning. Applique la correction demandée sur une branche, fais passer les deux suites de tests, puis livre l’aperçu local, la liste des écarts de demi-journées et de noms, et une demande de fusion prête à relire. Ne publie rien sans mon accord.