DEV Community: Rémi Alvado

Quelle dilution accepter en levée d'amorçage ?

Rémi Alvado — Tue, 11 Aug 2026 05:23:19 +0000

« On me propose de l'argent, je signe. » C'est compréhensible quand le cash manque, mais la dilution d'un tour d'amorçage n'est pas une variable qu'on subit : c'est une décision de dirigeant qui engage toute la suite de votre table de capitalisation. Céder trop, ou pas assez, se paie au tour suivant.

La dilution raisonnable en levée d'amorçage se situe entre 15 et 25 % du capital, pool d'options compris. En dessous de 15 %, le tour intéresse peu un fonds. Au-dessus de 25 %, vous vous fragilisez pour la série A, où vous diluerez encore. L'objectif n'est pas de céder le moins possible, mais de garder une trajectoire saine jusqu'au tour suivant.

Cet article prolonge combien lever en seed, qui traite du montant. Ici, on regarde la contrepartie : le pourcentage de capital que vous cédez.

Pourquoi la fourchette 15-25 % n'est pas un hasard

Cette zone est le point d'équilibre entre deux intérêts opposés. L'investisseur veut une part assez significative pour que son retour ait du sens si la boîte réussit, sinon il ne s'engage pas. Le fondateur, lui, veut garder assez de capital pour rester motivé, garder le contrôle, et avoir de quoi diluer encore aux tours suivants sans devenir minoritaire trop tôt.

La dilution se calcule simplement : le montant levé divisé par la valorisation post-money. Si vous levez 800 K€ sur une valorisation post-money de 4 M€, vous cédez 20 %. Tout l'enjeu se joue donc autant sur le montant que sur la valorisation que vous arrivez à défendre, et cette valorisation dépend directement de ce que votre produit a déjà prouvé.

Les deux erreurs symétriques

Vu de mes années en CODIR, les fondateurs se trompent dans les deux sens, et les deux erreurs coûtent cher, juste à des moments différents.

La bonne nouvelle, c'est que la fourchette 15-25 % réconcilie ces deux risques. Elle laisse l'investisseur suffisamment motivé tout en préservant votre marge de manœuvre future. Quand un term sheet vous emmène nettement en dehors, ce n'est pas un détail à négocier à la marge : c'est le signal qu'il faut revoir soit le montant, soit la valorisation.

Le pool d'options : la dilution qu'on oublie

Voici le piège que je vois le plus souvent. La dilution ne se limite pas à la part cédée à l'investisseur. Il faut y ajouter le pool d'options : la réserve de capital mise de côté pour recruter et fidéliser les premiers salariés clés (futurs lead techniques, premiers commerciaux). Un fonds exige presque toujours la création ou l'extension de ce pool, en général de 8 à 15 % du capital.

Élément	Part typique au seed	Qui le porte
Part cédée à l'investisseur	12 à 20 %	Dilue tous les actionnaires existants
Pool d'options	8 à 15 %	Souvent imputé aux fondateurs
Dilution totale ressentie	15 à 25 % et plus	Selon où est placé le pool

Le point qui change tout : quand le pool est-il créé, avant ou après la levée ? S'il est constitué en pre-money, ce sont les fondateurs seuls qui le supportent, et la dilution réelle grimpe bien au-delà du chiffre affiché sur le term sheet. S'il est en post-money, investisseur compris, la charge est partagée. C'est un des points de négociation les plus rentables d'un tour, et l'un des plus mal compris par les fondateurs qui lèvent pour la première fois.

Lisez le term sheet en dilution totale, pas en part cédée

Le pourcentage annoncé par le fonds est rarement votre dilution réelle. Reconstituez toujours le total : part de
l'investisseur, plus pool d'options, en regardant si le pool est en pre ou post-money. C'est cette dilution totale qui
détermine où vous serez à la série A, pas le chiffre de couverture du term sheet.

Garder de la place pour la série A

Un tour d'amorçage n'est jamais le dernier. Si tout va bien, vous rouvrirez votre capital dans 18 à 24 mois, et vous rediluerez. Raisonner la dilution du seed sans projeter la série A, c'est piloter en regardant ses pieds.

L'idée à garder en tête : à chaque tour, les fondateurs cèdent une part. Si vous lâchez 25 % au seed, puis 20 % en série A, vous êtes mécaniquement passés sous la moitié du capital avant même d'avoir atteint la rentabilité. Ce n'est pas dramatique en soi (beaucoup de belles sorties se font fondateurs minoritaires), mais ça doit être un choix conscient, pas une dérive subie tour après tour. La discipline du seed conditionne votre marge de manœuvre future.

C'est aussi pour ça que la valorisation compte autant que le montant. Mieux vaut lever un peu moins sur une valorisation bien défendue que beaucoup sur une valorisation bradée : la seconde option vous coûte un capital que vous ne récupérerez jamais. Et défendre une valorisation, ça se prépare en démontrant que la tech et le produit tiennent la promesse, exactement ce que scrute un investisseur en due diligence technique.

Le réflexe de dirigeant avant de signer

Si je devais résumer en une phrase : ne négociez pas la dilution, négociez la trajectoire. Demandez-vous où sera votre table de capitalisation après la série A, pas seulement après ce tour-ci. Reconstituez la dilution totale, pool compris, vérifiez qu'elle reste dans la fourchette, et assurez-vous que la valorisation est défendable plutôt que bradée par peur de manquer de cash. Avant d'en arriver là, encore faut-il savoir de combien de mois de trésorerie vous disposez : c'est tout l'objet du calcul de votre runway.

Préparer le volet capitalistique de votre levée ?

J'interviens comme CTO fractional pour solidifier votre base technique et rendre votre trajectoire crédible avant un
tour. Voyez la préparation d'une opération capitalistique, ou
réservons 30 minutes pour situer ce que votre tech doit prouver
avant de négocier votre valorisation.

Combien lever en seed pour une startup ?

Rémi Alvado — Mon, 10 Aug 2026 05:24:36 +0000

« On lève 1 million. » Le chiffre rond sonne bien en pitch, mais il ne répond pas à la seule question qui compte pour un investisseur : pour atteindre quoi ? Lever un montant qu'on ne sait pas justifier par un objectif précis, c'est le meilleur moyen de se faire diluer pour rien, ou de manquer de cash six mois avant le palier qui aurait débloqué le tour suivant.

Le bon montant à lever en seed ne se décide pas en chiffre rond mais en runway multiplié par milestone : combien de mois de trésorerie il vous faut pour atteindre le prochain palier qui justifie une valorisation plus haute. En France, un tour de seed va typiquement de 200 K€ à 2 M€, pour une dilution de 15 à 25 %.

Si vous vous demandez aussi quand structurer votre direction technique pour rassurer un fonds, c'est dans quand recruter un CTO en startup. Ici, on raisonne sur le montant lui-même.

Raisonner en runway × milestone, pas en chiffre rond

