Il y a encore un an, quand je pensais un nouvel outil, une bonne partie de mon énergie partait dans “comment on va coder ça”. Aujourd’hui, cette question a presque disparu de mon quotidien.

Je peux me concentrer presque entièrement sur ce que j’attends du produit : le comportement voulu, les cas limites, les contraintes métier. La question de l’implémentation ne monopolise plus mon attention — d’ingénieur qui code, je suis en train de devenir architecte de ce que je fais construire.

Mais ça ne veut pas dire moins de travail, ça veut dire un travail différent. Une bonne partie du temps gagné sur le dev part directement dans la qualification : vérifier que le livrable répond réellement à la demande, qu’il respecte les contraintes de sécurité, les chartes internes, les standards de l’équipe. Cette phase-là ne se délègue pas, et elle prend du temps.

Et en entreprise, un outil ne peut pas s’arrêter à un MVP. Il doit rester maintenable et exploitable dans la durée. Ça ne veut pas dire relire chaque ligne de code, mais ça veut dire garder une vision claire des choix d’implémentation et de la logique globale. Sans ça, on construit une dette qu’on découvre six mois plus tard.

Ce que ça change concrètement, sur deux fronts à la fois :

  • Sur le neuf : je peux tester la viabilité technique d’une idée en quelques heures plutôt qu’en plusieurs jours, et passer du concept à un premier livrable exploitable très vite.
  • Sur l’existant : je peux enfin m’attaquer à ce qui traînait dans le backlog depuis des mois — les refontes d’outils devenus obsolètes, jamais assez prioritaires pour qu’on y consacre du temps.

Les deux comptent autant l’un que l’autre. Mais s’il y a un terrain où je vois un gain qu’on ne mesurait pas avant, c’est celui de la dette technique : ce n’est plus seulement “on ira plus vite sur le prochain projet”, c’est “on peut enfin traiter ce qu’on n’avait jamais le temps de traiter”.