Documenter son projet :un ROI x18 en 10 minutes

Documenter son projet, quand on construit seul, ce n'est pas pour les autres : c'est écrire pour votre futur vous, et votre futur vous a tout oublié. Dix minutes de notes lors de la construction d'une fonctionnalité m'auraient évité les trois heures passées plus tard à faire de la rétro-ingénierie sur ma propre base de données. C'est un retour de 18 fois, sur une seule fonctionnalité.

La documentation paraît être l'habitude la plus « entreprise » et la plus facile à sauter pour un solopreneur. C'est l'inverse : c'est l'habitude qui permet à une entreprise d'une personne de se comporter comme une équipe, car la personne qui a écrit le code il y a six mois est, en pratique, quelqu'un d'autre.

Le jour où j'ai oublié le schéma de ma propre base de données

Trois mois plus tôt, j'avais construit une fonctionnalité complexe pour ma plateforme d'accélérateur. Une conception de base de données multi-tables, soigneusement structurée, avec des politiques de sécurité, tout le jeu. Il m'avait fallu six heures pour la concevoir et la mettre en œuvre, et j'en étais fier.

Puis j'ai dû ajouter un seul champ à cette fonctionnalité. J'ai ouvert le code, regardé les tables, commencé à lire, et je n'avais absolument aucune idée de pourquoi j'avais pris certaines décisions. Pourquoi quatre tables de jonction au lieu de deux ? Pourquoi cette colonne est-elle facultative ? Pourquoi cette règle d'accès vérifie-t-elle deux choses au lieu d'une ?

J'ai passé trois heures à faire de la rétro-ingénierie sur mon propre code. Pas celui de quelqu'un d'autre. Le mien. Aucune note sur la fonctionnalité, aucune explication de la conception, rien qui montre comment les pièces étaient reliées. Juste du code, et une mémoire qui avait discrètement tout effacé.

Dans une équipe, les décisions se discutent et le savoir se partage. En solo, il n'existe qu'un seul exemplaire du « pourquoi », dans votre tête, et il expire plus vite que vous ne le pensez. C'est le coût caché du développement en solo, et presque personne ne le chiffre.

Documenter son projet : le calcul du seuil de rentabilité

Dix minutes de documentation lors de la construction de cette fonctionnalité auraient fait gagner trois heures plus tard. Un retour de 18 fois, pour une fonctionnalité. Passons à l'échelle : j'ai 45 fonctionnalités en production. Si documenter d'avance fait gagner environ deux heures par fonctionnalité au fil du temps, cela fait 90 heures par an, soit 7 200 € de mon temps à 80 €/heure, achetés avec dix minutes par fonctionnalité.

Le calcul sur la durée de vie est encore plus déséquilibré. Prenez une fonctionnalité qui subit dix modifications futures :

Environ 18 heures économisées par fonctionnalité sur sa durée de vie. Sur 45 fonctionnalités, cela fait 815 heures, soit 65 200 € de valeur à 80 €/heure. Mais honnêtement, l'argent n'est pas le sujet. Le sujet, c'est ce que la documentation vous permet de faire : refactoriser sans crainte parce que vous savez ce qui va casser, construire sur le travail passé parce que vous vous souvenez de vos propres conceptions, et déboguer en quelques minutes parce que les pièges sont écrits.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Les quatre documents dont chaque fonctionnalité a besoin

Après 45 fonctionnalités, je me suis fixé sur quatre types de documents, par ordre d'importance.

Les docs « Pourquoi » : le contexte métier. Les plus importants et les plus sautés. Quel problème cette fonctionnalité résout-elle, quel impact a-t-elle, et pourquoi avez-vous fait les choix de conception clés ? C'est le document qui empêche votre futur vous d'« optimiser » une décision qui existait pour une raison. En tant qu'architecte de votre produit, vos décisions sont le seul actif qui ne peut pas être régénéré : écrivez-les.

