DEV Community: Rémi Alvado

Composer sa première équipe tech après le MVP : qui recruter, dans quel ordre, à quel niveau

Rémi Alvado — Thu, 25 Jun 2026 21:32:08 +0000

La question revient à chaque mission de création d'équipe tech & produit : "Qui je recrute en premier ? Un fullstack ? Un backend ? Un data scientist parce qu'on a beaucoup de données ?". La plupart du temps, la question est mal posée. Ce qui compte, ce n'est pas le bon profil dans l'absolu — c'est le bon profil au bon stade de maturité, avec le bon niveau d'expérience, sur une stack que vous saurez recruter dans 18 mois. Et en 2026, avec l'IA agentique, l'équation change encore : un dev senior productif fait 2 à 3 fois plus qu'avant, donc on recrute moins mais mieux.

Ce guide consolide ce que j'ai appris en 20 ans à structurer des équipes tech — Wizbii (de 15 à 150), Winter (de 0 à 15), et plus récemment des dizaines de Sprint Fondateur et de missions de création d'équipe. Il s'inscrit dans une réflexion plus large sur comment construire son équipe tech et produit, du premier recrutement jusqu'à la structuration en scale-up. Il couvre les six profils de base : backend, frontend, fullstack, data engineer, data analyst, data scientist. Et il termine par ce qui change vraiment quand votre équipe est outillée IA agentique.

TL;DR : à quel stade, quel profil, quel niveau

Stade	Équipe technique typique	Niveau requis
Pré-MVP / Sprint	1 fractional CTO + IA agentique (vous, ou moi)	Senior obligatoire
Post-MVP, 0-2 devs	1 backend confirmé/senior (qui fait aussi infra et CI/CD)	Confirmé minimum
Post-MVP, 3-5 devs	+ 1 frontend confirmé, +1 fullstack si polyvalence utile	Mix junior/confirmé sous encadrement seniors
Post-PMF, 6-15 devs	Backend + frontend dédiés + 1 data analyst	Spécialisation possible
Scale-up, 15-50 devs	Spécialisation poussée + data engineer	Profils seniors, juniors encadrés
Scale-up, 50+ devs	Data scientist si problème ML concret + SRE dédié	Tous niveaux

Trois principes traversent ce tableau : on commence par le backend (le plus structurant), on évite la spécialisation pré-PMF (la polyvalence prime), et on n'embauche un profil rare que quand le précédent est déjà saturé. Le détail dans ce qui suit.

Backend developer

Le développeur backend est souvent le premier vrai recrutement d'une équipe technique post-MVP. Et pour cause : c'est lui qui orchestre les données, les règles métier et l'infrastructure dans une petite structure. C'est aussi le pilier qu'on sous-estime systématiquement.

Le cœur du métier : orchestrer données et logique métier

Le backend developer travaille principalement sur ce qu'on ne voit pas à l'écran. Son terrain de jeu, c'est la base de données, le code qui implémente les règles métier de votre produit, et les APIs qui permettent aux interfaces de communiquer avec tout ça. Concrètement, quand un utilisateur crée un compte, valide un paiement ou télécharge un document, c'est le backend qui vérifie que tout est conforme, stocke les bonnes informations au bon endroit, et retourne le résultat approprié.

C'est lui qui est garant de la cohérence de vos données avec les règles requises par votre activité. Si votre marketplace doit empêcher qu'un vendeur valide deux fois la même commande, c'est le backend qui met en place cette sécurité. Si votre SaaS applique des règles de facturation complexes selon les abonnements, c'est encore lui. Cette responsabilité est cruciale : une erreur à ce niveau peut coûter des revenus, corrompre des données, créer des problèmes légaux.

L'infrastructure : presque toujours dans le périmètre

Dans les petites structures, le backend ne se contente pas d'écrire du code métier. C'est aussi souvent lui qui met en place et gère l'infrastructure de production. Chez Winter par exemple, avec quatre développeurs dans l'équipe, ce sont les backends qui faisaient vivre l'infrastructure : scripts de CI/CD GitLab-CI, configurations Docker Compose, surveillance des serveurs.

Cette approche a du sens. D'abord, à cette taille d'équipe, il n'y a pas de place pour un SRE à temps plein. Ensuite — et c'est peut-être plus important — ça responsabilise l'équipe : en cas d'incident en prod, on ne peut pas se permettre d'attendre qu'un prestataire externe réagisse. Avec un simple serveur bare metal et une administration simplifiée par Docker Compose, on économise plusieurs milliers d'euros par mois dès que le trafic décolle, tout en gardant un contrôle total. C'est exactement le type de choix structurant que je détaille dans cloud public ou VPS.

Les choix techniques qui font la différence (et la dette)

Un backend developer ne se résume pas à celui qui tape du code. Au fil de son évolution, il prend des décisions structurantes : monolithe ou micro-services, choix de la base de données, stratégie d'hébergement. Ces décisions ont un impact direct sur les coûts, la capacité à évoluer, l'agilité.

Chez Wizbii, le choix de MongoDB comme base de données principale a été déterminant. Une expérience développeur forte, une simplicité de mise en production, et surtout une capacité à passer à l'échelle sur des collections contenant des milliards d'enregistrements. Mais au-delà de la techno elle-même, c'est le choix du déploiement qui a eu l'impact financier le plus important. En déployant la version open source sur des serveurs bare metal, l'entreprise ne payait que quelques dizaines d'euros par mois, là où MongoDB Atlas aurait multiplié ce coût par vingt à cinquante. Sur une année : des dizaines de milliers d'euros économisés, sans compromis sur la performance.

Ces décisions ne se prennent pas dans le vide. Un bon backend senior ne choisit pas une techno parce qu'elle est à la mode ou parce qu'il a envie de l'apprendre. Il prend en compte le contexte : qui sera impacté, quelles évolutions sont planifiées, le reste de l'équipe sera-t-il à l'aise avec ces choix. Cette maturité ne s'acquiert qu'avec l'expérience — c'est exactement ce qui différencie un junior d'un senior.

Junior, confirmé ou senior ? Le seuil de bascule

Un backend junior va s'occuper d'un périmètre restreint et restera principalement sur du dev pur : implémenter une fonctionnalité selon les specs fournies, corriger des bugs, optimiser une requête. Il a besoin d'être guidé. Ça fonctionne très bien dans une scale-up où il bénéficie de l'expertise des seniors autour de lui.

Dans une startup en revanche, le backend va immédiatement devoir faire des choix structurants. Il n'y a personne au-dessus de lui pour valider ses décisions techniques, pas de SRE pour gérer l'infra, pas d'architecte pour définir les patterns. C'est pour ça qu'il faut absolument un confirmé voire un senior dans une startup, alors qu'une scale-up a plus de latitude pour embaucher et former des juniors dans un environnement encadré.

Cette montée en compétence technique doit s'accompagner d'une montée sur les fondamentaux business. Un excellent dev qui prend des décisions techniques brillantes mais déconnectées de la réalité business peut faire plus de mal que de bien. À l'inverse, un dev moins technique qui comprend les enjeux et sait poser les bonnes questions est un atout considérable. C'est précisément la mutation décrite dans le PO Technique — la culture produit devient plus différenciante que la pure technique.

Frontend developer

Le frontend conçoit les interfaces que l'utilisateur verra quand il accède à votre produit. Mais son travail ne se résume pas à transformer une maquette Figma en code. Il doit comprendre comment les utilisateurs interagissent avec l'interface, anticiper leurs comportements, créer une expérience fluide qui fonctionne sur tous les supports.

Cette responsabilité implique de maîtriser bien plus que du HTML et du CSS : gérer l'état de l'application, optimiser les performances pour que l'interface reste réactive avec des données complexes, assurer l'accessibilité y compris pour les utilisateurs en situation de handicap, garantir le fonctionnement sur tous les navigateurs. Chacun de ces aspects peut avoir un impact direct sur votre taux de conversion ou de rétention.

Le binôme avec le Product Designer

L'époque où le frontend implémentait passivement des maquettes est révolue. Aujourd'hui, il forme un vrai binôme avec le Product Designer. Cette collaboration bidirectionnelle apporte une valeur considérable.

D'un côté, le frontend tient le designer au courant des nouveautés techniques qui peuvent influencer le design : une nouvelle API navigateur qui permet des animations plus fluides, une contrainte de performance qui impose de simplifier une interaction, une bibliothèque qui rend possible ce qui semblait trop complexe. De l'autre, le designer aide le développeur à comprendre pourquoi telle interaction a été conçue de cette manière, ce qui facilite l'implémentation et évite les incompréhensions.

Dans les meilleures équipes, ce binôme va plus loin : le frontend participe aux phases de discovery en apportant son regard technique sur la faisabilité, et le designer continue à intervenir pendant le développement pour ajuster les détails qui font la différence. Cette collaboration rapprochée accélère la livraison et améliore la qualité du résultat final.

Web et mobile : la frontière s'estompe

Avec React Native et Expo, la frontière entre frontend web et développeur mobile s'estompe. Un dev qui maîtrise React peut aujourd'hui créer des apps mobiles natives pour iOS et Android en réutilisant une grande partie de ses compétences et de son code.

Ça change la donne pour les startups. Plutôt que de recruter séparément un dev web et un dev mobile natif, vous pouvez construire votre équipe autour de frontends capables de travailler sur les deux supports. Vous gagnez en cohérence d'interface, en vitesse de développement, en capacité à mutualiser le code.

Attention cependant : développer mobile avec React Native reste différent de développer web. Les patterns d'interaction sont différents, les contraintes de performance aussi, et certaines fonctionnalités nécessitent du code natif. Un bon frontend qui se lance sur mobile a besoin de temps pour monter en compétences — mais ce sera plus rapide que de former quelqu'un qui part de zéro.

Fullstack developer

Le fullstack, c'est un peu le Graal du recrutement tech. Celui qui maîtrise autant le backend que le frontend, qui peut tout faire, et qui coûte le prix d'une seule personne. Cette perle rare existe-t-elle vraiment ? Et surtout, est-ce vraiment ce dont vous avez besoin ?

Dans la réalité, le fullstack est très rarement quelqu'un qui maîtrise parfaitement les deux univers. C'est plutôt un frontend qui a émis le souhait de toucher au backend et qui a eu la chance de pouvoir le faire, ou inversement un backend qui s'est formé au frontend. Cette polyvalence a de la valeur, mais il faut comprendre ce qu'elle implique vraiment.

Il est extrêmement difficile d'être à la fois expert sur toute une série de bases de données, de maîtriser les subtilités de l'architecture backend, des patterns de sécurité et de performance côté serveur, tout en ayant une expertise similaire sur le CSS, les animations fluides, l'accessibilité et les frameworks frontend modernes. Ces deux domaines ont chacun une profondeur technique considérable. Ce qui se passe généralement, c'est qu'un fullstack sera très bon d'un côté et correct de l'autre. Il pourra débloquer l'équipe sur les deux aspects, mais il n'aura probablement pas la même profondeur d'expertise qu'un spécialiste qui passe 100% de son temps sur son domaine.

Quand le fullstack a vraiment du sens

Dans une startup très early-stage avec deux ou trois développeurs, avoir des profils fullstack est précieux. Vous n'avez pas les moyens d'équipes spécialisées, et vous avez besoin de personnes qui peuvent toucher à tout. Un dev qui peut aussi bien créer une API REST que développer l'interface qui va l'utiliser apporte une flexibilité considérable.

Cette polyvalence permet aussi d'avancer plus vite. Plutôt que de coordonner un backend et un frontend, synchroniser leurs calendriers, gérer les dépendances entre leurs tâches, une seule personne porte la feature de bout en bout. Sur un MVP ou un prototype, cette vélocité fait toute la différence. Et le fullstack a une vision d'ensemble du produit qui a de la valeur : il comprend comment les couches s'articulent, anticipe les impacts d'un changement d'un côté sur l'autre, fait des choix qui optimisent l'ensemble.

Quand la spécialisation devient nécessaire

Au fur et à mesure que votre équipe grandit, le fullstack perd de son importance. Passé cinq ou six développeurs, vous pouvez vous permettre des spécialistes. Et ces spécialistes vont apporter une profondeur d'expertise que des fullstack ne peuvent pas atteindre. Un backend qui passe 100% de son temps sur ce domaine va développer une maîtrise fine des bases de données, des patterns d'architecture, de la sécurité et de la performance qu'un fullstack n'aura pas. De la même manière côté frontend.

Il y a aussi un aspect psychologique. Les meilleurs développeurs veulent généralement approfondir leur expertise dans un domaine plutôt que rester en surface sur plusieurs. En scale-up, vous attirez des talents en leur offrant la possibilité de devenir vraiment excellents dans leur spécialité. Phénomène intéressant que j'observe : les devs qui commencent fullstack dans une startup finissent souvent par se spécialiser naturellement au fur et à mesure que l'équipe grandit. Cette évolution est saine et devrait être encouragée.

Le piège du mouton à 5 pattes

Cherchez un fullstack qui maîtrise React, Vue, Angular, toutes les bases de données du marché, le DevOps et qui fait
du design dans Figma, et vous chercherez six mois sans rien trouver. Pendant ce temps, vos concurrents recrutent un
bon backend + un bon frontend, ils livrent, ils apprennent. Soyez honnête sur ce dont vous avez besoin : trois devs
qui démarrent un MVP ? Un fullstack par défaut. Dix devs qui livrent en parallèle ? Spécialistes obligatoires.

Les profils data : analyst, scientist, engineer

Les métiers autour de la data sont souvent confondus. Analyst, Scientist, Engineer : ces trois profils ont des compétences, des missions et des moments d'intervention très différents. La règle d'or : on les recrute dans cet ordre exact, et jamais avant d'avoir un produit avec des utilisateurs.

Data analyst

Le data analyst a un métier en apparence simple : analyser les données à sa disposition pour en tirer des enseignements. En pratique, c'est un rôle fondamental qui transforme des chiffres bruts en recommandations actionnables pour les équipes produit, marketing et business.

Son terrain de jeu principal, c'est l'usage qui est fait de votre produit. Quel écran bloque les utilisateurs dans un parcours d'inscription ? À quel moment décrochent-ils dans un tunnel de conversion ? Quelle fonctionnalité est réellement utilisée et laquelle ne l'est jamais ? Identifier ces points de friction est critique pour la réussite d'un produit, et un bon analyst doit pouvoir faire des préconisations régulières là-dessus.

En termes d'outils, son langage de prédilection est le SQL, et il est adepte de solutions de visualisation comme Tableau, Zoho Analytics, Metabase ou Power BI. La différence entre un junior et un senior ne se situe pas dans la maîtrise du SQL — elle se situe dans la capacité à savoir quelles requêtes poser et comment interpréter les résultats. Un junior produit les rapports qu'on lui demande. Un senior propose des analyses que personne n'avait pensé à demander.

C'est à mon sens le premier profil data à intégrer. Tant qu'il n'y a pas de data analyst, c'est souvent le Product Owner qui fait ce travail — et l'analyse finit par être sacrifiée au profit de tâches plus urgentes. Pour commencer, pas besoin d'une infra data sophistiquée. Chez Wizbii, notre premier analyst travaillait avec des données mises à disposition dans une simple base SQL. Pas très scalable, mais largement suffisant pour les premiers mois.

Data scientist

Le data scientist utilise les données à sa disposition pour créer des modèles de machine learning qui répondent à des besoins métier concrets : classification de documents, détection de fraudes, systèmes de recommandation, prédiction de comportements. Ce sont des problèmes que les approches classiques de développement ne peuvent pas résoudre efficacement, et qui nécessitent de laisser un algorithme apprendre à partir des données.

Un point important : le data scientist ne crée que très rarement de nouveaux algorithmes. Il utilise ceux qui sont publiquement disponibles en étant capable de les comprendre suffisamment pour choisir celui ou ceux qui répondent à son besoin. Sa vraie valeur n'est pas dans l'invention d'algorithmes mais dans sa capacité à formuler un problème business en termes mathématiques, à sélectionner et configurer le bon modèle, puis à évaluer si les résultats sont suffisamment fiables pour la production.

Quand un data scientist travaille sur le bon problème, l'impact peut être spectaculaire. Chez Wizbii, deux data scientists travaillaient sur la classification automatique de milliers d'offres d'emploi — niveau de qualification, zone géographique, catégorie. Sans cette automatisation, impossible de proposer des résultats pertinents aux utilisateurs sans intervention humaine. Sur un précédent client, j'ai vu des data scientists transformer la trajectoire SEO d'une entreprise en classifiant correctement des pages de forum pour créer des liens entre les documents. Le trafic organique avait été transformé.

Mais — et c'est crucial — le data scientist ne se justifie que si vous avez un problème concret que le ML peut résoudre. Si vous n'avez pas de problème de classification, de recommandation, de détection de patterns ou de prédiction, il va tourner en rond. Pire, il risque de créer des solutions en cherchant des problèmes, ce qui est la recette pour dépenser beaucoup de temps et d'argent sans résultat tangible. L'erreur la plus courante : recruter un data scientist par effet de mode, alors que l'entreprise a juste besoin d'un meilleur reporting.

Data engineer

Le data engineer est là pour mettre à disposition les données de l'entreprise aux analyst et scientist. C'est avant tout un développeur, mais un développeur qui s'est spécialisé dans le domaine de la donnée. Il connaît la majorité des bases de données du marché, les formats de fichiers, les protocoles de transfert, et peut choisir les bons outils selon le contexte.

Concrètement, il conçoit et maintient les pipelines qui transportent vos données depuis les bases de production vers des systèmes optimisés pour l'analyse : Data Warehouses, Data Lakes, ou d'autres architectures selon les besoins. Il s'assure que les données arrivent au bon endroit, au bon moment, dans le bon format, et surtout avec le bon niveau de qualité.

Le data engineer travaille beaucoup avec les développeurs backend, car ce sont souvent eux qui créent les données et leur schéma dans les bases de production. Cette collaboration est essentielle et fonctionne dans les deux sens. Chez Wizbii, quand nous avons mis en place les transferts MongoDB → BigQuery, le data engineer a implémenté toute la partie complexe avec Spark : framework de transfert, transformations, gestion des erreurs. Ensuite, la configuration des transferts pour chaque nouvelle collection a été confiée aux backends, qui étaient les mieux placés pour décider du format et des champs pertinents. Ils n'avaient pas la compétence pour implémenter le pipeline avec Spark, mais une fois en place, ils s'en servaient en autonomie.

Cette manière de fonctionner — construire la plateforme puis la mettre à disposition des équipes — ressemble beaucoup à ce que fait un SRE dans le mouvement DevOps. Le rôle n'est pas de répondre à toutes les demandes de données de l'entreprise, mais de construire une plateforme qui permette à chacun de se servir. Beaucoup plus scalable que de centraliser toutes les demandes sur une seule personne.

C'est typiquement le troisième profil data à recruter, après l'analyst et éventuellement le scientist. À l'inverse, chez Winter, nous avions mis en place un Data Warehouse avec Zoho Analytics assez rapidement, mais sans data engineer pour en assurer la qualité. Résultat : des problèmes réguliers de cohérence dans les données et des décisions plus compliquées à prendre. Si vous n'êtes pas encore prêt pour un recrutement permanent, une prestation court terme pour mettre en place la solution, puis laisser l'équipe existante la piloter, est une option intéressante.

L'ordre de recrutement par stade de maturité

Voici la séquence que je recommande quasi-systématiquement après un MVP — et que j'applique en mission de création d'équipe tech & produit.

Pré-MVP (avant validation produit). Personne. Vraiment. Soit vous êtes le fondateur technique et vous codez, soit vous prenez un fractional CTO armé d'IA agentique sur un format Sprint Fondateur. Recruter avant d'avoir validé votre PMF, c'est cramer du cash sur une équipe qui ne sera plus la bonne dans six mois.

Post-MVP, 0 → 2 devs. Premier recrutement : un backend confirmé/senior qui sait gérer aussi l'infra et le CI/CD. C'est lui qui pose les fondations. Deuxième recrutement (souvent dans la foulée) : un fullstack qui pourra renforcer le backend et démarrer les écrans manquants, ou un frontend confirmé si votre produit est très UX-driven.

Post-MVP, 3 → 5 devs. Vous pouvez ajouter des juniors sous encadrement seniors. C'est aussi le moment où un premier data analyst commence à se justifier, si vous avez assez d'usage pour qu'il en tire quelque chose. Pas avant.

