Mon amie Priya gère les plannings d'un service médical de 34 lits et passe deux ans à gérer les demandes d'échange de garde via un SMS de groupe que personne ne lit dans l'ordre. Elle voulait un outil que les infirmières puissent ouvrir sur leur téléphone pendant une pause, y publier une garde à couvrir, et voir quelqu'un la réclamer avant que l'infirmière-chef ne doive réorganiser le tableau manuellement. Je l'ai construit en trois semaines de soirées. Voici le journal du jour où c'est réellement passé en production — publication, domaine personnalisé, vraies infirmières, vraies gardes — car l'écart entre « ça marche en test » et « ça marche à 7h du matin quand le service manque de deux personnes » s'est révélé être une leçon en soi.
6h58 — publication
J'avais configuré la destination de déploiement sur le domaine personnel de Priya la veille au soir, donc cette étape a été sans surprise : cliquer sur publier, regarder le journal de vérification du build passer ses contrôles :
- Les routes se résolvent
- Le point d'accès de réclamation de garde renvoie une vraie réponse au lieu d'un stub
- Le hook de notification SMS effectivement configuré au lieu d'être en mode test
Tout est au vert. J'ai envoyé le lien à Priya par SMS à 6h58, car je savais qu'elle arriverait juste à ce moment-là pour sa garde et je voulais qu'elle le voie en ligne avant le début de sa journée, pas après.
7h15 — la première vraie utilisatrice fait quelque chose que je n'avais pas testé
Priya a publié une garde ouverte pour le soir même en vingt minutes, ce qui était plus rapide que prévu et signifiait que je n'avais pas fini mon café avant l'apparition de la première vraie donnée. Puis une infirmière nommée Denise l'a réclamée, l'a annulée quatre minutes plus tard, puis l'a reréclamée. Je n'en ai aucune idée — peut-être a-t-elle vérifié son propre agenda en cours de réclamation et réalisé qu'elle avait un rendez-vous chez le dentiste. L'application a bien géré la situation. Ce que je n'avais pas testé, c'était trois personnes essayant de réclamer la même garde dans la même fenêtre de dix secondes, car en trois semaines de tests en solo, ce scénario ne m'était jamais venu à l'esprit. Il ne m'est pas venu à l'esprit non plus cette fois-là. C'est la réalité qui s'en est chargée environ cinq heures plus tard.
9h40 — le calme, et j'en deviens nerveux
Rien ne s'est passé pendant deux heures et demie. Aucune réclamation, aucune publication, aucune erreur dans les journaux. J'ai quand même vérifié le tableau de bord quatre fois, une habitude que je devrais probablement corriger — un build qui n'est pas utilisé n'est pas cassé, il n'est simplement pas encore utilisé, et ce sont deux problèmes différents avec des solutions différentes. Je me suis forcé à fermer l'onglet et à faire un vrai travail.
11h52 — le bug
Le point d'accès de réclamation a accepté les trois, car j'avais écrit la logique « marquer comme réclamé » comme une simple vérification de mise à jour si ouvert, sans verrou, et dans des tests normaux à un seul utilisateur, cette situation de compétition n'a tout simplement jamais l'occasion de se produire. Avec trois appuis simultanés depuis trois téléphones différents, elle en a largement l'occasion. Les trois infirmières ont reçu un SMS de confirmation indiquant qu'elles avaient couvert la garde. Denise en faisait partie, pour la deuxième fois de la journée, et cette fois elle était agacée.
Je tiens à être honnête sur la façon dont j'ai découvert cela — je ne l'ai pas repéré grâce à la surveillance. Priya me l'a signalé par SMS, emoji rieur inclus, même si je ne pense pas qu'elle le trouvait vraiment drôle, car c'était en fait un problème pour son après-midi :
l'appli dit que 3 personnes ont eu la même garde mdr
12h10 — dans le chat du build
J'ai décrit le bug en termes simples : plusieurs personnes peuvent réclamer une même garde si elles cliquent à peu près au même moment, et une seule réclamation devrait tenir. Je n'ai pas essayé d'écrire d'abord la solution moi-même, en partie parce que j'étais sur mon téléphone dans un parking et en partie parce que décrire précisément l'échec est généralement plus rapide que de le diagnostiquer précisément. L'agent l'a retracé jusqu'à l'absence de verrouillage de ligne sur la table de réclamation, et a proposé de passer à une mise à jour conditionnelle atomique — la réclamation ne réussit que si le statut de la garde est encore « ouverte », et c'est l'opération elle-même qui décide qui l'emporte, au lieu d'une vérification-puis-écriture qui permet à trois requêtes de voir « ouverte » en même temps. C'est le vrai bug en une phrase, et c'est le genre de chose évidente une fois qu'on la formule, et invisible tant que rien ne la force à apparaître.
12h34 — le correctif part, et je fais attendre Priya
Le correctif était petit. Je ne l'ai quand même pas poussé directement sur le domaine en production pendant une garde active — je l'ai d'abord exécuté sur une version de prévisualisation et j'ai demandé à une collègue infirmière-chef de Priya, qui n'était pas de garde, de réessayer les trois clics simultanés depuis trois onglets de navigateur. Ça a tenu. Une réclamation est passée, deux ont reçu un message « cette garde vient d'être réclamée par quelqu'un d'autre » au lieu d'une fausse confirmation. Je l'ai mis en ligne à 12h34, environ quarante-deux minutes après l'apparition du bug, ce qui semblait lent sur le moment et rapide avec le recul.
14h00 à 18h00 — la partie ennuyeuse et positive
- 11 gardes supplémentaires publiées
- 9 réclamées sans incident
- 2 expirées sans être réclamées et reversées au tableau que Priya gère encore manuellement — ce qui est très bien, l'outil n'a pas besoin de tout résoudre dès le premier jour, il doit résoudre le problème précis qui était cassé
- 0 réclamation en double supplémentaire
J'ai observé les chiffres au lieu d'imaginer des scénarios, ce qui est une activité différente et bien plus apaisante.
Ce que je ferais différemment
Deux choses.
- J'aurais décrit le scénario de réclamation simultanée dans la demande de build initiale au lieu de le découvrir en direct — « plusieurs utilisateurs, même action, même instant » est une simple phrase, pas une demande compliquée, et je n'ai tout simplement pas pensé à l'inclure car mes propres tests sont par nature séquentiels ; je ne clique jamais que sur un seul bouton à la fois.
- J'ai trop investi dans le libellé de la notification SMS pendant la deuxième semaine — trois réécritures distinctes d'un texte de confirmation dont personne ne s'était plaint — et pas assez dans exactement le genre de cas limite de concurrence qu'un service rempli d'infirmières en pause, toutes les yeux rivés sur leur téléphone au même moment, allait forcément rencontrer dès le premier jour.
Au prochain lancement, je passerai moins de temps à peaufiner un texte que personne ne critiquera et plus de temps à me demander « que se passe-t-il si cinq personnes font ça en même temps », car pour tout ce qui a plus d'un vrai utilisateur, tôt ou tard, quelqu'un le fera.