Un montant de levée n'est pas un objectif, c'est un moyen. La bonne logique part de la fin : quel est le prochain palier qui fera grimper votre valorisation (un PMF démontré, un certain niveau de revenus récurrents, une preuve d'acquisition rentable), combien de temps faut-il pour l'atteindre, et combien ça coûte par mois d'y aller. Le montant à lever, c'est ce coût mensuel multiplié par le runway nécessaire, plus une marge de sécurité.

Concrètement, la séquence de raisonnement tient en quatre temps, quel que soit le secteur.

Les fourchettes du marché français

Une fois ce raisonnement posé, les repères de marché aident à savoir si votre montant est crédible pour votre stade. Voici les ordres de grandeur courants d'un seed en France, sachant que les montants ont tendance à monter sur les secteurs très capitalistiques (hardware, deeptech, biotech) et à descendre sur le SaaS léger.

Type de tour	Montant typique (FR)	Dilution usuelle	Ce qu'il finance
Pre-seed	100 à 500 K€	10 à 20 %	Premier produit, premiers users
Seed	500 K€ à 1,5 M€	15 à 25 %	PMF, premières traction et revenus
Seed étendu / large	1,5 à 3 M€	15 à 25 %	Accélération avant la série A

La dilution de 15 à 25 % n'est pas un hasard : c'est la zone où le fondateur cède assez pour intéresser l'investisseur, sans se retrouver minoritaire trop tôt sur sa propre table de capitalisation. Descendre sous 15 % rend le tour peu attractif pour un fonds, monter au-dessus de 25 % vous fragilise pour les tours suivants, où vous diluerez encore. Garder cette fourchette en tête est un garde-fou simple contre les deux erreurs symétriques.

Ce que la tech doit prouver pour chaque palier

Un montant crédible ne suffit pas : encore faut-il que la technique tienne la promesse du palier visé. À chaque stade, un investisseur regarde des choses différentes, et c'est souvent là que les levées calent. Au pre-seed, on attend surtout un produit qui existe et des premiers usages. Au seed, on attend la preuve que le produit peut grandir sans s'effondrer, et que vous savez où va l'argent.

Ce que la tech doit démontrer pour débloquer le tour suivant est rarement de la sophistication. C'est de la solidité et de la lisibilité : une base saine qu'on peut faire évoluer, pas de dette qui ralentirait la suite, une direction technique crédible (interne ou fractionnelle) capable de répondre aux questions d'un fonds. C'est exactement ce que regarde un investisseur en due diligence technique, et c'est ce qui rassure ou inquiète au moment de signer.

Le piège classique au seed, c'est de lever pour « construire la plateforme parfaite » avant d'avoir prouvé que quelqu'un en veut. On finance alors la version la plus chère d'un produit non validé. Le bon réflexe est inverse : lever de quoi atteindre le palier de preuve, avec un produit juste assez abouti pour le démontrer. La méthode pour cadrer ce produit minimum sans sur-construire est détaillée dans le guide du MVP au Product-Market Fit.

Le bon réflexe avant d'aller voir des fonds

Si je devais donner un seul conseil avant une levée seed, ce serait celui-ci : sachez dire en une phrase à quoi sert chaque euro levé, et quel palier il vous amène à franchir. Un fondateur qui raisonne en runway et en milestone inspire confiance, parce qu'il montre qu'il sait où il va. Celui qui annonce un chiffre rond sans le justifier envoie le signal inverse. Le montant idéal n'est pas le plus gros que vous pourriez obtenir, c'est le plus petit qui vous emmène, avec marge, jusqu'à la prochaine preuve.

Préparer le volet tech de votre levée ?

J'interviens comme CTO fractional pour solidifier votre base technique, préparer la due diligence et rendre votre
trajectoire crédible auprès d'un fonds. Réservons 30 minutes pour
situer ce que votre tech doit prouver avant d'aller lever.

Combien coûte la digitalisation d'une PME ?

Rémi Alvado — Fri, 07 Aug 2026 05:23:00 +0000

« La transformation digitale, ça coûte combien ? » Posée comme ça, la question n'a pas de réponse, et c'est précisément le problème. « Digitaliser » ne veut rien dire tant qu'on n'a pas dit quel cas d'usage on adresse. Selon que vous voulez arrêter de ressaisir des commandes à la main ou refondre tout votre système d'information, on ne parle pas du même ordre de grandeur, ni du même ROI.

La digitalisation d'une PME ne se chiffre pas en bloc mais cas d'usage par cas d'usage. Les premiers gains, automatiser une saisie, mettre un devis en ligne, connecter deux outils, coûtent souvent de quelques milliers à 20 000 € et se rentabilisent en quelques mois. Le vrai piège budgétaire, c'est de vouloir tout reconstruire sur mesure d'un coup.

Cet article regarde la facture. Pour la méthode complète (par où commencer, quels outils, cloud ou pas), tout est dans le guide de la digitalisation d'une PME. Ici, on parle d'argent.

Décomposer le coût par cas d'usage à ROI rapide

La seule façon de chiffrer une digitalisation sans se noyer, c'est de partir d'un problème concret qui vous coûte de l'argent aujourd'hui, et de le traiter pour lui-même. Pas « passons au digital », mais « combien me coûte de ressaisir 200 commandes par mois à la main, et combien coûte d'arrêter ». Voici les chantiers qui rapportent le plus vite, du moins cher au plus structurant.

La logique est toujours la même : on commence par le cas d'usage qui a le ROI le plus court et le périmètre le plus net, on le livre, on le mesure, puis on enchaîne. Cette approche évite le projet fleuve dont personne ne sait dire s'il a rapporté quoi que ce soit. La méthode pour identifier ce premier chantier est détaillée dans par où commencer sa transformation digitale.

Le piège du « tout custom »

Le moment où une digitalisation dérape, c'est presque toujours quand on décide de tout reconstruire sur mesure « pour que ça colle parfaitement ». C'est souvent une mauvaise idée, et chère. Avant de faire développer quoi que ce soit, la vraie question est : existe-t-il déjà un outil qui fait 80 % du besoin ?

Le réflexe sain n'est pas idéologique. Le sur-mesure se justifie pleinement quand votre cœur de métier n'a pas d'équivalent logiciel, ou quand un outil maison devient un vrai actif différenciant. Mais reconstruire un CRM ou une facturation que des solutions matures font déjà très bien, c'est payer cher pour réinventer la roue. La règle : on assemble des briques pour le standard, on développe sur mesure uniquement là où c'est notre différence.

Les fourchettes, et ce qui les fait varier

Trois facteurs expliquent l'essentiel des écarts de prix. Le premier est le périmètre : un outil qui fait une chose coûte une fraction d'un outil qui en fait dix. Le deuxième est l'intégration : connecter un nouvel outil à votre existant (comptabilité, ERP, messagerie) coûte souvent plus que l'outil lui-même. Le troisième est le choix entre briques assemblées et développement sur mesure, qu'on vient de voir.

Pour un dirigeant, le bon ordre de lecture d'un devis est donc : qu'est-ce que ça résout précisément, en combien de temps ça se rentabilise, et est-ce qu'on aurait pu le faire avec une brique existante. Si le prestataire répond « on va tout refondre » à un problème ponctuel, c'est un signal. Un bon partenaire commence petit, prouve la valeur, puis élargit. C'est aussi ce qui permet de garder la main : on construit un actif qu'on possède, brique par brique, plutôt qu'un gros chantier dont on ne maîtrise plus le coût.

Ce qu'il faut retenir avant de signer

La digitalisation d'une PME n'est pas un projet à plusieurs centaines de milliers d'euros qu'on lance une fois. C'est une série de petits chantiers ciblés, chacun rattaché à un problème qui vous coûte déjà de l'argent, chacun rentabilisé avant de passer au suivant. Le budget total dépend entièrement de votre ambition et de votre rythme, et c'est une bonne nouvelle : vous gardez le contrôle. Le seul vrai danger budgétaire, c'est de vouloir tout faire en même temps et tout sur mesure.

Vous voulez chiffrer votre premier chantier ?

J'accompagne les dirigeants de PME pour identifier le cas d'usage à ROI rapide, choisir entre briques existantes et
sur-mesure, et garder la main sur le budget. Découvrez l'accompagnement PME et
digitalisation, ou réservons 30
minutes pour cadrer le premier pas.

Combien payer un développeur freelance senior ?

Rémi Alvado — Thu, 06 Aug 2026 05:23:36 +0000

« Son TJM est trois fois mon coût horaire interne, c'est du vol. » Je l'entends souvent, et c'est une erreur de lecture. Un TJM ne se compare pas à un salaire brut : il intègre des choses qu'un CDI ne vous facture jamais directement. Avant de négocier ou de renoncer, il faut savoir ce que vous payez vraiment, et où se situe le marché.

En France en 2026, un développeur freelance senior se facture entre 500 et 750 € par jour selon la stack et la rareté, soit l'équivalent d'un salaire chargé de 90 000 à 130 000 € par an pour un profil comparable en CDI. L'écart de TJM ne reflète pas une marge cachée mais des charges, des risques et une disponibilité immédiate que le salariat mutualise autrement.

Si vous cherchez surtout à savoir qui recruter et dans quel ordre après votre MVP, c'est dans composer sa première équipe tech. Ici, on regarde un point précis : le prix d'un développeur senior, et comment le lire sans se tromper.

Les fourchettes de marché par séniorité

Avant de discuter du « pourquoi », posons des repères. Ces fourchettes sont des ordres de grandeur du marché français pour du développement applicatif courant (web, back-end, mobile). Elles montent vite sur les expertises rares (data engineering, sécurité, certaines stacks de niche) et varient selon que vous travaillez en direct ou via une plateforme qui prend sa commission.

Profil	TJM freelance (marché FR)	Salaire chargé équivalent CDI
Junior (0 à 2 ans)	250 à 400 €	45 000 à 60 000 €
Confirmé (3 à 6 ans)	400 à 550 €	60 000 à 90 000 €
Senior (7 ans et plus)	500 à 750 €	90 000 à 130 000 €
Expert / niche rare	700 à 1 100 € +	130 000 € et au-delà

La colonne de droite est celle que les fondateurs oublient. Un salaire « brut affiché » n'est pas le coût réel d'un salarié : il faut y ajouter les charges patronales (de l'ordre de 40 à 45 % en France), les congés, la mutuelle, le matériel, l'inactivité entre deux projets, le recrutement lui-même. Pour comparer honnêtement, c'est le salaire chargé qu'il faut mettre en face du TJM, pas le brut.

Ce qui justifie l'écart de prix

Reste la vraie question : pourquoi un senior à 600 € par jour, et pas 400 comme un confirmé ? La différence ne se mesure pas en lignes de code écrites. Elle se mesure en décisions évitées et en problèmes qui n'arrivent pas.

À ce jugement s'ajoute une autre chose que le freelance senior vend et que le CDI ne vend pas de la même façon : la disponibilité immédiate et la mutualisation du risque. Il arrive opérationnel, sans courbe d'apprentissage de plusieurs mois, et s'il ne convient pas vous arrêtez le contrat sans procédure. Cette flexibilité a un prix, et ce prix est légitime. Pour décider entre un engagement ponctuel, un temps partagé ou un recrutement, j'ai détaillé l'arbitrage dans le guide pour construire son équipe tech.

Le piège du moins cher

Le réflexe naturel face à ces chiffres est de chercher à payer moins. C'est souvent une fausse économie. Un développeur junior à 300 € par jour qui met quatre jours là où un senior en met un, et qui produit du code qu'il faudra reprendre, vous revient plus cher au résultat. La bonne question n'est jamais « quel est le TJM le plus bas » mais « quel est le coût total pour atteindre le résultat ».

Cela ne veut pas dire qu'il faut toujours prendre le plus cher. Un junior bien encadré par un senior est une excellente combinaison, et c'est même comme ça qu'on fait progresser une équipe. Le piège, c'est de prendre un junior seul en pensant économiser, sur un sujet qui exige du jugement. Là, vous ne payez pas moins cher, vous payez plus tard, et davantage.

Comment l'IA agentique change le ratio en 2026

Voilà ce qui bouge vraiment cette année. L'IA agentique ne remplace pas le jugement du senior, elle l'amplifie. Un développeur expérimenté qui pilote correctement des agents produit aujourd'hui un volume de travail qui demandait, il y a deux ans, une petite équipe. La conséquence directe : la valeur se déplace encore plus vers le haut de la pyramide.

Concrètement, le ratio coût/production d'un senior augmente, parce qu'il abat plus de travail au même TJM. Et le calcul « je prends deux juniors plutôt qu'un senior » devient moins évident : le senior augmenté fait souvent le travail des deux juniors, en évitant la dette qu'ils auraient créée. C'est pour cette raison que je conseille, après le MVP, de privilégier un profil senior capable de piloter l'IA plutôt que d'empiler des profils peu chers. Le détail de cette logique de composition d'équipe est dans comment composer sa première équipe tech, et la manière de structurer un recrutement qui évalue ce jugement plutôt que la vitesse de code est dans le process de recrutement tech.

Attention à ne pas en tirer la conclusion inverse, qui serait de croire qu'on peut tout faire avec un junior plus un agent. L'agent amplifie le niveau de qui le pilote : entre des mains juniors, il produit vite du code que personne ne sait évaluer. C'est exactement pourquoi le senior reste le profil sur lequel investir.

Comment lire un TJM sans se tromper

Si je devais résumer en un réflexe : ne comparez jamais un TJM à un salaire brut, et ne regardez jamais le prix seul sans le résultat. Un senior à 650 € qui livre une base saine et la documente coûte moins cher, sur la durée du produit, qu'un profil deux fois moins cher qui laisse une dette que vous paierez en réécriture. Le bon arbitrage n'est pas « combien ça coûte par jour », c'est « combien ça coûte pour atteindre le résultat, dette comprise ».

Vous hésitez sur le profil et le budget à mettre ?

J'interviens comme CTO fractional pour cadrer vos besoins tech, dimensionner les bons profils et structurer leur
recrutement. Réservons 30 minutes pour situer ce dont vous
avez vraiment besoin avant de signer un contrat ou une fiche de poste.

MVP trop cher : 4 leviers pour reprendre le budget

Rémi Alvado — Wed, 05 Aug 2026 05:23:40 +0000

Le devis vous fait reculer, ou le budget a déjà glissé en cours de route. La réaction réflexe est de chercher moins cher, un autre prestataire, un freelance à plus bas tarif. C'est presque toujours une fausse économie. Un MVP qui coûte trop cher est rarement un problème de prix horaire : c'est un problème de décisions. Et les décisions, elles, se reprennent.

Pour maîtriser le budget d'un MVP, agissez sur quatre leviers : réduire le périmètre au seul parcours qui valide votre hypothèse, choisir une stack mature plutôt que sur-dimensionnée, séquencer le produit au lieu de tout livrer d'un coup, et privilégier une base saine que vous possédez. Ces quatre leviers, ensemble, divisent souvent la facture par deux sans toucher à ce qui compte.

Cet article suppose que vous savez déjà d'où vient le coût d'un MVP. Si ce n'est pas le cas, commencez par combien coûte un MVP, qui décompose la facture décision par décision. Ici, on passe à l'action : comment la faire baisser. La méthode produit complète, elle, est dans le guide du MVP au PMF.

Avant tout : un MVP trop cher est presque toujours trop large

Quand un budget dérape, l'instinct cherche le coupable du côté de qui code. Dans la quasi-totalité des cas que je vois, le coupable est ailleurs : le produit qu'on cherche à construire est trop gros pour ce qu'il doit prouver. On a confondu le MVP avec une première version complète.

C'est une bonne nouvelle, parce que ça veut dire que le levier est entre vos mains, pas dans le tarif d'un tiers. Voici les quatre que j'actionne en priorité, du plus puissant au plus structurel.

Les 4 leviers, du plus puissant au plus structurel

L'ordre n'est pas neutre. Le périmètre pèse plus que tout le reste réuni : un produit deux fois plus petit coûte grossièrement deux fois moins, avant même qu'on parle de technologie. La stack et le séquençage affinent. La propriété, elle, ne change pas le chèque d'aujourd'hui, mais elle décide si vous repayez tout dans six mois.

Le levier qu'on actionne mal : couper sans casser

Recadrer le périmètre fait peur, parce qu'on a l'impression d'appauvrir son produit. C'est l'inverse. Un MVP n'est pas un produit auquel il manque des choses : c'est un produit concentré sur la seule chose qui doit être prouvée. La discipline n'est pas de retirer au hasard, c'est de hiérarchiser par le risque.

La bonne question pour chaque fonctionnalité n'est pas « est-ce utile ? » (presque tout l'est) mais « si je l'enlève, est-ce que je peux encore tester mon hypothèse principale ? ». Si oui, elle sort du MVP et rejoint la liste de l'après. Cette discipline, appliquée à un backlog entier, est ce qui sépare un MVP de 40 000 € d'un projet de 120 000 € qui dit pourtant la même chose au marché.

Le piège du « moins cher » qui coûte plus

Le réflexe le plus tentant face à un budget trop élevé est aussi le plus dangereux : descendre en gamme sur l'exécution. Prendre le prestataire le moins cher, le freelance au plus bas tarif, le no-code pour « gagner du temps ». Sur le moment, le chiffre baisse. À l'arrivée, vous récupérez souvent une base que personne ne peut reprendre, une dépendance à une seule tête, ou un produit qu'il faut entièrement réécrire dès qu'il marche.

L'économie qui se paie deux fois

Choisir l'option la moins chère sur l'exécution, sans regarder ce qu'il vous reste à la fin, c'est déplacer la
dépense, pas la supprimer. Le vrai indicateur n'est pas le prix du devis, c'est le coût total jusqu'au moment où vous
voudrez accélérer. Un MVP « pas cher » qui vous laisse sans rien est le plus cher de tous.

Le bon arbitrage n'oppose pas « cher » et « pas cher ». Il oppose « ce que je dépense » et « ce que je possède en sortant ». C'est exactement la logique que je détaille sous l'angle des acteurs (agence, freelance, no-code, expert qui pilote l'IA) dans combien coûte un MVP, et pour le cas particulier du mobile, qui gonfle vite la note, dans combien coûte une application mobile.

