De VP Engineering à la construction en solo

TL;DR

Je pense que le ratio entre ceux qui construisent et ceux qui managent, cohérent en 2020, ne tient plus en 2026 et s’apprête à s’inverser. Dans mon expérience, un senior assisté par IA produit aujourd’hui ce que faisaient auparavant 3 à 5 personnes ; c’est une comparaison ressentie, pas une mesure. La couche de management qui existe uniquement pour coordonner est sous pression, tandis que le développement des personnes, la vision technique, la culture et les paris d’architecture gardent leur valeur.

Revenir à la construction signifiait aussi apprendre une autre façon de travailler. Mon expérience m’aide à décider quoi construire et à juger le résultat, pendant que j’apprends à déléguer davantage l’exécution. Le temps et les ressources disponibles pour cet apprentissage comptent, et même en livrant plus vite, je reste responsable de l’utilisation ou non de ce que nous livrons.

Sujet	Détails
Parcours	Environ 15 ans dans le logiciel, dont 8 à 10 ans de lead et de direction, Lead Dev compris : stagiaire → Lead Dev → CTO → VP Engineering -> CTPO -> AI Founding Engineer. Jusqu’à 30 personnes managées, plus de 60 ingénieurs recrutés dans 6 pays.
Décision	Retour choisi à la construction technique sur le terrain comme AI Founding Engineer (depuis juillet 2025).
Pourquoi	L’IA a déplacé l’endroit où le travail crée de l’impact. Un créateur solo avec l’IA atteint désormais la production d’une petite équipe d’il y a 3 ans.
Toujours utile	Pensée système, vitesse d’exécution, discipline de périmètre, communication, instinct de recrutement.
Obsolète (en solo)	Entretiens individuels, planification de sprint, alignement des parties prenantes, culture de réunion, coordination du management intermédiaire.
Projets et contributions présentés	7 projets open source ou plus, 16 000 lignes de documentation, 473 questions de quiz (en octobre 2026), outils CLI Rust. Mes projets personnels sont construits en solo avec l’IA. RTK est collectif, j’y suis contributeur historique et soutien actuel.
Le déplacement	Le ratio management/construction s’inverse. Dans mon expérience (ressentie, pas mesurée), 1 senior assisté par IA = 3 à 5 personnes auparavant. Les managers doivent désormais exceller dans le développement des personnes, au-delà de la coordination.

La plupart des responsables d’ingénierie gravissent les échelons sans regarder en arrière.

Dev -> Senior Dev → Lead Dev → Engineering Manager -> VP Engineering -> CTO / CTPO

J’ai environ 15 ans d’expérience dans le logiciel, dont 8 à 10 ans de lead et de direction, Lead Dev compris. Construit plusieurs équipes de zéro. Managé jusqu’à 30 personnes. Recruté plus de 60 ingénieurs dans plus de 6 pays.

Puis j’ai choisi de revenir au code comme contributeur individuel senior. Le leadership n’avait pas échoué. J’en avais envie, et l’IA a déplacé l’endroit où le travail crée de l’impact.

La trajectoire que tout le monde suit

Ce parcours couvre environ 15 ans dans le logiciel, dont 8 à 10 ans de lead et de direction.

Les années formatrices (2013-2018) ont posé les fondations. Chez EDF (2013-2014), le stage est devenu un premier vrai déploiement : un MVP dans une centrale nucléaire. On apprend vite la rigueur quand les erreurs ont des conséquences. Chez Aussiito (2014-2017), j’ai construit ma première équipe de 0 à 10 personnes. Migrer plus d’un million de lignes de PHP historique vers Symfony + Angular tout en maintenant l’activité m’a plus appris sur le management que n’importe quel livre. Le plus difficile n’était pas le code, mais recruter sans chasseurs de têtes. J’ai appris à repérer le talent en entretien plutôt que sur les CV. 80 % de mes meilleurs recrutements venaient de profils atypiques.

Chez Qemotion (2017-2018), même schéma : équipe de 0 à 6, refactoring d’un monolithe Rails, pipelines NLP en Python. Un traitement prenait 6 heures pour 10 000 documents. Après optimisation du cache, refonte des tâches asynchrones et réécriture de l’algorithme central, nous sommes descendus à 4 minutes. Un facteur 100. Le CEO m’a demandé si j’avais triché. Pas de magie, du profiling méthodique et des choix d’architecture judicieux.

