Deux commits en 2025.
Quatorze mois de silence.
Puis un démarrage en trombe.
Ce que raconte cet historique, ce n'est pas que je suis devenu plus rapide. C'est que deux freins ont sauté.
Surtout avec un détail qui compte : je n'avais jamais utilisé Rust en production avant ce projet.

Premier frein : le modèle mental nécessaire

Pour écrire une ligne utile dans une application événementielle, il faut d'abord charger le système en mémoire. Où en est le modèle, quels événements existent déjà, quelle décision a été prise trois semaines plus tôt et pourquoi.

Ce chargement est coûteux cognitivement parlant. Quand on a deux soirées par semaine pour avancer, la soirée où l'on aurait pu coder peut souvent être passée à relire son propre code pour comprendre ce que le soi de février avait voulu faire.

Rien que l'idée de charger ce modèle mental, est coûteuse, quand on a déjà une journée de boulot dans les pattes.

Ce frein-là est tombé le jour où le contexte a cessé de devoir tenir dans ma tête. Il pouvait être écrit quelque part et rechargé ailleurs.

Second frein : le langage

En 2025, j'apprenais Rust. Seul, le soir, sur un projet réel.

On dit que la courbe d'apprentissage du Rust est raide.
C'est en dessous de la vérité.
Ceux qui sont passés par là savent : le compilateur refuse, on ne comprend pas pourquoi, on cherche, on trouve, on recommence. Chaque séance paie une taxe avant de produire quoi que ce soit.

Une courbe d'apprentissage, ce sont deux choses empilées. La syntaxe et les idiomes d'un côté. Les concepts de l'autre, et pour Rust ce sont l'ownership, les durées de vie, le raisonnement du borrow checker.

L'assistant agentique fait s'effondrer la première. Il ne remplace pas la seconde, mais l'expérience aide grandement : les concepts se transfèrent, on reconnaît les motifs, on sait quelles questions poser.

Résultat : j'ai livré en production dans un langage que je n'avais jamais mis en production.

Et là, c'est incroyable

Je pèse le mot.

Ce qui se débride, ce n'est pas la vitesse de frappe. C'est l'étape créative. Celle où l'on conçoit, où l'on essaie une modélisation, où l'on jette et où l'on recommence. Celle qui, avant, était étouffée sous le coût de l'exécution.

L'écart entre « j'ai une idée d'architecture » et « je peux la voir tourner » s'est effondré. Pour quelqu'un qui aime concevoir des systèmes, c'est la meilleure chose qui soit arrivée au métier depuis longtemps.

Sauf que...

Le paradoxe de Jevons.

Il paraît que lorsque l'efficacité d'usage d'une ressource augmente, la consommation augmente au lieu de baisser. Le charbon au XIXᵉ, les autoroutes qui créent le trafic qu'elles devaient absorber etc...

Notre ressource ici, c'est le cerveau du PM, utilisé comme usine a fonctionnalité. Que peut-il bien se passer, si le dev peut multiplier les fonctionnalités, comme un barbu le faisait avec les petits pains ?

Ce que le coût du développement faisait vraiment

Le coût du développement n'était pas seulement un coût. C'était aussi un filtre.

Les mauvaises idées mouraient parce qu'elles étaient trop chères. Rappelez vous :

« le client Y ne signe que si cette fonction existe », Michel, Commercial.
« si la plateforme ne fait pas ça, c'est même pas la peine » Simone PM.

Très bien, on va chiffrer.
Et le chiffrage tuait la moitié des demandes sans que personne n'ait à trancher, car finalement le business vivait très bien sans ces fonctions "absolument essentielles".

Ce filtre était grossier, arbitraire, souvent injuste. Il a tué de bonnes idées.

Mais il en a tué beaucoup de mauvaises. Et il le faisait sans que personne ait à assumer le refus.

Ce filtre vient de disparaître.

Le phénomène Monsieur Plus