Post-PMF, 6 → 15 devs. La spécialisation devient pertinente. Backend et frontend dédiés, premier vrai design system, parfois un premier dev mobile si votre produit l'exige. Le data analyst devient indispensable. Vous commencez à voir la nécessité d'un Engineering Manager pour faire grandir tout ce monde.

Scale-up, 15 → 50 devs. Spécialisation poussée. Premier data engineer si la plomberie data devient un vrai sujet. Premier SRE dédié quand l'infra dépasse ce que les backends peuvent gérer en parallèle de leur métier. Premier Head of Engineering à partir de ~30 collaborateurs tech.

50+ devs. Tous les profils sont possibles, y compris data scientist si et seulement si vous avez un problème ML concret à résoudre. Si vous recrutez un data scientist parce que "c'est cool d'avoir de la data science", vous le perdrez en six mois — et avec lui le coût d'un mauvais recrutement.

Ce qui change en 2026 avec l'IA agentique

L'IA agentique ne change pas les rôles — elle change les ratios. Et ça impacte directement la composition d'équipe.

Premier effet : un dev senior productif équipé d'IA agentique fait 2 à 3 fois plus qu'avant. Une équipe de 40 développeurs équipée et formée peut absorber la charge qui aurait nécessité 60 à 80 développeurs sans ces outils. Concrètement, si vous prévoyez de recruter 10 développeurs cette année pour tenir votre roadmap, il est probable que 1 à 2 suffisent — à condition que votre équipe existante soit correctement formée. Les chiffres détaillés sont dans le ROI de l'IA agentique. L'objectif n'est jamais de licencier — c'est d'aller plus vite, plus loin, sans que la tech devienne un goulot d'étranglement.

Deuxième effet : l'écart de productivité entre junior et senior se réduit. Pas parce que le junior est devenu senior, mais parce que l'IA compense les compétences qu'il n'a pas encore. Un junior équipé d'un CLAUDE.md riche et de conventions documentées monte en compétences 2 à 3 fois plus vite. Vous pouvez recruter des profils plus juniors (moins chers, plus disponibles, plus faciles à attirer) sans sacrifier la qualité. Mais le senior devient plus critique, pas moins : il devient l'architecte-reviewer qui définit les conventions, structure les projets pour que l'IA soit efficace, revoit le travail produit, et mentore les juniors. Tout ça est détaillé dans les nouveaux rôles dans une équipe tech augmentée par l'IA.

Troisième effet : le profil hybride dev + culture produit (le PO Technique) prend une importance considérable. Un développeur expérimenté qui comprend le produit peut, avec un agent IA, livrer ce qui demandait auparavant une équipe de 3 à 5 personnes. Ratio observé sur le terrain : sur un backoffice complet, estimation classique à 40 jours-homme, livraison effective en 2 jours-homme par un PO Technique. Facteur 20 sur une vraie feature, pas un benchmark. Ça ne vaut pas pour tout (les sujets à forte complexité technique ou architecturale demandent toujours des spécialistes), mais sur tout le CRUD-like — back-offices, intégrations, dashboards — c'est redoutablement efficace.

Quatrième effet : la migration cloud → bare metal devient accessible. Avec l'IA agentique, un DevOps généraliste peut monter un cluster Kubernetes sur du bare metal avec une fiabilité équivalente au cloud public, pour un coût 5 à 10 fois inférieur. Ça change la composition d'équipe : moins besoin d'un SRE expert dédié quand vous démarrez, plus tard que prévu pour le premier vrai recrutement infra.

Concrètement, en 2026, je conseille moins de recrutements mais plus de seniors et plus de PO Techniques. Et je laisse Terraform et l'IaC pour beaucoup plus tard qu'avant — quand l'IA assiste sur la configuration, l'over-engineering infra coûte plus qu'il ne rapporte.

Les erreurs classiques au moment du recrutement

Trois erreurs reviennent dans 80% des missions où on m'appelle pour "remettre l'équipe en route".

Le mouton à 5 pattes. Le développeur qui maîtrise parfaitement backend et frontend, connaît toutes les bases de données, peut gérer l'infra les yeux fermés, et qui en plus est dispo pour le salaire que vous proposez. Cette personne n'existe pas — ou alors elle a déjà créé sa propre boîte. Résultat : six mois à chercher pendant que vos concurrents avancent avec des profils certes moins parfaits sur le papier, mais qui font le job. Soyez honnête sur ce dont vous avez vraiment besoin.

La techno exotique. Beaucoup de fondateurs se laissent séduire par le dernier framework à la mode, pensant que ça va faciliter le recrutement ou rendre le produit plus moderne. C'est exactement l'inverse. En choisissant un framework ultra récent ou une base exotique, vous réduisez drastiquement votre vivier. Pire, vous prenez le risque de vous retrouver bloqué si la techno n'est plus maintenue dans deux ans. Restez sur des standards éprouvés. PHP/Symfony offre un écosystème mature et un vivier large en France. Java avec un framework récent reste une valeur sûre. Node.js peut fonctionner — mais la qualité des profils est plus inégale. Côté frontend, React reste le choix le plus sûr ; Vue.js fonctionne bien en France. Tout le détail du raisonnement dans choisir ses technologies. La productivité ne vient pas de l'exotisme de la stack — elle vient de la capacité à livrer de la valeur sans friction.

Sous-évaluer l'infrastructure. Les fondateurs surinvestissent souvent côté code (frameworks tendance, architecture micro-services pré-PMF) et sous-investissent côté infra (cloud public par défaut, pas de monitoring, pas de backups). C'est l'inverse qu'il faut faire : un setup infra simple et solide (Docker + VPS, backups testés, monitoring basique) couvre 90% des startups jusqu'à plusieurs millions d'utilisateurs — Wizbii tournait sur 3-4 serveurs bare metal avec 2-3 millions d'utilisateurs. La sur-ingénierie infra pré-PMF est pure perte. Pour les processus de sélection, le détail dans process de recrutement et tests techniques en recrutement.

Ce qu'il faut retenir

Composer une équipe tech, ce n'est pas trouver le profil parfait. C'est faire les bons choix au bon stade : backend confirmé en premier, polyvalence pré-PMF, spécialisation post-PMF, data analyst avant data scientist avant data engineer. Restez sur des technologies éprouvées qui facilitent le recrutement à 12-18 mois. Recrutez moins mais mieux quand votre équipe est outillée IA agentique — l'écart entre une équipe formée et une équipe non formée se compte aujourd'hui en facteurs 2 à 3, et l'écart se creusera. Et surtout, ne sautez pas les étapes : un Data Scientist sans Data Analyst, un Tech Lead sans Engineering Manager, un cluster Kubernetes sans premier dev backend confirmé — autant de manières classiques de cramer du cash avant d'avoir validé votre produit.

Si vous êtes en phase de structuration post-MVP, c'est exactement le moment où une mission de création d'équipe tech & produit ou un accompagnement IA agentique est la plus rentable : on vous évite les six mois d'errance à chercher la perle rare, et on vous met en piste pour les bons recrutements dans le bon ordre.

CTO, Head of Engineering, Lead Dev, Engineering Manager : qui pour quoi à quelle taille d'entreprise

Rémi Alvado — Thu, 25 Jun 2026 21:26:36 +0000

La confusion entre CTO, Head of Engineering, Tech Lead et Engineering Manager est l'une des erreurs de structuration les plus coûteuses que je rencontre. Un fondateur qui recrute "un CTO" alors qu'il a besoin d'un EM. Un CTO premier dev qu'on charge de missions stratégiques pour lesquelles il n'est pas armé. Un Tech Lead qu'on positionne là où une équipe partagée fonctionnerait mieux. Un Head of Engineering recruté trop tôt, qui repart au bout de huit mois faute de terrain de jeu.

À chaque fois, ça coûte des dizaines de milliers d'euros (le mauvais recrutement), des mois de retard (l'équipe se grippe), et parfois une perte de confiance entre fondateurs et tech qui met deux ans à se réparer. Ce guide synthétise ce que j'ai appris en accompagnant des dizaines de CTO et d'équipes techniques en croissance — ce que Wizbii m'a appris pendant 10 ans, et ce que je vois aujourd'hui chez mes clients en création d'équipe tech & produit ou en accompagnement scaling.

TL;DR : taille d'entreprise vs rôles présents

Taille tech	CTO	Head of Engineering	Engineering Manager(s)	Tech Lead(s)
0-2 devs	Fondateur ou Fractional	Non	Non	Non
3-10 devs	1 (premier dev ou architecte)	Non	Non (rôle assumé par CTO)	Évitez — répartition à privilégier
10-30 devs	1 (idéalement Manager)	Pas encore	2-4 (un par squad)	Mission ponctuelle (3-6 mois)
30-50 devs	1 (Leader stratégique)	1	4-7	Mission ponctuelle uniquement
50-150+ devs	1 (C-Level)	1 + Heads spécialisés	7+, organisés par staff EM	Pas de Tech Lead permanent

Trois principes traversent ce tableau, que je détaille dans tout ce qui suit. Premièrement, le rôle de CTO change selon la taille — les attendus à 10 devs ne sont pas ceux à 100. Deuxièmement, le Tech Lead permanent est presque toujours une erreur ; ce qu'on cherche derrière, c'est un Engineering Manager. Troisièmement, l'option fractional permet de gagner deux ans sur un recrutement définitif — et c'est presque toujours la bonne option pour ouvrir un poste de C-Level technique.

Types de CTO

Embaucher un CTO est une décision structurante, que vous soyez une startup en amorçage, une scale-up en hyper-croissance ou une PME en digitalisation. Mais derrière ce titre unique se cachent des réalités très différentes. J'identifie quatre profils distincts, avec des forces, des angles morts et des contextes idéaux qui ne se recouvrent pas.

Vue d'ensemble des 4 profils

Profil	Force principale	Point de vigilance	Contexte idéal
Premier Dev	Connaissance intime du code	Manque d'expérience managériale	Startup early-stage
Architecte	Excellence technique	Éloignement du business	Produit tech-intensive
Manager	Process et organisation	Déconnexion de la technique	Scale-up structurée
Leader	Vision stratégique	Rareté sur le marché	Toutes tailles

Le CTO "Premier Dev"

C'est souvent le premier développeur de l'entreprise. Jeune, investi, il connaît le code par cœur. Le titre de CTO lui a été donné pour crédibiliser l'entreprise vis-à-vis des investisseurs et des candidats. Ses forces : rapidité d'exécution sur le MVP, connaissance intime de la codebase, coût salarial maîtrisé.

Ses limites sont moins techniques que stratégiques. Définir la vision technique : sans expérience de différents contextes (scale, M&A, pivots), il est difficile de prendre du recul et de définir une trajectoire alignée avec le business. Créer un actif valorisable : la propriété intellectuelle, l'architecture scalable et la documentation sont souvent négligées au profit de la vélocité pure. Recruter et faire grandir une équipe : conduire des entretiens, définir des grilles salariales, onboarder efficacement — ces compétences s'acquièrent avec le temps. Gérer les relations externes : dossiers CIR, audits de sécurité, négociations hébergeurs demandent une maturité qu'il n'a pas encore.

Ce profil junior progresse vite. Sa valeur marché augmente rapidement. Sans attention (salaire, responsabilités, perspectives), il risque de partir. Surveillez les signaux faibles : baisse de motivation, télétravail croissant, désengagement. La solution : un coaching CTO personnalisé pour développer ses compétences managériales et stratégiques sans mettre l'entreprise à risque.

Le CTO "Architecte"

Expert technique reconnu, ce CTO excelle dans la conception de systèmes robustes. Il garantit une plateforme de qualité… mais reste souvent dans sa zone de confort. Ses forces : excellence technique, choix d'architecture pertinents, capacité à résoudre des problèmes complexes, crédibilité auprès des équipes.