La phase de croissance (2018-2023) m’a appris la coordination à grande échelle. Chez Explain (2018-2021), je suis passé d’un noyau de 6 personnes à 2 équipes pluridisciplinaires totalisant 14 personnes. J’ai construit un pipeline de données serverless de zéro. Piloter un plan social pendant le Covid n’avait rien d’agréable. Cela m’a appris à tenir sous pression. La leçon la plus dure était la délégation. J’ai fait les deux erreurs : tout micromanager (épuisement), puis déléguer sans suivi (dette technique). Trouver l’équilibre a pris 18 mois.

Chez Cheerz (2021-2023), VP Engineering de 30 personnes (15 en direct, les autres via les leads). J’ai recruté plus de 15 ingénieurs sur le marché du recrutement le plus tendu qui ait existé. Organisé plus de 10 meetups tech passés de 30 à 120 participants (replays disponibles). Piloté une optimisation FinOps réduisant de 10 % un budget de 350 000 €. J’ai appris que la culture se transmet à grande échelle par la transparence et l’énergie, pas par des documents de processus.

Le retour hybride (2023-2025) a fait le lien entre l’ancien et le nouveau monde. Chez Native Spaces, rôle de CTPO mais 70 % de travail technique sur le terrain (fullstack TypeScript/Next.js/React Native). Recrutement de quelques ingénieurs, 1 designer et 1 spécialiste SEO. Héritage d’un monolithe PHP historique (PHP 4, code spaghetti). Refactoring, migration vers PHP 8, amélioration de l’architecture. Mais nous avons atteint un mur : dette technique trop profonde, passage à l’échelle impossible. Décision : reconstruire une v2 de zéro. J’ai piloté la réécriture complète tout en gardant la v1 active. Ces 70 % de code ont maintenu ma crédibilité sur les décisions techniques. Sans cela, j’aurais managé un workflow que je ne comprenais pas.

En juillet 2025, j’ai rejoint Méthode Aristote comme AI Founding Engineer & CTO (EdTech + IA, groupe Cartesia Education). Stack T3 (Next.js, tRPC, Prisma, PostgreSQL). Responsabilité complète : architecture, produit, stratégie technique. Le pari était audacieux. Quand Ben et Aimery (cofondateurs, mes patrons) m’ont demandé si je pouvais livrer la plateforme de zéro, le calendrier était serré : début le 15 juillet, échéance le 1er septembre. Six semaines, plateforme complète, seul. J’ai dit « deal, but I’m going all-in on AI » (traduction fidèle : « d’accord, mais je mise tout sur l’IA »). Pas le temps pour une architecture parfaite. Pas le temps de tout suranalyser. Livrer vite, itérer ensuite. Claude Code, Cursor, génération intensive de squelettes de code, raccourcis pragmatiques quand ils avaient du sens. Un rythme qui aurait nécessité une équipe de 3 à 4 ingénieurs et 3 à 4 mois avant l’IA. Nous avons livré à temps. Début seul sur la technique, puis recrutement d’un founding product designer après 6 mois. Construction d’un environnement de développement augmenté par IA (Claude Code, Cursor), aux configurations avancées, permettant à des membres non techniques de construire et livrer en production à mes côtés. Quelques semaines de mise en place, mais cela fonctionne maintenant. Le product designer livre directement des fonctionnalités.

Tout ce que les livres de leadership recommandent ? Je l’ai fait. Constituer des équipes et étendre les processus, gérer des budgets, recruter dans 6 pays, accompagner des seniors dans des transitions techniques, piloter des migrations de plateforme sans arrêter l’activité, organiser des meetups, et même relire techniquement 3 livres (Backbone.js, JS Regex, Mastering Grunt).

Et cela a fonctionné.

Ce qui a changé : l’IA a réécrit l’équation

Le modèle traditionnel du logiciel : on ne peut pas se démultiplier, donc on passe par les autres. Un lead développeur gère 5 à 8 ingénieurs. Un CTO coordonne 2 à 3 leads. Un VP Engineering supervise 15 à 30 personnes. Ce calcul a tenu pendant 30 ans.

L’IA l’a cassé.

