Chaque étude retrace un franchissement : le défi, le passage, le résultat. Pour la liste complète des réalisations, voyez tous nos travaux.
Dans les quatre cas, un système existait déjà et tenait par la volonté de quelqu'un : des tableurs recopiés à la main après chaque rendez-vous, des terminaux ouverts en série et des scripts éparpillés, un groupe de discussion où « on fait quoi ce soir ? » se noyait. Le travail ne commence donc jamais par une idée neuve, mais par la lecture honnête de ce qui tient encore et de ce qui a déjà lâché.
Ce qui donne sa forme à un produit n'est pas la liste de ce qu'il fait, c'est la chose qu'il s'interdit. Ne jamais montrer à l'apprenant un mot qu'il n'a pas encore vu. Ne jamais installer le moindre process sur les serveurs surveillés. Ne jamais classer un lieu selon un budget publicitaire. Ne jamais faire saisir deux fois le même chiffre. Ces refus coûtent des fonctionnalités, et ce sont eux qu'on défend en réunion.
Une démo se juge sur ce qu'elle montre, un produit sur ce qu'il fait tout seul. Un moteur de répétition espacée qui décide quoi réviser et quand. Une surveillance planifiée qui réveille quelqu'un quand un serveur cesse de répondre. Un calcul partagé qui met le reste à vivre à jour des deux côtés en même temps. C'est cette part invisible qui distingue un produit livré d'un prototype abandonné.
Un produit ne remplace jamais rien du jour au lendemain : il faut reprendre les données existantes, former ceux qui vont s'en servir, et basculer sans interrompre l'activité en cours. C'est la partie la moins spectaculaire d'un projet, celle qu'aucune maquette ne montre, et la première qui fait échouer une mise en service quand elle est traitée à la fin.