À propos
Je dirige des transformations technologiques et j’aide des organisations à construire et à livrer de meilleurs logiciels, plus efficacement. Ingénieur, architecte, leader technique, directeur: les titres ont changé, l’intérêt jamais. Ce qui suit n’est pas un CV: les quatre tournants dans ma façon de voir le métier, puis les six dimensions du rôle que j’exerce aujourd’hui et les principes qui guident mes décisions
Ingénieur
L’informatique est ma passion depuis que j’ai découvert QBasic. J’ai fait mes premières armes sur des applications réseau, puis, avec l’arrivée d’Ajax, sur des applications web pour des banques, des médias et des opérateurs télécoms. Migrations, tests de performance, contraintes de production: le métier consistait d’abord à livrer, et à faire en sorte que ce qui était livré résiste à la réalité.
Assez vite, mon regard s’est déplacé. Les problèmes qui m’intéressaient le plus n’étaient plus dans le code que j’écrivais, mais dans le système qui l’entourait. L’architecture s’était construite par strates, sans plan d’ensemble, et ses dépendances finissaient par rendre chaque évolution coûteuse. Avant d’ajouter une fonctionnalité, il fallait parfois commencer par remettre les fondations à plat.
C’est là que se sont formées deux convictions que je garde. La simplicité n’est pas une vertu de débutant mais la chose la plus difficile à préserver, et le logiciel se lit bien plus souvent qu’il ne s’écrit: le code est d’abord une façon de parler aux personnes qui le maintiendront.
Architecte
Décomposer un système par domaine métier, introduire le streaming d’événements et les conteneurs, standardiser les API REST: mes années d’architecture m’ont appris que la difficulté n’est pas d’écrire le code, mais de définir les frontières qui lui permettent d’évoluer une fois en production. Une bonne frontière survit aux trois fonctionnalités suivantes; une mauvaise se paie à chacune d’elles.
Ces années m’ont aussi appris à quoi sert une architecture. Pas un schéma à admirer, mais un ensemble de décisions qui rendent la suivante moins coûteuse: où placer un changement, comment le tester, comment le livrer sans y passer le week-end. J’ai compris alors que la livraison fait partie de l’architecture; elle ne vient pas après.
Leader technique
Une architecture n’existe vraiment que lorsqu’une équipe se l’est appropriée. Avant cela, ce n’est qu’un dessin. Accompagner des équipes Scrum, piloter des démarches d’excellence pour de grandes DSI et enseigner le Craftsmanship, le DevSecOps et le domain-driven design ont déplacé mon attention de la conception elle-même vers ce qui la fait tenir: les pratiques, l’outillage et les personnes. La livraison continue, la sécurité intégrée dès le premier commit, des tests qui permettent de changer d’avis.
Je retiens deux choses de ces années. La dette technique est un sujet métier avant d’être un sujet technique, et la discussion est perdue quand les ingénieurs ne savent pas en parler dans les termes de ceux qui la paient. Et un savoir qui n’est pas partagé ne passe pas à l’échelle: j’ai enseigné parce que c’était la seule façon de changer plus de code que je ne pouvais en écrire.
Directeur
Aujourd’hui, les questions se posent à l’échelle d’une organisation, et j’ai appris à les instruire dans les instances où elles se décident, comités exécutifs et comités de projet, avec les DSI et les directions du numérique. Mon travail porte désormais sur ce qu’une organisation finance, arrête ou transforme: auditer un programme, arbitrer une trajectoire, dimensionner les équipes et les budgets qui la portent, et en répondre devant un DSI ou un comité de direction.
Les six dimensions qui suivent décrivent ce rôle. Je reste proche du code, non pour le produire à la place des équipes, mais parce que je ne fais confiance à aucune orientation que je ne saurais expliquer à un ingénieur.
Six dimensions du leadership technologique
Le même rôle vu sous six angles, et la façon dont je l’aborde
Stratégie technologique et transformation
Une stratégie technologique n’est utile que si elle dessine une trajectoire que l’organisation peut réellement emprunter. J’ai vu trop de schémas cibles élégants rester des schémas, parce qu’ils ignoraient l’existant, les équipes qui le faisaient tourner ou le budget qu’ils exigeaient.
Je pars donc des enjeux de l’entreprise et j’en déduis la technologie: quels choix structurants, quels investissements, quelle modernisation, dans quel ordre. La transformation devient ensuite une question de rythme: assez rapide pour peser, assez progressif pour que les capacités se construisent vraiment.
Organisation et excellence de l’ingénierie
Une organisation d’ingénierie se conçoit avec la même rigueur qu’un système: un modèle opérationnel, des responsabilités claires, des standards partagés, des communautés qui font circuler les pratiques. La qualité et l’expérience des développeurs se pilotent à cette échelle, pas équipe par équipe.
L’excellence technique ne se décrète pas; elle se mesure et se défend. Des tests qui rendent le changement sûr, une chaîne de livraison automatisée, une dette technique visible de ceux qui la financent: c’est ce qui permet à une organisation de tenir la qualité et la vitesse en même temps, et c’est par là que je commence.
Architecture et fondations technologiques
Une frontière bien placée, une plateforme bien choisie, un système distribué conçu pour survivre aux pannes: chacune de ces décisions d’architecture engage des années de coûts et de capacités, et la plupart ne se reprennent pas facilement.
J’ai gardé une lecture précise de ces sujets, du streaming d’événements aux plateformes cloud, non pour décider à la place des architectes mais pour arbitrer en connaissance de cause. À l’échelle d’une organisation, cette profondeur permet de distinguer une modernisation nécessaire d’une mode coûteuse, et de savoir quand une décision peut attendre.
IA et technologies émergentes
L’IA générative n’est pas une fin en soi: elle change l’économie de l’ingénierie. Quand le code coûte moins, la valeur se déplace vers la spécification, l’architecture, la vérification et le jugement. C’est ce déplacement qu’il faut conduire, pas seulement l’achat d’un outil.
Je fais passer ces technologies de l’expérimentation à la capacité opérationnelle: un cadre d’adoption, des pratiques d’ingénierie assistée par l’IA éprouvées sur de vrais systèmes, une industrialisation progressive. Et une règle constante: la décision reste humaine, la qualité et la sécurité ne se négocient pas.
Gouvernance technologique et risques
Une dette technique, une vulnérabilité, une obligation réglementaire ou une dépendance fragile sont des sujets de direction, mais ils arrivent devant les instances dans un langage qu’elles ne peuvent pas arbitrer. Mon travail consiste à les traduire en options, en coûts et en risques comparables, pour que la décision devienne possible.
La gouvernance que je défends ouvre la voie plus qu’elle ne la barre: des décisions consignées avec leurs raisons, des arbitrages explicites, une sécurité et une résilience conçues dès le départ. Rendre les risques gouvernables, c’est ce qui permet de prendre les bons sans être paralysé par les autres.
De la stratégie à l’exécution
Une trajectoire tient à ses priorités, à ses arbitrages et à ses jalons, et surtout aux équipes qui doivent la porter. Je la découpe en étapes que l’organisation peut absorber, chacune avec un résultat qui se mesure et un responsable qui en répond.
Je tiens à cette part du rôle. Elle demande de la présence, de la constance et la capacité de réviser le plan quand le terrain enseigne autre chose, sans perdre la direction. C’est là que se joue la différence entre une stratégie présentée et une stratégie exécutée.
Ma façon de penser la technologie
Ce qui guide mes décisions, du comité de direction au code
La technologie sert une trajectoire, pas une stack
Aucune technologie ne vaut par elle-même. Elle vaut par la capacité qu’elle donne à l’entreprise dans deux ou trois ans, et par ce qu’elle coûte pour y arriver. Une stratégie technique dit non aussi souvent que oui.
L’architecture est une discipline de décision
Une architecture n’est pas un dessin à protéger, mais un ensemble de décisions dont chacune doit rendre la suivante moins coûteuse. Celles dont je suis fier ont survécu à des changements que personne n’avait prévus, parce qu’elles étaient simples et que leurs raisons étaient écrites.
Une organisation d’ingénierie est aussi un système
Une décision tient rarement parce qu’elle est astucieuse; elle tient parce qu’une équipe entière la comprend et peut la défendre. Une organisation se conçoit comme un système: des frontières claires, des boucles de feedback courtes, des pratiques qui circulent.
La livraison fait partie de l’architecture
La façon dont un logiciel est construit, testé et déployé fait partie du système. Une conception qui ne peut pas être livrée par petits pas sûrs n’est pas terminée; un logiciel qui doit durer reste en livraison continue tant qu’il sert.
La stratégie ne compte que lorsqu’elle atterrit
Une trajectoire présentée en comité n’a encore rien changé. Elle compte quand les équipes l’ont faite leur, quand les résultats se mesurent et quand les pratiques survivent au programme qui les a introduites.
L’IA change l’économie de l’ingénierie, pas la responsabilité
L’IA écrit le code plus vite que n’importe lequel d’entre nous. Elle ne décide pas s’il doit exister, ce qu’il ne doit jamais faire, ni quand il est assez bon pour partir en production: ce jugement reste à l’ingénieur, et la responsabilité avec lui. Quand le code ne coûte plus rien, le jugement vaut tout.