Avec Claude Code, un senior qui construit (en sachant ce qu’il fait et où il va) peut aujourd’hui produire autant qu’une petite équipe d’il y a 3 ans. Tout en travaillant à temps plein comme AI Founding Engineer chez Méthode Aristote, je construisais aussi : 7 projets open source en développement actif, 16 000 lignes de documentation dans 3 guides, 473 questions de quiz (en octobre 2026) avec parcours interactifs, outils CLI Rust (RTK, projet collectif auquel j’ai contribué : réduction de tokens de 60 à 90 %, 487 000 tokens économisés), tableau de bord à deux modes (accélération de 89 fois avec cache SQLite). Sur RTK, je suis aujourd’hui contributeur historique et soutien du projet. Ces chiffres restent les métriques du récit, pas des résultats dont je serais l’unique auteur.

Mes projets personnels étaient construits en solo avec des agents IA en parallèle, sans planification de sprint ni entretiens individuels. Mes contributions à RTK s’inscrivaient dans un projet collectif. Je suis encore manager d’ingénierie d’une certaine façon, mais je manage désormais des agents plutôt que des personnes.

L’écart de débit entre « VP with team » et « senior builder with AI » (traductions : « VP avec équipe » et « senior qui construit avec l’IA ») s’est effondré. Dans certains domaines, le senior solo gagne maintenant en vitesse. Avant 2025, je n’aurais pas pu faire cela.

L’inventaire franc

Ce qui reste utile du leadership

Ces années de lead et de direction ont laissé des compétences qui se transfèrent autrement.

La discipline de périmètre. Ça m’arrive de demander à l’agent de retirer une feature qu’il vient d’ajouter. Elle peut être sympa, mais on ne l’avait pas prévue, on n’a pas fait les specs et on ne l’a pas testée. Je lui demande de la remettre au backlog ou de l’isoler sur une branche. Le fait que ce soit déjà codé ne me donne pas une raison de le livrer. J’en ai parlé pendant le live Insitoo : déléguer l’implémentation me laisse encore la décision de ce qui entre dans le produit.

La pensée système. Comprendre dépendances, portée des conséquences, dette technique : rien ne disparaît. Quand je code sur ces projets, je pense toujours comme un architecte. Pas « how do I make this code work », mais « how does this feature impact the entire system in 6 months » (traductions : « comment faire fonctionner ce code » et « quel impact cette fonctionnalité aura-t-elle sur le système entier dans 6 mois »). Savoir prendre du recul tout en entrant dans le détail.

La vitesse d’exécution. Le management m’a appris que « done » vaut mieux que « perfect » (traductions : « terminé » et « parfait »). L’école d’ingénieurs m’a appris à optimiser, les startups à livrer. Je n’ai compris la différence qu’après les deux expériences.

La communication. Documentation, README, issues GitHub clairs : toujours au centre. Construire seul ne signifie pas construire en silence. L’écrit asynchrone compte même davantage sans équipe avec qui s’aligner oralement. Un README est un argumentaire. Une issue, une spécification à relire 3 mois après. Un message de commit, le morceau de contexte qui survit à une réécriture. Chez Cheerz, je défendais la culture documentaire : contrats d’API, approche contract-first, specs claires. Cela fonctionnait, lentement. Écrire prenait du temps. Avec l’IA, c’est maintenant automatisé. Donnez-lui le bon guide de style et elle produit immédiatement une excellente documentation. Mêmes exigences, 10 fois plus vite.

L’instinct de recrutement. J’ai recruté plus de 60 personnes (80 % en direct, sans chasseurs) en Bulgarie, Angleterre, au Vietnam, en Pologne, Tunisie et France. Je sais reconnaître un bon profil. Ce n’est pas une science exacte. Je me suis déjà trompé. Mais j’ai appris à faire confiance à ma capacité à reconnaître les profils, acquise au fil de plus de 60 recrutements. Des stagiaires sont devenus leads. Des juniors, seniors aguerris. Quand je relis du code open source, je distingue encore qui peut progresser de qui suit simplement des tutoriels. Même instinct, autre application.

Ce qui est devenu obsolète, pour construire seul

L’optimisation des processus. Sans équipe, ni planification de sprint, ni stand-up, ni rétrospective. Optimiser des workflows Jira ne me manque pas. Résoudre des problèmes techniques me manque. Il se trouve que j’ai toujours préféré cela.

L’alignement des parties prenantes. Quand on est founding engineer, les décisions techniques vont vite. Chez Cheerz, un changement architectural majeur demandait des semaines d’alignement. Chez Native Spaces, quelques jours. Au début de la construction chez Méthode Aristote, seul sur la technique ? Quelques heures pour prototyper et valider directement avec les utilisateurs.

