Quel leader je suis, et pourquoi

Ce qui m’a façonné

J’ai passé les premières années de ma carrière à faire : du logiciel d’entreprise, de l’architecture, des systèmes distribués. Puis j’ai co-fondé une startup deep-tech qui construisait l’une des premières caméras sous-marines autonomes. Porter un produit du concept au marché — et jusqu’au brevet — m’a appris quelque chose que le code seul ne m’aurait pas appris : la qualité d’une décision technique se mesure à ce qu’elle rend possible pour les autres, pas à son élégance.

Le vrai basculement est venu quand j’ai commencé à répondre de l’ingénierie plutôt qu’à en produire. Mener l’ingénierie pendant une acquisition internationale, avec une trentaine d’ingénieurs et une organisation qui change de propriétaire, ne laisse pas de place à l’improvisation : il faut des décisions écrites, des indicateurs partagés, et des gens à qui on a dit la vérité. Ensuite j’ai construit une agence d’ingénierie de zéro à douze consultants, et j’ai découvert le métier par l’autre bout — recruter, rémunérer, faire progresser, arbitrer un budget.

De tout ça je retiens une chose simple : mon meilleur code ne pèsera jamais autant qu’une équipe qui fonctionne.

Ce que je crois

Le code est un outil, jamais le centre

La technique sert un projet, une équipe, une ambition. Quand elle devient le sujet, on perd de vue le pourquoi — et on optimise des choses qui n’ont d’importance que pour nous.

Le droit à l’erreur n’est pas un slogan

C’est une pratique quotidienne, et elle se vérifie à des détails : est-ce qu’on écrit des post-mortems sans chercher de coupable ? Est-ce qu’un junior peut dire « je ne comprends pas » en réunion ? On ne construit rien de solide là où les gens ont peur de se tromper.

L’équipe passe avant l’architecture

La technologie compte, et je ne l’ai jamais lâchée. Mais la meilleure architecture du monde ne survit pas à une équipe qui se délite, alors qu’une bonne équipe rattrape une architecture moyenne. Cette asymétrie décide de la plupart de mes arbitrages.

Le leader que je suis

Je recrute lentement et j’onboarde sérieusement. Je préfère un career ladder écrit à une promesse orale, parce que l’écrit engage et que l’oral s’oublie. Je documente les décisions structurantes — ADR, RFC, post-mortems — non par goût du process, mais parce qu’une décision non écrite se rejoue tous les six mois.

Je garde les mains dans le code, parce qu’on ne mène bien que ce qu’on comprend, et parce que relire le travail de son équipe reste la façon la plus honnête de savoir où elle en est. Et je dis les choses : sur un projet qui s’arrête, sur un recrutement qui ne se fera pas, sur une estimation à laquelle je ne crois pas.

Ce que je change dans une organisation

• Des cadres de progression et de rémunération explicites, pour que « comment j’évolue ici » ait une réponse écrite.
• Un recrutement outillé et régulier plutôt que des campagnes d’urgence : plus de trente ingénieurs recrutés, des centaines d’entretiens menés.
• Une gouvernance légère mais réelle — décisions tracées, indicateurs partagés, budget assumé.
• Une adoption de l’IA menée à l’échelle de l’organisation, avec la revue et la traçabilité qui doivent l’accompagner.

Me joindre

Par e-mail à delfour.k@gmail.com, ou sur LinkedIn. Mon code public vit sur GitHub.