Ses angles morts : l'équipe (peu de management, pas de culture commune), la vision business (déconnexion des enjeux marché), le recrutement (tendance à cloner son propre profil), et l'over-engineering (par curiosité technique, il fait des choix technologiques trop complexes pour le stade de l'entreprise — Kubernetes pré-PMF, micro-services à 5 devs, etc.).

Deux chemins possibles selon ses appétences. Soit il reste expert, et on lui adjoint un Head of Engineering pour le management. Soit il évolue vers le business, ce qui demande un accompagnement intensif avec des pairs expérimentés pour développer sa vision stratégique. Les deux choix sont légitimes — mais il faut les expliciter, sinon ce CTO se retrouve à faire deux mi-temps mal couplés.

Le CTO "Manager"

Aussi appelé "CTO Hands Off", son travail n'est pas de faire, mais de faire faire. Il excelle dans la mise en place de processus et l'organisation des équipes. Ses forces : processus efficaces et évolutifs, excellente préparation aux Due Diligences (documentation, équipes alignées), capacité à rassurer les investisseurs.

C'est un profil particulièrement adapté à la préparation d'opérations capitalistiques (levée, M&A). Mais ses limites : taille critique requise (ce CTO ne peut s'épanouir qu'avec une équipe d'au moins 10 développeurs), besoin de relais techniques seniors, parfois issu de grands groupes (DSI), il peut manquer d'agilité, et il y a un risque de conservatisme technologique.

Quand est-ce le bon profil ? Post-Product Market Fit, quand la stabilité prime sur l'expérimentation. Avant une levée ou un M&A : c'est le profil idéal pour structurer. En phase de scaling : il sait organiser la croissance.

Le CTO "Leader"

C'est le profil qu'on imagine quand on pense "CTO" : charismatique, visionnaire, capable de transformer l'entreprise par sa compréhension du marché et de la technique. Pourquoi il est rare : il nécessite des années d'expérience variée, est souvent fondateur ou co-fondateur (donc peu disponible), et reste très fidèle (a besoin de temps pour maîtriser le contexte).

Ce CTO coche toutes les cases : vision, exécution, management, stratégie. Ses équipes prennent les bonnes décisions sans lui — c'est le signe d'un leadership mature. Comment le garder ? Package attractif (BSPCE, equity, intéressement — le détail dans BSPCE oui ou non), périmètre large (laissez-le influencer au-delà de la tech), impact visible (c'est sa motivation principale).

Et si une seule personne portait Tech ET Produit ? Dans certains contextes (early-stage, équipe réduite), fusionner les rôles de CTO et CPO en un CTPO peut accélérer les décisions. C'est un modèle que j'ai pratiqué pendant près de 10 ans chez Wizbii et que je détaille dans CTO et CPO : faut-il fusionner les deux rôles ?

Head of Engineering

Dans une startup en croissance, il arrive un moment où le CTO ne peut plus tout faire. Entre la gestion des Engineering Managers, les sujets d'infrastructure, la data, les choix technologiques et son rôle au CODIR, ses journées débordent et ses missions de C-Level passent au second plan. C'est exactement le moment où le Head of Engineering entre en jeu.

Le bon moment : autour de 30 collaborateurs tech

Le seuil n'est évidemment pas une science exacte, mais dans mon expérience, c'est autour de 30 collaborateurs techniques que le besoin devient évident. À ce stade, le CTO gère directement 4 à 5 Engineering Managers, plus quelques fonctions transverses comme la data ou l'infrastructure. Même en étant très organisé, il ne lui reste plus assez de temps pour ses activités de C-Level : la réflexion stratégique à long terme, la représentation de l'entreprise à l'extérieur, le test de nouvelles méthodologies. Chez Wizbii, c'est précisément ce qui s'est passé. Quand l'équipe technique a atteint cette taille, recruter un Head of Engineering est devenu une nécessité pour que le CTO puisse se recentrer sur ce qui fait la valeur d'un rôle de C-Level.

Mais il existe un second pattern, plus fréquent dans les startups de taille plus modeste. Autour de 10 développeurs, certains CTO fondateurs veulent rester dans la technique et n'ont aucune appétence pour le management au quotidien. Ils gardent leur titre de CTO via leur statut de fondateur, mais délèguent l'essentiel de la gestion d'équipe à un Head of Engineering. C'est un schéma qui fonctionne bien, à condition que les rôles soient clairement définis et que le Head of Engineering ait réellement les mains libres pour structurer.

Recrutement externe pour ouvrir le poste

Contrairement à d'autres postes de management où la promotion interne fait souvent sens, je recommande plutôt un recrutement externe pour l'ouverture d'un poste de Head of Engineering. La raison est simple : ce rôle va structurer une organisation qui n'existe pas encore sous cette forme. Il faut quelqu'un qui a déjà eu cette responsabilité ailleurs, qui sait mettre en place les bons processus et qui apporte un regard neuf. La mise en place de méthodes comme Accelerate, la refonte du format des entretiens individuels, la structuration des parcours de carrière : tout cela nécessite une expérience qu'un Engineering Manager interne n'a pas forcément encore acquise.

Une option intéressante est de confier cette ouverture de poste à un prestataire dans un premier temps. Un Head of Engineering en mission de transition peut structurer le rôle, mettre en place les fondations, puis passer les rênes à un développeur senior ou un Engineering Manager déjà dans l'entreprise une fois l'organisation stabilisée. C'est exactement la logique de mes missions de création d'équipe tech & produit.

Le binôme avec le CTO : la clé de tout

L'erreur la plus fréquente sur ce poste n'est pas un manque de compétence technique ou managériale. C'est un problème de matching culturel. Le Head of Engineering est celui qui va faire passer les messages du CODIR auprès des équipes techniques au quotidien. Si cette personne ne partage pas les valeurs de l'entreprise, ou si sa manière de communiquer ne colle pas avec l'ADN de l'équipe, les dégâts peuvent être considérables. Les développeurs vont sentir la dissonance immédiatement, et la confiance sera très difficile à reconstruire.

Plus que les compétences métier — qui sont évidemment indispensables — il faut trouver un vrai partenaire pour le CTO. Quelqu'un avec qui la confiance sera très forte, car ces deux personnes vont former un binôme étroitement lié. Le CTO donne la direction, le Head of Engineering s'assure que l'organisation suit. Si la communication entre les deux est fluide, l'ensemble de la chaîne technique en bénéficie. Si elle grince, tout le monde le ressent.

Les autres "Head Of" à connaître

Le Head of Engineering n'est pas le seul rôle de ce type qui peut apparaître. Le Head of Platform Engineering devient pertinent quand l'équipe SRE dépasse les 7 à 10 personnes — l'infrastructure devient un sujet suffisamment stratégique pour justifier un responsable dédié. Le Head of Quality est un rôle que j'évite autant que possible, la qualité étant la responsabilité de chacun ; mais dans des entreprises soumises à des contraintes réglementaires fortes (fintech, healthtech, défense), centraliser cette responsabilité peut avoir du sens. Le Head of Developer Relations est plus rare mais peut devenir pertinent dès 7 à 10 DevRel — la plupart des CTO ne connaissent que mal cette fonction, et la structurer tôt évite d'improviser.

L'autre erreur classique sur le Head of Engineering : recruter trop tôt. Si l'entreprise prévoit une vague d'embauche technique qui ne se concrétise pas, le Head of Engineering recruté se retrouve avec un terrain de jeu insuffisant. Et dans ce cas, il est probable qu'il parte de lui-même, frustré par un périmètre qui ne correspond pas à ce qu'on lui avait vendu. Mieux vaut attendre que le besoin soit réel et concret, quitte à passer par une phase de transition avec un prestataire pour absorber la charge en attendant.

Engineering Manager vs Lead Dev

Les fondateurs qui cherchent à structurer leur équipe technique tombent souvent sur le même réflexe : recruter un Tech Lead. C'est un titre rassurant, qui évoque un profil expérimenté capable de porter la technique. Mais dans la majorité des cas, ce n'est pas d'un Tech Lead dont ils ont besoin. C'est d'un Engineering Manager. Et la confusion entre les deux rôles est l'une des erreurs d'organisation les plus fréquentes que je rencontre.

Deux rôles, deux missions très différentes

Le Tech Lead est avant tout un expert technique. C'est en général un développeur très expérimenté qui connaît les bons patterns à appliquer, les pièges à éviter, et qui peut prendre les décisions d'architecture les plus structurantes. Le mot "technique" dans son titre a toute son importance : c'est un leader sur le plan du code, pas sur le plan humain. Il ne gère pas les carrières, ne fait pas d'entretiens individuels, ne s'occupe pas de la montée en compétence de l'équipe au-delà de la dimension technique pure.

L'Engineering Manager, à l'inverse, est un manager. Sa mission première est de faire grandir les développeurs qui composent son équipe : gérer leur progression de carrière, identifier leurs forces et leurs axes d'amélioration, s'assurer qu'ils s'épanouissent et qu'ils progressent. C'est aussi (ou c'était aussi) un développeur, mais ce n'était pas forcément le meilleur d'entre eux. Ce qui le distingue, c'est avant tout une appétence pour le management et pour tout ce qui fait qu'une équipe fonctionne bien ensemble : la répartition de la charge, l'équilibre entre temps forts et temps faibles, la vélocité collective.

Intelligence collective plutôt qu'expertise centralisée

Les entreprises qui cherchent des Tech Leads n'ont en général pas compris que la principale force d'une équipe technique réside dans son intelligence collective et dans sa résilience. Avoir un Tech Lead va à l'encontre de tout ça : il centralise des compétences au lieu de les faire rayonner. Si cette personne part, prend des vacances ou veut simplement changer de projet, l'équipe se retrouve démunie sur les sujets qu'elle portait seule.

C'est l'inverse que je cherche systématiquement. Plutôt que de concentrer l'expertise chez une seule personne, je préfère répartir le rôle de leadership technique entre les membres de l'équipe. Chaque développeur senior peut porter une partie de cette responsabilité : l'un est référent sur les choix d'architecture, l'autre sur les pratiques de test, un troisième sur la performance. Cette répartition rend l'équipe beaucoup plus résiliente et permet à chacun de monter en compétence sur des sujets qui dépassent son périmètre habituel.

Quand le Tech Lead en prestation fait sens

Il existe des situations où une expertise technique pointue est nécessaire et où personne dans l'équipe ne la possède. Dans ce cas, plutôt que de recruter un Tech Lead permanent, je recommande de faire appel à un expert en prestation courte, de 3 à 6 mois maximum. J'ai par exemple fait intervenir des SRE pour mettre en place une infrastructure de monitoring, des experts en développement mobile pour lancer une application native, ou des spécialistes data pour structurer un premier pipeline. La mission est claire : mettre en place le projet, former l'équipe, transmettre les connaissances, puis partir en laissant le projet entre de bonnes mains.

Cette approche a plusieurs avantages considérables. D'abord, c'est l'équipe entière qui monte en compétence, pas une seule personne. Ensuite, le prestataire sait qu'il est là de manière temporaire, ce qui élimine les questions d'ego et de territoire. Il n'a aucun intérêt à garder son expertise pour lui puisque sa mission est précisément de la transférer. On apporte ainsi une bien plus grande résilience à l'équipe, et on évite le risque classique d'avoir une compétence critique concentrée chez une seule personne qui peut partir du jour au lendemain.

Quand promouvoir en interne vs recruter en externe

C'est l'un des arbitrages les plus structurants — et les plus délicats — quand on fait grandir une équipe technique. La règle que j'applique : on promeut en interne pour les rôles de coaching opérationnel ; on recrute en externe pour les rôles de structuration organisationnelle.

Promotion interne pour les rôles opérationnels : Engineering Manager (un développeur qui s'intéresse aux dynamiques d'équipe — c'est presque toujours le bon choix), Tech Lead temporaire sur un sujet ponctuel, Head of Product (cf. l'article dédié sur les rôles produit en 2026). Recrutement externe pour les rôles de structuration : Head of Engineering (qui doit installer une organisation managériale qui n'existe pas), CTO senior (qui doit apporter une expérience qu'un premier dev n'a pas encore acquise), VP Engineering dans les organisations très grandes.

La transition dev → Engineering Manager

C'est la promotion interne la plus fréquente, et c'est presque toujours la bonne. La transition vers le rôle d'EM ne se décrète pas du jour au lendemain. C'est un chemin progressif que j'ai pu observer chez quasiment tous les Engineering Managers avec qui j'ai travaillé. Le schéma est presque toujours le même : un développeur commence à s'intéresser à ce qui pourrait rendre l'équipe meilleure. Il passe souvent par un rôle de Scrum Master tournant, ce qui lui donne une première exposition aux dynamiques d'équipe, à la facilitation, aux problèmes d'organisation. C'est là qu'il prend conscience de ce qu'il peut apporter au-delà du code.

On lui confie ensuite des responsabilités progressives. D'abord l'encadrement d'un stagiaire, puis d'un alternant. Si ça fonctionne, il bascule petit à petit vers un rôle d'EM sur une petite équipe de 4 à 5 personnes, avant éventuellement de prendre une équipe plus grande pouvant aller jusqu'à 10 personnes. Cette progression graduelle a un double avantage : on peut évaluer le candidat à chaque étape, et lui-même peut décider si le rôle lui convient vraiment. J'ai vu des développeurs excellents tester le management et revenir vers un rôle purement technique sans que personne ne le vive mal, justement parce que la transition avait été progressive.

Un point essentiel dans cette transition : il faut essayer de laisser à l'EM au moins 50% de son temps en développement. Ne pas perdre la main sur son expertise technique lui permet de rester crédible auprès de son équipe et surtout de bien comprendre les enjeux concrets de ses collaborateurs. Un manager qui ne code plus du tout finit par perdre le contact avec la réalité du terrain, et les développeurs le sentent très vite.

Repérer les bons candidats internes

Le signal le plus fiable que j'ai observé, c'est le développeur qui commence spontanément à réfléchir à comment l'équipe pourrait aller encore mieux. Pas uniquement sur le plan technique, mais sur le plan organisationnel et humain. Les entretiens trimestriels sont un excellent moment pour sonder cette appétence : demander à chaque développeur comment il se voit évoluer dans les 2, 5 et 10 ans à venir permet de détecter ceux qui envisagent naturellement une trajectoire managériale.

Le cas du fondateur non technique

Il y a un cas où recruter un EM en externe fait particulièrement sens : quand les fondateurs exercent d'autres expertises (métier, marketing, sales, produit) et ne se sentent pas légitimes à manager des développeurs. Dans ce contexte, l'EM est le premier profil technique à structurer. Il saura aussi faire du développement, ce qui est crucial dans une petite équipe, mais sa valeur ajoutée principale sera de manager l'équipe tech avec la crédibilité technique que les fondateurs n'ont pas. C'est un choix bien plus pertinent qu'un Tech Lead qui ne ferait que du code sans s'occuper de la dimension humaine.

Les 5 signaux qu'il est temps de structurer

Vous reconnaissez ces patterns dans votre équipe ? C'est le moment d'agir. (1) Votre prestataire est devenu
indispensable et vous n'osez plus changer. (2) Les décisions techniques sont opaques même pour le CEO. (3) Le
time-to-market s'allonge sans qu'on sache pourquoi. (4) Vous préparez une levée et la due diligence vous fait peur.
(5) Le turnover s'accélère sur l'équipe tech. Le détail dans les 5 signaux qu'il est temps de structurer votre équipe
tech.

L'option Fractional : un raccourci sous-utilisé

L'option fractional — un CTO ou un Head of Engineering à temps partagé pendant une période définie — est probablement la plus sous-utilisée des startups françaises. C'est dommage, parce qu'elle permet de gagner deux ans sur un recrutement définitif et d'éviter les pires erreurs de structuration.

Le principe est simple : vous prenez un CTO senior 2 à 3 jours par semaine pendant 6 à 12 mois, dans une logique de mission claire. Cette mission s'organise typiquement en trois étapes. Étape 1 : audit (1-2 mois). Le fractional CTO réalise un audit technique, identifie les risques (dette, recrutement, dépendances externes), pose un diagnostic factuel sur l'état de la tech, et propose un plan en 3 horizons (court, moyen, long terme). Étape 2 : transition (3-6 mois). Il met en place les fondations : structuration de l'équipe, processus de recrutement, premiers EM, métriques d'équipe, animation des rituels. Étape 3 : recrutement définitif (2-3 mois). Il pilote le recrutement de son successeur en CDI — souvent quelqu'un qu'il aurait pu cibler dès l'audit, mais qu'il choisit avec le contexte acquis pendant la mission. Il assure ensuite la passation.

Cette logique vaut autant pour ouvrir un poste de CTO (c'est exactement le format de mes missions de création d'équipe tech & produit) que pour ouvrir un poste de Head of Engineering. Le coût est largement compensé par les recrutements évités (un mauvais CTO senior coûte 200K€ en salaire + 6-12 mois de retard) et par la qualité du recrutement final, fait en connaissance de cause. Le détail des trois options (CDI, freelance, fractional) avec les fourchettes de prix dans combien coûte un CTO et CTO freelance, fractionnel ou recrutement. Si vous traversez un départ CTO non anticipé, c'est aussi le format d'intervention le plus efficace pour stabiliser sans précipiter.

Quand la Fractional est obligatoire

Trois contextes où je considère la fractional comme la seule bonne option. Premier : la startup post-MVP qui a besoin d'un CTO senior mais qui ne peut pas se l'offrir en CDI (le bon CTO senior coûte 130-180K€ + BSPCE — beaucoup de seed-stage ne peuvent pas suivre). Deuxième : le départ soudain d'un CTO en place — recruter dans l'urgence garantit un mauvais recrutement, alors qu'un fractional couvre l'intérim et pilote la recherche du successeur. Troisième : une Due Diligence technique à préparer en moins de 6 mois — le travail est intense et se termine, donc peu compatible avec un CDI.

Ce que change l'IA agentique sur la pyramide management/IC

L'IA agentique modifie discrètement mais profondément la structure des équipes techniques. Pas dans le sens d'une "fin du management" — au contraire. Mais dans le sens d'un rééquilibrage entre managers et IC (individual contributors).

Premier effet : moins de managers nécessaires. Une équipe plus petite (parce que productivité multipliée par 2-3, cf. le ROI de l'IA agentique) demande mécaniquement moins de niveaux de management. Une équipe de 25 développeurs en 2024 devient une équipe de 12-15 en 2026 avec la même capacité de production. Du coup, là où il fallait 3 EM, il en faut 2. Là où on commençait à parler d'un Head of Engineering, on peut s'en passer encore un an. C'est un réajustement à anticiper, parce que cette logique inverse les schémas de carrière auxquels on est habitués : si l'équipe rétrécit, le passage de dev senior à EM se fait sur des équipes de 5-7 personnes plutôt que de 8-10.

Deuxième effet : les seniors qui codent reprennent du leadership. Avec l'IA, la valeur ajoutée d'un senior se déplace vers la conception (architecture, conventions, structuration des projets pour que l'IA soit efficace) et la revue (savoir lire et challenger du code, pas seulement l'écrire). Le senior devient un architecte-reviewer naturel, et porte de fait une part croissante du leadership technique. C'est exactement ce que je détaille dans les nouveaux rôles dans une équipe tech augmentée par l'IA. Le pattern Tech Lead permanent perd encore en pertinence : le leadership technique se distribue spontanément entre les seniors qui revoient le travail des juniors et de l'IA.

Troisième effet : le CTO devient plus stratège, moins opérationnel. Avec une équipe plus petite mais plus productive, le CTO passe moins de temps à débugger les problèmes d'orga interne et plus de temps à réfléchir à l'avantage concurrentiel que la tech peut créer. Le test que j'utilise : un CTO mature ne dit pas "c'est techniquement faisable", il dit "voici comment cette feature peut générer 20% de CA en plus, et voici le chemin". Avec l'IA agentique qui absorbe une part croissante du temps technique, ce passage à la stratégie devient quasi-obligatoire — ou alors le CTO devient lui-même le goulot d'étranglement.

Quatrième effet : le ratio juniors/seniors s'inverse. Un junior équipé d'un agent IA bien configuré (CLAUDE.md riche, conventions documentées, bonnes pratiques intégrées) monte en compétences 2 à 3 fois plus vite. Vous pouvez recruter des profils plus juniors (moins chers, plus disponibles) sans sacrifier la qualité. Mais le senior devient plus critique : il devient le multiplicateur qui transforme 5 juniors équipés IA en équivalent de 15 développeurs classiques. La pyramide s'inverse : moins de managers, plus de juniors, et des seniors irremplaçables.

Ce qu'il faut retenir

La taxonomie des rôles de leadership tech tient en cinq lignes de force. Premièrement, il y a quatre types de CTO (Premier Dev, Architecte, Manager, Leader) — il faut savoir quel profil vous avez et accompagner sa progression vers les missions qu'il ne maîtrise pas encore. Deuxièmement, le Head of Engineering arrive autour de 30 collaborateurs tech, avec un recrutement externe préférable et un binôme CTO/Head qui repose autant sur le fit culturel que sur les compétences. Troisièmement, le Tech Lead permanent est presque toujours une erreur — préférez l'intelligence collective et les missions ponctuelles. Quatrièmement, on promeut en interne pour les rôles opérationnels (EM, Head of Product) et on recrute en externe pour les rôles de structuration (Head of Engineering, CTO senior). Cinquièmement, l'option fractional est sous-utilisée et permet de gagner deux ans sur un recrutement définitif tout en préparant le terrain.

L'IA agentique accélère trois tendances déjà en cours : moins de managers, plus de seniors-architectes, ratio juniors/seniors inversé. Les fondateurs qui anticipent ces effets dès maintenant auront des équipes mieux structurées et plus efficaces dans 18 mois — ceux qui ne le font pas continueront à reproduire les patterns d'organisation des équipes tech d'il y a cinq ans, avec des coûts plus élevés et une vélocité plus faible.

Si vous êtes en phase de structuration de votre leadership tech, en départ CTO non anticipé, en préparation de Due Diligence, ou en réflexion sur le bon profil à recruter, c'est exactement le moment où une mission de création d'équipe tech & produit est le plus rentable. Si vous êtes en hyper-croissance (10 → 50 développeurs ou plus), c'est un accompagnement scaling qui répond à la question — et qui évite la majorité des erreurs détaillées dans ce guide.

Pour aller plus loin sur les questions connexes : la méthodologie d'audit technique, le fonctionnement du CODIR, la transition d'un fondateur technique vers son rôle de CEO qui doit lâcher le code.

Anatomie d'un cluster Kubernetes de production : HA, multi-tenant et GitOps en une dizaine d'heures

Rémi Alvado — Thu, 25 Jun 2026 21:21:05 +0000

Il y a quelques mois, j'ai raconté ici comment j'avais monté un cluster Kubernetes sur du bare metal pour un client. À l'époque, ça m'avait pris trois semaines. Mes propres projets, eux, tournaient encore sur de bons vieux VPS en Docker Compose. Depuis, j'ai franchi le pas pour moi-même : j'ai construit mon cluster et j'y ai migré l'ensemble de mes produits — le blog que vous lisez, un CRM, une académie de formation, des bases de données, du monitoring, des backups chiffrés. Et reconstruire le tout, aujourd'hui, me prend une dizaine d'heures de travail effectif.

Ce chiffre ne veut rien dire si je ne décris pas ce qu'il y a sous le capot. N'importe qui peut « monter un cluster Kubernetes en une journée » — un cluster qui tombe au premier serveur en panne, qui n'héberge qu'une seule application, dont les secrets traînent en clair dans Git et qu'on ne sait pas restaurer après un sinistre. L'intérêt de l'histoire n'est pas la vitesse. C'est ce que la vitesse permet quand elle s'appuie sur une vraie exigence de qualité. Voici donc l'anatomie complète.

Le point de départ

Cet article est la suite de Kubernetes sur bare metal : une infra résiliente à
100€/mois, qui posait le pourquoi du bare metal et la stack en survol. Ici, on rentre
dans le détail de la plateforme de production. Si le sujet est nouveau pour vous, commencez par là.

Trois semaines, puis dix heures : ce qui a changé

Petit repère temporel, parce qu'il est éclairant. Il y a un an, monter une infrastructure de ce type demandait facilement trois mois à deux SRE. Il y a six mois, avec de l'IA de complétion classique, un développeur senior y arrivait en trois semaines — c'est exactement le chiffre que je donnais dans mon précédent article. Aujourd'hui, avec de l'IA agentique et l'expérience accumulée, le travail humain effectif tient dans une dizaine d'heures.

Soyons précis sur ce que recouvrent ces dix heures, parce que c'est là que beaucoup d'articles trichent. Ce sont dix heures de temps homme : écrire les configurations, piloter les agents, vérifier, corriger, valider. Le temps d'horloge, lui, est plus long — quelques jours au maximum. Mais ces jours, ce n'est pas du travail : c'est de l'attente. OVH qui livre et provisionne les serveurs, les tests de réinstallation pour vérifier qu'une machine repart proprement de zéro, la vérification que le BIOS est à jour, la propagation DNS, l'émission des certificats. De l'attente incompressible qui n'occupe pas mes mains.

Et surtout : ces dix heures ne sont accessibles qu'à quelqu'un qui sait ce qu'il fait. L'IA ne remplace pas l'expertise infrastructure, elle l'amplifie — j'en ai fait un article entier parce que c'est le cœur du sujet. Sans bagage, l'IA vous produit un cluster qui a l'air de marcher et qui s'effondre au premier incident réel. La preuve la plus honnête que je puisse en donner, ce sont les galères que j'ai traversées pour arriver là. Elles sont disséminées dans cet article, et ce sont elles qui font la différence entre une démo et une production.

La stack, en un coup d'œil

Brique	Rôle	Pourquoi ce choix
Talos Linux	OS des nœuds	Immutable, sans SSH, API déclarative — du « bétail »
Cilium	Réseau (CNI) + Gateway + L2	Remplace kube-proxy, Gateway API native, annonce L2 d'IP
ArgoCD	Déploiement GitOps	App-of-apps, sync-waves, tout l'état du cluster dans Git
Sealed Secrets	Secrets dans Git	Secrets chiffrés versionnés, déchiffrables par le seul cluster
cert-manager	Certificats TLS	Let's Encrypt DNS-01, wildcards renouvelés automatiquement
Longhorn	Stockage répliqué	Volumes persistants distribués, backups S3 intégrés
MongoDB / RabbitMQ / Typesense	Données	Bases opérées par des operators, pas bricolées à la main
Prometheus / Loki / Grafana	Observabilité	Métriques, logs, alerting par sévérité

Chacune de ces briques mérite qu'on s'y attarde, parce que c'est dans les détails d'intégration que se joue la différence entre « ça tourne » et « ça tient en production ».

Talos : un OS qu'on ne touche jamais à la main

Talos Linux est un système d'exploitation entièrement dédié à Kubernetes. Pas de shell, pas de SSH, pas de gestionnaire de paquets. On ne se connecte pas à un nœud Talos : on lui parle via une API déclarative, on lui pousse une configuration, et c'est tout. Cette contrainte, qui déroute au début, est en réalité une bénédiction. La surface d'attaque est minuscule. La dérive de configuration — ce moment où un serveur finit par être différent des autres parce que quelqu'un a bidouillé un truc en SSH un soir de production — devient littéralement impossible.

Le revers, c'est que quand le bootstrap se passe mal, on ne peut pas « aller voir » à l'ancienne. Et il s'est mal passé. Lors d'une de mes tentatives de reconstruction, le service etcd refusait de démarrer sur le premier nœud. Les logs finissaient par lâcher la vraie cause : error writing kubelet PKI: read-only file system — le répertoire /etc/kubernetes n'était même pas monté. Diagnostiquer ça sur un OS sans shell, en mode rescue OVH, en remontant la partition système pour comprendre qu'un résidu d'installation précédente bloquait le montage : voilà le genre de problème que l'IA ne résout pas à votre place. Elle aide à formuler des hypothèses, à lire des traces, à se souvenir d'une option obscure. Mais c'est l'expérience qui sait par où commencer à creuser.

L'autre vertu de Talos, c'est qu'il rend concrète la philosophie du « bétail, pas des animaux de compagnie ». Quand un de mes serveurs a eu une défaillance matérielle, je n'ai rien réparé : j'ai demandé un remplacement à l'hébergeur, repoussé la configuration, et le nœud a rejoint le cluster comme si de rien n'était. Un serveur n'est plus un objet précieux qu'on bichonne. C'est une ressource interchangeable. C'est exactement ce qu'on attend d'une infrastructure résiliente, et c'est ce qui permet de dormir tranquille.

Cilium : un seul réseau, une seule IP, tous les projets

Le réseau est l'endroit où la plupart des clusters maison montrent leurs limites. J'ai choisi Cilium, qui remplace à la fois le CNI (le réseau interne des pods), kube-proxy (le routage des services), et fournit nativement la Gateway API ainsi que l'annonce d'adresses IP en couche 2. Une seule brique pour ce qui demande souvent trois ou quatre composants empilés.

Le point d'architecture dont je suis le plus satisfait, c'est la Gateway unique partagée. Dans le modèle Gateway API, la Gateway appartient à l'infrastructure, et les routes (les HTTPRoute) appartiennent aux applications. Concrètement, j'ai une seule porte d'entrée pour tout le cluster, sur une seule IP, et le routage se fait par nom de domaine via SNI. Ajouter un nouveau projet — une nouvelle application, un nouvel environnement — ne consiste jamais à commander une IP supplémentaire. C'est ajouter un listener et une route. Quand on sait qu'une IP de failover par projet et par environnement serait à la fois absurde et coûteuse, ce design fait toute la différence pour la suite.

Cette IP unique est annoncée par Cilium en couche 2, par un mécanisme d'élection : un nœud porte l'adresse, et si ce nœud tombe, un autre la reprend en envoyant un ARP gratuit pour rediriger le trafic. J'ai testé le basculement en conditions réelles — quinze requêtes sur quinze servies pendant la ré-élection. Mais y arriver proprement m'a coûté une vraie panne. En refondant cette partie, un nœud a été élu sans la route réseau adéquate et a englouti le trafic dans un trou noir pendant environ trois minutes. La leçon est précieuse : sur ce genre de mécanisme, le chemin nominal est facile, ce sont les cas limites du basculement qui font mal.

J'ai aussi appris à mes dépens une subtilité de l'implémentation Cilium de la Gateway API. Pour rediriger le HTTP vers le HTTPS, il faut un listener HTTP par domaine, avec un nom d'hôte explicite : un listener « attrape-tout » sans hostname renvoie un 404 au lieu de la redirection attendue. Pire, un listener HTTP générique ne sert pas un domaine déjà réclamé par un listener HTTPS exact. Le symptôme — des redirections qui marchent en staging mais cassent en production — n'a aucun sens tant qu'on n'a pas compris la règle sous-jacente. C'est typiquement le genre de piège qu'on ne trouve dans aucune documentation et qu'on paye en heures de débogage.

GitOps : si ce n'est pas dans Git, ça n'existe pas

Tout l'état du cluster est décrit dans un dépôt Git, et ArgoCD se charge de faire converger le cluster vers cette description. Aucun kubectl apply manuel en production. Aucun hotfix appliqué à la main qu'on oublie de versionner. Un déploiement, c'est un commit ; un rollback, c'est un revert. Cette discipline n'est pas un confort esthétique : c'est ce qui rend le cluster reconstructible. Si tout part en fumée, je recrée les nœuds Talos, ArgoCD resynchronise depuis Git, et l'infrastructure se reconstitue d'elle-même.

L'organisation suit le modèle app-of-apps : une application racine qui décrit toutes les autres, déployées dans un ordre maîtrisé grâce aux sync-waves. Le stockage avant les bases de données, les certificats avant les routes, et ainsi de suite. Cet ordonnancement n'est pas un détail. Installer Longhorn via ArgoCD, par exemple, m'a confronté à deux pièges connus mais bloquants : un hook de pré-installation qui réclamait un compte de service pas encore créé, et le fait que Talos refuse par défaut les pods privilégiés dont le stockage a besoin. Les deux se règlent — désactiver le hook, forcer les labels de sécurité du namespace — mais il faut savoir que le problème existe avant de perdre une soirée dessus.

Pour les secrets, j'utilise Sealed Secrets : les secrets sont chiffrés et versionnés dans Git, et seul le cluster, avec sa clé privée, peut les déchiffrer. Élégant, sauf qu'il y a un point critique souvent négligé. Cette clé maîtresse, si elle change, rend illisibles tous les secrets déjà chiffrés. Lors d'une reconstruction, il faut donc impérativement restaurer l'ancienne clé avant de démarrer le contrôleur, sinon il en génère une neuve et tous les pods se retrouvent en erreur de configuration. C'est le genre de séquence qu'on n'apprend qu'en se l'étant fait une fois.

Structurer votre infrastructure ?

En création d'équipe Tech & Produit, je vous aide à faire les bons
choix d'infrastructure pour votre stade — du VPS au cluster Kubernetes — sans sur-ingénierie ni dette prématurée. Et
si l'enjeu est de déployer l'IA agentique dans vos équipes pour atteindre
ce niveau d'autonomie, c'est tout l'objet de mon accompagnement.

Les données : des bases opérées, pas bricolées

C'est là que beaucoup de clusters maison déraillent. Faire tourner une base de données dans Kubernetes n'est pas trivial : il faut de la réplication, de la persistance, des sauvegardes, et une stratégie de mise à jour qui ne perde pas de données. J'ai fait le choix d'operators dédiés plutôt que de StatefulSets bricolés à la main, parce qu'un operator encode le savoir-faire opérationnel d'une base — comment elle se réplique, comment elle bascule, comment elle se met à jour.

MongoDB tourne en replica set à trois membres, opéré par l'operator officiel, avec une version de compatibilité épinglée pendant les montées de version pour ne jamais se retrouver coincé. RabbitMQ et Typesense sont gérés de la même manière. Chacun a ses subtilités — Typesense, par exemple, exige que son service réseau publie les adresses des pods avant même qu'ils soient prêts, sans quoi le consensus Raft ne s'établit jamais, un classique problème d'œuf et de poule. Côté stockage, Longhorn fournit deux classes : une répliquée pour les volumes critiques uniques, une à réplica unique pour les bases qui se répliquent déjà elles-mêmes au niveau applicatif. Doubler la réplication serait du gâchis.

Et surtout, les sauvegardes. Une base sans sauvegarde testée n'est pas une base, c'est une bombe à retardement. Un CronJob exporte chaque nuit les bases vers un stockage objet S3 chez un autre hébergeur, et Longhorn fait de même pour ses volumes. Le point important : j'ai testé la restauration, pas seulement la sauvegarde. Plusieurs centaines de documents restaurés, comptages identiques à la source. Tant qu'on n'a pas restauré pour de vrai, on ne sait pas si on a une sauvegarde — on a juste un fichier dont on espère qu'il est bon. Si le choix d'une base vous intéresse au-delà du réflexe SQL, j'en ai parlé dans un autre article.

Observabilité : voir ce qui se passe, être prévenu quand ça casse

Un cluster qu'on ne surveille pas est un cluster dont on apprend les pannes par ses utilisateurs. J'ai installé la pile classique : Prometheus pour les métriques, Loki pour les logs, Grafana pour les tableaux de bord. Mais l'observabilité utile ne se résume pas à collecter des chiffres ; c'est savoir lesquels regarder et être alerté au bon moment.

Les alertes partent vers mon téléphone, avec une priorité calée sur la sévérité : une alerte critique sonne, une information passe en silence. Les tableaux de bord eux-mêmes sont versionnés dans Git et déployés par GitOps, comme le reste — un dashboard n'est pas quelque chose qu'on clique à la main et qu'on perd à la prochaine reconstruction. J'ai ajouté des sondes externes qui vérifient en continu que chaque service répond et que les certificats ne vont pas expirer, ainsi qu'une alerte qui se déclenche si une sauvegarde de base venait à manquer. Parce que le pire scénario, ce n'est pas la panne : c'est la panne silencieuse qu'on découvre le jour où on a besoin du backup.

Résister à la catastrophe : la stratégie de survie

C'est le critère qui sépare une infrastructure sérieuse d'un projet de week-end. Que se passe-t-il si je perds tout ? Pas un nœud — tout. Le cluster entier, et mon Mac de travail avec.

J'ai conçu la réponse autour de deux secrets qui ne peuvent pas se régénérer : la clé maîtresse qui déchiffre les secrets du cluster, et le certificat TLS, parce que Let's Encrypt limite le nombre d'émissions par semaine — une limite que j'ai d'ailleurs atteinte en enchaînant les reconstructions, ce qui force à sauvegarder le certificat valide plutôt que d'en redemander un. Ces éléments sont sauvegardés, et le script de reconstruction les réinjecte automatiquement dans le bon ordre. Au-delà, tout mon coffre de secrets est archivé chiffré chez un fournisseur cloud distinct de mon hébergeur, et la clé qui ouvre ce coffre vit uniquement dans mon trousseau, sur un troisième fournisseur encore. Trois acteurs différents, aucune dépendance circulaire : je peux tout reconstituer même si mon Mac et le cluster disparaissent le même jour. J'ai écrit la procédure de reprise noir sur blanc, justement pour qu'elle soit exécutable sous stress, le jour où le pire arrive.

Multi-tenant en pratique : un nouveau projet en deux heures

Toute cette architecture n'aurait qu'un intérêt théorique si ajouter un projet restait compliqué. La meilleure preuve que le design tient, c'est la facilité avec laquelle on l'étend. Récemment, j'ai eu besoin de mettre en ligne un petit projet personnel — un site statique, chiffré côté client, sans backend. Le développement m'a pris deux heures. Le déploiement sur le cluster : quelques minutes. Un conteneur servant les fichiers statiques, un listener et une route ajoutés à la Gateway partagée, un certificat dédié émis automatiquement. Aucune nouvelle IP, aucune nouvelle infrastructure, aucune décision d'architecture à reprendre.

C'est exactement le retour sur investissement d'une plateforme bien pensée. Le premier projet coûte cher en réflexion et en mise en place. Tous les suivants deviennent presque gratuits. C'est la différence entre bricoler une machine par application et construire une plateforme qui accueille des projets. Et c'est précisément ce qui rend le bare metal viable pour un indépendant qui jongle entre plusieurs produits : la mutualisation.

Alors, dix heures, vraiment ?

Oui — mais maintenant vous savez ce qu'il y a derrière, et pourquoi le chiffre seul est trompeur. Dix heures de travail humain pour reconstruire une plateforme haute disponibilité, multi-tenant, avec des bases répliquées et sauvegardées, du GitOps de bout en bout, de l'observabilité et une stratégie de survie au sinistre. Ce résultat n'est pas accessible à n'importe qui en dix heures. Il est accessible à quelqu'un qui a vingt ans de métier, qui a déjà rencontré la plupart de ces pièges, et qui sait reconnaître le moment où l'IA propose une solution plausible mais fausse.

L'IA est un multiplicateur formidable. Elle m'a fait passer de trois semaines à dix heures. Mais elle multiplie une expertise ; elle ne la crée pas. Donnez le même outillage à quelqu'un sans les fondamentaux, et vous obtiendrez un cluster qui passe la démo et meurt au premier vrai incident — un nœud qui tombe, un certificat qui expire, une clé qu'on n'a pas su restaurer. Toutes ces galères que j'ai racontées, ce ne sont pas des anecdotes : ce sont les endroits exacts où l'expertise fait la différence, et où l'IA seule vous aurait laissé en plan.

Pour qui, et quand

Soyons honnêtes : cette infrastructure n'est pas pour tout le monde, et certainement pas pour tout de suite. Pour une startup qui démarre son produit, un simple conteneur sur un VPS à vingt euros reste le bon choix. Passer à Kubernetes par anticipation ou par effet de mode est une erreur que je vois régulièrement. La question du cloud public ou du bare metal ne se tranche qu'au regard d'un besoin réel de haute disponibilité ou de maîtrise des coûts.

Mais quand ce besoin arrive — un SLA à tenir, un produit qui ne tolère pas l'interruption, une facture cloud qui devient déraisonnable — le calcul a basculé. Ce qui exigeait une équipe SRE dédiée et des mois de travail est désormais à la portée d'un profil expérimenté outillé d'IA, en une fraction du temps et pour une fraction du coût. Ce n'est pas une raison pour se passer de compétences infra à terme. C'est une raison pour ne plus reporter indéfiniment une vraie infrastructure résiliente sous prétexte qu'elle serait trop chère ou trop longue à mettre en place.

C'est tout l'enjeu, finalement. La barrière n'est plus la vitesse ni le coût. C'est l'expertise — et c'est justement ce qui, à l'heure de l'IA, reprend de la valeur.

Monter en compétence sur l'IA agentique ?

Atteindre ce niveau d'autonomie, ce n'est pas une question d'outil mais de méthode. En accompagnement IA
agentique, je forme et je coache vos équipes tech pour qu'elles produisent
ce genre de résultats — sur votre infrastructure, vos contraintes, vos projets réels.

Design System : et si votre Product Designer le mettait à jour lui-même ?

Rémi Alvado — Thu, 25 Jun 2026 21:15:34 +0000

Dans la plupart des équipes produit, il se passe entre 2 et 4 semaines entre le moment où un Product Designer met à jour le design system dans Figma et le moment où ces changements arrivent en production. Et encore, quand ils arrivent. Car certaines modifications ne sont tout simplement jamais scopées, créant un décalage permanent entre ce que le designer conçoit et ce que l'utilisateur voit. Avec l'arrivée de Claude Code et du MCP Figma, ce délai peut maintenant se compter en minutes.

L'IA au service des équipes tech et produit

Cet article se concentre sur l'impact de l'IA pour les Product Designers. Pour une vue plus large sur l'IA dans les
équipes techniques, consultez IA au service de la DX. Et pour mieux comprendre le
rôle du Product Designer, voir Product Designer : bien plus que la couleur des
boutons.

Le problème en un coup d'œil

	Workflow classique	Avec Claude Code + MCP Figma
Délai de mise à jour	2 à 4 semaines (1-2 sprints)	Quelques minutes
Qui intègre les changements	Développeur frontend	Product Designer
Cohérence Figma / Code	Décalée en permanence	Quasi permanente
Risque principal	Tickets oubliés ou dépiorisés	Limité au périmètre du design system

Le fossé entre Figma et la production

Le problème est connu de tous les CPO et pourtant il persiste. Le Product Designer fait évoluer le design system dans Figma — nouveaux tokens, composants mis à jour, variantes ajoutées — puis crée un ticket pour que l'équipe frontend intègre ces changements. Ce ticket rejoint le backlog, attend sa priorisation, passe par un sprint planning, est développé, reviewé, puis déployé. Dans le meilleur des cas, ça prend 1 à 2 sprints. Dans la réalité, certaines modifications passent à la trappe parce qu'elles ne sont pas jugées prioritaires face aux fonctionnalités business. Le designer finit par être déconnecté de la réalité terrain : il conçoit ses prochaines maquettes avec des composants qui n'existent pas encore en production.

De l'autre côté, les développeurs frontend travaillent avec une version du design system qui a plusieurs semaines de retard sur Figma. Le résultat, c'est une incohérence permanente entre les maquettes et le produit réel, des allers-retours pour réconcilier les deux, et une frustration palpable des deux côtés. Plus le temps passe, plus l'écart se creuse, plus le coût de rattrapage augmente. C'est un cercle vicieux que j'observe dans quasiment toutes les organisations produit que j'accompagne, quelle que soit leur taille ou leur maturité. Et jusqu'ici, personne n'avait vraiment trouvé de solution satisfaisante parce que le coût de synchronisation continue était trop élevé.

Claude Code, le MCP Figma et un nouveau workflow

Depuis quelques mois, des outils comme Claude Code permettent de manipuler du code via des instructions en langage naturel. Ce qui change la donne pour notre sujet, c'est l'arrivée du MCP (Model Context Protocol) Figma : un connecteur qui permet à Claude Code d'accéder directement au contenu d'un fichier Figma — composants, tokens, variantes, styles. En combinant les deux, on obtient un workflow où le Product Designer peut mettre à jour le design system dans le code sans écrire une seule ligne lui-même. Concrètement, voici ce que ça donne :

Le Product Designer met à jour un composant ou un token dans Figma, comme il le fait déjà
Il ouvre Claude Code Desktop et lui demande, en langage naturel, de mettre à jour le composant correspondant dans le code
Claude Code lit les spécifications Figma via le MCP, identifie les différences avec le code existant, et propose les modifications
Le designer voit le résultat directement dans l'interface de Claude Code Desktop, qui affiche un aperçu visuel du composant modifié
Il valide, et les changements sont prêts à être mergés

L'arrivée de Claude Code en version Desktop est un élément clé de ce workflow. La CLI est un outil que les designers ne connaissent pas et qui peut légitimement faire peur — un terminal noir avec du texte blanc, c'est loin de leur quotidien. L'interface graphique de Claude Code Desktop change complètement la donne : on interagit en langage naturel, on voit les résultats visuellement, on n'a pas besoin de maîtriser git ou le terminal pour obtenir un résultat. Le designer reste dans un univers familier tout en ayant un impact direct sur le code. C'est un point fondamental, car l'adoption par le designer est le facteur clé de succès de ce workflow. Si l'outil lui semble hostile ou trop technique, le bénéfice théorique restera théorique.

Le designer, gardien élargi du design system

Ce nouveau workflow ne transforme pas le Product Designer en développeur frontend. Il étend son périmètre naturel. Si on y réfléchit, le designer est déjà le gardien du design system dans Figma : il en définit les règles, les fait évoluer, s'assure de la cohérence. Lui permettre de pousser ces évolutions directement dans le code, c'est simplement supprimer l'intermédiaire sur une tâche où il est le plus légitime. Le Product Owner n'a plus besoin de créer un ticket, le développeur n'a plus besoin de traduire une maquette en code pour des changements de tokens ou de composants standards. Tout le monde gagne du temps.

Il y a un enjeu plus stratégique derrière. Avec l'accélération des temps de développement permise par les outils IA — comme l'IA agentique qui permet aux développeurs d'aller 5 à 10 fois plus vite — les Product Designers risquent de devenir un goulot d'étranglement dans l'organisation produit s'ils ne trouvent pas eux aussi le moyen d'accélérer. La solution réside justement dans le design system : en le maintenant rigoureusement à jour et en le faisant grandir, ils fournissent la palette nécessaire aux développeurs et aux Product Owners pour concevoir toutes les interfaces simples de manière autonome. Dès que ça devient plus complexe et que le design system existant manque de profondeur, le designer reprend la main et montre alors sa vraie valeur — la conception d'expériences utilisateur que personne d'autre dans l'équipe ne peut imaginer.

Le prérequis non négociable : un design system solide

Aussi prometteur que soit ce workflow, il ne fonctionne qu'avec un design system clairement défini et bien structuré. Sans cette fondation, l'IA va accélérer le chaos au lieu de l'ordre. C'est une constante avec ces outils : l'IA est un accélérateur. Quand les bases sont solides, tout va mieux très vite. Quand elles sont fragiles, tout s'effondre très vite aussi. Un design system "prêt" pour ce type d'usage, c'est au minimum des tokens bien définis (couleurs, typographies, espacements), des composants atomiques clairement documentés dans Figma, et une implémentation frontend qui suit la même structure. Si votre Figma est un ensemble de maquettes sans composants réutilisables, ou si votre code frontend duplique des styles sans logique commune, Claude Code ne pourra pas faire de miracle. Il va générer du code incohérent qui va créer plus de problèmes qu'il n'en résout.

C'est d'ailleurs une raison supplémentaire d'investir sérieusement dans votre design system si ce n'est pas encore fait. Comme je le mentionnais dans l'article sur les métriques d'équipe CPO, la couverture du design system est un indicateur clé de la maturité d'une équipe produit. Avec ce nouveau workflow, ce n'est plus seulement un indicateur de qualité — c'est un prérequis pour débloquer un levier d'accélération majeur. Chaque composant correctement documenté dans votre design system est un composant que votre designer pourra mettre à jour en autonomie, sans mobiliser de développeur. L'investissement se rentabilise très vite.

En résumé

Le décalage entre le design system dans Figma et son implémentation en production est un problème ancien que personne n'avait vraiment résolu. Pas parce que c'est techniquement impossible, mais parce que le coût de synchronisation continue était trop élevé pour être fait en continu. Avec Claude Code et le MCP Figma, ce coût devient quasi nul pour les mises à jour du design system. C'est une opportunité concrète pour les CPO qui veulent à la fois accélérer leur équipe design et améliorer la cohérence de leurs produits. À condition, comme toujours, d'avoir les fondations en place.

Besoin de structurer votre équipe Produit ?

En création d'équipe tech & produit, je vous aide à organiser votre
équipe design, à mettre en place un design system qui tient la route et à intégrer les bons outils IA dans vos
workflows produit.

IA au service de la DX : bien plus que de la complétion de code

Rémi Alvado — Thu, 25 Jun 2026 21:10:02 +0000

L'IA générative permet d'écrire du code de plus en plus rapidement. Mais se limiter à cette vision, c'est passer à côté de l'essentiel. L'IA peut analyser une base de code de grande ampleur, comprendre une Pull Request en quelques secondes, ou documenter un projet entier en quelques minutes. Et avec l'émergence de l'IA agentique, c'est le métier même de développeur qui est en train de se transformer.

Comment fonctionne un LLM ?

Si vous voulez comprendre le fonctionnement des modèles de langage qui se cachent derrière ces outils, consultez LLM
: comment ça marche vraiment ?.

Les 3 niveaux d'usage de l'IA pour les développeurs

Niveau	Outil type	Gain estimé	Impact
Complétion de code	GitHub Copilot	+20 à 50%	Utile mais pas transformateur
Analyse et compréhension	Claude Code, ChatGPT	Variable	Change la manière de documenter
IA agentique	Claude Code, Gemini CLI, Jules	x5 à x10	Transforme le métier de développeur

Niveau 1 : la complétion de code

C'est l'usage le plus répandu aujourd'hui. Des outils comme GitHub Copilot proposent de l'autocomplétion intelligente directement dans l'éditeur de code. Le développeur commence à écrire une fonction, et l'IA suggère la suite. Nous avons pas mal testé Copilot en équipe et les résultats sont franchement pas mal : on sent qu'un développeur peut facilement gagner 20 à 50% de productivité sur les tâches de rédaction de code pur. Les suggestions sont souvent pertinentes, surtout sur du code standard — implémentation d'une API REST, écriture de tests unitaires, manipulation de données.

Ce n'est clairement pas quelque chose à ignorer et toute équipe technique devrait aujourd'hui avoir accès à ce type d'outil. Mais ce n'est pas non plus un game changer. Le développeur reste celui qui pense l'architecture, qui découpe le problème, qui décide de l'approche. L'IA ne fait qu'accélérer la partie "frappe au clavier" du travail. Or cette partie, même si elle prend du temps, n'est pas celle qui crée le plus de valeur. Un développeur qui tape deux fois plus vite du code mal conçu ne produit pas deux fois plus de valeur — il produit deux fois plus de dette technique. La complétion de code est donc un bon point de départ pour familiariser vos équipes avec l'IA, mais il ne faut pas en attendre une transformation profonde de la productivité. C'est un outil d'hygiène, pas un levier stratégique.

Niveau 2 : l'analyse et la compréhension de code

C'est là que les choses deviennent plus intéressantes. Des outils comme Claude Code sont devenus vraiment excellents pour analyser une base de code existante. Il y a encore quelques mois, il fallait absolument rédiger un fichier de documentation (un CLAUDE.md par exemple) le plus clair possible pour que le modèle arrive à se retrouver dans le projet. C'était un investissement initial non négligeable, et la qualité du résultat dépendait directement de la qualité de cette documentation.

Aujourd'hui, c'est le modèle lui-même qui initialise cette documentation en analysant le projet. Il parcourt la structure des fichiers, identifie les patterns utilisés, comprend les dépendances et génère une description cohérente du projet. Aux développeurs qui connaissent ce projet, il ne reste que la relecture de ce fichier et, éventuellement, de le compléter avec des éléments que la machine n'aurait pas identifiés par elle-même — des conventions d'équipe, des choix d'architecture non évidents, des contraintes business qui ne sont pas dans le code.

À l'heure où la rédaction de code va se faire de plus en plus de manière assistée par les modèles de langage, la relecture et la compréhension de ce code vont devenir les nouveaux enjeux forts de vos équipes techniques. Utiliser une IA pour générer des descriptions claires de votre base de code ou de vos modifications — un résumé de PR, une documentation d'API, un guide d'architecture — va devenir un must have absolu pour que vos équipes techniques continuent à accélérer sans perdre en qualité.

Besoin d'accélérer vos équipes techniques ?

En accompagnement IA agentique ou en accompagnement
scaling, je vous aide à intégrer l'IA dans les pratiques de vos équipes de
développement — de la complétion de code à l'IA agentique.

Niveau 3 : l'IA agentique — le vrai game changer

C'est le niveau qui change réellement la donne. L'IA agentique — des outils comme Claude Code en mode agent, Gemini CLI ou Google Jules — ne se contente pas de compléter du code ou d'analyser un fichier. Elle exécute des tâches complètes de manière autonome : créer une fonctionnalité, corriger un bug, refactorer un module entier, monter une infrastructure. Le développeur décrit ce qu'il veut, l'agent le réalise.

Avec ces outils, on peut quasiment parler de développeurs qui vont 5 à 10 fois plus vite une fois qu'ils maîtrisent l'outil. C'est un ordre de grandeur complètement différent de la complétion de code. Et c'est logique : au lieu d'accélérer la frappe, l'IA agentique prend en charge la réalisation entière pendant que le développeur se concentre sur la direction à donner. Son métier évolue alors vers quelque chose qui ressemble à un Product Owner technique : il pilote une équipe d'agents qui réalisent le code pour lui, en leur donnant le bon contexte, en validant les résultats, en réorientant quand c'est nécessaire.

C'est ce que j'utilise moi-même depuis plusieurs mois, et le résultat est saisissant. Un exemple concret : je suis en train de réaliser un POC pour monter un cluster Kubernetes de 3 machines avec Talos comme OS et ArgoCD pour le déploiement automatisé. Je ne suis pas SRE de formation, mais en m'appuyant sur l'IA agentique, j'ai pu avancer en 2 à 3 jours sur un sujet qui m'aurait pris plusieurs semaines en autonomie complète. Ce n'est pas de la magie — il faut avoir des bases techniques pour piloter l'agent et valider ses choix — mais la capacité d'accélération est considérable.

Le dev de demain : plus de relecture, moins de frappe

La tendance est claire : écrire du code va devenir une commodité. Ce qui va différencier les bons développeurs, c'est leur capacité à comprendre, relire et valider du code — qu'il soit écrit par un humain ou par un agent. Les compétences d'architecture, de design de systèmes et de compréhension business vont prendre encore plus de valeur. Un développeur qui sait poser le bon problème et évaluer la qualité d'une solution sera bien plus précieux qu'un développeur qui tape vite.

Pour les entreprises, l'enjeu est double. D'abord, équiper leurs équipes avec ces outils et leur laisser le temps de les maîtriser — ce n'est pas instantané et il faut accepter une courbe d'apprentissage. Cela commence par un environnement de travail homogène et adapté : la plupart de ces outils en ligne de commande supposent un terminal Unix, ce qui pèse dans le choix de l'OS de vos équipes. Ensuite, faire évoluer leurs critères de recrutement : les tests techniques qui évaluent la capacité à écrire du code de mémoire vont perdre de leur pertinence. Ce qu'il faudra évaluer, c'est la capacité à piloter un agent, à relire du code généré et à identifier les problèmes avant qu'ils n'arrivent en production.

En résumé

L'IA ne sert pas qu'à écrire du code plus vite. Elle transforme profondément la manière dont les développeurs travaillent, de la complétion basique à l'IA agentique qui change l'échelle de productivité. Les équipes qui adoptent ces outils progressivement — en commençant par la complétion, puis l'analyse, puis l'agentique — vont prendre une avance significative. Celles qui attendent vont se retrouver à recruter plus cher pour aller moins vite. C'est le prochain grand sujet pour beaucoup d'entreprises, et il est temps de s'y préparer sérieusement.

Le PO Technique : le profil qui va redéfinir les équipes produit

Rémi Alvado — Thu, 25 Jun 2026 21:04:31 +0000

Un développeur chevronné équipé de Claude Code ou d'un outil d'IA agentique similaire peut aujourd'hui réaliser une fonctionnalité dans son intégralité : modèle de données, API, frontend, logs, analytics. Ce qui était autrefois le travail coordonné de plusieurs spécialistes peut désormais être conduit par une seule personne. Mais cette puissance de réalisation ne vaut rien sans une compréhension profonde de ce qu'on construit et pourquoi. Et c'est là qu'un profil encore méconnu va prendre une importance considérable : le PO Technique.

L'IA agentique en détail

Pour comprendre comment l'IA agentique transforme le quotidien des développeurs et les 3 niveaux d'usage de l'IA,
consultez IA au service de la DX : bien plus que de la complétion de code.

Deux compétences, deux trajectoires très différentes

Compétence	Aujourd'hui	Demain avec l'IA agentique
Réflexes techniques (tests, architecture, endpoints)	Indispensable, acquise en années	Assistée par les skills et les bonnes pratiques embarquées
Compréhension produit (besoin utilisateur, analytics, infra)	Appréciée mais optionnelle	Indispensable et différenciante
Vitesse de réalisation	Limitée par la spécialisation	x5 à x10 grâce à l'IA agentique
Autonomie sur une feature complète	Rare, réservée aux seniors fullstack	Accessible à tout dev expérimenté bien outillé

Les réflexes techniques : une barrière qui s'abaisse

Quand un développeur réalise une fonctionnalité de bout en bout aujourd'hui, il doit maîtriser un ensemble de réflexes techniques : concevoir un endpoint propre, penser aux tests automatisés dès le départ, valider que l'architecture est cohérente avec le reste du système, anticiper les cas limites. Ces réflexes s'acquièrent en années de pratique et distinguent un développeur junior d'un développeur confirmé. Mais ces barrières sont en train de s'abaisser significativement grâce à l'émergence de skills dédiées dans des outils comme Claude Code. Ces skills fonctionnent un peu comme les containers Docker il y a quelques années : on va chercher sur étagère une brique qui embarque exactement les bonnes pratiques dont on a besoin, alors qu'il aurait fallu des jours pour les construire soi-même. Besoin de générer une API REST avec les bons patterns ? Une skill s'en charge. Besoin d'ajouter des tests unitaires qui couvrent les cas limites ? Idem.

Ces réflexes techniques ne vont pas disparaître complètement. Il faudra toujours quelqu'un capable de valider que le code généré tient la route, que l'architecture ne dérive pas, que la dette technique reste sous contrôle. Mais la barre d'entrée pour produire du code correct et bien structuré va considérablement baisser. Je ne serais d'ailleurs pas surpris que ces skills finissent par être directement intégrées dans les moteurs eux-mêmes — les LLM ou les CLI — rendant ces bonnes pratiques automatiques plutôt qu'optionnelles. Dans ce contexte, la pure compétence technique va perdre de sa rareté. Et ce qui était autrefois le principal critère de valeur d'un développeur va progressivement céder sa place à autre chose.

Ce qui restera indispensable : comprendre ce qu'on construit

Réaliser une fonctionnalité à la vitesse de l'IA agentique, c'est impressionnant. Mais réaliser la bonne fonctionnalité, de la bonne manière, pour les bonnes raisons, c'est une toute autre affaire. Et c'est là que la compréhension produit devient le vrai facteur différenciant. Il ne s'agit pas simplement de comprendre les écrans à implémenter ou les composants du design system à utiliser. Il faut comprendre pourquoi cette fonctionnalité existe, ce que les utilisateurs en attendent réellement, ce dont l'équipe de Data Analyse aura besoin en aval pour mesurer son impact, les contraintes de l'infrastructure de production qui vont influencer les choix d'implémentation. Un développeur qui comprend tout ça va produire un résultat radicalement meilleur qu'un développeur qui se contente d'implémenter une spec.

Soyons cash : un développeur qui ne s'intéresse qu'au code et pas à son produit va perdre beaucoup de valeur dans les années qui viennent. Quand l'IA agentique permet de coder 10 fois plus vite, la partie "coder" n'est plus ce qui crée le plus de valeur. C'est la partie "savoir quoi coder" qui fait la différence. Un développeur qui comprend les enjeux business, qui anticipe les besoins des utilisateurs, qui dialogue avec les équipes Sales et Support pour comprendre les vrais points de douleur — celui-là sera irremplaçable. Celui qui attend qu'on lui donne une spec détaillée pour commencer à travailler ne sera probablement pas remplacé quand il partira.

Le PO Technique : un profil qui existe déjà

Ce profil de développeur avec une forte compréhension produit n'est pas une invention théorique. J'en croise régulièrement chez mes clients sous différentes appellations. Ce sont des développeurs expérimentés — confirmés voire seniors — qui se sont pris au jeu de faire le lien entre la technique et le produit. Souvent, ils ont commencé par un rôle adjacent : Scrum Master, Delivery Owner, ou Proxy Product Owner dans certaines organisations. Issus des équipes d'engineering, ils ont une vue très claire du produit parce qu'ils ont participé à sa construction depuis le début. Ils connaissent les contraintes techniques, comprennent les choix d'architecture, et ont développé en parallèle une vraie culture produit en s'intéressant aux besoins des utilisateurs et des clients.

Mais jusqu'ici, ces profils étaient paradoxalement sous-exploités. Par manque de temps et de bande passante, ils étaient cantonnés à des tâches classiques de Product Owner : rédaction de user stories, discussions avec les parties prenantes, tests fonctionnels, priorisation du backlog. À la fin du processus, ils communiquaient une spec facilement actionnable par les équipes techniques. C'est déjà un apport considérable — la qualité de ces specs est souvent bien meilleure que celle d'un PO sans background technique. Mais il restait de la latence, de la perte d'information entre la spec et l'implémentation, des allers-retours pour clarifier des détails. Avec l'IA agentique, cette dernière friction disparaît : ils vont pouvoir mettre en pratique directement et en toute autonomie ce qu'ils ont compris de leur produit, sans intermédiaire.

Trois personnes au lieu de trente

Le ratio habituel dans une équipe produit bien rodée, c'est environ un Product Owner pour 7 à 10 développeurs. Une équipe typique de 3 PO et 25 développeurs livre à un certain rythme. Remplacez cette équipe par 3 PO Techniques équipés d'outils d'IA agentique et les résultats sont saisissants. Nous avons pu tester récemment avec une équipe que j'accompagne la création d'un backoffice complet. L'estimation initiale, faite par l'équipe avec un workflow classique, frôlait les 40 jours-homme. Tout a été réalisé en 2 jours-homme, et nous sommes même allés un peu plus loin que le périmètre initialement prévu. C'est un facteur 20 sur une feature réelle, pas un benchmark artificiel.

Ce chiffre n'est pas magique — il s'explique par la suppression de toute la latence organisationnelle. Plus de handoff entre PO et développeur, plus d'attente de priorisation, plus d'allers-retours pour clarifier une spec. Le PO Technique comprend le besoin, le formule et le réalise dans un flux continu. Évidemment, ça ne signifie pas que toutes les features se prêtent à ce mode de fonctionnement. Les sujets à forte complexité technique ou architecturale nécessiteront toujours des développeurs spécialisés. Mais pour une part significative du backlog — back-offices, intégrations, CRUD, dashboards — ce mode de fonctionnement est redoutablement efficace. Et ça va mécaniquement rebattre les cartes de comment nous dimensionnons et structurons nos équipes produit et technique.

Ce que ça change pour les CTO et CPO

Les implications sont profondes. Côté recrutement d'abord : les processus qui évaluent principalement les compétences techniques pures vont devoir évoluer. Ce qu'il faudra détecter chez un candidat, c'est son appétence produit, sa capacité à comprendre un besoin business, sa curiosité pour les usages. Un développeur moyen techniquement mais excellent en compréhension produit aura plus de valeur qu'un excellent technicien qui ne s'intéresse pas à ce qu'il construit. C'est un renversement majeur des critères de sélection.

Côté organisation ensuite : les frontières entre équipe produit et équipe technique vont continuer à s'estomper. Les PO Techniques sont les pionniers de cette convergence, mais ils ne sont pas le seul rôle qui bouge — le senior devient architecte-reviewer, le junior monte en compétences plus vite, le manager change de focus. J'ai cartographié l'ensemble de ces mutations dans les nouveaux rôles dans une équipe tech augmentée par l'IA. Ces profils font d'ailleurs souvent d'excellents managers par la suite — leur double culture leur permet de dialoguer aussi bien avec la direction produit qu'avec les équipes d'engineering. Ils accèdent naturellement à des fonctions de Head of Product voire de CPO. Les identifier tôt dans votre organisation, les accompagner dans cette montée en compétences produit, et leur donner les outils pour exprimer leur plein potentiel va devenir un avantage compétitif majeur dans les prochaines années.

En résumé

L'IA agentique ne rend pas les développeurs obsolètes. Elle rend obsolète l'idée qu'un développeur peut se contenter de coder sans comprendre ce qu'il construit. Le PO Technique — ce profil hybride issu de l'engineering avec une vraie culture produit — est celui qui va tirer le meilleur parti de ces outils. En combinant compréhension du besoin et capacité de réalisation autonome, une petite équipe de ces profils va produire ce qui nécessitait auparavant des dizaines de personnes. Ce qui les distingue, ce n'est pas un outil miracle mais leur capacité à manier toute la boîte à outils du Product Builder — du cadrage aux tests déterministes — et à savoir lequel sortir selon le contexte. Pour les CTO et CPO, l'enjeu est clair : identifier ces profils, les faire grandir, et repenser vos organisations autour de cette nouvelle réalité.

Repenser votre organisation tech et produit ?

En accompagnement IA agentique, je vous aide à identifier les bons profils,
adapter vos processus de recrutement et structurer vos équipes pour tirer parti de l'IA agentique.

Partager toute la doc git d'un projet avec un fondateur non-dev (et son LLM) : 400 lignes, zéro Notion

Rémi Alvado — Thu, 25 Jun 2026 20:58:59 +0000

Sur un Sprint Fondateur en cours, le CEO est un dirigeant non-dev. Il pilote, prend les décisions produit, alimente la roadmap. Et il a un LLM perso — Claude, en l'occurrence — avec lequel il travaille au quotidien. Ma question, deux semaines après le démarrage du projet : où est-ce que sa mémoire de projet vit ? Parce que si elle vit dans Notion, je sais déjà comment l'histoire se termine — un silo séparé du code, qui dérive en silence, et qui ne sait pas parler aux LLMs (le sien, les miens).

J'ai dit non à Notion. Pas parce que Notion est mauvais — il est très bien pour beaucoup d'équipes — mais parce que dans ce contexte précis, la doc projet doit être au même endroit que les ADR techniques, le modèle de données et les comptes rendus de RDV. C'est-à-dire dans le repo git. Le problème : un fondateur non-dev n'a pas de compte GitHub, pas de Git CLI, pas envie d'apprendre. Et ses sessions Claude ne savent pas, par défaut, où aller chercher cette mémoire.

J'ai donc écrit en deux heures un petit système qui résout ça : un endpoint HTTP qui sert toute la doc du repo dans un zip, ingérable par n'importe quel LLM via un skill custom. Et un second skill qui permet au fondateur de proposer une modif via une PR GitHub — sans jamais ouvrir GitHub. Cet article décrit le pattern, les décisions techniques que j'ai prises, et les limites que j'assume.

La suite d'un article précédent

J'ai déjà décrit comment je publie cette même doc en lecture web pour le client via Astro Starlight, OpenDesigner et
un sous-domaine docs.client.com. Ce flow-là couvre la consultation. Ce
que je décris ici couvre le canal LLM : comment alimenter directement la mémoire de l'IA du fondateur, et lui
rendre la doc éditable. Les deux flows cohabitent — ils servent deux usages différents.

Pourquoi j'ai dit non à Notion (pour ce projet)

Le contexte mérite d'être posé. L'équipe Sprint Fondateur est minuscule : un fondateur non-dev, moi côté tech, deux consultants amis en support ponctuel (architecte, CDP IT). La doc projet contient les décisions produit, les ADR techniques, le modèle de données, les comptes rendus de RDV stratégiques, les notes de discovery, la roadmap. Toute la matière qui, dans une boîte plus grosse, vivrait dans Notion ou Confluence.

Notion impose cinq choses dans ce contexte précis :

Un silo séparé du code. Dès qu'une décision technique évolue, la page Notion dérive. Personne ne pense à la mettre à jour quand un commit change la donne — parce que ce n'est pas dans le flow du dev.
Un compte par membre. Friction immédiate pour onboarder l'architecte ami ou un nouveau prestataire ponctuel.
Un abonnement mensuel. Coût récurrent pour une équipe de trois ou quatre. Marginal en valeur absolue, mais c'est un coût qui ne sert rien d'autre.
Un vendor lock-in. Si on revend le projet, ou si on migre l'équipe, il faut exporter, reformatter, migrer.
Aucune intégration LLM native. Ni mon Claude Code (qui code sur le repo), ni le Claude perso du fondateur ne peuvent lire Notion sans plumberie spécifique. On parle d'un workspace cloisonné en dehors du flow agentique.

Mais l'alternative « tout dans le repo git » exclut le fondateur. Il n'a ni git clone, ni gh pr create, ni envie d'apprendre — et il a raison de ne pas avoir envie. Son job, ce n'est pas Git. Son job, c'est de prendre des décisions et de les confronter à un LLM qui connaît tout le projet.

Le vrai problème à résoudre, donc, n'est pas « comment partager la doc » au sens humain. C'est : comment alimenter le LLM du fondateur avec exactement la même mémoire que celle qui pilote mes propres sessions Claude Code, et lui donner un moyen d'y contribuer.

La solution, en une URL

J'ai exposé un endpoint sur l'API du projet :

GET /_internal/memory/{uuid}

Le {uuid} est un UUID v4 statique, partagé une fois au fondateur via Signal. L'endpoint renvoie un fichier ZIP qui contient :

Toute la doc du repo (docs/**/*.md)
Un llms.txt auto-généré (le standard ouvert créé par Jeremy Howard / Answer.AI fin 2024, déjà adopté par Anthropic, Vercel, FastAPI, Tailwind)
Un README.md qui explique l'installation côté Claude
Deux skills Claude custom : memory-update et memory-pr
Un PAT GitHub fine-grained injecté à la volée dans les skills

Le flow opérationnel ressemble à ça :

Claude (côté fondateur)
        │
        │  /memory-update
        ▼
HTTPS GET /_internal/memory/{uuid}
        │
        ▼
API (rate limit 10/min/IP, log audit)
        │
        ├─► lit docs/**/*.md du repo
        ├─► génère llms.txt
        ├─► bundle skills + PAT + README
        ▼
   ZIP (~345 KB)
        │
        ▼
Mémoire LLM locale du fondateur

Plus tard, dans la même session :

Fondateur : « ajoute dans la doc qu'on a tranché X au RDV de jeudi »
        │
        │  /memory-pr "ajoute dans la doc qu'on a tranché X..."
        ▼
skill → API GitHub → branche + commit + PR
        │
        ▼
URL de PR retournée au fondateur
        │
        ▼
Je valide ou je refuse, en review GitHub classique

Côté fondateur, le setup tient en cinq minutes : il colle l'URL dans son Claude la première fois, lance /memory-update, et c'est fait. Pour mettre à jour sa mémoire ensuite (nouvelles décisions, nouveaux ADR), il relance /memory-update quand il en a envie. Pour proposer une modif, il décrit ce qu'il veut changer en langage naturel et le skill /memory-pr fait le boulot Git à sa place.

Côté dev (moi, mes sessions Claude Code), rien ne change : accès direct au repo, comme avant. C'est une couche de service par-dessus le même repo, pas une migration.

Le controller Symfony qui sert tout ça tient en une cinquantaine de lignes. La logique : valider l'UUID en constant_time_equals contre la variable d'env, rate-limiter, lire docs/, générer le llms.txt à la volée, packager le tout, streamer le zip. Une commande curl suffit à tester :

curl -o memory.zip https://api.projet.com/_internal/memory/<uuid>
# 200 + zip de 345 KB en ~130 ms

curl -i https://api.projet.com/_internal/memory/wrong-uuid
# 404 (pas 401, pas de fuite de signal)

# 11 requêtes rapides depuis la même IP
# → 429 Too Many Requests à la 11ème

Les décisions techniques qui valent d'être discutées

C'est la partie où je m'attendais à plus de débat interne — et où en pratique chaque choix a été assez vite tranché par contrainte de simplicité.

UUID statique au lieu d'OAuth. Un UUID v4 = 122 bits d'entropie. Inattaquable au bruteforce dans des temps raisonnables. La signature secrète, c'est l'URL elle-même, partagée en privé sur Signal. Setup pour le fondateur = zéro OAuth, zéro compte, juste une URL. Côté serveur, je rate-limite à 10 req/min/IP et je log chaque accès pour audit. Si demain je sens que c'est trop léger, je passe à un GitHub App OAuth — mais ce sera de l'over-engineering aujourd'hui.

PAT GitHub fine-grained bundlé dans le zip. Scopé Contents: R/W + Pull requests: R/W sur un seul repo. Expiration 90 jours, rotation trimestrielle au Makefile. Le pire scénario si le zip fuit : un attaquant peut ouvrir des PR sur un seul repo. Ces PR ne se mergent pas sans validation humaine, sont triviales à fermer, à supprimer en bloc, et le PAT est révoqué en deux clics. Pas de risque pour la prod, pas de risque pour les secrets (le PAT ne lit pas les workflows GitHub Actions ni les secrets repo). C'est un risque borné et réversible.

Pas de whitelist de fichiers. Si un doc est dans docs/, il est partageable. Convention simple : un doc privé va dans docs/internal/ ou commence par _private_. Je n'aime pas les allow-lists par fichier — c'est de la maintenance constante, ça finit toujours par oublier un doc, et la première fois que quelqu'un ajoute un nouveau type de doc personne ne pense à l'ajouter dans la whitelist. Une convention de dossier, c'est lisible à l'œil dans le tree.

Default-deny côté serveur. Si la variable d'env MEMORY_SHARE_UUID ou MEMORY_SHARE_GITHUB_PAT n'est pas configurée (cas par défaut en dev local et en CI), l'endpoint répond 503 memory_share_not_configured. Zéro chance d'exposer accidentellement la doc en environnement de dev qui aurait fuité sur un sous-domaine de prévisualisation. La configuration prod est explicite, par variable d'env, dans le pipeline de déploiement uniquement.

llms.txt en bonus. Le fichier est dans le zip, et il est aussi potentiellement servi à la racine du domaine public. Quand le site marketing du projet sera lancé, ChatGPT, Perplexity et les autres crawlers IA pourront lire directement le résumé de la doc sans intervention manuelle. C'est gratuit comme bénéfice — le format llms.txt est ouvert, court à générer, et Anthropic, Vercel, FastAPI, Tailwind l'exposent déjà sur leurs propres docs publiques. Mintlify le génère automatiquement dans son offre payante ; je le génère en trente lignes de PHP.

Bénéfices attendus et limites — la partie honnête

À l'heure où j'écris cet article, la V1 est codée. Le suite de tests PHP passe (1026 tests verts), la génération du zip prend environ 130 ms pour un payload de 345 KB sur le projet en cours, et j'ai testé manuellement les deux skills depuis ma propre session Claude. Mais je n'ai pas encore mis cette URL dans les mains du fondateur. Les bénéfices que je liste ci-dessous sont donc des extrapolations, basées sur ce que j'observe avec mes propres sessions Claude Code qui consomment déjà cette doc directement depuis le repo.

Bénéfices que j'attends.

Le fondateur peut interroger sa mémoire de projet en langage naturel. « Rappelle-moi les décisions du RDV du 12 mai » → son LLM lit le markdown des notes et résume.
Plus de désync Notion ↔ code. La doc évolue avec le commit qui change le code. git log est l'historique.
Onboarding d'un nouveau collab non-dev = une URL Signal. Pas de licence, pas de création de compte, pas de gestion de permissions individuelles.
Coût marginal nul. Le repo git est déjà là. Le PAT est gratuit. Le llms.txt se génère côté serveur en 30 ms.
Les LLMs du fondateur et les miens sont alimentés par la même source. Ça devrait drastiquement réduire les malentendus de type « ah mais je pensais que… » en RDV de cadrage.
Audit trail natif : qui a proposé quel changement, quand, validé par qui — c'est git log + GitHub PR review. Mieux que n'importe quel historique Notion.

Limites que j'assume.

Le fondateur n'écrit pas du markdown directement : il dicte à son LLM, qui structure. C'est moins direct qu'un éditeur WYSIWYG. Je l'accepte parce que le fondateur travaille déjà tout le temps avec son Claude — l'asymétrie d'effort est négligeable pour lui.
Le PAT statique impose une rotation manuelle tous les 90 jours. J'ai un Makefile pour ça mais c'est de la discipline humaine, pas de l'automatisation. Si je l'oublie un trimestre, le /memory-pr arrête de fonctionner, le fondateur me ping, je rotate.
Si le fondateur perd l'URL UUID, il faut la lui re-renvoyer en privé. Pas de portail self-service de récupération. C'est volontaire — ça force le rappel manuel d'authentification.
L'audit log est basique (un document Mongo par accès). Pas de dashboard. À itérer si le volume justifie un jour.
V2 envisagée mais pas prioritaire : une UI web lecture-seule pour quand le fondateur n'a pas son LLM sous la main, une recherche server-side, un GitHub App OAuth pour les équipes plus grandes. Je n'en ai besoin sur aucun projet aujourd'hui.

Pattern reproductible

Le pattern « endpoint serveur → zip de la doc + skills LLM + PAT scopé » est reproductible en ~1 jour de dev dans n'importe quelle stack avec un backend HTTP. Symfony, FastAPI, Express, Rails — peu importe. Tout ce dont tu as besoin, c'est :

Un endpoint authentifié par URL signée (UUID statique ou JWT, peu importe).
Une fonction qui lit ton dossier docs/, génère un llms.txt et package un zip.
Un PAT GitHub fine-grained à expiration courte, injecté à la volée dans le bundle.
Deux skills LLM côté client (lecture mémoire + proposition de PR).

Adapté aux petites équipes (1 dev + 1-5 non-devs) où Notion est une overhead. Pas adapté aux grosses équipes (>20) qui ont besoin de permissions fines par document — là, un Outline self-hosté ou un GitBook seront plus pertinents. Mais pour le segment startup early-stage avec un fondateur non-dev qui pilote au quotidien, c'est devenu mon défaut.

Cette approche s'inscrit dans une trajectoire que je décris ailleurs : faire du monorepo une mémoire vivante d'entreprise, et accepter que le code, le deck et la roadmap deviennent des artefacts régénérables tandis que la mémoire structurée devient le vrai actif. Toute cette logique, je l'ai consolidée dans mon guide pour travailler avec l'IA agentique au quotidien. Le partage de cette mémoire aux non-devs — sans qu'ils aient à devenir devs — est l'angle mort de cette trajectoire. Cet article est ma première tentative de le combler proprement.

Si tu testes ce pattern dans ta stack, écris-moi. Je suis curieux de voir comment les contraintes de ton contexte changent les décisions techniques — notamment sur la partie auth (PAT vs GitHub App vs OAuth) et sur le format du bundle.

Tu démarres un projet avec un fondateur non-dev ?

C'est exactement le contexte dans lequel j'ai déployé ce pattern : un Sprint Fondateur
— deux mois pour livrer un MVP suffisamment abouti pour confronter le produit au marché, avec un fondateur non-tech
qui pilote au quotidien. La mémoire partagée doc + LLM en fait partie, au même titre que le monorepo, le design
system, les maquettes et le BP. Si tu veux discuter de comment ça pourrait s'appliquer à ton projet,
parlons-en.

Le monorepo-mémoire : le vrai levier n'est pas le prompt

Rémi Alvado — Thu, 25 Jun 2026 20:53:28 +0000

Il y a quelques jours, Andrej Karpathy — ancien Director AI chez Tesla, cofondateur d'OpenAI — a publié un tweet suivi d'un gist qui décrivent une idée simple : utiliser les LLMs non comme des systèmes de retrieval sans mémoire, mais comme des mainteneurs actifs d'une base de connaissances structurée en markdown. Un wiki vivant, mis à jour par l'IA elle-même, qui se bonifie dans le temps.

« A large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge. »
— Andrej Karpathy, sur X

En le lisant, j'ai souri : c'est précisément la méthode que j'applique depuis 6 mois sur les projets que j'accompagne, et c'est ce qui me permet de livrer en 2 mois des MVP qui ressemblent davantage à des V1 aboutis qu'à des prototypes jetables.

Le problème : l'IA agentique est puissante mais amnésique

L'IA agentique de 2026 est devenue spectaculaire. Contexte d'un million de tokens, mode agentique, outils intégrés — elle peut coder, refactorer, auditer, rédiger à un niveau de qualité impressionnant. Mais elle a un défaut structurel : elle oublie tout entre deux sessions. Scale ce défaut sur six semaines d'accompagnement, et vous obtenez un désastre silencieux.

Session 3, l'IA re-propose la stack MongoDB que j'ai écartée session 1 parce que les données sont très relationnelles. Session 7, elle suggère un abonnement mensuel alors qu'on a tranché pour un freemium deux semaines plus tôt. Session 12, elle réinvente une architecture d'auth incompatible avec le choix fait session 4. Chaque oubli coûte du temps — parfois quelques heures à reconstruire le raisonnement, souvent des journées de développement à jeter. Sur un projet de deux mois, ça représente jusqu'à 30% du temps total. La solution n'est pas de mieux prompter : c'est de donner à l'IA une vraie mémoire.

La solution : le monorepo comme mémoire du projet

Le principe tient en une phrase. On versionne ensemble, dans le même Git, le code et la documentation structurée en markdown. Sur les projets que j'accompagne, l'arborescence ressemble à ceci :

mon-projet/
├── apps/
│   └── app/                      # Le code du MVP
├── docs/
│   ├── business-plan/            # Exec summary, marché, modèle éco, projections
│   ├── competitors/              # Analyse concurrentielle détaillée
│   ├── pricing/                  # Stratégie de pricing
│   ├── marketing/                # Personas, go-to-market, messages clés
│   ├── prd/                      # Product Requirement Documents
│   ├── adr/                      # Architecture Decision Records
│   ├── couts/                    # Infrastructure et coûts IA
│   ├── audits/                   # Rapports d'audit qualité
│   └── experts/                  # Profils des subagents spécialisés
└── CLAUDE.md                     # Conventions globales du projet

Chaque fichier est écrit en français, lisible par un humain, et chargé dans le contexte de l'agent à chaque session. Ce n'est pas de la documentation cosmétique — c'est la condition pour que l'IA reste cohérente sur la durée.

Pourquoi dans le monorepo, pas à côté

Il y a une différence fondamentale entre un wiki externe (Notion, Confluence) plus le code dans Git, et le code et les docs dans le même repository. Dans le premier cas, l'agent voit le code mais pas le business — ou l'inverse. À chaque session, il faut copier-coller des extraits pour lui donner le contexte, et vous perdez la plupart des liens transversaux.

Dans le second cas, l'agent voit tout en même temps. Quand je lui demande d'implémenter le module checkout, il peut croiser le PRD dans docs/prd/checkout.md, l'ADR docs/adr/002-stripe-vs-adyen.md, le code existant dans apps/app/, et le plan marketing dans docs/marketing/personas.md pour savoir si l'UX doit viser le persona "parent pressé" ou "gourmet exigeant". Le résultat : des décisions prises avec le contexte complet, pas en silo. C'est ce qui élimine 80% des retours "tu n'as pas pris en compte X" qu'on fait habituellement à un dev junior ou à une IA aveugle.

Autre bénéfice : tout est versionné dans Git. Chaque décision a un commit, un auteur, une date. Je peux retracer pourquoi on a choisi MongoDB plutôt que Postgres il y a trois semaines, réverter, brancher pour tester une alternative. Toutes les propriétés de Git s'appliquent à la mémoire de l'entreprise. Et quand j'embarque un associé ou un premier recrutement technique, il clone le repo et hérite instantanément de toute la mémoire accumulée. Même un fondateur non-dev peut entrer dans cette boucle : j'ai monté un système pour lui servir toute cette doc git directement dans son LLM, sans Notion ni compte GitHub, afin qu'il lise et édite la mémoire du projet comme le reste de l'équipe.

L'équipe d'experts que je constitue pour chaque projet

L'IA agentique sait jouer des rôles avec un réalisme bluffant. On peut constituer une véritable équipe d'experts virtuels dédiée à un projet, chacun avec son domaine, sa posture, ses critères d'évaluation.

Côté technique, pour un audit qualité je ne mobilise pas un expert mais onze : Symfony/PHP, React Native/Expo, Go, Next.js/SEO, DevOps/SRE, DBA MongoDB, architecte monorepo, Staff Engineer paranoïaque (le pattern "qu'est-ce qui va casser en prod"), pentester, expert i18n, product manager technique. Chacun audite sa partie de la codebase en parallèle, produit un rapport markdown structuré avec des scores chiffrés, et ses recommandations deviennent des stories pour le cycle suivant. Là où une agence de conseil mettrait deux semaines et 10 à 15K€ pour un audit transversal équivalent, les onze subagents produisent leurs rapports en 15 à 20 minutes chacun. Ce n'est pas 10 fois plus rapide — c'est plutôt 100 fois.

Côté business, le pattern est identique. Récemment, pour relire un business plan avant stress-test stratégique, j'ai mobilisé un profil de "senior partner dans un fonds pré-seed, ami de l'entrepreneur, qui ne passe rien sous silence". Le retour a été d'une qualité comparable à un vrai feedback de VC : problèmes d'unit economics pointés ligne par ligne, incohérences dans la trajectoire financière identifiées, ton cash sans complaisance. C'est ce retour qui m'a permis de produire un dossier complet sur un cas fictif pédagogique (une app fictive de meal planning familial, "Bouch.ee") — business plan, stratégie de financement, deck seed, mail d'intro VC. Ces livrables servent d'échantillon de ce que produit la méthode — pas d'une levée réelle.

D'autres profils que je mobilise régulièrement : expert marketing B2B, stratège pricing, designer produit senior, expert conformité RGPD, rédacteur juridique pour les CGU/CGV, expert SEO/GEO. Chaque profil est documenté dans docs/experts/, réutilisable d'un projet à l'autre, et se bonifie avec l'expérience accumulée. Ces experts IA ne remplacent pas les humains — quand je paie un avocat pour relire des CGU, il ne part plus d'une page blanche, il relit un draft structuré qui couvre 80% des cas standards. Pour un fondateur qui démarre, c'est la différence entre 8 000 € de rédaction complète et 1 500 € de relecture experte. L'impact économique cumulé de cette démarche devient considérable sur la durée d'un sprint.

Le résultat : un MVP quasi-V2 en 2 mois

Combiner ces trois éléments — code et docs dans le même repo, documentation structurée de toute l'entreprise, équipe d'experts IA à la demande — ne donne pas une amélioration marginale de productivité. C'est un changement de régime. Sur les projets que j'accompagne, je livre en deux mois un MVP qui, fonctionnellement, ressemble davantage à une V1 aboutie qu'à un prototype — parfois même à une V2 débutante si le scope initial était bien cadré. Ce qui permet au fondateur de confronter son produit au marché avec une version suffisamment crédible pour que la validation du product-market fit soit réelle.

Ce qui rend ça possible : aucune dérive au fil des semaines parce que chaque session d'IA hérite des décisions passées ; moins d'erreurs parce que l'agent croise systématiquement code et business avant chaque choix ; des audits quasi quotidiens qui remontent les problèmes avant qu'ils ne s'accumulent ; une transmission immédiate à toute personne qui rejoint le projet. Le monorepo-mémoire n'est pas juste une astuce productivité. C'est un actif d'entreprise — un repository Git partageable qui contient, à un instant T, la quasi-totalité de la mémoire d'une société. Cet actif se valorise à chaque décision structurante : levée de fonds, recrutement, due diligence, revente.

Ce que Karpathy vient de formaliser, c'est l'intuition que plusieurs praticiens avaient développée : face à un LLM, le vrai levier n'est pas le prompt, c'est la structure de la mémoire qu'on lui donne. Les bonnes questions deviennent : qu'est-ce que je stocke, comment je l'organise, comment je le maintiens à jour. C'est le socle de tout ce que je regroupe dans mon guide pour industrialiser l'IA agentique sur un vrai projet.

Appliquer cette méthode à votre projet

C'est exactement l'approche que je déploie en Sprint Fondateur. En 2 mois, je livre à
un fondateur un monorepo complet contenant la mémoire vivante de son projet — business plan, stratégie de financement,
deck VC, PRD détaillé, MVP fonctionnel déployé — prêt à présenter à des investisseurs et à étendre avec une future
équipe technique.

Tester ses maquettes avec des personas joués par Claude : 4 insights que l'équipe n'aurait jamais trouvés

Rémi Alvado — Thu, 25 Jun 2026 20:46:22 +0000

Quand tu démarres un produit, tu fais des maquettes. Tu les regardes. Toi tu les aimes. Ton cofondateur les aime. Ton designer les aime. Le problème, c'est que vous êtes tous biaisés : vous savez ce que vous avez voulu, vous savez ce que vous avez construit, et donc vous voyez ce que vous avez voulu construire — pas ce qu'un client va voir.

Le coût classique de désambiguïsation est connu : 4 à 8 utilisateurs cible recrutés à 150 €/test, 2 à 4 semaines pour caler les agendas, transcriptions et analyse derrière. Plusieurs k€ et un mois. La voie courte — un atelier interne entre fondateurs — est gratuite mais biaisée par les convictions partagées : l'équipe répète ses propres certitudes et confond consensus avec validation. La voie longue est solide mais lente. Entre les deux, les fondateurs solos ou en duo prennent souvent la décision la plus chère : ils tranchent au feeling et partent en dev.

Je viens de tester en 24 heures une quatrième voie sur un projet B2B en cours de discovery — un produit complémentaire à mon académie de formation IA, ciblant cette fois des publics non-tech. Cinq variantes UX produites par Claude Design, quatre puis six personas joués par des sessions Claude Code isolées, des verbatims structurés en retour. Coût direct : zéro. Insights produit générés : quatre décisions structurantes qu'un atelier interne n'aurait pas sorties spontanément. Je ne pense pas une seconde que ça remplace les tests utilisateurs réels — j'expliquerai pourquoi à la fin. Mais c'est devenu un passage obligé de mon workflow amont, et ça vaut un article long.

Cet article s'inscrit dans un workflow plus large

J'ai déjà décrit comment je structure la mémoire et les maquettes d'un projet pour que client et IA y aient
accès. La méthode décrite ici se branche en amont de ce flow : avant de
valider les maquettes avec le client, on les fait critiquer par des personas joués par l'IA. Ça lève des angles morts
que ni le client ni l'équipe ne verront.

La méthode, en quatre étapes

Le process tient en quatre étapes courtes, dont une seule est vraiment nouvelle.

Étape 1 — Produire plusieurs variantes esthétiques. J'ai commandé à Claude Design quatre directions UX radicalement différentes pour le même produit : un SaaS éditorial style « magazine », une variante illustrée façon papier-crayon, un compagnon conversationnel dark, et un hybride. Chaque variante : 28 à 30 pages HTML navigables localement.

Étape 2 — Trancher à l'œil entre les variantes. L'équipe regarde, débat, préfère plus ou moins. On élimine ce qui ne marche pas, on garde ce qu'on aime, on rédige un cinquième brief « E » qui synthétise. Claude Design produit E. À ce stade, l'équipe se sent bien — mais n'a aucune preuve qu'un client achèterait. C'est exactement le point où la plupart des fondateurs partent en dev.

Étape 3 — Tester les variantes sur des personas joués par Claude, en aveugle. Je construis quatre personas très spécifiques (cf. § règles), j'ouvre quatre sessions Claude Code séparées sans contexte projet partagé, je leur donne un prompt détaillé et un accès Playwright pour screenshotter les écrans. Chaque persona navigue, juge, vote. En vingt minutes par persona, j'obtiens une matière structurée que je n'aurais pas eue autrement.

Étape 4 — Itérer, valider, trancher. Je synthétise les retours en treize corrections priorisées, je commande une variante E-prime, et je refais un round 2 avec un protocole hybride : deux anciens personas en revue ciblée sur leurs critiques V1, deux nouveaux en aveugle sur la V2 seule. Au verdict du round 2 : six personas sur six achètent sous conditions. On entre en dev, sans plus aucun débat interne ouvert.

Les quatre insights qu'un atelier interne n'aurait pas sortis

C'est le cœur de la valeur. Voilà quatre retours qui ont concrètement modifié le produit — et qu'on n'aurait pas trouvés à dix dans une salle.

1. La notif WhatsApp du dirigeant

Comment le canal qu'on avait prévu pour l'apprenant a basculé côté dirigeant.

Karim, le premier persona, est un dirigeant de TPE — une boulangerie de 26 salariés en région. Dans le brief initial, on avait prévu des notifications soignées pour l'apprenant : email à J+0, push à J+1, WhatsApp à J+3 en cas de décrochage. Karim regarde les maquettes vingt minutes et répond :

« Si je paye lundi et que vendredi personne s'est connecté, l'argent est perdu et j'ai l'air d'un con auprès de mon équipe. Ce qu'il me faut, c'est pas une belle maquette — c'est une notif WhatsApp tous les soirs qui me dit qui a fait son exercice et qui décroche. »

Je doute qu'un atelier interne aurait sorti ça en première intention. C'est le verbatim d'un dirigeant qui paie de sa poche, qui n'a pas le temps d'ouvrir une console, et qui veut un canal qu'il consulte déjà en boucle. Conséquence directe : un canal de notification dirigeant distinct du canal apprenant. Pas un dashboard. Un message WhatsApp court, le soir, une ligne par personne, fait/pas fait. Le persona suivant — une Office Manager d'une agence — a validé ce nouveau design avec un 5/5 et un commentaire en majuscules : « CECI EST DU GÉNIE. »

2. Le mot « vacances » qui claque la porte dans l'industrie

Quand un nom marketing fort devient un mur de vente sur certains segments.

Le projet a un nom marketing fort, taillé pour la presse et le contenu d'été. Yannick, RRH d'un sous-traitant automobile de la métropole lilloise, le dit sans détour :

« Si je peux retirer toute mention "vacances" dans les écrans que je montre en interne et ne garder que "le programme IA métier", c'est plié. »

Il a raison. Dans un site industriel où on parle production et tableau de bord HSE, un nom léger fait perdre l'achat avant le pitch. Conséquence : un mécanisme de rebrand tenant-side. Chaque client configure un nom interne — par exemple « Programme IA Métier · MétalRoubaix » — qui remplace le nom marketing dans tous les écrans authentifiés. Le nom externe reste celui qui claque pour la presse et les contenus publics. Sans cette fonctionnalité, on perdait probablement 30 à 40 % des cibles industrie et grand compte. Aucun moyen de l'anticiper en interne — c'est un détail qu'on ne voit que quand un RRH te le dit avec ses mots à lui.

3. Le ROI en heures, pas en pourcentages

La vraie question qu'un DG pose dans 3 mois, et la métrique qui y répond.

Sur l'écran « slide COMEX » — celui que le décideur projette en comité exécutif pour justifier l'achat — on affichait des KPI propres : 94 % de places activées, 79 % d'exercices terminés, 3,6/5 de compétences acquises. Sandrine, DRH d'une PME de bureau d'études à Nantes, lit la slide et répond :

« Si mon DG me demande "qu'est-ce que ça a changé ?" dans 3 mois, je veux pas dire "ils se sentent mieux". Je veux dire "40 heures économisées sur les fiches de poste et 60 heures sur les relances candidats". »

Conséquence : un module Heures économisées sur le COMEX. « 25 h économisées sur 60 jours · équivalent ~½ ETP de gain sur ton équipe », avec un tableau par cas d'usage. C'est ce qui transforme un produit de formation en un produit avec ROI mesurable, lisible par un DG qui ne lit jamais le détail. Au round 2, Sandrine donne 5/5 à cet écran et écrit : « La slide que je veux mettre devant mon DG. Pas du sentiment, des heures. Et le ½ ETP, c'est traduit en langage DAF. »

4. Les concurrents qu'on n'avait pas vus : les cabinets de conseil

Quand l'angle d'attaque concurrentiel ne vient pas du marché SaaS mais de PowerPoint vendus 300 k€.

Dans l'analyse de marché initiale, on avait listé les acteurs SaaS de la formation IA. Plateformes en ligne, mentorat, e-learning. Patricia, DRH d'une ETI de 1 200 personnes à Paris, identifie un concurrent qu'on n'avait pas inscrit :

« Ce qui me fait peur, c'est que pendant que je négocie ça, BCG Brighthouse ou McKinsey QuantumBlack vienne pitcher au CODIR un programme transverse à 300 k€ et qu'on coupe la décision à mon niveau. »

Ce ne sont pas des produits SaaS — ce sont les branches IA de cabinets de conseil, qui ne vendent pas un outil mais un programme de transformation facturé directement au DG, court-circuitant la DRH. Pour une ETI, c'est l'angle d'attaque le plus dangereux : la décision quitte la DRH avant qu'elle ait eu le temps de comparer. Conséquence stratégique : notre positionnement doit désormais être explicite — « pilote agile sur 14 personnes, 60 jours, sortie possible » par opposition au « programme 300 k€ sur 18 mois ». Sans Patricia, on partait en go-to-market en croyant qu'on se battait contre des plateformes en ligne. On se bat aussi contre des decks PowerPoint vendus à 300 k€ — et on les bat différemment.

Les sept règles qui font que ça marche

Lancer Claude dans le rôle d'un persona, c'est trivial à dire. Le faire bien, c'est plus subtil. Voilà les règles que j'ai trouvées en pratique pour que les retours soient utilisables, et pas une bouillie polie de bons sentiments.

Règle 1 — Persona spécifique, pas archétype

Mauvais prompt : « Tu es une DRH de PME, donne ton avis. » Bon prompt : 250 mots de spec qui ancrent la persona dans un réel. Pour une DRH de PME, ça ressemble à ça :

« Sandrine Bertrand, 47 ans, DRH d'AltiSciences — bureau d'études techniques 68 salariés à Nantes. DRH depuis 9 ans là-bas. Pas tech : tu utilises Microsoft 365 quotidiennement, tu détestes les formules Excel. Tu as essayé ChatGPT 4 ou 5 fois en 2024-2025, jamais intégré dans ta semaine. Ton DG t'a demandé en mars 2026, en CODIR : "Sandrine, qu'est-ce qu'on fait sur l'IA pour les équipes ?" Tu lui as répondu "je regarde". Depuis, tu n'as pas vraiment regardé. Tu es méfiante des "outils miracles" — tu en as vu passer trop en 9 ans (Officevibe, Lattice, un LMS qu'on a payé 12 k€ et que personne n'a utilisé). Budget formation 2026 quasi épuisé ; tu peux puiser 2 à 4 k€ sur ton enveloppe discrétionnaire si tu as une vraie raison. Deux peurs : (1) que les salariés balancent des données sensibles à un LLM et qu'on se prenne la CNIL, (2) que le COMEX te demande "ROI" dans 3 mois et que tu n'aies rien à montrer. »

Plus le persona est précis, plus le retour est précis. Les détails non-fonctionnels — école, échec d'outil passé nommé, marge budgétaire au k€ près, phrase qu'elle a dite à son DG — sont ce qui transforme un archétype en personne. Sans eux, Claude joue une DRH générique et le retour est plat.

Règle 2 — Isolation totale de la session

L'agent qui joue le persona ne doit pas pouvoir lire les docs/ du repo (ils contiennent toute la stratégie produit — biais énorme), ni le git log, ni les README, ni les fichiers de style des maquettes, ni naviguer le web pour chercher ce qu'est le produit. Cette interdiction se précise dans le prompt : « Tu n'as pas le droit de lire X, Y, Z. Limite-toi au rendu visuel des maquettes. » Sans ça, Claude lit les docs/ et son retour devient celui d'un consultant qui sait ce que le produit veut faire — exactement ce qu'on essayait d'éviter.

Règle 3 — Rendu visuel, pas le HTML

Lire le HTML ne dit rien sur la qualité visuelle. La grande typo serif italique, le confort de lecture, l'effet « centre aéré pour CE2 » d'une variante illustrée — tout ça se voit, pas se lit. J'installe Playwright en local et je fournis à l'agent une commande qui screenshotte les pages clés en PNG, puis il lit les images. Sans cette étape, le persona ne « voit » pas la maquette — il en devine la structure. Avec elle, il dit « on dirait Madame Figaro, ça fait Lubéron » devant une photo placeholder. C'est ce niveau de jugement qu'on cherche.

Règle 4 — Format de réponse strict

Mauvais brief : « Donne ton avis. » Bon brief : un template figé. Pour chaque variante, première impression en 15 secondes, ce qui m'attire (verbatim 2-3 phrases), ce qui me freine (verbatim 2-3 phrases), trois notes /5 (confiance d'achat, effet wahou, crédibilité COMEX), une seule chose que je changerais avant d'acheter. Sans format imposé, Claude part en analyse design senior et noie le poisson. Avec le format, il reste dans la peau du persona qui dit « c'est moche, je vais le dire comme ça ».

Règle 5 — Ton autorisé explicite

Pour la DRH PME : « Pas de politesse excessive. Pas de "c'est très bien". Si c'est moche, dis "c'est moche". Si c'est confus, dis "j'ai pas compris". » Pour le RRH industrie : « Tu dis "machin", "ça va pas le faire", "c'est un peu m'as-tu-vu", tu détestes les anglicismes. » Pour le DG d'agence expert IA : « Direct, exigeant, vocabulaire produit ("UX", "onboarding", "north star", "jobs-to-be-done"). » C'est ce qui produit des verbatims utilisables. Sans contrainte de ton, Claude vouvoie tout le monde poliment et la matière est inexploitable.

Règle 6 — Multi-persona, diversité forcée

J'ai varié sur six axes : taille d'entreprise (12 sal. → 1 200 sal.), secteur (artisanat, industrie, services pro, agence com, bureau d'études), âge (33 → 54 ans), tech literacy (faible → expert), rôle de décision (DG, DRH, RRH, Office Manager), pression interne (aucune → COMEX dans 6 mois). Sans diversité, on obtient six fois le même retour. Avec, on obtient six retours qui se contredisent par moments — et les contradictions sont riches. La variante illustrée recueille un 8/12 du dirigeant de TPE (« c'est rigolo, ça désamorce le côté flippant ») et un 6/15 de la DRH d'ETI (« je ne peux pas mettre ça devant un COMEX d'audit financier »). Les deux ont raison pour leur cible. C'est ce diagnostic qui te dit ce que tu n'écriras pas en homepage publique mais que tu garderas pour le pitch commercial.

Règle 7 — Round 2 hybride pour la V2

Quand j'ai livré la V2 corrigée des retours V1, je n'ai pas refait tester les quatre mêmes personas en aveugle. Risque connu : ils sont contaminés, ils savent ce qu'ils ont dit, ils vont chercher si on les a écoutés — effet demand characteristics. Protocole utilisé : deux anciens en revue ciblée (« voici tes critiques V1, dis-moi si elles sont traitées, point par point »), et deux nouveaux en aveugle (persona neuve, V2 seule, pas de comparaison cross-variante). Ce protocole isole deux questions distinctes : « les corrections marchent-elles ? » (anciens, confirmation) et « le produit séduit-il un cerveau frais ? » (nouveaux, vrai signal). Au round 2, les six convergent. À ce moment-là, le débat interne s'arrête.

Les limites — ce que la méthode ne fait pas

Soyons honnête sur ce qu'un persona joué par Claude ne fait pas.

Il ne clique pas en hésitant. Pas d'observation comportementale : où la souris hésite, où le testeur abandonne, où il scrolle trois fois avant de comprendre, où il revient en arrière. Cette matière-là — précieuse pour l'UX réelle — n'existe pas dans un retour Claude. Tu auras les verbatims et les notes ; tu n'auras pas la friction de clic.

Il ne dit pas n'importe quoi. Un vrai utilisateur peut dire des trucs incohérents, contredire dans la phrase suivante, ne pas savoir pourquoi il n'aime pas un truc. Claude est trop propre. Ses retours sont structurés, articulés, parfois trop intelligents pour la persona qu'il joue. Un Office Manager fictif peut sortir un raisonnement de Senior Product Designer sans s'en rendre compte. Le ton imposé et le vocabulaire interdit limitent ça, mais ne l'éliminent pas.

Il ne représente pas la diversité réelle. Six personas Claude n'égalent pas six vraies personnes. Il y a une cohérence interne au modèle qui peut homogénéiser les retours, surtout sur les sujets où le modèle a des opinions implicites. C'est précisément pour ça que la diversité forcée (règle 6) est non-négociable — et que les contradictions entre personas sont le signal qu'il faut traquer.

Il ne paie pas. Pas de prix exact testable, pas de mesure d'engagement, pas de validation économique. Pour ces sujets-là, il faut des vrais utilisateurs, point.

Quand ne pas l'utiliser. Pour décider d'un prix exact (les personas ne paient pas vraiment). Pour mesurer un effet d'engagement (pas d'observation de durée, de taux de retour). Pour des produits émotionnels complexes — luxe, dating, jeu — où le verbatim ne suffit jamais à capter l'intention d'achat.

Comment compléter. Cette méthode est un complément amont, pas un remplacement. Elle te permet d'éliminer les 80 % de fausses pistes avant d'investir dans des tests réels, d'identifier les bonnes questions à poser à de vrais utilisateurs, et d'itérer cinq fois plus vite sur les maquettes. Tu fais quand même des tests utilisateurs réels — mais trois ou quatre au lieu de douze, sur des hypothèses précises au lieu de fishing. Comme l'IA en général n'invente pas l'expertise mais l'amplifie, un persona Claude n'invente pas la voix du client : il amplifie ta capacité à formuler les bonnes questions avant de la confronter à la réalité.

Récap chiffres

Métrique	Valeur
Durée totale du process	24 heures (14 h hier → 13 h aujourd'hui)
Variantes UX explorées	5 (A, B, C, D, E)
Personas testés round 1	4
Personas testés round 2	6 (4 anciens en revue ciblée + 2 nouveaux en aveugle)
Durée moyenne d'un test persona	~20 minutes (prompt → retour structuré)
Coût direct	~0 € (sessions Claude Code Pro existante)
Coût équivalent en tests réels	4 à 5 k€ + 2 à 4 semaines
Insights produit majeurs générés	4 (notif dirigeant, rebrand tenant, ROI en heures, cabinets de conseil)
Conversion round 2	6/6 personas (~6 800 € HT de prospects warm modélisés)
Corrections produit identifiées	13 (4 bloquantes + 9 importantes) + 7 sujets roadmap

Alors, est-ce que les LLM remplacent les tests utilisateurs ?

Non. Et personne sérieux ne devrait dire le contraire. Un persona Claude ne paie pas, ne clique pas en hésitant, ne contredit pas ses propres convictions à mi-phrase. Les vrais tests utilisateurs restent indispensables pour valider une intention d'achat, une métrique d'engagement, un prix.

Mais pour un fondateur solo ou un duo en pré-revenu, avec une fenêtre de lancement courte et un budget contraint — ce qui est la situation par défaut de tout projet B2B SaaS en discovery — la méthode change la nature du jeu. Tu ne passes plus quatre semaines à recruter douze testeurs pour confirmer ton intuition. Tu passes 24 heures à confronter cinq variantes à six points de vue diversifiés, à extraire treize corrections, à éliminer 80 % des fausses pistes. Quand tu sors pour faire les vrais tests utilisateurs derrière, tu poses trois ou quatre questions précises au lieu d'aller pêcher au filet. Le ROI est dans la qualité des questions, pas dans le remplacement des réponses.

Elle est devenue un passage obligé de mon workflow pour tout projet en phase amont — et notamment sur les missions Sprint Fondateur, où le délai de deux mois ne laisse pas le luxe d'aller pêcher au filet.

Vous attaquez un projet en discovery ?

J'applique exactement cette méthode dans chaque Sprint Fondateur : génération de
variantes UX, tests personas Claude, itération guidée par les verbatims, validation V2 avant tout dev. Si vous êtes
fondateur non-tech et que vous voulez confronter votre intuition à six points de vue diversifiés en 24 heures plutôt
qu'à un mois de recrutement, parlons-en. Je propose aussi cet exercice en mode atelier ponctuel dans
le cadre de mes accompagnements IA agentique.

51 stories, 4 sprints, 0 régression : comment j'ai livré une academy complète avec des agents IA autonomes

Rémi Alvado — Thu, 25 Jun 2026 20:46:17 +0000

J'ai livré une application de formation complète en 4 sprints d'agents IA autonomes. 51 stories. 68 tests E2E. 5 parcours journey. Zéro bug de régression détecté en test manuel. Le tout en quelques heures de travail agent — pas de travail humain sauf la supervision et le test final.

Ce qui m'intéresse dans cette expérience, ce n'est pas la vitesse. C'est ce qui l'a rendue possible : exactement les mêmes pratiques de gestion de projet qu'on utilise depuis 20 ans — vision produit, découpage en stories, tests automatisés, gates de qualité. Sauf qu'au lieu de les appliquer à une équipe de développeurs, je les ai appliquées à des agents.

Contexte

Cet article fait partie d'une série sur l'IA agentique en conditions réelles. Si le sujet vous intéresse, l'article
Le monorepo-mémoire : le vrai levier n'est pas le prompt pose les fondations
de cette approche.

Le problème : les deux mauvaises options

Quand on utilise l'IA agentique pour développer un lot de fonctionnalités, on a en général deux options et aucune n'est satisfaisante.

La première, c'est le mode feature par feature. On lance l'agent sur une story, on teste manuellement, on corrige, on passe à la suivante. Le résultat est bon mais l'agent passe 80% de son temps à attendre que l'humain teste. La nuit, le week-end, quand on est sur un autre projet — il ne fait rien. C'est un gaspillage de temps d'horloge considérable.

La seconde, c'est le mode tout d'un coup. On lance toutes les features, on revient plus tard. Le problème c'est qu'on se retrouve avec une montagne de code à tester. Exactement comme un Product Owner qui revient de vacances et découvre 30 stories en "Product QA" dans son Kanban. L'équipe a super bien avancé, les tests unitaires passent, mais personne n'a jamais cliqué sur un bouton pour vérifier que le parcours utilisateur fonctionne de bout en bout.

Il fallait une troisième voie. Et après 4 sprints de production, je peux dire que cette troisième voie fonctionne vraiment.

La méthode : un harnais en 3 couches

L'idée est simple en théorie : donner à l'agent non seulement les stories à développer, mais aussi les critères pour vérifier lui-même que son travail est correct. Pas juste "le code compile" — "le parcours utilisateur fonctionne".

Concrètement, j'ai mis en place trois couches de sécurité empilées.

Couche 1 : l'analyse statique et les tests unitaires. C'est le minimum syndical — PHPStan, TypeScript strict, PHPUnit. L'agent les fait tourner après chaque story. Si c'est rouge, il corrige avant de passer à la suite. Rien de nouveau ici, c'est ce que toute équipe de dev devrait faire.

Couche 2 : un test E2E Playwright par story. Chaque story s'accompagne d'un vrai test navigateur qui vérifie ses critères d'acceptance. Pas un test unitaire frontend — un parcours complet : login, navigation, action, vérification. L'agent l'écrit ET le fait passer.

Couche 3 : les tests journey cross-stories. C'est là que ça devient intéressant. Avant de commencer à coder, j'ai écrit 3 scénarios end-to-end qui traversent tout le produit, de la création d'un devis jusqu'à l'envoi des attestations de formation. Ces tests sont initialement désactivés (test.fixme). Au fur et à mesure que l'agent progresse, il active les étapes que sa story débloque. Si un test journey casse à cause d'une story ultérieure, il le corrige immédiatement.

Le protocole de l'agent pour chaque story devient :

1. Lire la story et ses critères d'acceptance
2. Implémenter le backend + frontend
3. Écrire le test E2E de la story
4. Gate 1 : analyse statique + tests unitaires → vert
5. Gate 2 : test E2E de la story → vert
6. Gate 3 : tests journey (ceux déjà activés) → verts
7. Si rouge → fixer AVANT de passer à la suite

La règle d'or est brutale : ne jamais passer à la story suivante si un test est rouge.

Ce que ça donne en pratique : 4 sprints

Le scope final est une application de formation complète pour mon CRM — academie.alva.do. Au lieu de tout lancer en un seul bloc, j'ai découpé le travail en 4 sprints séquentiels, chacun confié à un agent autonome dans un container Docker.

Avant de lancer le premier agent, j'ai passé environ 2 heures à préparer le terrain. Un PRD de 3 pages qui décrit la vision. 18 stories détaillées avec critères d'acceptance. 3 tests journey en mode fixme. Un Dockerfile avec tout l'outillage (PHP, Node, Playwright, Chromium). Une commande de seed qui crée les données de test. Et un prompt de 200 lignes qui décrit le protocole gate par gate.

Sprint 1 — L'EPIC fondateur : 18 stories pour le socle (rapports hebdomadaires, sessions de formation, convention, émargement digital, app stagiaire, documents partagés). 1h20 d'agent. Résultat : une nouvelle app web complète, 25 endpoints API, 275 tests unitaires.

Sprint 2 — Les présentations : 11 présentations MDX pour le programme de formation (45 min à 15 slides chacune). L'agent a créé le contenu pédagogique — pas juste du code. 33 tests E2E qui vérifient que chaque présentation compile et s'affiche.

Sprint 3 — L'infrastructure quiz : modèle de données (Quiz, QuizAnswer), API (18 endpoints), scoring côté serveur avec classement en temps réel, export CSV, interface d'administration pour le formateur. 14 tests E2E + 11 tests unitaires.

Sprint 4 — L'expérience interactive : page quiz plein écran avec timer animé, classement live avec médailles, résultats détaillés par question, ROTI anonyme, export PDF pour le RH. 21 tests E2E + 1 journey complet.

Le bilan après les 4 sprints :

Métrique	Valeur
Stories livrées	51
Fichiers créés ou modifiés	~250
Lignes ajoutées	~20 000
Tests unitaires	295
Tests E2E	68
Tests journey	5 parcours complets
Bugs de régression	0
App frontend	1 (academie.alva.do)
Endpoints API	40+
Présentations créées	11

Un point important : je ne lis plus le code. Je ne l'ai pas lu pendant les 4 sprints et je ne le lirai pas après. Ce n'est pas de la négligence — c'est que les 3 couches de tests font le travail de vérification à ma place. Si les 5 tests journey passent, ça signifie qu'un utilisateur peut se connecter, participer à un quiz avec timer et classement live, signer son émargement, voir ses résultats. C'est plus fiable que n'importe quelle revue de code manuelle.

Ce qui a cassé (et ce que ça nous apprend)

Tout n'a pas marché du premier coup sur le sprint 1. L'agent a livré les 18 stories avec un backend solide, mais il a jugé que les tests journey étaient "hors scope". Il a eu tort, et je l'ai relancé. Au deuxième run, le seed avait des bugs : l'agent avait deviné les noms de champs de l'API au lieu de lire les controllers. L'équivalent d'un développeur qui code contre une API sans lire la documentation. Un troisième prompt a été nécessaire pour corriger un raccourci architectural (iframe au lieu de rendu natif des slides).

Ce qui est remarquable, c'est la suite. Les sprints 2, 3 et 4 se sont chacun déroulés en un seul run, sans intervention humaine pendant l'exécution. Toutes les gates (PHPStan, PHPUnit, TypeScript, Playwright) sont passées du premier coup. La raison est simple : chaque sprint a bénéficié des leçons du précédent. Le prompt s'est affiné. Les garde-fous se sont précisés ("N'utilise PAS de caractères Unicode échappés", "Fais un git commit après chaque story"). Le harnais de tests s'est enrichi.

L'infrastructure des workers a aussi évolué en cours de route. Le premier sprint utilisait un script naïf qui supprimait le clone à chaque lancement — 10 minutes perdues en réinstallation de dépendances. En m'inspirant d'un projet précédent, j'ai réécrit le système avec des clones persistants et un store pnpm partagé entre les workers. Résultat : le deuxième lancement d'un worker prend 15 secondes au lieu de 10 minutes.

Au total sur les 4 sprints : quelques heures de travail agent, environ une demi-journée de temps humain (setup, supervision, tests manuels, corrections UX). La bonne nouvelle c'est que chaque correction a rendu le système plus robuste pour la suite. L'agent a créé de lui-même un service "bouchon" pour remplacer Google Drive en environnement de test, un pattern qui permet à tous les tests de tourner sans configuration externe.

Le vrai enseignement : les sprints séquentiels

Le découpage en sprints séquentiels n'était pas prévu au départ. J'avais initialement voulu tout faire en un seul prompt. Mais après le sprint 1, le pattern est devenu évident : chaque sprint doit construire sur le précédent, pas essayer de tout faire d'un coup.

Sprint 1 (backend + app) → Sprint 2 (contenu) → Sprint 3 (infra quiz) → Sprint 4 (UX interactive). Chaque sprint hérite du code, des tests et du contexte du précédent. L'agent du sprint 3 peut lire les documents créés par l'agent du sprint 2. L'agent du sprint 4 peut réutiliser les endpoints créés par l'agent du sprint 3.

C'est le même principe que dans une équipe humaine : on ne demande pas au même développeur de faire l'architecture, le contenu, l'infra et le frontend en même temps. On découpe, on séquence, on valide à chaque étape. La différence c'est que là, chaque "développeur" est un agent qui travaille en 30 minutes ce qui prendrait 2-3 semaines.

Pourquoi les bonnes pratiques comptent plus, pas moins

Ce retour d'expérience confirme une conviction forte : l'IA agentique n'élimine pas le besoin de bonnes pratiques de gestion de projet. Elle les rend encore plus importantes.

Sans PRD, l'agent code dans le vide. Sans stories découpées, il fait des choix architecturaux incohérents. Sans tests automatisés, il produit du code qui compile mais qui ne fonctionne pas de bout en bout. Sans gates de qualité, les régressions s'empilent silencieusement. Et sans découpage en sprints, un agent qui déraille au milieu vous coûte tout le travail au lieu d'un seul sprint.

La métaphore que j'utilise en formation est celle du chef d'orchestre. Le chef ne joue pas d'instrument, mais sans lui, l'orchestre joue faux. Le PRD est la partition. Les stories sont les mesures. Les tests sont les répétitions. L'agent est l'orchestre. Et vous êtes le chef.

Ce qui change avec l'IA, c'est que l'orchestre joue 100 fois plus vite. Ce qui ne change pas, c'est qu'il a besoin d'une partition pour jouer juste.

Ce que l'humain fait mieux (et doit continuer à faire)

Les 68 tests E2E sont verts. Les 5 parcours journey passent. La mécanique fonctionne. Mais il reste des choses que l'agent ne peut pas valider, et c'est important de les nommer.

Le feeling UX d'abord. Après les 4 sprints, j'ai passé une heure à naviguer dans l'application en me mettant à la place d'un formateur, puis d'un stagiaire. Le timer du quiz était en décompte (15 → 0) alors que ce n'est pas une course de vitesse — je l'ai fait passer en compteur croissant. Les stagiaires voyaient un badge "Piège !" sur certaines questions, ce qui n'a aucune valeur pédagogique — je l'ai retiré. Le temps de réponse était affiché dans le classement, ce qui créait une pression inutile — masqué. Six corrections de ce type, toutes trouvées en test manuel, aucune détectable par un test automatisé.

Le design d'information ensuite. L'agent avait créé deux blocs séparés "Présentations" et "Quiz" dans l'interface du formateur. En pratique, un formateur pense en "programme" : il sait qu'il fait la présentation "Mémoire du projet" le matin du jour 1, puis le quiz correspondant juste après. J'ai fusionné les deux en un bloc "Programme" unique, groupé par jour et demi-journée. Cette décision structurante ne pouvait pas venir de l'agent — elle vient de la compréhension du métier.

En comptant honnêtement, c'est une demi-journée de travail humain sur l'ensemble des 4 sprints — et pas une demi-journée de concentration intense : j'ai fait autre chose en parallèle pendant que les agents travaillaient. Le résultat aurait pris 3-4 mois à une équipe de 2-3 développeurs avec un PO. Pas parce que l'IA est magique, mais parce que les bonnes pratiques, appliquées rigoureusement, créent un effet multiplicateur que les méthodes traditionnelles ne permettent pas d'atteindre.

Vous voulez installer ce process dans votre équipe ?

En formation IA agentique, on installe exactement cette méthode — du PRD aux
tests journey en passant par les workers autonomes — pour que vos équipes puissent livrer des EPICs entiers en
autonomie avec un harnais de qualité. 2 jours pour transformer votre façon de travailler.

Loop engineering : ce qui est vraiment nouveau

Rémi Alvado — Thu, 25 Jun 2026 19:12:00 +0000

Cette semaine, je suis tombé sur un article d'Addy Osmani qui théorise le « loop engineering » : ne plus prompter ses agents de code soi-même, mais concevoir le système qui les prompte à votre place. Il cite Boris Cherny, le créateur de Claude Code : « Je ne prompte plus Claude. J'ai des boucles qui tournent et qui promptent Claude. Mon travail, c'est d'écrire des boucles. » J'ai pris l'article comme un test : qu'est-ce que ma méthode couvrait déjà, et qu'est-ce qui me manquait vraiment ?

Le contexte de ma méthode

Si vous découvrez ce blog, deux articles posent les fondations de ce qui suit : le
monorepo-mémoire et 51 stories livrées par des agents autonomes sans
régression.

Les cinq briques du loop engineering

L'article décompose une boucle en cinq briques, plus une fondation : des automatisations qui se déclenchent toutes seules, des worktrees pour isoler les agents parallèles, des skills pour capitaliser la connaissance projet, des connecteurs MCP pour agir sur vos vrais outils, des sous-agents pour séparer celui qui produit de celui qui vérifie. Et en dessous de tout ça, une mémoire qui vit hors du contexte de conversation — un fichier markdown, un board, peu importe, du moment que ça survit à la session.

En confrontant cette grille à ma méthode, le bilan était plus flatteur que prévu :

Brique	Chez moi	Verdict
Mémoire externe	Monorepo-mémoire : docs/, ADR, PRD versionnés dans Git	Acquis depuis longtemps
Skills	Bibliothèque de skills réutilisables cross-projets	Acquis
Sous-agents	Audits multi-experts, personas qui testent les maquettes	Acquis, et au-delà
Connecteurs MCP	Mon CRM expose ses propres outils MCP aux agents	Acquis, dans les deux sens
Worktrees	Workers Docker isolés avec clones persistants	Équivalent maison
Automatisations	Rien : c'est moi qui appuyais sur le bouton	Le vrai trou

Quatre briques sur cinq existaient déjà, parfois depuis plus d'un an. La mémoire versionnée est même la thèse centrale de ce blog : l'agent oublie tout entre deux sessions, le repo n'oublie rien. Si tu veux la vue d'ensemble de cette approche, j'ai rassemblé tout ce que je sais sur l'IA agentique appliquée au build dans un guide dédié. Cette mémoire, je la pousse aujourd'hui jusqu'à la servir directement dans le LLM d'un fondateur non-dev, pour que même celui qui ne touche pas au code travaille sur la même base que les agents. Mais la première brique — celle qui fait qu'une boucle est une boucle et pas un run qu'on relance à la main — me manquait entièrement. Tout mon système attendait que je le déclenche. C'est exactement la différence entre outiller ses agents et concevoir le système qui les fait travailler.

Ce qu'on a construit : une boucle fermée

J'ai donc passé une journée à fermer la boucle, avec Claude Code comme partenaire de conception. Le résultat tient en trois pièces, toutes versionnées dans le repo.

D'abord, une queue de fichiers : un dossier todo/ où chaque tâche est un fichier markdown autosuffisant — le scope complet, les contraintes découvertes, les décisions déjà tranchées. Quand je cadre un besoin en conversation avec Claude Code, la valeur de cette itération se capitalise dans le fichier au lieu de s'évaporer à la fin de la session. Une session de boucle réclame ensuite une tâche en la déplaçant vers doing/ (un déplacement de fichier fait un verrou très convenable), la traite, puis la range dans done/ avec son rapport. La boucle s'auto-alimente : une tâche finie, la suivante démarre.

Ensuite, un harnais d'exécution : pour chaque tâche, un workflow déterministe enchaîne implémentation, tests automatisés à trois niveaux — unitaires, fonctionnels de bout en bout, parcours complets — puis une boucle de convergence dont je reparle plus bas. Le point clé : un agent ne passe jamais à la suite si un test est rouge, et il n'a pas le droit d'affaiblir un test pour le faire passer. Le vérificateur qui compte n'est pas un autre agent qu'on peut convaincre, c'est une suite de tests qui ne négocie pas.

Enfin, une inbox de décisions : tout ce qui relève d'un choix produit — un comportement à trancher, un wording ambigu, un état manquant — sort de la boucle sous forme d'une page HTML que j'ouvre dans mon navigateur. Chaque décision propose Go, No-go ou À discuter, avec un champ de commentaire, et un bouton « Copier pour Claude Code » assemble ma réponse. Je la colle dans n'importe quelle session, les Go redeviennent des tâches dans la queue. Les agents ne tranchent jamais un choix produit à ma place : c'est une règle écrite dans le contrat, pas une bonne intention.

Là où ma méthode va plus loin que l'article

La littérature sur le sujet s'arrête en général à la revue de code : un agent écrit, un autre relit. C'est nécessaire, mais ça ne regarde que le code. Or ce que vos utilisateurs voient, c'est un écran.

Ma boucle de convergence ajoute donc une dimension que je n'ai vue nulle part ailleurs : à chaque tour, un agent lance l'application, capture chaque écran nouveau ou modifié — en desktop et en mobile — et confie ces captures à deux experts joués par des agents distincts. Un expert product design, qui cherche les problèmes de hiérarchie visuelle, les états vides ou d'erreur manquants, la lisibilité mobile. Un expert product management, qui vérifie que la valeur promise par la tâche est réellement perceptible à l'écran et que le parcours n'a pas de friction. C'est le prolongement direct de ce que j'avais expérimenté en faisant tester des maquettes par des personas joués par Claude — appliqué cette fois en continu, à chaque feature, sans intervention de ma part.

Leurs findings sont triés par une règle simple : ce qui est mécanique — un contraste insuffisant, une troncature, une duplication de code — est corrigé immédiatement par un nouvel agent, et les tests repassent. Ce qui est produit part dans mon inbox. La boucle est bornée : trois tours maximum, un seuil de sévérité pour ignorer le pinaillage, et une condition de convergence — un tour sans correction mécanique, c'est terminé. Sans ces bornes, une boucle de relecture devient une machine à polir indéfiniment, qui dégrade autant qu'elle améliore.

La première tâche réelle a d'ailleurs été instructive : deux frictions détectées dans la journée — un format d'argument mal passé entre agents, un port de développement déjà occupé par mon propre serveur — et deux corrections reportées le soir même dans les templates d'un installeur réutilisable. Ma boucle s'installe maintenant sur n'importe quel repo en une commande. C'est ça, le vrai livrable : pas une feature, un système qui s'améliore à chaque friction rencontrée.

Ce que la boucle ne fait toujours pas

L'article d'Osmani se termine sur une mise en garde que je partage entièrement : deux personnes peuvent construire exactement la même boucle et obtenir des résultats opposés. L'une s'en sert pour aller plus vite sur un travail qu'elle comprend en profondeur, l'autre pour éviter de comprendre. La boucle ne fait pas la différence. Vous, si.

Concrètement, ma boucle ne supprime ni la préparation — qui reste l'essentiel du travail — ni la revue humaine. Et elle n'est qu'un outil parmi d'autres : le loop engineering excelle sur du travail répétitif et bien cadré, mais il serait dangereux sur de l'exploratoire à fort enjeu. Je l'ai resitué depuis dans la boîte à outils complète du Product Builder, où la vraie compétence n'est pas de connaître un outil mais de savoir lequel sortir selon le contexte. Elle déplace mon levier : je ne prompte plus l'implémentation, je rédige des tâches autosuffisantes et je traite des décisions dans une inbox. Ma bande passante de relecture reste le plafond du système, et c'est un plafond que j'assume : le jour où je l'oublierai, la qualité de ce que je livre le rappellera à ma place.

Envie de mettre ça en place chez vous ?

J'accompagne les équipes qui veulent passer de l'usage individuel des agents IA à un système outillé — harnais de
tests, boucles, gouvernance des décisions. C'est l'objet de ma prestation d'accompagnement IA
agentique, et ça commence souvent par une formation pour vos
équipes.