Deux clients, une seule place

Provoquez la panne

Un créneau d'atelier avec trois postes de pose, et six clients qui valident au même instant. Choisissez une façon d'écrire le code, puis lisez ce que le serveur a réellement fait. Chaque visiteur reçoit son propre bac à sable, effacé au bout de trois heures, donc rien de ce que vous faites ici ne sort de votre écran.

Ce qui se passe entre la lecture et l'écriture

Réserver une place demande de lire le nombre de places restantes, de le diminuer de un, puis de réécrire le résultat. Tant qu'un seul visiteur est là, ces gestes se suivent sans incident. À deux visiteurs simultanés, le second lit la valeur avant que le premier n'ait écrit la sienne. Il écrase alors une réservation qu'il n'a jamais vue.

Aucune erreur ne s'affiche nulle part. Les deux clients reçoivent une confirmation, le compteur affiche un nombre cohérent, et le journal du serveur reste vide. Le défaut attend le jour de la pose pour se manifester.

La rareté porte ici sur un créneau de pose, pas sur un article de catalogue. Un tee-shirt en quatre tailles et trois coloris se gère très bien avec une référence et un stock par déclinaison, nous l'avons écrit dans vendre du produit sur mesure en ligne. Ce qui casse, c'est la ressource unique disputée au même instant, la dernière place d'une session ou le créneau d'un technicien.

Pourquoi fermer la porte à clé ne suffit pas ici

La deuxième méthode est celle du manuel. Elle pose un verrou pendant l'opération, exactement comme le recommande la documentation. Sur un serveur ordinaire elle fonctionne, le second client attend son tour et le compte est juste. C'est ce qu'écrit un développeur à qui on signale le problème.

Sur un hébergement mutualisé, non. Les fichiers y vivent sur un disque partagé par le réseau, où deux programmes peuvent obtenir la même clé en même temps. Nous l'avons mesuré le 25 juillet 2026 depuis un fichier de ce site. Le code paraît correct et la documentation lui donne raison. Il perd quand même des réservations, sans qu'aucun journal ne le signale. Choisissez la méthode du manuel plus haut et comptez les confirmations.

La troisième méthode ne répare pas le verrou, elle supprime le besoin d'en avoir un. Chaque place devient un jeton portant son propre nom, et réserver revient à prendre ce jeton. Deux clients qui visent le même, un seul l'obtient, parce que le système d'exploitation garantit qu'un nom ne peut être créé qu'une fois. Plus de lecture suivie d'une écriture, donc plus rien à protéger.

Ce que ça change sur un vrai projet

Aucune de ces trois règles ne relève du web. Elles viennent du métier. L'atelier sait combien de postes il a, le gérant sait à partir de quel montant il offre la reprise, le comptable sait comment il arrondit. Le travail du développeur commence après : transcrire ces règles sans les trahir, puis vérifier qu'elles tiennent quand deux personnes cliquent au même instant.

C'est aussi pour cette raison que nous mesurons le comportement de l'hébergement au lieu de nous fier à la documentation. Un verrou qui ne verrouille pas n'apparaît dans aucun journal d'erreur. Il se voit en lançant six requêtes et en comptant. La même exigence traverse nos autres démonstrateurs, de l'analyseur de données structurées à l'optimiseur de tournée, et notre approche du développement sur mesure détaille la méthode.

Une plateforme de réservation, un planning d'interventions. Si votre métier a des ressources uniques et des clients simultanés, le problème est déjà dans votre code. Il attend deux demandes tombées dans la même milliseconde, ce qui devient d'autant plus fréquent que le trafic monte.