01
La qualité logicielle est une décision business, pas une option technique.
Mon parcours
25 ans dans le code. Et une question qui revenait sans cesse.
01 / L'interrogation
Il y a 25 ans, j'écrivais du code comme tout le monde.
Des fonctions, des classes, des bases de données. Des features qui marchaient. Des sprints qui se terminaient. Des releases qui partaient en prod.
Et quelque part entre les lignes, une question revenait, discrète mais persistante :
Pourquoi est-ce que ça devient aussi difficile à mesure que ça grandit ?
Pas parce que l'équipe était nulle. Pas parce que les choix techniques étaient stupides. Mais parce que personne ne nous avait appris à voir le système dans sa globalité.
On codait. On livrait. On accumulait. Sans le savoir, on construisait notre propre dette.
02 / Le constat
J'ai grandi dans le code. Et j'ai vu ce que ça coûte.
Au fil des années, j'ai occupé tous les rôles : développeur, tech lead, engineering manager, coach technique. J'ai travaillé dans des grandes organisations.
Et à chaque fois, j'ai observé le même pattern :
Des équipes compétentes. Des ambitions réelles. Et un moment où le système commence à peser plus lourd que la valeur qu'il produit.
Un module qu'on n'ose plus toucher. Une fonctionnalité simple qui prend trois fois trop de temps. Des tests qui rassurent en théorie mais pas en pratique.
Ce n'était jamais un problème de personnes.
C'était toujours un problème de système.
C'était toujours un problème de système.
03 / Le tournant
Une équipe qui avait peur de déployer un vendredi.
Quelque part dans une grande banque française. Pas parce qu'ils étaient mauvais. Parce que leur système était devenu une boîte noire.
J'ai passé plusieurs mois avec eux. On n'a pas réécrit tout le code. On a changé la façon dont ils le regardaient, l'organisaient, et en parlaient.
Résultat : les déploiements du vendredi ne leur faisaient plus peur.
Ils comprenaient leur propre système. Ils en étaient à nouveau responsables.
Ils comprenaient leur propre système. Ils en étaient à nouveau responsables.
C'est là que j'ai compris ce que je voulais faire.
04 / La double clé
J'ai compris que la technique seule ne suffisait pas.
Vingt-cinq ans dans le code, et une évidence : les vrais blocages ne sont jamais purement techniques. Ils se jouent au carrefour entre la technologie et la stratégie business.
J'ai décidé d'aller chercher l'autre moitié de la réponse : un MBA Executif à l'Epitech.
Ce diplôme ne m'a pas appris à coder différemment. Il m'a appris à parler le langage du DSI, du DAF, du DG. À quantifier l'impact financier d'une dette technique. À construire une roadmap qui a du sens pour un comité de direction.
Je suis peut-être la seule personne dans la salle qui comprend à la fois le code qui tourne en production — et le P&L qui en dépend.
C'est cette double compétence qui rend mes interventions différentes.
05 / Aujourd'hui
Coach international en Software Craftsmanship.
Mon travail : aider les équipes techniques et les managers IT à reprendre la maîtrise de leurs systèmes. Avec une perspective rare — celle d'un ingénieur de 25 ans d'expérience formé également aux enjeux business et stratégiques.
Pas en imposant une méthode. Pas en vendant une transformation à 18 mois. En travaillant dans le réel : le code, les pratiques, les décisions quotidiennes.