La question qu'on n'ose pas poser à voix haute
Il est 22 h 40 un mardi soir, je viens de fermer un ADR — le soixante-quatorzième de ce dispositif, écrit consciencieusement, daté, croisé avec sa migration, son test de contrat et le commit qui l'a déclenché. Et la question monte, comme elle monte toujours à cette heure-là quand on code seul depuis dix heures : pour qui je viens d'écrire ça. Pas de chef tech à convaincre, pas de PR review qui va l'attraper, pas de repreneur hypothétique à rassurer, pas de comité d'archi à briefer le lendemain. Juste le fichier, juste moi, juste le doute.
C'est la question d'un dev solo à 70 jours de pratique sérieuse. Elle a une réponse honnête, et cette réponse n'est ni « ça paiera quand tu vendras » ni « ça paiera quand tu embaucheras ». Ces deux ROIs-là appartiennent à d'autres trajectoires. Le ROI du dev solo qui documente, c'est un ROI qu'il s'achète à lui-même — différé, intangible par moments, mais matériellement chiffrable si on s'oblige à le mesurer en première personne. Voici la mienne, sur 74 ADR et 18 règles de doctrine accumulés en 70 jours, sans aucun observateur extérieur pour valider la grille.
La fausse économie du « je m'en souviens »
Premier piège, celui qui m'a coûté trois semaines avant que je n'en tire la leçon. Le dev solo croit qu'il n'a pas besoin d'écrire ce qu'il a décidé parce qu'il l'a décidé lui-même — sa mémoire vaut bien un ADR. C'est faux à 14 jours, et c'est systématiquement faux à six semaines. Pas parce que la mémoire générale fait défaut, mais parce que la mémoire technique a une forme particulière qui trompe : on se souvient parfaitement qu'on a tranché, on ne se souvient plus pourquoi on a tranché ainsi.
Trois semaines après la session du 5 mai où j'ai écrit l'ADR-0051 (FK ON DELETE SET NULL + CHECK NOT NULL incompatibles, DELETE qui échoue silencieusement), je rouvre la migration concernée pour ajouter une colonne. Je relis le diff, je ne comprends pas pourquoi telle CHECK constraint est formulée comme ça — l'alternative que j'écarte mentalement aujourd'hui me paraît plus simple, et je suis à deux doigts de refactor. Je vais voir l'ADR. La réponse y est, datée, sourcée, en trois lignes. L'alternative simple est exactement celle que j'avais explorée et abandonnée à cause d'un cas limite que j'ai oublié depuis. Sans l'ADR, je l'aurais refait. Probablement deux heures de re-décision, plus l'incident silencieux que mon code allait re-produire dans six mois.
L'ADR n'est pas un livrable d'audit. C'est une note à soi-même qu'on s'envoie en différé. Le bénéficiaire est dans la même chaise, juste à un autre moment du temps.
Le ROI mesurable en première personne
Sur 70 jours, je peux chiffrer trois choses.
Temps de re-décision épargné. Quinze fois environ, je suis retourné consulter un ADR au lieu de retrancher. À chaque fois, vingt à quarante minutes économisées sur le diff cognitif d'une rediscussion silencieuse avec moi-même — celle où on relit le code, on imagine les alternatives, on se demande si on n'avait pas pris la mauvaise option. L'ADR coupe court : la mauvaise option a déjà été examinée, voici pourquoi elle perd, on passe. Vingt minutes × quinze ≈ cinq heures récupérées sur 70 jours. Pas du temps facturable au sens où un consultant le mesurerait — du temps que je n'ai pas passé à douter, et que j'ai passé à livrer.
Cycles fix-rollback évités. Le protocole falsify before fix — formuler une hypothèse causale puis exécuter trois sondes conçues pour la réfuter — m'a évité, sur la même période, sept cycles fix-puis-rollback bien identifiés (les sessions où le terme apparaît explicitement, comptage conservateur). Chacun de ces cycles, c'est cinq à dix minutes de protocole en amont contre trente à quatre-vingt-dix minutes de fix qui ne fixe pas, suivi du rollback et du recommencement. Le ratio se calcule sans optimisme : six à dix-huit fois le temps investi, par incident où le protocole a tenu. Sur un dev solo, ce n'est pas une économie de productivité au sens où on l'entend en équipe — c'est une économie de moral, qui n'est pas refacturable mais qui décide si je code encore à 18 h ou si j'ai déjà arrêté en silence à 16 h sans le dire à personne.
Dérives silencieuses détectées. Le pattern un cas confirmé, grep le pattern complet — chaque fois qu'un bug remonte sur un cas précis, élargir avant de fixer — m'a fait passer plusieurs fois d'un signalement isolé à un audit qui a remonté quatre, seize, parfois cinq cents lignes affectées par la même cause racine. Ce n'est pas l'ADR qui exécute le grep, mais c'est la doctrine qui pose le réflexe et l'ADR qui le code pour que mon moi-de-dans-trois-semaines ne l'oublie pas. La vraie mesure de ROI, ce n'est pas le nombre de cas trouvés, c'est le ratio entre ce que j'aurais vu sans la règle (un cas, le visible) et ce que j'ai vu avec (la classe entière, l'invisible).
Ce que ça ne paie pas
Honnêteté brutale. La discipline ADR ne paie pas la vitesse de prototypage — quand je veux essayer une idée folle un samedi matin, je n'écris pas d'ADR, j'écris du code marqué [spike] qui sera supprimé sous sept jours, et je m'en porte mieux. Elle ne paie pas le doute existentiel — l'ADR confirme que j'ai bien tranché, il ne me dit pas si j'ai bien tranché à propos du bon problème, et c'est une question d'un autre ordre que la doctrine ne touche pas. Elle ne paie pas le marketing, ne paie pas la cohésion d'équipe (je n'ai pas d'équipe), ne paie pas la prospection commerciale.
Le piège que je vois aussi, et que je signale parce qu'il me concerne directement, c'est celui du dev solo qui se met à documenter parce que documenter rassure, et qui finit par documenter au lieu de livrer. La doctrine devient un terrier. À 70 jours, je tiens le ratio — un ADR pour ce qui est décidé et durable, pas pour ce qui est exploré. Mon ratio actuel tourne à 1,7 ADR par session active, et c'est précisément le seuil où je commence à me regarder de travers. Au-dessus de deux par session, je serais probablement en train de me cacher du code derrière la doctrine. C'est un signal d'alerte que personne d'autre ne peut me donner.
Le ROI invisible
Reste l'axe qu'aucun observateur externe ne saurait coder en métrique, et c'est probablement celui qui pèse le plus pour qui pratique le solo.
La confiance dans son propre système. Pouvoir rouvrir un module qu'on n'a pas touché depuis six semaines, lire les trois ADR qui le décrivent, et reprendre la modification sans avoir à tout relire ligne à ligne. Le calme cognitif d'un système qui ne demande pas de re-comprendre, qui te tend ses raisons et te laisse continuer. C'est ce dont un fondateur solo a besoin pour ne pas craquer au mois 4 — pas une métrique de productivité, une métrique de tenue dans le temps. Personne ne me l'a vendu en début de parcours parce que personne ne la vend ; on la découvre rétrospectivement, quand on s'aperçoit qu'on n'a pas paniqué une seule fois ce mois-ci, et qu'on se demande pourquoi.
C'est probablement la seule réponse honnête à la question de 22 h 40. L'ADR ne paiera ni l'embauche, ni le client, ni la valorisation. Il paiera ma capacité à continuer à coder ce système dans trois mois sans le détester. C'est un ROI qu'aucun investisseur ne valorisera, et qui est néanmoins le seul qui me concerne.
Coda
Si tu hésites à écrire le tien parce que tu te dis que personne ne va le lire, écris-le quand même. Le lecteur, c'est toi dans trois semaines. Il en aura besoin. C'est exactement ça, et ce n'est rien d'autre.
Dev solo, 74 ADR en 70 jours, pas d'équipe, pas de PR review. Le bilan honnête — mesuré depuis la seule chaise qui compte : la mienne.
Top comments (0)