J'ai vu plusieurs projets mourir de ça, et jamais d'un coup.

Ça ne se passe jamais comme une décision. Personne ne dit « faisons un logiciel trop gros ». On ajoute une fonction, puis une autre, chacune défendable prise isolément. Puis un jour le produit fait quarante choses et n'en fait aucune bien. Les nouveaux utilisateurs ne comprennent plus par où commencer. Chaque évolution touche cinq fonctionnalités qui s'ignorent. Et l'équipe passe son temps à maintenir des fonctions que personne n'utilise.

C'est le gloubiboulga métier. Un empilement où plus rien ne se distingue.

Maintenant, remettez ce mécanisme dans un monde où ajouter une fonction ne coûte presque plus rien.

Il n'y a plus de chiffrage pour dire non à Michel. Il n'y a plus de « trois semaines de dev » pour arbitrer la demande de Simone. Il reste juste quelqu'un qui doit dire non, sans aucun argument économique pour se couvrir.

Combien de personnes savent faire ça ?

Et moi je fais quoi, exactement

Et dire non a un truc gratuit, c'est vachement dur.

Kreek est en principe protégé de ce travers. C'est la refonte d'une application qui tourne depuis dix ans. Je sais ce qui manque, je sais ce qui sert, j'ai dix ans d'usage réel pour trancher. Le périmètre est censé être connu d'avance.

Et pourtant.

J'ai construit un calendrier d'administration de compétition. On y programme les journées de ligue, on bascule entre date fixe et plage de dates, il y a du scroll infini, une sidebar, une vue détaillée par journée. Dix routes d'actions. Sept documents de spécification. Quatre cartes de kanban. Des tests de bout en bout. Et ses propres bugs, comme les journées de match dupliquées à chaque chargement.

Rien de tout ça n'était obligatoirement nécéssaire. C'est du confort.

Le pire, c'est la suite. Dans mon kanban, une carte attend son tour : implémenter les notifications par email. Parce qu'évidemment, une fois qu'on a un calendrier, il faut bien envoyer des rappels avant les journées de ligue.

Le gadget a engendré son gadget suivant. C'est écrit noir sur blanc dans mon propre outil de suivi.

Et à aucun moment je ne me suis dit « je fais une bêtise ». Je me suis dit « tant qu'on y est ».

Le « tant qu'on y est »

C'est une phrase inoffensive. C'est même une phrase sympathique, celle du type consciencieux qui finit bien le travail.

Elle a tué plus de projets que n'importe quelle erreur d'architecture.

Parce qu'elle ne demande pas d'autorisation. Elle ne passe pas en comité. Elle ne fait l'objet d'aucun arbitrage. Elle s'ajoute pendant qu'on est déjà dans le fichier, pendant que le contexte est chargé, pendant que ça ne coûte presque rien.

Et l'accumulation est dans notre nature. Ce n'est pas un défaut de méthode, c'est un trait humain. Aucune rigueur méthodologique ne le fait disparaître, elle le rend juste plus lent.

Avant, le coût du développement nous protégeait de nous-mêmes.

Maintenant, il faut se protéger tout seul.

La question que je laisse ouverte

Je n'ai pas de réponse propre, et je me méfierais de quelqu'un qui en aurait une.

Le prix ne dit plus non. Donc quelqu'un doit dire non, explicitement, en assumant le refus, sans pouvoir se cacher derrière un chiffrage. Ça demande une autorité que peu de gens ont dans une organisation, et une conviction sur le produit que peu de gens prennent le temps de construire.

Ce que je sais, c'est que le danger a changé de nature. Pendant vingt ans, la question était « comment produire plus avec les moyens qu'on a ». Elle devient « comment ne pas produire ce dont personne n'a besoin ».

C'est une question beaucoup moins excitante.

C'est probablement la seule qui compte maintenant, et j'espère que cela va redonner ces lettres de noblesse a une fonction largement galvaudé par la dérive de l'agilité,
Le product Management.