Les docs « Quoi » : comment ça fonctionne. Les tables concernées, la façon dont les données circulent dans la fonctionnalité, ce qui se passe dans quel ordre. C'est le document qui répond à « pourquoi quatre tables de jonction ? » en trente secondes au lieu de trois heures.

Les docs « Comment » : le guide d'utilisation. Comment vous (ou, un jour, une personne du support) faites réellement fonctionner la fonctionnalité : où la configurer, ce que voient les utilisateurs, quelles sont les étapes.

Les docs « Pièges » : les notes de dépannage. Chaque piège qui vous a mordu : le réglage qui a l'air cassé mais est juste lent, les données qui doivent exister avant que quelque chose marche, le correctif de l'erreur que vous reverrez à coup sûr. Chaque entrée évite une future session de débogage.

Rendre la documentation automatique

Voici l'objection honnête : je ne veux pas passer ne serait-ce que dix minutes par fonctionnalité à écrire de la documentation à la main. C'est ennuyeux, et c'est du temps qu'on ne passe pas à construire. Avant l'IA, cette objection l'emportait : la documentation prenait deux à trois heures par fonctionnalité, donc je la sautais.

Avec l'IA, la friction a disparu. Chaque fonctionnalité que je construis part d'un brief structuré, un PRP, qui contient déjà l'objectif, les décisions de conception et les pièges. Quand la fonctionnalité est livrée, l'IA transforme ce brief en documentation en une dizaine de minutes. Complète, cohérente, et elle ne saute jamais de sections par ennui.

Puis une règle maintient l'habitude : si je livre du code sans documentation, je n'ai pas livré. Ma checklist l'impose : fonctionnalité, tests, documentation, les trois ou rien n'est fusionné. Je ne peux pas contourner ma propre règle, et c'est précisément le but.

Le résultat : plus d'un millier de pages de documentation consultable, écrites en grande partie par l'IA, couvrant chaque fonctionnalité du produit. Zéro moment du genre « à quoi je pensais ? » depuis. Et quand j'embaucherai mon premier ingénieur, il héritera de tout dès le premier jour : deux semaines d'avance sur l'intégration que la plupart des entreprises construites en solo n'ont tout simplement pas.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Questions fréquentes

Pourquoi documenter un projet sur lequel je suis seul à travailler ?

Parce que dans six mois, vous êtes, à toutes fins pratiques, quelqu'un d'autre. J'ai passé trois heures à faire de la rétro-ingénierie sur ma propre base de données parce que je n'avais rien documenté. La documentation en solo n'est pas de la bureaucratie : c'est un message de vous aujourd'hui à votre futur vous, et votre futur vous le lit toujours avec gratitude.

Que dois-je documenter exactement ?

Quatre choses par fonctionnalité : pourquoi elle existe et pourquoi vous avez pris les décisions clés ; ce qu'elle fait techniquement ; comment l'utiliser ; et les pièges qui vous ont mordu. Si vous n'en écrivez qu'un, écrivez le pourquoi : c'est la seule partie que le code lui-même ne pourra jamais vous dire.

Combien de temps prend la documentation avec l'IA ?

Environ dix minutes par fonctionnalité. Si vous construisez à partir d'un brief structuré, l'IA génère la documentation à partir de matière qui existe déjà : c'est une conversion, pas un projet d'écriture. L'ancien coût était de deux à trois heures par fonctionnalité, ce qui explique que personne ne le faisait.

Quel est le ROI de la documentation pour un fondateur solo ?

Mes chiffres : dix minutes de documentation contre trois heures pour se remettre dedans, c'est 18 fois sur une seule modification. Sur la durée de vie d'une fonctionnalité, cela fait environ 18 heures économisées ; sur mes 45 fonctionnalités, environ 815 heures, soit 65 200 € à 80 €/heure. Plus la part qu'on ne peut pas chiffrer : la confiance de modifier son propre code sans crainte.