Notes de cas (anonymisées)

Les mêmes leçons, sans noms, sans adresses. Chaque note est une vraie forme de problème, débarrassée de tout ce qui pourrait remonter à un produit en ligne. Ce qui compte, c'est le motif, pas l'adresse.

Un SaaS grand public. Un produit où les utilisateurs envoient des événements et reçoivent en retour des actions automatisées. Les leçons les plus tranchantes portaient sur l'argent et le rejeu : stocker l'argent en centimes entiers, et garder chaque événement entrant d'un tiers derrière une contrainte d'unicité pour qu'un webhook rejoué ne double jamais un effet (Partie 7). Et sur l'écran d'accueil : la plus grande victoire produit a été de retirer une fonctionnalité, pas d'en ajouter une, parce que ce dont les utilisateurs avaient réellement besoin était « qu'est-ce que je fais maintenant », pas « voici vos données » (Loi 3 sur les chemins rejetés, et le goût qui reste humain, Partie 11).

Un outil interne. Un back-office utilisé par une petite équipe d'opérations. Les leçons portaient sur la vérité des données et le changement de masse : un objet dont le nom ne correspondait pas au sens faisait rejeter à une relation la plupart de ses lignes, jusqu'à ce qu'on la corrige par l'usage plutôt que par le nom (Loi 7), et chaque changement de données en masse était prouvé par un invariant et un delta en production, jamais par une relecture (Loi 6).

Une application client. Un produit construit pour quelqu'un d'autre, où la documentation et la vérification pesaient le plus lourd. Les deux leçons les plus coûteuses : une vérification écrite mais jamais réellement exécutée, qui a laissé des fichiers exposés pendant des mois en silence (Loi 4), et la discipline d'écrire chaque décision avec ses alternatives rejetées pour que le même débat ne se rouvre pas des mois plus tard avec quelqu'un qui n'était pas là (Loi 3).