Idée principale

La lisibilité d'un dépôt — nommage cohérent, structure explicite, commentaires utiles, historique de merge requests exploitable — a longtemps été défendue par un seul argument : elle réduit le coût d'intervention des développeurs. C'est un argument interne à l'équipe technique, et il perd tous les arbitrages où il entre en concurrence avec une date de livraison.

Dès que le dépôt sert à reconstruire une documentation de support, un changelog ou une spécification, sa lisibilité conditionne la qualité de ces sorties. Un code obscur ne produit pas une documentation obscure : il produit une documentation fausse, plausible et non détectable, puisque personne ne relira la source pour la vérifier.

La propreté du code devient alors une variable produit. Elle n'est plus un confort d'équipe négociable contre du délai, elle est la condition d'existence d'une famille d'artefacts destinés au client.

Couche apportée par « Quatre jours de vibe coding… » (2026-07-28). Un second usage du dépôt produit le même déplacement, et il est plus exigeant : quand la codebase devient le terrain sur lequel un profil non développeur construit avec un assistant, sa lisibilité décide de ce qui y est faisable. Sur une base dont les API internes sont documentées, les concepts métier lisibles et les composants stables, un Product Manager compose un module ou un parcours avec des briques existantes. Sur une base mal cadrée, la même personne et le même assistant ne peuvent produire qu'un objet séparé, branché de l'extérieur — le bricolage n'est pas alors un défaut de méthode, c'est le seul régime que le terrain autorise.

Pourquoi c'est important

Cela donne à un Product Manager une raison, formulée dans ses termes, de défendre un investissement de refactoring — jusqu'ici défendu uniquement par les développeurs, et donc entendu comme une préférence d'artisan.

Cela pose aussi une condition d'entrée honnête : l'approche qui consiste à régénérer les artefacts depuis le dépôt n'est pas disponible partout. Sur une base illisible, elle ne dégrade pas le résultat, elle le rend trompeur.

Nuances et limites

« Propre » n'a pas de définition opposable. Un dépôt peut être parfaitement structuré pour un développeur et rester muet sur le vocabulaire métier, qui est précisément ce dont une documentation de support a besoin.

Et l'exigence peut se retourner : faire du dépôt un support de génération risque d'y faire écrire des commentaires destinés à la machine plutôt qu'au mainteneur.

Questions ouvertes

• À quoi reconnaît-on, avant d'essayer, qu'une base de code est assez lisible pour qu'on puisse en régénérer des artefacts produit ?