La vraie économie : livrer plus tôt, apprendre plus vite

Maîtriser le budget d'un MVP, ce n'est pas dépenser le moins possible. C'est dépenser le strict nécessaire pour obtenir, le plus tôt possible, la réponse à la seule question qui compte avant le Product-Market Fit : est-ce que quelqu'un veut ce produit ? Chaque euro qui sert cette réponse est bien placé. Chaque euro qui sert autre chose (une fonctionnalité de confort, une scalabilité anticipée, un polish prématuré) est un euro qui retarde l'apprentissage.

Les quatre leviers convergent vers le même but : sortir vite, sur une base saine, avec juste ce qu'il faut. C'est précisément la promesse d'un MVP livré sur une vraie stack en quelques mois par un expert qui pilote l'IA, plutôt que par une équipe entière ou un prototype jetable.

On reprend votre budget en main ?

J'interviens comme CTO fractional armé d'IA pour recadrer le périmètre, choisir la stack juste et livrer une base que
vous gardez. Découvrez le Sprint Fondateur, ou réservons 30
minutes pour identifier où votre projet peut respirer sans rien sacrifier.

Combien coûte une application mobile ?

Rémi Alvado — Tue, 04 Aug 2026 05:23:35 +0000

« Il me faut une app sur l'App Store. » La phrase tombe souvent très tôt, parfois avant même que le produit existe. Et elle a un coût caché : à périmètre égal, partir sur du mobile natif double fréquemment le budget d'un MVP. Avant d'engager cet argent, il vaut la peine de comprendre pourquoi, et de vérifier que vous en avez vraiment besoin maintenant.

Une application mobile pour une startup coûte, sur le marché, de 30 000 à 50 000 € en approche hybride ou web, et de 60 000 à 150 000 € voire plus en natif pour iOS et Android. L'écart vient surtout du fait qu'en natif, vous construisez et maintenez deux applications distinctes, plus l'infrastructure de publication. Dans bien des cas, un site web mobile bien fait suffit pour valider votre idée.

Si vous cherchez d'abord à cadrer ce que doit contenir votre premier produit, c'est dans le guide du MVP au PMF. Ici, on regarde le cas particulier du mobile et sa facture.

Pourquoi le mobile double souvent la note

L'intuition trompeuse, c'est qu'une app mobile « c'est juste mon site en plus petit ». En réalité, vous n'ajoutez pas un écran, vous ouvrez plusieurs chantiers parallèles. Et chacun a un coût qui ne se voit pas dans le devis initial.

À cela s'ajoute un coût récurrent que les fondateurs sous-estiment : une app native n'est jamais « finie ». Apple et Google publient des versions d'OS, durcissent leurs règles, déprécient des API. Sans entretien régulier, votre app casse. Un site web, lui, ne vous impose pas ce calendrier subi.

Les trois approches, et ce qu'elles coûtent

Toutes les apps mobiles ne se valent pas en coût ni en compromis. Il existe un continuum entre le web pur et le natif intégral, et la bonne réponse dépend de ce que votre produit fait réellement avec le téléphone.

Approche	Ce que c'est	Fourchette marché	Quand c'est le bon choix
Site web responsive / PWA	Un seul produit web, qui s'installe sur l'écran	15 000 à 40 000 €	Tester l'idée, contenu, formulaires, peu de natif
Cross-platform (un seul code)	Une base unique compilée pour iOS et Android	40 000 à 90 000 €	Vraie app, budget contraint, fonctions standard
Natif intégral (deux apps)	iOS et Android développés séparément	80 000 à 150 000 € +	Perf graphique poussée, usage intensif du device

La ligne du milieu, le cross-platform, est celle qu'on oublie le plus souvent. Elle permet de publier sur les deux stores depuis une seule base de code, donc à un coût bien moindre que le natif, tout en offrant une vraie expérience d'application installée. Pour un MVP, c'est très souvent le bon point d'équilibre quand le web ne suffit plus mais que le natif intégral est prématuré.

Quand le web mobile suffit (c'est plus souvent qu'on croit)

Avant de financer une app native, posez-vous une question simple : votre produit a-t-il vraiment besoin du téléphone, ou seulement d'être accessible sur le téléphone ? Ce n'est pas la même chose. Un site web responsive, bien conçu, s'ouvre sur n'importe quel mobile, peut s'épingler sur l'écran d'accueil et offre l'essentiel des usages. Une PWA va plus loin : installation, fonctionnement hors-ligne partiel, notifications dans la plupart des cas.

Le web mobile suffit largement quand votre produit repose sur du contenu, des formulaires, un tableau de bord, une réservation, un paiement, bref tout ce qui ne sollicite pas en continu le matériel du téléphone. C'est le cas de la grande majorité des MVP.

Le test à se poser avant de payer du natif

Listez les fonctions de votre produit qui exigent vraiment le device : capteurs, caméra en continu, GPS en
arrière-plan, notifications push critiques au métier, paiement en boutique, performance graphique. Si cette liste est
courte ou vide, vous n'avez probablement pas besoin de natif pour votre MVP. Vous avez besoin d'un bon web mobile, et
vous garderez le natif pour quand l'usage l'aura prouvé.

Quand le natif se justifie vraiment

Soyons justes : il y a des cas où l'app native n'est pas un luxe. Si votre produit vit dans le téléphone (géolocalisation permanente, usage de la caméra ou des capteurs au cœur de la valeur, notifications push centrales au métier, performance graphique exigeante, ou une présence sur les stores qui fait partie de votre crédibilité commerciale), alors le surcoût est un investissement, pas un gaspillage.

Mais même dans ces cas, la bonne séquence est rarement de tout construire en natif dès le premier jour. On valide d'abord la valeur avec le moyen le moins cher, puis on passe au natif quand l'usage le mérite. Décider l'inverse, c'est financer la version la plus chère d'un produit dont personne n'a encore prouvé qu'il rencontrera son marché, exactement le piège que je décris pour le coût d'un MVP en général dans combien coûte un MVP.

Le vrai arbitrage : pas « web ou natif », mais « quand »

La question n'est presque jamais binaire. Elle est temporelle. Le bon réflexe n'est pas de choisir une fois pour toutes entre web et natif, c'est de choisir le moment où chaque investissement devient pertinent. Web ou cross-platform pour valider vite et à coût maîtrisé, natif quand l'usage réel et le modèle économique le justifient. Sauter directement au natif intégral pour un produit non validé, c'est le meilleur moyen de dépenser le plus, le plus tôt, sur l'hypothèse la moins sûre. Si votre budget mobile a déjà dérivé, les leviers pour le reprendre sont dans MVP qui coûte trop cher.

On situe votre besoin mobile ensemble ?

J'interviens comme CTO fractional armé d'IA pour cadrer votre MVP, choisir l'approche mobile juste et livrer une base
saine. Découvrez le Sprint Fondateur, ou réservons 30
minutes pour décider web, cross-platform ou natif sans surpayer.

Combien coûte un MVP pour une startup ?

Rémi Alvado — Mon, 03 Aug 2026 05:23:30 +0000

« Combien ça coûte de développer mon MVP ? » C'est souvent la première question d'un fondateur, et c'est la mauvaise. Pas parce qu'elle est illégitime, mais parce qu'elle attend un nombre là où il n'y a qu'un faisceau de décisions. Le même produit peut coûter 15 000 € ou 150 000 € selon trois ou quatre arbitrages que vous prenez sans toujours en mesurer le poids.

Le coût d'un MVP en France va, sur le marché, d'environ 10 000 € à 30 000 € pour un no-code ou un produit volontairement minimal, à 50 000 € jusqu'à 150 000 € voire plus pour un développement sur mesure complet. Ce qui détermine votre position dans cette fourchette n'est pas la chance : c'est le périmètre que vous fixez, la stack que vous choisissez, et surtout qui écrit le code.