La culture de réunion. VP chez Cheerz, j’avais 15 à 20 heures de réunion par semaine. Maintenant, peut-être 2 à 3 heures pour s’aligner rapidement ou interroger des utilisateurs. Les réunions m’épuisent. Trop longues, trop lentes. Le temps récupéré va directement dans la codebase.

La coordination du management intermédiaire. Pas besoin de coordonner des équipes quand on est l’équipe. Pas de traduction entre « what the business wants » et « what engineering can deliver » (traductions : « ce que veut le métier » et « ce que l’ingénierie peut livrer »). J’incarne les deux couches. Boucles de retour plus rapides, moins de pertes d’information.

Ce qui s’est étonnamment bien transféré

Les compétences de leadership n’ont pas disparu. Elles ont changé de direction. Penser roadmap est devenu gérer un pipeline multi-projets. Je planifie toujours plusieurs trimestres à l’avance, mais des releases plutôt que de la capacité d’équipe. L’évaluation des risques sert désormais à prioriser les expériences : paris à tenter ou reporter. Les budgets sont passés des salaires à mon infrastructure personnelle (AWS, Vercel, hébergement). Même discipline FinOps, à plus petite échelle.

Le transfert le plus inattendu ? La délégation devenue orchestration d’agents. Je déléguais à des seniors avec contexte clair et autonomie. Je délègue maintenant aux agents IA (Claude Code, GitHub Copilot, serveurs MCP) de la même façon : contexte clair, périmètre défini, points de validation. Le modèle mental est identique. La couche d’exécution a changé. L’article ultérieur sur les responsabilités du context engineering distingue spécification, harnais, identité et évaluation, dont quelqu’un doit toujours être responsable.

L’environnement s’est adapté aussi. VP, un ordinateur et une salle de réunion suffisaient. Pour construire, il m’a fallu un cockpit multi-écrans : terminaux, éditeurs, agents, documentation, tout visible simultanément. Même réflexe multitâche que pour plusieurs équipes sur plusieurs stacks, appliqué à plusieurs projets sur plusieurs écrans.

