Le journal, et la phrase qui le tient ensemble
En juillet 2026, j'ai commencé à tenir un journal de dev — une base de connaissances personnelle, un dossier par projet, chacun avec une chronologie, un relevé de décisions, une liste courante de problèmes, et un ensemble de notes sur des techniques précises. Ce site web est généré à partir de lui. Pas copié depuis lui — généré, avec un script, pour que le site et la source ne puissent pas diverger.
Pourquoi il existe est la thèse de tout ce qui est ici.
Travailler seul est différent, et pas juste en charge de travail
Être le seul développeur sur un projet est un métier vraiment différent d'être un développeur dans une équipe. Ce n'est pas surtout une affaire d'heures. C'est qu'il n'y a pas de second relecteur pour attraper une mauvaise décision avant qu'elle ne soit livrée, et aucun autre modèle mental du système contre lequel recouper tes hypothèses.
Cette absence est ce qui a transformé des choses que je traitais comme des « bonus » en infrastructure porteuse. Le monitoring d'erreurs automatisé. Les contrôles de dérive de schéma en CI. Des tests de non-régression ciblés pour les bugs que j'avais déjà rencontrés une fois. Un registre de vérification. Ce ne sont pas de la finition — ils font une partie du travail qu'un second développeur ferait autrement rien qu'en remarquant les choses au passage. Quand il n'y a personne pour remarquer, il faut construire le fait de remarquer.
Le registre de vérification
La pratique centrale est simple.
Chaque flux visible par l'utilisateur dans un projet est une ligne dans un tableau. Chaque ligne a un statut. Un flux n'est marqué vérifié que quand il a été parcouru de bout en bout, par moi, en tant que rôle utilisateur réel pour lequel ce flux existe, dans l'application réellement en fonctionnement — avec la chose précise que j'ai cliquée et la chose précise qui est apparue à l'écran, écrites en regard d'une date. Compiler ne compte pas. Des tests qui passent ne comptent pas. « J'ai lu le code et il a l'air correct » ne compte absolument pas — c'était mon ancienne barre, et la première fois que je l'ai remplacée par celle-ci, une seule passe a révélé plus de onze vrais bugs dans une tranche sur laquelle j'aurais parié de l'argent.
Il y a une règle de rétrogradation automatique : touche un bout de code partagé et chaque flux qui en dépend retombe à non vérifié, parce qu'un correctif dans un endroit partagé a le don de casser discrètement quelque chose d'adjacent. Et le registre est explicitement la source unique de vérité de ce qui marche — pas la base de code, pas la suite de tests, pas ce qui « devrait » marcher parce que le code existe.
Deux constats auxquels je reviens sans cesse :
« Pas encore re-testé » et « n'a jamais été construit au-delà de l'API » sont des statuts complètement différents, et les fusionner cache un trou produit derrière ce qui ressemble à du backlog. J'ai trouvé une fonctionnalité posée dans un registre comme « la preuve antérieure tient, pas re-testée cette passe » — un CRUD back-end complet, un client entièrement typé — et je suis allé chercher le bouton à cliquer, et il n'y avait pas de bouton. Nulle part. Ça n'avait jamais été construit au-delà de la couche API. « Le code a l'air fini » ne te dira jamais ça. Aller chercher le bouton, oui.
Accepter une conséquence et la mesurer sont des actions différentes, et une seule des deux change quelque chose. La classe d'erreur la plus coûteuse que j'aie faite n'était pas une mauvaise décision. C'était une décision dont la conséquence a été correctement identifiée, écrite, et formellement acceptée — puis jamais énumérée. « Certains anciens enregistrements cesseront de résoudre » et « ces quinze entreprises nommées ne peuvent prendre aucune commande à ce jour » sont le même fait à deux résolutions, et seule la seconde fait bouger quelqu'un.
Les notes
À côté du registre, il y a environ quarante-cinq notes — une idée autonome par note. Comment un outbox transactionnel garantit réellement qu'un effet de bord n'est pas silencieusement perdu. Pourquoi le pooling de connexions devient nécessaire et le bug search_path exact qui m'a mordu. Numéros de séquence et relecture d'événements pour un système temps réel qui ne peut pas se permettre un trou silencieux. Pourquoi j'ai choisi un outil plutôt qu'un autre et ce que ça a coûté.
Elles sont écrites pour être utiles à quelqu'un d'autre, pas comme un florilège, ce qui veut dire qu'un bon nombre d'entre elles portent sur des erreurs. C'est volontaire. La section notes est ce que j'ai de plus proche d'un corpus de travail, et je préfère qu'elle soit honnête plutôt qu'impressionnante.
La phrase
Si je ne pouvais garder qu'une ligne de tout le journal, c'est celle-ci :
Rien n'est fait tant qu'on ne l'a pas vu fonctionner.
Tout le reste — le registre, les notes, le « teste en tant que chaque rôle réel », le « lis le corps de la réponse, pas le code de statut », le « une migration qui rapporte 27 lignes écrites est une preuve sur la migration, pas sur la fonctionnalité » — tout ça n'est que cette phrase, appliquée.
Et en dessous de ça, il y a la boîte à rythmes. La première chose que j'aie construite existait parce qu'un outil que je voulais n'existait pas et ne me satisfaisait pas, et j'en ai construit une mauvaise version plutôt que d'attendre d'être qualifié. La chose la plus récente que j'aie construite est un démon pair-à-pair en Rust avec des invariants cryptographiques, et elle existe pour la même raison.
Les outils sont devenus bien plus durs. La raison n'a jamais changé. C'est ça, l'histoire.
Ce site est un document vivant ; il change à mesure que je change. Si quelque chose ici est périmé, c'est que je n'y suis pas encore arrivé.