Plutôt que de vous donner un chiffre que vous ne pourriez pas utiliser, je préfère vous montrer les leviers. Si vous voulez d'abord la méthode (qu'est-ce qu'un vrai MVP, comment le cadrer pour atteindre le Product-Market Fit), elle est dans le guide complet du MVP au PMF. Cet article-ci parle d'argent.

Le coût n'est pas un prix, c'est la somme de vos décisions

Quand un prestataire vous annonce un montant, il a déjà tranché une série de questions à votre place : combien de fonctionnalités, sur quelle technologie, avec quel niveau de finition, en mobilisant qui. Le danger, c'est de comparer deux devis qui n'ont en réalité pas fait les mêmes choix. L'un chiffre un prototype jetable, l'autre une base saine sur laquelle bâtir trois ans : le rapport peut être de un à cinq, et les deux ont raison sur leur périmètre.

C'est pour ça qu'un cadrage sérieux du périmètre vaut, en économies, bien plus que ce qu'il coûte en temps. Tant que le « quoi » est flou, le « combien » est un pari. Trois décisions structurent l'enveloppe, dans l'ordre où elles pèsent.

Décision n°1 : le périmètre (le seul vrai levier que vous tenez)

Un MVP n'est pas une version 1 réduite de votre vision : c'est le plus petit produit qui teste votre hypothèse la plus risquée. La confusion entre les deux est, de loin, le premier facteur d'explosion de budget. Chaque fonctionnalité « tant qu'on y est » ajoute du code, des cas limites, des tests, de la maintenance, et décale la seule chose qui compte vraiment : la confrontation au marché.

Périmètre	Ce qu'on construit	Fourchette de marché indicative
Prototype jetable (no-code, maquette)	Tester une promesse, pas le produit	5 000 à 15 000 €
MVP ciblé (1 parcours critique)	Le cœur de valeur, rien autour	20 000 à 50 000 €
MVP riche sur mesure (plusieurs parcours)	Plusieurs rôles, paiement, back-office	50 000 à 120 000 €
Produit « V1 déguisée en MVP »	Tout, tout de suite, sur une stack durable	120 000 € et plus

La quatrième ligne est le piège classique. On ne décide pas de construire une V1, on y glisse fonctionnalité par fonctionnalité, chacune raisonnable prise seule. Le tableau ci-dessus n'est pas une grille de tarifs, c'est une grille de discipline : plus vous descendez, plus vous repoussez le moment où vous saurez si quelqu'un veut votre produit.

Décision n°2 : qui écrit le code

À périmètre égal, l'acteur que vous choisissez change le prix, la qualité et surtout ce qui vous reste à la fin. Ce n'est pas qu'une affaire de tarif horaire : c'est une affaire de ce que vous possédez une fois le chèque encaissé.

Le point commun des trois premières options : aucune ne vous rend autonome par défaut. Vous arbitrez entre vitesse, prix et propriété, et trop de fondateurs n'optimisent que le prix affiché, en oubliant ce qu'ils ne possèdent pas à la sortie. Je détaille ce que vaut chacun de ces formats sous l'angle leadership tech dans combien coûte vraiment un CTO.

Décision n°3 : la stack et le niveau de finition

Le troisième levier est plus discret mais bien réel. Une technologie mature, avec un vivier de développeurs et un écosystème fourni, coûte moins cher à mettre en œuvre et à faire évoluer qu'un choix exotique séduisant sur le papier. À l'inverse, sur-investir trop tôt (architecture micro-services, infrastructure cloud complexe, tests à 100 %) gonfle la facture pour résoudre des problèmes que vous n'avez pas encore. La règle à ce stade : choisir pour le time-to-market et la réversibilité, pas pour une scalabilité dont vous rêvez mais que vous n'avez pas prouvée. La méthode de choix, six critères pondérés, est dans choisir sa stack technique.

Le niveau de finition est l'autre cadran. Un MVP n'a pas besoin du polish d'un produit installé : il a besoin d'être assez crédible pour que vos premiers utilisateurs jugent la valeur, pas l'emballage. Chaque cran de perfectionnisme prématuré se paie.

Ce qui fait vraiment exploser le budget par trois

Si je devais nommer le facteur unique qui transforme un MVP à 40 000 € en projet à 120 000 €, ce ne serait aucune ligne technique. Ce serait le périmètre qui dérive.

Le mécanisme est toujours le même. On démarre avec un parcours critique clair. Puis arrivent les « petites » demandes : un second type d'utilisateur, un tableau de bord administrateur, trois intégrations, des notifications, une app mobile « parce que ce serait mieux ». Chacune semble peser peu. Cumulées, elles doublent ou triplent le coût et repoussent la mise sur le marché de plusieurs mois, c'est-à-dire qu'elles retardent l'apprentissage qui justifiait le projet. D'ailleurs, l'envie d'app mobile native mérite un examen à part, parce qu'elle double souvent la note à elle seule : j'en ai fait un article dédié.

Le vrai coût d'un MVP trop cher n'est pas l'argent

C'est le temps. Un budget qui gonfle, c'est un produit qui arrive plus tard sur le marché, donc des semaines de retard
sur la seule question qui compte avant le PMF : est-ce que quelqu'un en veut ? Si votre devis a déjà dérivé, le
problème n'est presque jamais le prestataire, c'est le périmètre. Les leviers pour le reprendre en main sont dans MVP
qui coûte trop cher : reprendre le budget.

Comment lire un devis sans se faire piéger

Quand vous recevez un chiffrage, posez trois questions avant de regarder le total. Première question : quel périmètre exact ce montant couvre-t-il, et qu'est-ce qui est explicitement exclu ? Un devis sans liste de ce qui n'est pas inclus est un devis incomplet. Deuxième question : qu'est-ce qui m'appartient à la fin, code, accès, documentation, ou seulement un produit qui tourne tant que le prestataire est là ? Troisième question : sur quelle base est-ce que je pourrai construire la suite, ou faudra-t-il tout reprendre ?

Un devis bas qui vous laisse sans rien à la fin est plus cher qu'un devis moyen qui vous rend autonome. Le coût d'un MVP ne se mesure pas le jour de la signature, il se mesure le jour où vous voulez accélérer.

On chiffre votre MVP par les bonnes décisions ?

J'interviens comme CTO fractional armé d'IA pour cadrer le périmètre minimal, choisir la stack et livrer une base
saine que vous gardez. Découvrez le Sprint Fondateur, ou réservons 30
minutes pour situer votre projet et estimer son enveloppe réaliste.

CTO à temps partagé : ce que vous obtenez vraiment

Rémi Alvado — Fri, 31 Jul 2026 05:23:28 +0000

« Un CTO à temps partagé, à deux jours par semaine, ça sert vraiment à quelque chose ? » C'est la première question des fondateurs. Réponse directe : oui, à condition de bien comprendre ce qu'on achète. Pas une paire de bras supplémentaire, mais une tête. Quelqu'un qui prend les décisions structurantes que vous ne savez pas prendre seul, et qui débloque ce qui coince, sans le coût d'un temps plein.

La confusion la plus fréquente, c'est de raisonner en volume horaire. « Deux jours sur cinq, je n'ai que 40 % d'un CTO. » C'est faux, parce qu'un CTO ne produit pas de la valeur à la ligne de code. Il en produit aux moments de décision, et ces moments ne tombent pas tous les jours. Je détaille ce qu'est ce format dans le guide complet du CTO fractionnel ; cet article-ci répond à une question plus terre-à-terre : concrètement, qu'est-ce que vous obtenez quand un CTO entre dans votre boîte deux jours par semaine ?

Ce que vous ne pouvez pas vous payer en temps plein

Posons le problème tel que la plupart des fondateurs non-techniques le vivent. Vous savez qu'il vous manque une tête tech. Vous regardez les salaires d'un CTO senior (facilement 150 K€ brut, soit autour de 220 K€ chargés) et vous fermez l'onglet. Ce n'est pas le bon moment, vous n'avez ni le budget ni la certitude que le besoin est durable. Alors vous reportez. Et pendant ce temps, les décisions techniques se prennent quand même : par votre prestataire, par votre premier développeur, ou par défaut, faute d'arbitre.

Le temps partagé existe précisément pour cette zone-là. À deux jours par semaine, vous mobilisez un profil senior (quinze à vingt ans de terrain, plusieurs boîtes accompagnées) pour un coût de l'ordre de 80 à 120 K€ par an, et autour de 40 à 60 K€ à un jour. Vous n'achetez pas une fraction de salaire, vous achetez une séniorité ciblée sur la phase où elle compte. Le détail des fourchettes, format par format, est dans combien coûte vraiment un CTO.

L'erreur serait de croire qu'à mi-temps, on obtient la moitié des résultats. Un CTO à temps plein passe une bonne part de ses journées en réunions et en gestion de l'urgence. Le fractionnel concentre ses jours sur ce qui fait levier : les choix d'architecture, les recrutements, les arbitrages de roadmap. C'est plus dense, pas plus dilué.

Une journée type : quelles décisions je prends

Pour rendre ça concret, voici à quoi ressemblent mes deux jours dans une jeune startup. Le matin du premier jour, je revois l'état du produit avec le développeur en place : ce qui avance, ce qui coince, ce qui a été décidé sans moi la semaine précédente. C'est souvent là que se jouent les vrais sujets. Un choix de base de données pris à la légère, une dépendance externe qui devient critique, une fonctionnalité partie dans une direction coûteuse : autant de décisions qui, non challengées, deviennent irréversibles ou très chères à corriger.

Mon travail, à ces moments-là, c'est de trancher avec le recul que personne n'a en interne. Pas « c'est mieux comme ça parce que je le dis », mais « voici les deux options, voici ce que chacune coûte dans six mois, voici celle que je recommande et pourquoi ». Sur une semaine, les décisions structurantes que je prends ressemblent à ça :

Type de décision	Exemple concret	Ce que ça évite au fondateur
Architecture	Trancher entre deux approches de stockage des données	Une réécriture coûteuse 18 mois plus tard
Recrutement	Cadrer la fiche de poste du prochain développeur	Un mauvais casting à 6-12 mois de salaire
Priorisation	Arbitrer ce qui passe avant la levée, ce qui attend	De brûler du budget sur le superflu
Risque	Identifier une dépendance critique à un prestataire	De découvrir le problème en due diligence
Faisabilité	Dire au fondateur « ça, oui ; ça, pas à ce coût-là »	Des promesses intenables faites à un investisseur

Aucune de ces décisions ne demande que je sois présent tous les jours. Elles demandent que je sois là au bon moment, avec le bon recul, et qu'entre deux, l'équipe sache exécuter sans moi.

Ce que je débloque, ce que je délègue

C'est l'autre malentendu à lever : un CTO à temps partagé ne fait pas tout, et surtout ne fait pas tout lui-même. Une mission qui marche repose sur une répartition claire entre ce que je porte et ce que je confie au développeur ou au lead dev en place.

Ce que je porte

La vision technique et sa traduction en décisions : les choix d'architecture qui engagent l'entreprise pour deux ans, les arbitrages de roadmap (ce qui passe avant la levée, ce qui attend), le recrutement des premiers profils et la relation avec les investisseurs sur les sujets tech. Quand un fondateur prépare une levée, c'est moi qui réponds aux questions de due diligence sur l'architecture, la dette, le plan de scaling : des réponses floues à ce stade entament la crédibilité du dossier.

