Tu ne sais plus ce que ton code te coûte. On le mesure.

Ce que je regarde

Je lis le dépôt, l’historique, la chaîne de déploiement et les factures. Pas une revue de code ligne par ligne : ce qui m’intéresse, c’est ce qui décide du coût de ta prochaine évolution. L’état des migrations et leur correspondance avec la base réelle. Ce qui garde les routes d’administration. Ce qui se passe quand une dépendance sort une faille et qu’il faut mettre à jour sans rien casser. Le délai entre une demande et sa mise en ligne. Et la seule question qui tranche vraiment : est-ce qu’une sauvegarde a déjà été restaurée.

Ce que tu reçois

Un document, pas une conversation. Les risques classés par ce qu’ils peuvent te coûter, le temps que la dette te prend chaque semaine, et un plan de remédiation ordonné par ratio gain sur coût — de quoi savoir quoi faire lundi matin, et quoi ne pas faire. Puis 90 minutes pour le parcourir ensemble et répondre à ce que tu veux creuser.

Ce que je ne fais pas

Je ne te dis pas que tout est à refaire. C’est la réponse la plus fréquente d’un développeur qui arrive sur un code qu’il n’a pas écrit, et c’est la plus chère. Sur GoPronos, un prototype Lovable a été sorti de son générateur en quarante commits, sans réécriture. Ailleurs, j’ai engagé une migration puis j’ai renoncé en cours de route parce que le calcul ne tenait plus. Le critère n’est pas la qualité du code, c’est le coût de ce que tu veux construire ensuite.

Je ne rends pas non plus un audit qui ménage tout le monde. S’il y a un problème qui peut te coûter une journée de production, il est en première page.