Installation multi-écrans avec éditeurs de code, terminaux et agents IA actifs simultanément — Le cockpit de construction. Trois écrans, un ordinateur, zéro salle de réunion. (Oui, ce sont des LEGO Star Wars. #NoRegrets)

Le travail d’ambassadeur tech (plus de 10 meetups chez Cheerz, fréquentation passée de 30 à 120 personnes) est devenu animation communautaire open source. Même transfert d’énergie : autre support, même dynamique.

Mes 8 à 10 ans de lead et de direction m’ont donné une pensée système appliquée maintenant à l’architecture produit. Manager m’a appris à voir la complexité à grande échelle, ce qui se transfère directement à l’orchestration de projets parallèles. Le support a changé, le jugement sous-jacent est resté.

Ce que je construis maintenant

Projets et contributions open source depuis début 2026, avec l’aide de l’IA. Cette liste mêle créations personnelles et contributions collectives, à des stades de maintenance différents :

Claude Code Ultimate Guide • RTK (Rust Token Killer) (contribution historique, soutien actuel) • ccboard (moins maintenu aujourd’hui) • CC Copilot Bridge • Claude Cowork Guide • MCP Guide Assistant • Tableau de bord TUI/Web à deux modes

Une personne gère maintenant sept contextes simultanés. Je n’aurais pas pu le faire il y a 2 ans.

La vélocité continue d’augmenter. C’est ce qui me surprend le plus. Je ne plafonne pas, j’accélère. Les fonctionnalités sortent plus vite, les PR s’accumulent, les expériences tournent en parallèle. La contrainte est la capacité de mon cerveau à tout suivre, pas les outils. Avec l’IA, la vélocité croît exponentiellement dans les deux sens : livraison et itération rapides, mais aussi multiplication des bugs, accumulation rapide de dette, changements incompatibles en cascade. Le rythme est incessant, tout doit être réévalué constamment car ce qui fonctionnait hier peut être obsolète demain. À l’échelle actuelle, c’est grisant, avec un plafond encore non atteint. La limite est la charge cognitive d’orchestrer sept cibles mouvantes à la fois.

J’en ai aussi rencontré une conséquence moins flatteuse : perdre le fil et jeter le travail produit. Pendant le live Insitoo, je parle de trente ou quarante sessions, mais je ne les pilote pas toutes en même temps. Je passe d’un plan à une vérification et je garde le fil sur mon reMarkable. Ça ne m’a pas empêché de gaspiller du temps et des tokens. Ces abandons font partie du coût de ma façon de travailler. Le nombre de sessions ne dit pas combien de travail utile en sort.

La vérité inconfortable sur le leadership en ingénierie en 2026

Le ratio managers/personnes qui construisent s’apprête à s’inverser.

L’ancien calcul (2020)

Quand je construisais des équipes chez Aussiito, Qemotion, Explain : 1 lead pour 5 à 8 ingénieurs, 1 CTO pour 2 à 3 leads, 1 VP Engineering pour 15 à 30 personnes. C’était efficace. C’était nécessaire.

La nouvelle réalité (2026)

D’après mon expérience, un ingénieur senior assisté par IA produit ce que faisait une équipe de 3 à 5 personnes. Comparaison ressentie, pas mesurée, que je vois chaque jour. Chez Native Spaces (2023-2025), CTPO à 70 % sur la technique, j’ai reconstruit toute la plateforme (backend, frontend, mobile) avec une petite équipe pendant que l’activité était multipliée par 4. Chez Méthode Aristote, à partir de juillet 2025, j’ai commencé seul sur la technique pour construire la plateforme EdTech, puis ouvert la contribution à d’autres profils. En open source, j’ai construit des projets personnels et contribué à des projets collectifs qui auraient auparavant nécessité des équipes dédiées. Pour RTK, je reste un contributeur historique et un soutien actuel.

Ce changement est réel.

Comment le rôle évolue selon la séniorité

Contexte : ces observations viennent de mon parcours précis. Autre secteur, taille d’entreprise ou maturité d’équipe, autres réalités.

Un junior peut surprendre sur une tâche bornée. Un junior contribuant à un repository construit par un senior (architecture propre, patterns clairs, bonnes fondations) peut aller plus vite qu’un senior refusant l’IA. S’il comprend le système et utilise bien les outils, sa vitesse peut me surprendre. Cette vitesse ne dit pas grand-chose, à elle seule, de sa capacité à diagnostiquer un échec, contester une exigence ou évaluer les conséquences ailleurs dans le produit. Pour des prototypes rapides ou fonctionnalités bien délimitées sur une codebase établie, je prendrais cette contribution au sérieux. Pour des décisions architecturales complexes, systèmes critiques en production ou projets neufs exigeant un jugement approfondi, j’ai toujours besoin de l’expérience derrière ces décisions. Une fonctionnalité qui marche est une preuve parmi d’autres au recrutement.

L’expérience me donne un point de départ. J’ai vu des seniors éloignés de la technique depuis des années y revenir plus vite que prévu. Leurs fondations les aidaient à évaluer ce que les outils produisaient : patterns de conception, pensée systémique, principes d’ingénierie logicielle. Je consacre moins d’effort à mémoriser chaque API et plus à juger la pertinence d’une approche. Cette expérience m’aide à apprendre une pratique sans recommencer ma carrière. Cela demande encore de la pratique, notamment pour apprendre dans quelles situations les outils échouent et savoir quand solliciter le jugement d’autrui.

Qui s’adapte le plus vite à l’IA ? Dans mes observations : Staff Engineers, Engineering Managers et Senior Software Engineers ayant travaillé sur plusieurs projets en parallèle. Ces profils ont déjà le modèle mental du changement de contexte, de la priorisation et de l’orchestration. Ils géraient la complexité à grande échelle, par les personnes ou les systèmes. L’IA leur semble naturelle comme couche de plus à orchestrer. Si vous avez jonglé avec 3 équipes, 5 repositories et 10 parties prenantes simultanément, orchestrer des agents sur 7 projets applique la même compétence cognitive à un autre support.

Pour les Engineering Managers : le rôle change de forme. L’IA et les outils asynchrones réduisent le travail de coordination pure (traduire les exigences, débloquer les personnes). Ce qui garde sa valeur : développement exceptionnel des personnes, vision technique stratégique, culture, paris architecturaux à fortes conséquences. Si votre valeur est « I keep things running smoothly » (traduction : « je fais en sorte que tout tourne bien »), la position est plus faible qu’avant. Si c’est « I grow engineers into leaders, I shape how we build, I see around corners on technical strategy » (traduction : « j’aide les ingénieurs à devenir des leaders, je façonne notre manière de construire, j’anticipe les tournants de la stratégie technique »), elle est forte. La distinction compte.

Pour les VP/CTO : vous êtes maintenant en concurrence avec des seniors assistés par IA sur la vitesse d’exécution. Vous vous distinguez par la vision architecturale à long terme, la culture d’équipe à grande échelle, le recrutement et le développement des talents, les paris techniques sur plusieurs années. Si vous avez arrêté de coder il y a plus de 5 ans et animez surtout des réunions, demandez-vous si c’est encore la position au plus fort impact. Certains contextes nécessitent toujours de purs coordinateurs. Beaucoup n’en ont plus besoin.

Chacun décide de sa place. J’ai choisi de construire. Pas parce que c’est « better » que manager (traduction : « mieux »). Parce que j’en avais envie. J’en avais besoin. Je suis geek au fond, depuis toujours. Je traverse cette phase d’excitation mentale où tout peut aller incroyablement vite, et cette énergie est addictive. Pendant des années, je me croyais vraiment manager d’ingénierie détaché du code, fait pour faire grandir les équipes et optimiser les processus. Je me trompais. Je me reconnais davantage dans le builder qui intervient dès les débuts, l’esprit indie hacker : livrer vite, itérer constamment, lancer des projets à un rythme qui me fait me sentir vivant. Et ce qui me le permet ? Environ 15 ans dans le logiciel, dont 8 à 10 ans de lead et de direction. Chaque équipe que j’ai constituée, chaque processus que j’ai fait grandir, chaque architecture que j’ai passée en revue m’ont donné le jugement pour aller vite sans tout casser. La trajectoire n’était pas un détour. C’était la fondation.

Je ne suis pas le seul dans mon entourage à avoir changé ainsi. Ma femme Pauline était CPO dans une entreprise tech. Après un licenciement, elle n’a pas cherché le poste de CPO suivant. Elle a reconstruit de zéro : lancé Bel Etage, studio d’architecture intérieure. Du management à la création, autre secteur, même schéma. La voir traverser le doute, déplacer son énergie de la délégation vers l’action a confirmé mon ressenti. Me remettre à construire me semblait juste, d’une façon inattendue.

« Management is dead » ? Non. C’est naïf. Traduction : « Le management est mort ». Les produits complexes nécessitent toujours coordination interéquipes, culture d’ingénierie à grande échelle, recrutement et développement des talents, direction technique stratégique. Mais le ratio change. Avant : 1 manager pour 7 ingénieurs était sain. Maintenant : 1 pour 15 ingénieurs assistés par IA pourrait être viable dans certains contextes. La couche intermédiaire limitée à coordonner et traduire est sous pression. Pas supprimée, mais réduite. Si vous y êtes, la question n’est pas « Am I at risk? », mais « What unique value do I bring beyond coordination? » (traductions : « Suis-je menacé ? » et « Quelle valeur singulière est-ce que j’apporte au-delà de la coordination ? »). Répondez clairement, et cela ira. Évitez la question, l’environnement y répondra pour vous.

Être expérimenté et réapprendre

Préparer une discussion Insitoo sur l’IA et le logiciel m’a ramené à une question de carrière. Si je délègue davantage l’implémentation, pourquoi suis-je payé ? Ma réponse commence par les décisions qui entourent ce travail : comprendre le problème, poser les attentes, juger le résultat suffisant ou non. Apprendre cette pratique ajoute à mon expérience, tout en pouvant me faire abandonner des façons familières de montrer mon savoir-faire.

Je n’ai jamais été particulièrement attaché à taper moi-même le code. J’aime résoudre les problèmes, ce qui rendait la délégation de l’implémentation attirante. Je comprends que quelqu’un ayant passé des années à être fier de bien écrire ce code le vive autrement. Lui demander de laisser tomber son ego ignore l’investissement pour devenir bon. Il peut devoir découvrir où ce savoir l’aide dans une pratique d’abord étrangère.

Ce que mon expérience me permet encore

Mes erreurs de délégation chez Explain me servent toujours. J’ai essayé de tout contrôler, puis de déléguer le travail sans suivi suffisant. Cela m’aide à demander ce dont quelqu’un a besoin pour travailler seul et ce que je dois vérifier ensuite. J’utilise ces questions avec un agent, tout en découvrant où la comparaison avec un collègue humain tient.

Même chose pour les décisions produit. Je peux demander pourquoi une fonctionnalité a sa place dans le produit, quel problème elle résout et pour qui, et quelles preuves nous feraient changer de direction. Un agent peut m’aider à explorer ces questions. Je dois encore choisir avec l’information disponible et expliquer ce choix aux personnes concernées.

Un senior peut donc être expérimenté en ingénierie et débutant dans une nouvelle pratique à la fois. Je voudrais le voir appliquer son jugement à un travail borné, expliquer ce qu’il a délégué et reconnaître les parties du résultat qui demandent un examen plus poussé. Apprendre un outil devient plus utile quand il le relie à une décision qu’il sait déjà évaluer.

L’apprentissage nécessite une place dans le travail

Damien Cavaillès a soulevé une objection pratique dans cette conversation : les personnes peuvent vouloir apprendre tandis que l’employeur limite outils et budget. Il a aussi décrit des essais échoués avant d’avoir un environnement de travail auquel il faisait confiance. Cela doit faire partie de tout récit sur la façon dont quelqu’un change sa pratique.

Mon environnement de travail comprend des outils payants, du matériel et un budget de recherche. Je choisis d’expérimenter sur mon temps personnel parce que j’aime cela et que c’est devenu une partie de ma spécialisation. J’ai ainsi des possibilités d’essai que quelqu’un limité à un outil approuvé au travail n’a peut-être pas. Je dois intégrer ces conditions avant de juger sa volonté ou capacité d’apprentissage.

Si je demande à un salarié de changer sa pratique, je dois faire une place à l’apprentissage dans son travail. Accès aux outils adaptés, temps pour essayer une tâche bornée, quelqu’un de disponible après un échec. Je lui demanderais ce qu’il a essayé et appris. Je demanderais aussi à son manager ce que l’organisation a rendu possible.

Livrer plus vite peut encore manquer le but

Damien a aussi contesté la productivité : aller plus vite pour faire quoi ? J’avais un exemple inconfortable chez Méthode Aristote. Nous avions livré des fonctionnalités dont nous étions contents, puis ajouté un suivi d’usage et constaté qu’elles n’étaient pas utilisées. Sans plus de données, je ne peux pas m’appuyer sur ce récit pour mesurer ce que l’IA a apporté. Cela m’a donné une raison de questionner ce que je comptais comme progrès.

J’aime pouvoir construire ce qui aurait auparavant demandé une équipe. Cela donne envie de continuer à construire. Pouvoir produire une fonctionnalité de plus me laisse la décision de sa place dans le produit et le travail de découvrir comment elle est utilisée.

C’est là que mon expérience de leadership garde sa place. Je peux appliquer ma discipline de périmètre à la décision, parler aux utilisateurs et questionner mon enthousiasme à créer. Ce changement de carrière est satisfaisant parce qu’il me donne plus de moyens d’agir sur un problème. Je dois encore vérifier si l’action choisie a aidé quelqu’un.

Ce que je dirais à mon moi VP de 2021

Les 20 % de temps de code chez Cheerz étaient la seule raison de ma crédibilité architecturale. En dessous, je le sentais : décisions approuvées sans les comprendre entièrement, paris impossibles à évaluer, dépendance à l’équipe pour détecter mes manques. Ces 20 % n’étaient pas arbitraires. C’était le signal minimal viable que je comprenais encore ce que je demandais.

L’aisance avec l’IA suit la même logique. J’ai brièvement été en retard fin 2024, avant d’approfondir la configuration. Manager un workflow incompris fait de vous un goulot d’étranglement qui s’ignore. Un VP n’ayant pas récemment utilisé sérieusement Claude Code ou Cursor ne peut pas évaluer comment son équipe devrait les utiliser. Ce n’est pas un jugement de valeur, mais une limite pratique : il raisonne sur un processus qu’il n’a pas exécuté.

Ma crédibilité actuelle en open source vient de mes livraisons, pas de « VP Engineering » dans une biographie. Vraie surprise. J’ai passé des années à accumuler les titres avant de découvrir que les personnes avec qui je veux construire regardent GitHub, pas LinkedIn. Ce sont des publics différents, et cela faisait un moment que j’optimisais pour le mauvais.

Pendant l’essentiel de ma carrière, je traitais le parcours IC vers Manager comme une progression évidente, en partie par inertie. Le choix délibéré est arrivé tard. Je ne regrette pas ces années, qui me permettent d’aller vite sans tout casser. Mais si c’était à refaire, j’aurais choisi plus tôt.

Situation actuelle

Je travaille maintenant comme Chief AI Officer à temps partagé, en freelance, auprès de startups, grandes organisations et fonds d’investissement. J’audite toute la chaîne, processus, produit, stratégie, technologie et budgets, pour identifier les problèmes et prioriser les changements. Ma collaboration avec Méthode Aristote se poursuit en freelance depuis octobre 2026.

J’ai rejoint Méthode Aristote en juillet 2025 pour construire sa plateforme EdTech au sein du groupe Cartesia Education. Le travail couvre architecture, produit et stratégie technique, avec Next.js, tRPC, Prisma et PostgreSQL.

Notre approche Build vs Buy a changé avec le produit. Nous avons commencé surtout par acheter pour arriver plus vite sur le marché, puis construit sélectivement à mesure que nous comprenions la différenciation centrale. Nous achetons les composants standard et construisons les avantages concurrentiels défendables.

Le travail IA comprend de vrais problèmes techniques : recherche sémantique avec évaluation Elasticsearch/TypeSense (arbitrages précision/coût), vectorisation de base de données pour la recherche de similarités, pipelines d’embeddings pour les recommandations de contenu. Pas du « ChatGPT wrapper » (traduction : « simple enveloppe de ChatGPT »). De vraies décisions d’infrastructure à l’impact mesurable sur la performance.

En parallèle, 7 projets et contributions open source présentés ici, depuis début 2026. Leur rythme d’entretien varie. Je maintiens moins ccboard aujourd’hui, et mon rôle sur RTK est celui d’un contributeur historique qui continue à soutenir le projet.

Qui je suis

Geek depuis toujours, environ 15 ans dans le logiciel dont 8 à 10 ans de lead et de direction, maintenant je construis à nouveau.

Je tiens plus à bien faire qu’à sembler tout maîtriser. Transparence plutôt que politique, documentation des échecs aussi claire que celle des réussites, livrer quelque chose de testable avant de le présenter comme résolu. Version Charlie Munger : « go to bed slightly less stupid than you woke up » (traduction fidèle : « se coucher un peu moins bête qu’au réveil »). C’est mon système d’exploitation. Certains jours, un nouveau pattern architectural. D’autres, un chapitre de The Phoenix Project dans le train.

Français et anglais courants. Équipes non francophones managées en Bulgarie, en Angleterre, au Vietnam, en Pologne et en Tunisie. Plus de 60 ingénieurs recrutés au fil de ce parcours, 80 % sans chasseurs de têtes. Domaines : SaaS, e-commerce, data, B2B, B2C, IA, EdTech, de la phase pré-seed à l’après-rachat.

Le ratio entre builders et managers

Ces années à construire et accompagner des équipes m’ont donné ce que je n’aurais pas acquis autrement : le jugement pour savoir quoi écarter. L’IA m’a permis d’agir rapidement sur la base de ce jugement, sans attendre l’alignement d’une équipe. Ce jugement et cette vitesse ont changé le calcul de ce qu’une personne peut livrer. Pour le leadership en ingénierie aujourd’hui, l’inconfort vient de ce que ce n’est pas une exception temporaire. Le ratio cohérent en 2020 ne tient plus en 2026, et prétendre l’inverse est un choix, pas une stratégie. Je ne dis pas que tous devraient abandonner le management pour le code. Je dis que ceux qui refusent de regarder honnêtement les chiffres seront surpris.

GitHub : @FlorianBruniaux

LinkedIn : Florian Bruniaux

Méthode Aristote

Construit avec Claude Code et livré publiquement.

YSNK

(Ce que vous devriez maintenant savoir)

La règle des 20 % de code chez Cheerz était concrète : passer en dessous signifiait approuver des décisions d’architecture qu’il ne pouvait pleinement évaluer
Une optimisation chez Qemotion a réduit le traitement de 10 000 documents de 6 heures à 4 minutes, un facteur 100, par profiling et cache. Sans raccourci ni magie
Une fonctionnalité livrée par un junior et qui fonctionne est une preuve utile au recrutement. Elle n’établit pas sa capacité à diagnostiquer des échecs, contester des exigences ou prendre des décisions architecturales
L’expérience d’ingénierie peut aider à apprendre une nouvelle pratique ; accès aux outils, temps d’expérimentation et soutien influent sur cet apprentissage
Chez Méthode Aristote, le suivi d’usage a révélé que les fonctionnalités dont nous étions contents n’étaient pas utilisées. Cette expérience a changé ce que j’acceptais de compter comme progrès