Les fondations d'équipe : qui recruter, dans quel ordre, à quel niveau, sujet que je creuse dans composer sa première équipe tech. Et c'est moi qui repère les risques invisibles depuis le siège du fondateur, une dépendance critique à un prestataire, un choix de stockage qui coûtera une réécriture, avant qu'ils ne se paient au pire moment.

Ce que je délègue

L'exécution au quotidien. Le développeur en place code, déploie, gère les incidents courants. Mon rôle n'est pas de lui prendre son travail mais de lui donner un cadre et un cap, et souvent de le faire monter en compétence pour qu'il devienne le futur lead dev. Un bon signe que la mission fonctionne, c'est quand l'équipe se met à décider juste sans m'appeler.

Le temps partagé n'est pas du temps absent

Entre mes jours de présence, l'équipe continue d'avancer dans le cadre posé. Je reste joignable pour les décisions
urgentes, et les sujets de fond se traitent à mes journées dédiées. Ce qui compte n'est pas d'être là tout le temps,
c'est d'être là quand une décision structurante doit être prise, et d'avoir outillé l'équipe pour le reste.

Pour qui c'est fait, et pour qui ça ne l'est pas

Le temps partagé n'est pas une solution universelle, et je préfère le dire avant qu'après. Il y a une fenêtre où c'est le meilleur format, et des situations où c'en est clairement un mauvais.

C'est fait pour vous si vous êtes en amorçage ou en pré-série A, avec un produit qui avance mais une tech qui devient un sujet sérieux : un MVP à structurer, une première équipe à recruter, une levée à préparer. À ce stade, vous avez besoin d'une vision juste et de quelques décisions bien prises, pas d'une présence permanente. C'est exactement la zone où un CDI est surdimensionné et où un freelance purement technique ne suffit pas : je détaille ce choix de format dans CTO freelance, fractionnel ou CDI.

Ce n'est pas fait pour vous dans deux cas. D'abord, si votre tech exige une présence quotidienne : une plateforme critique qui tombe la nuit, des incidents permanents, une charge opérationnelle qui réclame quelqu'un en première ligne tous les jours. Deux jours par semaine ne tiendront pas ce rythme. Ensuite, si votre équipe technique est déjà grosse (au-delà de quinze à vingt développeurs sans personne pour porter les sujets au quotidien), un temps partagé se disperse. À ce stade, c'est un CTO en CDI qu'il faut, et le rôle du fractionnel est plutôt de préparer ce recrutement que de s'y substituer.

Un exemple concret

Un fondateur non-technique me contacte, expert reconnu de son domaine (un secteur réglementé exigeant) mais sans la moindre brique d'équipe tech. Il a une conviction produit forte, une fenêtre de marché étroite, et trois mauvaises options en tête : recruter un CTO (trois à six mois rien que pour le trouver), confier le tout à une agence (un prototype à jeter, zéro transfert), ou bricoler en no-code (intenable dans un secteur aussi sensible).

Ce dont il avait besoin n'était pas une paire de bras, mais quelqu'un pour trancher les choix qui engageaient les années suivantes : comment isoler les données de chaque client, quelle architecture pour tenir une contrainte réglementaire forte, quoi construire d'abord et quoi reporter. Ces décisions-là, prises tôt et bien, ont évité des mois de réécriture. Ce cas a pris la forme d'un Sprint Fondateur, un format intensif, mais la logique est la même en temps partagé étalé : la valeur ne vient pas du nombre de jours, elle vient de la justesse des décisions structurantes. J'ai raconté ce projet dans un SaaS de santé livré en un seul Sprint Fondateur.

Le fil conducteur, ici comme dans la plupart de mes missions : un fondateur non-technique n'a pas besoin qu'on lui code plus vite. Il a besoin qu'on prenne, à sa place et avec lui, les quelques décisions qui feront la différence entre un actif solide et une dette qu'il découvrira au pire moment.

Comment ça s'articule dans le temps

Une mission à temps partagé bien menée n'est pas une présence diffuse qui s'étire indéfiniment. Elle suit une logique en trois temps. Un bon CTO à temps partagé se rend remplaçable, c'est même le critère de réussite : la boîte doit pouvoir tourner sans lui.

C'est tout l'objet d'une mission de création d'équipe tech & produit : porter la casquette CTO le temps de poser les bases, recruter et former l'équipe qui prendra le relais, puis passer la main proprement. Vous ne vous engagez pas à l'aveugle sur un CDI dont vous ne savez pas encore s'il est justifié : vous clarifiez le besoin réel avant de vous engager.

On en parle pour votre situation ?

Un échange de 30 minutes pour situer votre stade, qualifier ce dont vous avez réellement besoin, et vous dire
franchement si un CTO à temps partagé est le bon format pour vous, ou si autre chose vous servirait mieux. Réservons
un appel.

Claude Design : du business plan aux maquettes implémentables en 3h

Rémi Alvado — Thu, 30 Jul 2026 09:09:29 +0000

Entre un business plan validé et le moment où une équipe de développement peut commencer à coder, il y a souvent plusieurs semaines de discovery design : ateliers, wireframes, itérations, validation. Pour un fondateur en pré-seed qui veut confronter son produit au marché vite, c'est du temps qu'il n'a pas. J'ai voulu tester ce que Claude Design peut faire de cette phase quand on lui donne un dossier projet déjà structuré.

Le projet « Bouch.ee » est un cas pédagogique fictif

Pour illustrer concrètement la méthode du Sprint Fondateur, j'ai monté un dossier
complet sur un projet imaginaire de meal planning familial. Ce n'est pas un client réel : les maquettes ci-dessous
servent d'échantillon pour montrer le niveau de détail et de qualité qu'on peut atteindre.

Le contexte : un dossier projet déjà mûr

Avant d'ouvrir Claude Design, le projet Bouch.ee avait déjà :

Un business plan en 10 chapitres
Un PRD détaillé en 10 modules
Une analyse concurrentielle
Un document de périmètre MVP validé
Une stack technique posée (Expo pour le mobile, Next.js pour le web, Symfony côté API)

Tout ça vit dans un monorepo dédié, et une session Claude Code connaît cette mémoire. Le but n'était donc pas de partir d'une feuille blanche : c'était de demander à un outil de design de lire ce qui existe déjà et de matérialiser une UX cohérente avec.

Le process en sept étapes

Ce qui suit, c'est ce que j'ai effectivement fait. Pas un protocole théorique : un déroulé que j'ai itéré pendant la session.

1. Demander à Claude Code de rédiger le prompt

Première étape, et probablement la plus importante : je n'ai pas écrit moi-même le prompt pour Claude Design. J'ai demandé à Claude Code, qui connaît le projet, de me préparer un brief en piochant dans le BP, le PRD et le design système prévu côté code. Il devait préparer un design system en même temps, pour que les maquettes ne soient pas une bulle isolée, mais bien la suite logique de ce qui était déjà décidé.

Cette première version était propre, mais sage. C'était la base, pas l'arrivée.

2. Demander deux variantes franchement différentes

J'ai ensuite demandé à Claude Design de me proposer deux nouvelles variantes, avec instruction explicite de prendre des partis pris très différents. Il pouvait changer des choix produits, retirer ou ajouter des écrans, modifier le ton, repenser la navigation. Chaque variante avec son propre design system.

Le résultat a dépassé ce que j'attendais. La variante B est partie sur un fond très foncé, presque exclusivement organisé autour d'un module conversationnel : l'app comme un chat, point. La variante C a pris la direction inverse : un assistant papier, tactile, presque artisanal. Deux philosophies opposées sur le même problème, chacune avec une cohérence interne réelle.

3. Donner des retours comme à un Senior UX Designer

C'est là que la méthode bascule. Je préférais l'UI de la variante C, mais plusieurs idées de la B étaient à creuser. J'ai fait mes retours comme je les ferais à un designer senior : ce qui marche, ce qui ne marche pas, et pourquoi dans chaque cas. Je lui ai demandé une quatrième variante qui prenne le meilleur des deux, en mobile et en desktop.

Cette posture est non-négociable. Si vous traitez Claude Design comme un générateur d'images, vous obtenez des images. Si vous le traitez comme un collaborateur, vous obtenez du design.

4. Demander un fichier par écran

Claude Design est récent. La vue globale qui empile mobile + desktop pour 30 écrans devient lente très vite, et illisible. J'ai demandé qu'il isole chaque écran dans son propre fichier (avec mobile et desktop côte à côte), accompagné de commentaires expliquant les subtilités d'interaction de chacun. Et un fichier markdown séparé qui liste tous les écarts vs design initial.

Ce découpage a deux vertus : on revoit chaque écran de façon focalisée, et le markdown sert plus tard de document de spec quand on passe au code.

5. Repasser dans Claude Code pour l'implémentation

J'ai exporté la quatrième variante en zip et je l'ai déposée dans le workspace Claude Code. Je lui ai demandé de regarder le travail, de challenger les choix de Claude Design quand ça lui semblait pertinent, et de proposer un plan d'implémentation. Il y a eu quatre ou cinq challenges réels : des points où le designer avait pris une décision que le code rendait fragile ou disproportionnée. À chaque challenge, j'ai tranché.

Ensuite, l'implémentation a été déléguée à des subagents par sprints, avec un harnais de tests E2E (plus de cinquante journeys au total). C'est le pattern décrit dans « 51 stories, 4 sprints, 0 régression ».

6. Boucler avec une nouvelle itération design

Une fois le code en place, j'ai redemandé à Claude Code de me préparer un nouveau prompt pour Claude Design, pour mettre à jour les maquettes avec les choix d'implémentation et ajouter quelques fonctionnalités sur le signup que j'avais en tête en cours de route. Phase classique de specification → review → développement → itération, sauf qu'aucune des deux parties n'est humaine.

7. Réinjecter dans le code

Dernier round : Claude Design met à jour les maquettes, je relis, je commente, et je redonne le tout à Claude Code pour implémenter. Avec les tests E2E qui valident chaque story.

Ce que ça donne en chiffres

Mon temps personnel sur l'ensemble : environ 2 à 3 heures, presque exclusivement passées à reviewer et à faire des copier-coller entre les deux instances de Claude. Le temps machine cumulé est plus important : quatre à cinq heures, surtout sur l'implémentation. À comparer aux plusieurs semaines qu'un produit de la complexité de Bouch.ee aurait demandées avec le process classique : ateliers UX, wireframes, validation, itérations en agence ou en interne.

Et le résultat n'est pas un mockup plat : c'est un design system documenté, trente écrans avec leurs variantes mobile/desktop, et un changelog qui explique chaque écart par rapport au plan initial.

→ Voir les maquettes Bouch.ee (variante D-2)

Les limites observées

Trois choses à savoir avant de se lancer.

D'abord, Claude Design n'est pas autonome. Sans une mémoire projet déjà structurée (BP, PRD, périmètre), il produit des maquettes génériques. La qualité du résultat est directement corrélée à la qualité de ce qu'on lui donne en entrée.

