De la release trimestrielle au salaire quotidien
Le salaire quotidien
Imaginez que votre salaire tombe chaque jour, et non en fin de mois. À montant égal, chaque euro commence à travailler des semaines plus tôt. Vous réinvestissez plus vite, vous lissez vos achats, vous saisissez une opportunité sans attendre le virement.
Sur une vie entière, ce simple décalage de cadence change le résultat, grâce aux intérêts composés et non à un effort supplémentaire.
Livrer un logiciel par petits incréments, c’est exactement ça. Ce n’est pas plus de valeur qu’on produit : c’est la même valeur qui se met à capitaliser plus tôt et plus souvent.
Deux raisons, et la seconde est la plus importante
1. La valeur non captée ne revient jamais.
Prenons une fonctionnalité qui rapporte 10 k€ par mois. Deux équipes la construisent à l’identique, en trois mois de travail.
L’équipe A livre tout en avril. L’équipe B découpe et livre un tiers utile dès février.
L’équipe B encaisse février et mars que l’équipe A a laissés passer. Ces 20 k€ ne sont pas « en retard » : ils n’existeront jamais. On ne rattrape pas un mois de valeur, comme on ne rattrape pas un mois d’épargne non versé.
C’est le Cost of Delay : le coût silencieux de ce qu’on ne livre pas encore.
2. Chaque incrément achète de l’information.
Une fonctionnalité, ce n’est pas un livret au taux garanti. C’est une action en bourse : son rendement est inconnu d’avance et ne se révèle qu’une fois la position prise, c’est-à-dire une fois la feature entre les mains d’un utilisateur. Avant ça, sa valeur n’est qu’une hypothèse.
Et personne de sensé ne mise toute son épargne d’un coup sur un seul titre incertain.
On construit sa position progressivement. On en prend un peu, on observe comment ça se comporte, on renforce ce qui marche, on coupe ce qui déçoit.
Imaginez un moteur de recherche prévu sur trois mois : recherche, filtres, autocomplétion, historique. Livré d’un bloc, c’est la mise unique sur un titre que vous ne connaissez pas encore.
Livrez la recherche seule en semaine 1, et les utilisateurs vous diront peut-être qu’ils veulent surtout des filtres, et se moquent de l’autocomplétion sur laquelle vous alliez passer trois semaines.
Le petit incrément n’est pas qu’un versement anticipé. C’est une petite position qui vous renseigne avant de réinvestir. Il transforme une conviction en mesure, et vous laisse corriger le tir tant que ça coûte encore peu.
Livrer tôt rapporte. Livrer souvent vous évite de miser gros sur la mauvaise chose.
Pourquoi sommes-nous payés une fois par mois ?
Pas parce que c’est optimal. Personne ne l’a démontré.
Le mois est un héritage : traiter une paie coûtait cher (bordereaux, banques, administratif). On a donc regroupé les versements. C’est un coût de transaction élevé qui impose un gros lot.
Reinertsen le formule simplement : la taille de lot optimale est dictée par le coût de transaction, pas par une vertu des gros lots.
Le piège : confondre contrainte et loi de la nature
« On release tous les trois mois. » Présenté comme une donnée. C’est un choix, imposé par l’outillage.
En logiciel, le coût de transaction a un nom : friction de déploiement, tests lents, intégration manuelle, validations interminables.
L’intégration continue, c’est précisément ce qui le fait baisser. Industrialiser le « versement » jusqu’à le rendre quasi gratuit : voilà ce qui rend la paie quotidienne possible.
La CI n’est pas qu’une hygiène de qualité. C’est l’infrastructure qui vous paie tous les jours.
Les deux dettes
Pour financer cette cadence, on emprunte. Et il y a deux emprunts très différents.
La dette technique vit dans le code, l’espace de la solution. Une bonne dette est consciente, à taux gérable, avec un plan de remboursement, comme un crédit pour obtenir l’actif maintenant. La mauvaise est usuraire et sans plan : on finit par ne payer que les intérêts (bugs, contournements), sans plus rien pouvoir investir. Le refactoring rembourse le principal.
La dette fonctionnelle vit ailleurs : dans l’écart entre le domaine réel et ce que le produit modélise, l’espace du problème. Langage qui dérive, règles métier absentes, modèle anémique. C’est un passif non provisionné : des engagements pris sans mettre le capital de côté. La plus dangereuse, car elle est stratégique et rarement nommée.
Là où la métaphore s’arrête
L’argent est fongible et mesurable. Pas la valeur, pas la dette logicielle.
Le piège du cadrage financier, c’est la sur-quantification : « nous avons 40 k€ de dette ». Un chiffre rassurant et largement fictif.
Une dette sur du code qu’on ne touchera jamais n’arrive jamais à échéance : tout rembourser serait du gaspillage. Et le « composé » ici est socio-technique, pas mécanique.
La métaphore ne sert pas à mesurer. Elle sert à voir un levier : baissez le coût de transaction, et le bon rythme se rapproche du continu.
Pour aller plus loin : Donald G. Reinertsen, The Principles of Product Development Flow (Celeritas, 2009)