Ensuite, la fluidité de l'outil reste perfectible sur des projets de cette taille. Le découpage en fichiers par écran est aujourd'hui un workaround pour rendre les itérations supportables.

Enfin, un œil produit + designer est indispensable côté humain. Pas pour dessiner, mais pour arbitrer entre variantes, repérer ce qui ne tient pas, savoir à quel moment passer de l'exploration à la convergence. C'est là que les vingt ans d'expérience pèsent réellement, pas dans la production.

Conclusion

Cette pipeline (Claude Code pour la mémoire et le code, Claude Design pour l'UX, un humain expérimenté pour piloter) est l'une des chaînes les plus productives que j'ai utilisées depuis longtemps. Elle ne remplace pas un Senior UX Designer sur un produit complexe à long terme. Mais pour cadrer rapidement un MVP de fondateur en pré-seed, elle change le rapport temps/qualité de façon difficile à ignorer.

Sprint Fondateur : design + code en 2 mois

Cette pipeline design est désormais intégrée à mon offre Sprint Fondateur. En 2 mois,
vous repartez avec un MVP fonctionnel, un business plan, une stratégie de financement, et un design system complet
avec ses maquettes implémentables.

Accelerate : la boîte à outils qui aide les meilleures équipes tech à le rester

Rémi Alvado — Thu, 30 Jul 2026 09:09:28 +0000

Accelerate, c'est une boîte à outils issue du programme de recherche DORA : un ensemble de métriques et de pratiques observées chez les équipes tech les plus performantes au monde, qu'on peut piocher selon son contexte pour améliorer sa vélocité, sa qualité et la satisfaction de ses utilisateurs. Ce n'est pas un framework à appliquer à la lettre, et c'est tout l'intérêt. Entre ceux qui en font un dogme et ceux qui l'ignorent complètement, peu de gens l'utilisent pour ce qu'il est vraiment.

Série Accelerate en 3 articles

Accelerate : définition et principes (cet article) 2. Les 4 métriques clés d'Accelerate 3. Les capabilities Accelerate : par où commencer ?

Accelerate, c'est quoi concrètement ?

Accelerate est une initiative née du programme DORA (DevOps Research & Assessment) qui a cherché à répondre à une question simple : qu'est-ce qui différencie les entreprises leaders en matière de delivery logiciel des autres ? Plutôt que de partir de réflexions théoriques, DORA a adopté une démarche empirique en collectant des feedbacks directement auprès de ces organisations pour identifier ce qui fonctionne et ce qui ne fonctionne pas.

Le résultat de cette recherche, c'est un ensemble de métriques et de capabilities qui permettent à n'importe quelle équipe de se situer et de progresser. L'idée n'est pas de copier ce que font Google ou Netflix, mais de comprendre les patterns qui reviennent systématiquement chez les entreprises performantes et de les adapter à son propre contexte.

La force de la démarche tient à sa nature empirique. Là où beaucoup de méthodologies tech reposent sur l'intuition d'un consultant ou la mode du moment, DORA s'appuie sur plusieurs années d'enquêtes auprès de dizaines de milliers de professionnels. Les corrélations identifiées (par exemple entre la fréquence de déploiement et la stabilité du produit) ne sont pas des opinions, ce sont des observations statistiques. C'est ce qui donne du poids à la démarche quand il faut convaincre un comité de direction ou un fondateur sceptique : on ne parle pas de croyances, on parle de ce qui distingue mesurablement les meilleures équipes des autres.

Pour donner une vue d'ensemble, voici comment se structure la boîte à outils Accelerate.

Composante	Ce que c'est	À quoi ça sert
Les 4 métriques clés	Deployment Frequency, Lead Time, Change Failure Rate, MTTR	Se situer rapidement, objectiver une discussion
Les capabilities	~30 pratiques techniques, culturelles, organisationnelles	Identifier les leviers d'amélioration concrets
La démarche empirique	Mesures issues d'enquêtes mondiales annuelles	Donner du poids aux décisions, dépasser l'intuition
L'orientation cloud	Recommandations parfois liées au cloud public / GCP	À adapter, pas à suivre aveuglément

Personne ne doit tout adopter d'un coup. L'art consiste à choisir les deux ou trois éléments qui font le plus de différence dans votre situation précise.

Ce qu'Accelerate peut apporter à votre entreprise

Les gains concrets d'une démarche Accelerate, quand elle est bien menée, se mesurent sur trois axes principaux.

Le premier, c'est la vélocité. En mesurant des éléments comme la fréquence de déploiement ou le temps entre une idée et sa mise en production, vous rendez visible ce qui ralentit votre organisation. Chez Wizbii, en regardant précisément le Lead Time to Change, on s'est rendu compte que les Product Owners avaient trop de backlog "en stock". Les nouvelles idées mettaient trop de temps à arriver en production, non pas parce que l'équipe technique était lente, mais parce que le pipe en amont était engorgé. Cette prise de conscience a permis de revoir complètement la manière de travailler du produit : moins d'anticipation sur la rédaction de user stories, plus de temps consacré à la recherche utilisateur en amont et aux tests en aval.

Le deuxième axe, c'est la qualité. Les métriques Accelerate permettent de mesurer objectivement si vous allez trop vite au détriment de la robustesse de votre produit. Cela a d'autant plus de sens dans une startup qui peut parfois sacrifier la qualité en toute conscience pour aller plus vite sur un marché pas encore validé, à condition de savoir le mesurer et de corriger le tir au bon moment.

Le troisième axe, et probablement le plus important, c'est l'adéquation entre ce qui est développé et ce qui est attendu par vos utilisateurs. En réduisant le temps entre une idée et sa mise en production, vous créez une boucle de feedback plus courte qui vous permet de corriger le tir beaucoup plus rapidement. Vous arrêtez de développer pendant six mois dans une direction pour découvrir que vos utilisateurs attendaient autre chose.

Sur une équipe plus jeune comme celle de Winter, l'enjeu était différent de Wizbii. Il ne s'agissait pas de débloquer un pipe engorgé, mais d'installer dès le départ une culture de la mesure légère. On a délibérément choisi de ne suivre qu'une seule métrique au début, la fréquence de déploiement, parce qu'elle est facile à instrumenter et qu'elle tire mécaniquement vers de bonnes pratiques : pour déployer souvent, il faut des déploiements automatisés, des tests fiables et des lots de changements petits. Une seule métrique bien choisie a fait progresser l'ensemble sans jamais transformer le suivi en usine à gaz. C'est exactement l'esprit de la boîte à outils : prendre l'instrument utile au bon moment, pas la panoplie complète.

Une boîte à outils, pas un framework

C'est le point le plus important et celui que beaucoup oublient. Accelerate n'est pas un framework sur étagère qu'on applique à la lettre. Chaque entreprise a ses spécificités, son stade de maturité, ses contraintes. Personne ne peut suivre et améliorer trente capabilities en parallèle sans impacter négativement le business.

Comme l'agilité en son temps, Accelerate donne une destination mais c'est à chacun de trouver son chemin pour y arriver. De la même manière que Scrum propose des outils (sprints, rétrospectives, planning poker) dans lesquels chaque équipe pioche selon ses besoins, Accelerate propose des métriques et des capabilities que vous devez sélectionner et prioriser en fonction de votre contexte.

Il faut aussi noter qu'une partie des recommandations d'Accelerate sont liées à l'utilisation de clouds publics, voire de Google Cloud Platform directement, puisque DORA fait partie de cette branche chez Google. Cela ne remet pas en cause l'ensemble de la démarche, mais gardez-le en tête quand vous lisez certaines recommandations très orientées cloud.

Besoin d'aide pour mettre en place Accelerate ?

En accompagnement Scaling Tech & Produit, je vous aide à choisir et mettre en
place les métriques et capabilities Accelerate adaptées à votre contexte, en m'appuyant sur mon expérience concrète de
cette démarche chez Wizbii.

Pour qui et à quel moment ?

Accelerate peut bénéficier à toute entreprise qui développe du logiciel, mais le contexte d'application varie énormément. Une startup en pré-product market fit n'a probablement pas besoin de mettre en place un suivi formel de ces métriques. Elle a besoin d'aller vite, de tester des hypothèses, et de pivoter si nécessaire. Par contre, avoir connaissance de cette boîte à outils est indispensable, car elle donne un vocabulaire commun et une direction pour le jour où la structuration deviendra nécessaire.

Pour une startup post-product market fit ou une scale-up, la mise en place d'Accelerate prend tout son sens. C'est le moment où l'équipe grandit, où les process commencent à se formaliser, et où les problèmes de coordination et de qualité deviennent visibles. Les métriques Accelerate permettent alors d'objectiver ces problèmes et de prioriser les améliorations.

Dans tous les cas, il faut garder en tête que les métriques sont des métriques, pas des vérités absolues. La vérité absolue pour votre entreprise, c'est la satisfaction de vos utilisateurs, la réponse à leurs attentes, la baisse du churn et la hausse des ventes. Accelerate est un moyen d'y arriver, pas une fin en soi.

Il y a un piège classique ici, et il revient souvent quand une équipe découvre ces métriques. Dès qu'un chiffre devient un objectif affiché, il cesse d'être un bon indicateur : c'est la loi de Goodhart. Si vous demandez à une équipe d'augmenter sa fréquence de déploiement, elle finira par déployer des changements artificiellement découpés juste pour faire grimper le compteur. Les métriques Accelerate servent à éclairer une discussion, pas à noter les gens. Le jour où elles deviennent un outil d'évaluation individuelle, elles perdent toute valeur. C'est exactement le même raisonnement que je développe sur les métriques d'équipe qui comptent vraiment : le tableau de bord ne remplace jamais l'écoute du terrain.

Par où commencer ?

Si Accelerate vous intéresse, commencez par comprendre les quatre métriques clés qui constituent le socle de la démarche. Elles sont simples à comprendre, relativement simples à mesurer, et elles vous donneront une première photographie très utile de la santé de votre organisation tech et produit. C'est l'objet du prochain article de cette série.

Une erreur fréquente consiste à vouloir tout instrumenter parfaitement avant de commencer. Ne tombez pas dans ce piège. Une mesure approximative mais régulière vaut infiniment mieux qu'une mesure parfaite qu'on ne fait jamais. Comptez vos déploiements à la main pendant un mois s'il le faut, regardez la tendance, et améliorez l'instrumentation ensuite. Le but n'est pas d'avoir un dashboard impressionnant, c'est de provoquer des conversations utiles entre la tech, le produit et le business. Une fois ces quatre métriques en place, vous pourrez explorer les capabilities Accelerate pour identifier les pratiques concrètes à mettre en œuvre selon ce que vos chiffres révèlent.

Et si vous hésitez sur le moment ou la manière de vous lancer, gardez en tête la règle de base : on n'optimise jamais ce qu'on ne mesure pas, mais on ne mesure pas tout pour autant. Choisir les bons indicateurs au bon stade de maturité fait partie intégrante du travail de structuration d'une équipe tech.

CTO externalisé ou interne : que choisir ?

Rémi Alvado — Wed, 29 Jul 2026 05:23:35 +0000

La question revient à chaque fois qu'un fondateur sent qu'il ne peut plus piloter la technique au feeling : faut-il un CTO externalisé ou un CTO interne ? Et la réponse honnête, ce n'est pas « l'un est mieux que l'autre ».

La réponse courte

Ça dépend de votre phase. En early stage et en transition, un CTO externalisé (fractionnel) bat souvent le CDI : même
niveau de décision, sans le coût ni le risque d'un recrutement à temps plein. Dès que l'équipe grossit et que l'IP
devient critique, l'interne s'impose. Le piège, c'est de choisir par défaut.

La plupart des fondateurs que j'accompagne arrivent avec une conviction déjà formée (« il me faut un CTO ») et entendent par là un recrutement en CDI : une fiche de poste, six mois de recherche, un C-Level qui s'installe à plein temps. C'est souvent la mauvaise première marche. Avant de choisir qui, il faut choisir quel format, et ce choix se raisonne au stade de l'entreprise, pas à la mode du moment. Cet arbitrage, je l'ai posé en profondeur dans mon guide complet sur le CTO fractionnel ; ici, je me concentre sur la décision binaire qui vous occupe : dedans ou dehors.

Ce qu'on compare, exactement

Première précision, parce qu'elle évite la moitié des erreurs : « CTO externalisé » ne veut pas dire « développeur freelance ». Un développeur externe résout un problème de code. Un CTO externalisé, on parle aussi de CTO fractionnel, occupe le rôle de directeur technique : vision, recrutement, architecture des choix structurants, représentation de la tech au CODIR. La seule chose qui change face à un CDI, c'est le format : quelques jours par semaine sur une mission bornée, au lieu d'un temps plein indéfini avec equity.

Donc on ne compare pas un junior contre un senior. On compare le même métier sous deux formats d'engagement. Et chaque format a ses phases de prédilection.

Les phases où l'externalisé gagne

Early stage : vous avez besoin de décisions, pas d'une présence

Avant le product-market fit, votre besoin n'est pas qu'un C-Level soit physiquement là tous les jours. Votre besoin, c'est que les trois ou quatre décisions qui vont engager l'entreprise pour deux ans soient bonnes : quelle architecture, quelle pile technique, quoi construire en premier, quoi ne surtout pas construire. Ces décisions tiennent dans un à deux jours par semaine d'un dirigeant tech expérimenté. Les payer à plein temps, c'est gaspiller du capital sur du temps de présence dont vous n'avez pas encore l'usage.

L'écart de coût n'est pas marginal. Un CTO en CDI, à ce stade, c'est de l'ordre de 220 K€ par an une fois chargé, plus de l'equity diluée au pire moment de votre valorisation. Un format externalisé à un ou deux jours par semaine se situe plutôt entre 40 et 120 K€ par an selon l'intensité, sans equity, et surtout sans le risque du recrutement raté qui vous coûte douze à dix-huit mois si vous vous trompez de personne. Quand le cash est votre ressource la plus rare, cet arbitrage se passe de commentaire.

Le besoin de vélocité de décision

Il y a un effet moins évident, et c'est souvent celui qui emporte la décision sur le terrain. Un CTO externalisé qui a déjà vu passer vingt projets tranche vite, parce qu'il reconnaît votre situation. Un premier CTO interne, même excellent, va découvrir votre contexte en même temps qu'il prend ses fonctions, et le temps qu'il monte en puissance, vous avez déjà pris les décisions structurantes sans lui. En early stage, la vélocité de décision compte plus que la disponibilité horaire.

La transition : combler un trou sans se tromper dans l'urgence

Troisième phase où l'externalisé brille : la transition. Votre CTO vient de partir, ou vous devez préparer une levée et il vous manque un interlocuteur tech crédible face aux investisseurs. Recruter dans l'urgence, c'est la garantie de mal recruter. Un CTO externalisé tient le poste le temps de stabiliser, puis pilote lui-même le recrutement de son successeur interne : il sait exactement quoi chercher, parce qu'il a fait le job. J'ai détaillé cette mécanique de passage de relais dans les 90 jours qui suivent un départ de CTO. Bien menée, la transition transforme une urgence subie en recrutement maîtrisé.

Les phases où l'interne s'impose

Soyons clairs : l'externalisé n'est pas une solution universelle, et je serais malhonnête de le présenter comme tel. Il y a des moments où le CDI n'est pas un luxe, c'est la bonne réponse.

Quand l'équipe grossit et a besoin d'une présence quotidienne

À partir du moment où vous avez une équipe technique qui dépasse une poignée de personnes, le travail du CTO change de nature. Ce n'est plus seulement trancher des choix d'architecture : c'est animer, arbitrer des tensions au quotidien, faire grandir des gens, tenir une culture d'ingénierie. Ça ne se fait pas un jour et demi par semaine. Le management d'équipe demande une présence continue : être là quand un conflit monte, quand un recrutement se décide, quand un incident de production tombe à 18 h un vendredi. À ce stade, l'externalisé atteint sa limite structurelle, et c'est sain.

Quand l'IP technique devient critique

Si votre avantage concurrentiel est votre technologie (un moteur propriétaire, un algorithme, une architecture difficile à reproduire), alors la connaissance fine de cette technologie doit vivre à l'intérieur de l'entreprise, dans une personne engagée sur le long terme et alignée par de l'equity. Un CTO externalisé partage son temps entre plusieurs missions ; c'est parfait pour structurer, c'est inadapté pour porter dans la durée le cœur d'IP qui fait votre valorisation. Le jour où la tech devient le produit, l'interne n'est plus une option.

Quand les investisseurs veulent un porteur engagé

Au-delà d'un certain ticket, les investisseurs financent une équipe autant qu'un projet : ils veulent un CTO interne, présent, qui a misé son temps et une partie de son avenir sur l'aventure. Un fractionnel rassure en amorçage et pendant la préparation d'une levée ; il ne remplace pas, en série A bien avancée, un CTO titulaire au capital.

La grille de décision

Voici comment je résume la chose quand un fondateur me pose la question de but en blanc.

Votre situation	Format qui gagne généralement
Pré-PMF, besoin de cadrer les choix structurants	Externalisé (fractionnel)
Cash rare, equity à préserver	Externalisé
Trou à combler, préparation de levée seed	Externalisé, puis recrutement
Équipe tech > 5-6 personnes à animer au quotidien	Interne (CDI)
L'IP technique est votre avantage concurrentiel	Interne
Série A avancée, investisseurs qui veulent un porteur	Interne

Cette grille n'est pas un oracle. Une startup deeptech peut avoir besoin d'un CTO interne dès le premier jour, parce que sa techno est le projet. À l'inverse, un SaaS B2B au modèle bien balisé peut très bien tourner deux ans avec un fractionnel avant de basculer. La grille donne le cas général ; votre contexte décide des exceptions.

Comment décider pour votre contexte

Si je devais réduire toute la réflexion à une seule question, ce serait celle-ci : ce qui vous manque, est-ce une décision ou une présence ?

Si c'est une décision (quoi construire, comment l'architecturer, qui recruter en premier), un format externalisé vous l'apporte plus vite et moins cher, sans engager votre capital ni votre cap-table. Si c'est une présence (animer une équipe qui grossit, tenir une culture, porter un cœur d'IP au quotidien), alors il vous faut un interne, et tout format intermédiaire ne fera que repousser le problème.

Cette question principale se décompose en quelques critères concrets. Regardez-les honnêtement, sans présupposer la réponse : selon là où penche la majorité, vous saurez vers quel format vous orienter.

La bonne nouvelle, c'est que ce n'est pas un choix définitif. Le scénario le plus courant, et le plus sain, n'est pas « externe ou interne » figé pour toujours, c'est une séquence où l'un prépare l'autre.

L'externalisé cadre en early stage. En amont du product-market fit, un CTO externalisé tranche les choix structurants, pose une architecture saine, et vous évite de figer du capital sur du temps de présence dont vous n'avez pas encore l'usage. Il clarifie votre besoin réel en travaillant, pas en théorisant.

Puis il structure et recrute les premiers profils. À mesure que ça se complexifie, il installe les bonnes pratiques, recrute les premiers développeurs, et bâtit l'équipe qui prendra le relais. C'est exactement ce que je fais en création d'équipe tech et produit : poser les fondations, puis organiser ma propre sortie.

Enfin, il passe la main à un interne quand l'équipe et l'IP l'exigent. Le jour où le management quotidien et la criticité de l'IP réclament une présence permanente, l'externalisé pilote lui-même le recrutement de son successeur interne : il sait quoi chercher, parce qu'il a fait le job. La transition est maîtrisée, pas subie.

Le format externalisé n'est donc pas un pis-aller en attendant le « vrai » CTO ; c'est souvent la bonne réponse pour votre phase actuelle, qui prépare proprement la suivante. Et si vous avez encore une hésitation sur la frontière entre freelance, fractionnel et CDI, j'ai consacré un article entier à départager ces trois formats.

Le seul mauvais choix, au fond, c'est de choisir par défaut : recruter un CDI parce que « c'est ce qui se fait », ou prendre un externe parce que « c'est moins cher », sans avoir d'abord regardé honnêtement la phase où se trouve votre entreprise.

Pas sûr du bon format pour votre stade ?

C'est exactement la conversation que j'ai avec les fondateurs avant toute mission. En création d'équipe tech &
produit ou en accompagnement
scaling, on regarde ensemble votre phase réelle et le format qui lui correspond,
sans pousser l'un plus que l'autre.

CTPO : faut-il fusionner les rôles de CTO et CPO ?

Rémi Alvado — Mon, 27 Jul 2026 07:23:16 +0000

Sur le papier, le CTO (Chief Technology Officer) et le CPO (Chief Product Officer) semblent avoir des objectifs opposés. L'un parle de dette technique et de stabilité, l'autre de nouvelles fonctionnalités et d'expérience utilisateur.

Pourtant, ces deux membres du CODIR partagent une mission unique : créer un maximum de valeur pour l'entreprise.

Faut-il alors les garder séparés pour garantir l'expertise, ou les fusionner en un seul rôle (le CTPO) pour gagner en vitesse ? Analysons les options.

Le duel théorique : Tech vs Produit

Historiquement, ces deux rôles abordent la création de valeur via deux prismes différents, souvent sources de friction :

Rôle	Objectif Principal	Préoccupations Quotidiennes
Le CPO	Croissance & Satisfaction	Plus d'utilisateurs, nouvelles fonctionnalités, couverture du marché, UX/UI.
Le CTO	Pérennité & Sécurité	Mise à jour des frameworks, scalabilité, sécurité des données, maîtrise des coûts.

Le piège des silos : En réalité, ces prismes sont indissociables. Un produit bourré de fonctionnalités (CPO) mais
techniquement instable (CTO) fera fuir les clients. À l'inverse, une architecture technique parfaite pour un produit
que personne n'utilise est un échec business.

Dans une organisation qui grandit, ces rôles s'éloignent de l'opérationnel pur. Le CTO code moins, le CPO ne fait plus de wireframes. Ils deviennent des stratèges qui doivent s'aligner. Alors, pourquoi ne pas n'en faire qu'une seule personne ?

Les compétences communes (et celles qui ne le sont pas)

Avant de trancher, il faut regarder ce que ces deux rôles partagent réellement. Parce que la question « peut-on cumuler CTO et CPO ? » n'a de sens que si le socle de compétences se recoupe suffisamment.

Et il se recoupe plus qu'on ne le croit. Un bon CTO et un bon CPO passent leur temps à faire la même chose au fond : transformer une intention business floue en quelque chose d'exécutable. Les deux décomposent un problème complexe, priorisent sous contrainte de ressources, savent dire non, et défendent une vision auprès du CODIR. Les deux vivent avec la frustration de ne jamais avoir assez de temps ni assez de mains. Et surtout, les deux raisonnent en arbitrages permanents : qu'est-ce qui crée le plus de valeur maintenant, avec ce que j'ai sous la main ?

Là où ça diverge, c'est sur la matière première. Le CPO travaille la connaissance utilisateur, le marché, la psychologie de l'adoption, le pricing, la data d'usage. Le CTO travaille l'architecture, la dette technique, la sécurité, le recrutement d'ingénieurs, les choix d'infrastructure. Ce sont deux corpus profonds, qui demandent chacun des années pour être maîtrisés vraiment. C'est précisément pour ça que le profil double (le CTPO) est rare : il faut avoir vécu les deux métiers de l'intérieur, pas seulement avoir survolé l'autre depuis le sien.

Dans la pratique, ce que je constate, c'est qu'un CTPO crédible vient presque toujours d'un parcours où il a d'abord été excellent dans un domaine, puis a basculé vers l'autre par nécessité, souvent en startup, parce qu'il n'y avait personne d'autre pour le faire. C'est mon cas : développeur à l'origine, j'ai pris le produit en main parce que la boîte en avait besoin, et j'y ai pris goût au point d'en faire une seconde expertise. Cette double trajectoire change tout par rapport à un manager qui « gère » les deux sans les avoir pratiqués.

Option 1 : Le CTPO (Chief Tech & Product Officer)

C'est l'option de la vélocité. Une seule personne porte les deux casquettes et arbitre les conflits internes entre "faire vite" et "faire propre".

Les Avantages

Rapidité de décision : Finis les débats interminables entre deux fondateurs ou directeurs. Le compromis est interne, la décision est immédiate.
Vision holistique : Le CTPO est obligé de balancer les risques. Il ne peut pas ignorer la dette technique pour sortir une feature, ni bloquer la roadmap pour un refactoring mineur.
Pas d'arbitrage du CEO : Le CEO n'a plus besoin de jouer les juges de paix entre la Tech et le Produit.

Les Risques majeurs

Le SPOF (single point of failure). Avoir une seule personne responsable de toute la création de valeur technique crée une dépendance critique : si votre CTPO part, l'entreprise risque la paralysie. C'est une situation que j'ai gérée lors de mes missions de création d'équipe tech & produit, souvent pour pallier un départ soudain.

La Licorne est rare : Trouver un profil réellement expert sur les deux tableaux est extrêmement complexe. Souvent, on aura un excellent CTO qui "bricole" le produit, ou l'inverse.
Le déséquilibre : Naturellement, le CTPO favorisera son domaine de prédilection (Tech ou Produit) au détriment de l'autre.

Si vous optez pour cette solution, la fidélisation est clé (BSPCE, Equity) car ce profil est la clé de voûte de votre exécution. C'est d'ailleurs le modèle que j'ai appliqué avec succès chez Wizbii pendant près de 10 ans.

Le vrai risque qu'on n'ose pas nommer : le conflit d'intérêt interne

Il y a un risque plus subtil que le SPOF, et c'est probablement le meilleur argument contre le cumul : le CTPO est juge et partie.

Quand le Produit et la Tech sont portés par deux personnes, leur désaccord est sain. Le CPO pousse pour sortir une feature ; le CTO alerte sur la dette que ça va créer. Cette tension est un mécanisme de contre-pouvoir : elle force un arbitrage explicite, visible, que le CEO peut observer et auquel il peut participer. Le débat se passe à la lumière.

Chez un CTPO, ce débat se passe dans une seule tête. Et c'est là que ça se complique. La personne qui décide de sacrifier la qualité technique pour tenir une deadline produit est la même qui devra réparer la dette plus tard, et qui devra l'expliquer au CODIR. La tentation de se ménager, de sous-estimer un risque technique gênant pour la roadmap, ou à l'inverse de gonfler une estimation pour s'offrir du confort, est humaine. Sans contradicteur, le contrôle disparaît.

Le test concret est simple : demandez-vous qui dit non au CTPO. Si la réponse est « personne, parce qu'il est le seul à comprendre à la fois la techno et le produit », vous avez un angle mort dans votre gouvernance. Il faut alors recréer ce contre-pouvoir autrement : un Lead Tech senior qui ose challenger l'architecture, un Head of Product qui défend la voix utilisateur, ou un regard extérieur régulier.

Option 2 : Le Duo CPO + CTO

C'est le modèle classique : deux experts, deux voix, un équilibre des pouvoirs.

Pourquoi choisir le Duo ?

Expertise pointue : Avec la complexification des métiers, il est plus facile de trouver un excellent CPO et un excellent CTO séparément qu'un génie polyvalent.
Focus : Chaque directeur peut se concentrer à 100% sur son périmètre sans se diluer.
Redondance : En cas de départ de l'un, l'autre peut souvent assurer l'intérim temporaire grâce à sa connaissance transverse du contexte.

L'inconvénient caché

Le risque principal est humain. Le recrutement doit se faire "en paire". Si le CTO et le CPO ne s'entendent pas ou n'ont pas la même vision de l'entreprise, vous créez une guerre froide qui ralentira toute l'équipe. Le CEO devra alors passer son temps à faire de la médiation et du coaching individuel.

Option 3 : Le Manager Généraliste

Peut-on mettre un "Head of Engineering" ou un gestionnaire pur au-dessus de la Tech et du Produit ?

C'est une option souvent retenue dans les grands groupes pour former de futurs dirigeants. Le profil est ici un excellent gestionnaire, capable de compromis et de reporting, mais sans compétence métier forte (ni code, ni product management).

Pourquoi c'est risqué en Startup/Scale-up ?
Dans des équipes à haute qualification (développeurs seniors, PMs expérimentés), la légitimité vient souvent de l'expertise. Un manager qui ne comprend pas les subtilités techniques ou produit risque de créer de la frustration, un sentiment d'incompréhension, et in fine, un turnover important des meilleurs éléments.

Option 4 : Le CTPO fractionnel (le compromis que peu envisagent)

Voici le scénario que je rencontre le plus souvent sur le terrain, et qui résout une bonne partie de l'équation. Une startup en amorçage a besoin d'une vision tech et produit de haut niveau. Mais elle n'a ni le budget pour recruter un CTO senior à temps plein, ni celui pour recruter un CPO senior à côté. Recruter deux C-Level, c'est facilement 250 à 300 K€ de masse salariale annuelle. Inenvisageable à ce stade.

La réponse classique, c'est de recruter un seul profil polyvalent en CDI, mais on retombe alors sur la rareté de la licorne, et sur le risque de se tromper de personne pour un poste structurant. L'autre réponse, plus souple, c'est le CTPO fractionnel : un profil double, expérimenté, qui intervient à temps partagé.

L'intérêt est double. D'abord, vous accédez à un niveau de séniorité que vous ne pourriez pas vous offrir à plein temps : quelqu'un qui a déjà construit des équipes, géré des refontes techniques, lancé des produits qui ont trouvé leur marché. C'est toute la logique d'un CTO fractionnel, transposée à un profil double tech et produit. Ensuite, vous obtenez la vision holistique du CTPO sans vous exposer pleinement au SPOF : le fractionnel structure, documente, recrute et forme l'équipe permanente, justement pour que l'entreprise ne dépende pas de lui à terme. Son rôle est de se rendre progressivement remplaçable.

C'est exactement la logique que j'applique en intervenant comme CTO et CPO fractionnel : porter les deux casquettes le temps de poser les fondations, puis construire l'équipe tech et produit qui prendra le relais. Un fondateur que j'accompagnais récemment avait passé six mois à chercher « le CTO parfait qui comprend aussi le produit » sans le trouver. En trois mois de fractionnel, on a clarifié la roadmap, fait les choix d'architecture structurants, et recruté un premier Lead Tech solide, sans jamais grever sa trésorerie de seed.

Le modèle fractionnel a aussi un avantage sur le conflit d'intérêt évoqué plus haut : un intervenant externe n'a aucun biais à protéger sa propre roadmap ou à camoufler une dette qu'il aurait laissée traîner. Il dit ce qu'il voit, parce que sa valeur tient justement à sa franchise.

Conclusion : Quel est le bon choix pour vous ?

Il n'y a pas de réponse unique, tout dépend de votre stade de maturité :

En amorçage / Série A : Le CTPO est souvent l'arme fatale pour aller vite et pivoter sans friction. À ce stade, la vélocité prime sur la profondeur d'expertise dans chaque domaine, et le coût d'un débat permanent entre deux directeurs serait disproportionné. C'est un rôle que j'exerce souvent en fractionnel pour les startups qui n'ont pas les moyens de recruter un profil senior à temps plein : la meilleure manière d'avoir les deux compétences sans recruter deux personnes.
En hyper-croissance / Série B+ : La spécialisation devient nécessaire. Scinder les deux rôles permet à chaque direction d'aller au fond de son sujet : un CTO qui structure une organisation d'ingénierie de plusieurs dizaines de personnes n'a plus le temps de piloter une discovery produit, et inversement. C'est aussi le moment où le contre-pouvoir entre Tech et Produit devient un atout de gouvernance plutôt qu'un frein.

Le bon réflexe n'est donc pas de choisir un modèle dans l'absolu, mais de faire évoluer votre organisation avec votre maturité : commencer par un CTPO (idéalement fractionnel pour limiter le risque et le coût), puis spécialiser au moment où l'échelle l'exige. L'erreur la plus fréquente, c'est de recruter un duo CTO + CPO trop tôt : deux salaires lourds, deux agendas à synchroniser, pour une boîte qui n'a pas encore confirmé son product-market fit. Et l'erreur symétrique, c'est de s'accrocher au CTPO unique trop longtemps, jusqu'à ce qu'il devienne un goulot d'étranglement épuisé qui bride à la fois la tech et le produit.

Vous hésitez sur votre modèle d'organisation ?

Que vous cherchiez à porter vous-même les deux casquettes, à recruter, ou à intervenir en transition, je vous aide à
choisir et à mettre en place la bonne organisation tech & produit. En création d'équipe tech &
produit, j'interviens comme CTPO fractionnel pour structurer vos
fondations et recruter l'équipe qui prendra le relais.