Il y a une croyance tenace dans l'écosystème startup : les grands groupes sont lents, bureaucratiques, et n'ont rien à apprendre aux équipes qui "bougent vite et cassent des choses". Move fast. Ship fast.
J'ai travaillé des deux côtés. AXA, ADP, Dassault Systèmes, Volkswagen d'un côté. Des startups en plein sprint de l'autre. Et avec le temps, j'ai fini par voir une chose assez nette.
Beaucoup de startups confondent vitesse et agitation.
Le mythe de la vélocité startup
Quand une startup dit qu'elle va vite, cela veut souvent dire autre chose : des features partent en développement alors que le besoin est encore flou, les indicateurs sont incomplets, la documentation est minimale, et certaines décisions importantes se prennent sur une intuition ou sur le dernier arbitrage entendu en réunion.
On se retrouve alors avec une roadmap instable, des équipes tech qui reprennent plusieurs fois les mêmes sujets, un PM coincé entre les demandes de direction, des specs fragiles et des bugs qui s'accumulent. On parle surtout d'un problème de dispersion.
Les grands groupes ont souvent payé très cher l'absence de clarté produit. C'est ce qui explique une partie de leurs garde-fous. Certains ont basculé dans l'excès procédural. D'autres ont simplement installé de bons réflexes. Ce sont ceux-là qui méritent d'être regardés.
Leçon 1 : on ne lance pas avant d'avoir clarifié
Dans les organisations les plus solides, une feature ne part pas en développement sans un minimum de cadrage. Rien de lourd. Juste ce qu'il faut pour répondre clairement à trois questions : quel problème traite-t-on, pour qui, et comment saura-t-on que cela fonctionne ?
Les startups skippent cette étape parce qu'elle "prend du temps". Sauf que ce qu'elles gagnent à court terme, elles le repaient au centuple en allers-retours, en refontes, en désaccords sur "ce qu'on voulait vraiment faire".
Un cadrage ne ralentit pas un produit. Il évite surtout de courir dans la mauvaise direction.
J'ai vu une équipe de six personnes passer deux sprints sur une feature avant de découvrir en démo que le CEO attendait tout autre chose. Deux semaines perdues. Le cadrage initial aurait probablement demandé deux heures.
Leçon 2 : on décide avec des données, pas des opinions
Les grands groupes ont souvent un défaut bien connu : ils mesurent tout. Jusqu'à produire parfois des dashboards illisibles. Malgré ça, le réflexe de fond reste sain : avant de prendre une décision produit importante, ils cherchent un appui dans les données.
À l'inverse, beaucoup de startups lancent rapidement puis mesurent tard, ou mal. Et quand un indicateur est suivi, c'est souvent un signal flatteur plutôt qu'un indicateur réellement utile pour savoir si le produit crée de la valeur.
A/B test, funnel d'activation, cohorte de rétention : ces outils ne sont pas réservés à des organisations déjà très structurées. Ils deviennent utiles très tôt, dès qu'une équipe accepte de remplacer une partie de ses intuitions par des observations.
Le problème, c'est que mesurer implique de définir à l'avance ce qu'on veut mesurer. Et ça, ça oblige à réfléchir avant d'agir. C'est inconfortable pour une équipe qui a l'habitude de courir.
Leçon 3 : ce qui n'est pas documenté n'existe pas
Voici une scène que j'ai vue plus d'une fois : un CTO rejoint une startup en série B et passe ses premières semaines à reconstituer le fonctionnement réel du produit. Pas la version racontable. La vraie. Les choix d'architecture, les décisions UX, les intégrations, les contraintes.
Et il ne trouve rien. Tout est dans la tête de deux ou trois personnes qui sont, évidemment, les plus occupées de l'équipe.
Les grands groupes documentent davantage, d'abord parce qu'ils ont appris qu'une connaissance non formalisée devient vite un risque opérationnel. Quand une personne clé part, elle emporte souvent avec elle une partie des décisions, du contexte et des arbitrages passés. Chez Dassault Systèmes, où j'ai passé quatre ans à piloter la transformation digitale, la documentation produit n'était pas optionnelle. À cette échelle, elle faisait simplement partie du fonctionnement normal : c'est ce qui permettait à des équipes réparties sur plusieurs continents de travailler sur les mêmes plateformes sans se marcher dessus.
Dans une startup qui scale, le problème s'accélère. Vous recrutez vite, les gens tournent, les équipes grossissent. Sans documentation, chaque onboarding devient une perte de temps immense, chaque décision est réinventée, chaque bug se transforme en enquête archéologique.
Et puis l'IA est arrivée, et l'excuse a disparu
Jusqu'en 2022, on pouvait défendre l'idée que documenter coûtait cher en temps de cerveau humain et qu'il fallait arbitrer entre produire et écrire sur ce qu'on avait produit. C'était un vrai débat. Plus aujourd'hui.
Le coût marginal de la documentation a chuté brutalement. Une réunion de cadrage ? Granola, Fathom ou tl;dv vous sortent un compte-rendu structuré sans que personne n'ait pris une note. Une intégration technique à documenter ? Cursor ou Claude Code génèrent une première version exploitable à partir du code lui-même en quelques minutes. Un PRD à rédiger ? Vous partez de trois bullet points, l'IA vous structure le document, vous corrigez et complétez. Une base de doc dans laquelle personne ne retrouve rien ? Notion AI ou Glean la rendent interrogeable en langage naturel.
Ce qui prenait une heure prend dix minutes. Ce qui demandait une discipline de scribe demande maintenant une discipline de relecteur.
Documenter fait partie du travail produit. C'est l'une des conditions pour faire grandir une équipe sans perdre en cohérence. Alors quand un fondateur ou un CTO me dit aujourd'hui "on n'a pas le temps de documenter", j'entends autre chose. J'entends "on n'a pas envie de prendre dix minutes pour relire ce que l'IA a produit". Aujourd'hui, cela relève davantage d'un choix d'organisation que d'une vraie contrainte de temps.
Attention quand même : l'IA ne décide pas de ce qui mérite d'être documenté, ni de la hiérarchie de l'information, ni de qui en a besoin. L'IA aide à produire plus vite. La hiérarchie de l'information, elle, reste un travail humain. C'est précisément la part qui crée de la valeur. Lancer ChatGPT sur une réunion ne suffit pas. Mais ne plus avoir d'excuse pour produire de la doc, c'est déjà un changement énorme.
Leçon 4 : la gouvernance produit, ça se construit avant d'en avoir besoin
Dans les grands groupes, la question du pouvoir de décision sur le produit est en général traitée de manière explicite. Les circuits ne sont pas toujours élégants, mais les rôles, les responsabilités et les arbitrages existent.
Dans les startups, cette question est souvent évitée jusqu'à ce qu'elle devienne une crise. Tant que l'équipe est petite et que tout le monde se parle au quotidien, ça tient. Mais dès qu'on passe 20, 30, 50 personnes, dès qu'il y a plusieurs équipes produit, plusieurs squads, plusieurs stakeholders, l'absence de gouvernance devient toxique.
J'ai passé deux ans au Groupe ADP à piloter la transformation Smart Airport, avec un jalon non négociable au bout : les Jeux Olympiques de Paris 2024. Quand vous préparez un événement international scruté par la planète entière, avec des dizaines de parties prenantes — exploitation, sûreté, IT, métiers, partenaires technologiques — et une deadline qui ne bougera jamais, vous comprenez très vite une chose. Sans gouvernance claire, personne n'arbitre. Et quand personne n'arbitre, c'est la réalité qui finit par trancher à votre place, généralement au pire moment.
Ce qu'on a installé chez ADP, ce n'était pas une usine à comités. Plutôt un cadre minimal mais explicite. Qui décide de la roadmap. Qui arbitre entre deux cas d'usage qui se disputent les mêmes ressources. Qui peut dire non, et à qui. Qui valide qu'un produit est prêt à passer en production dans un environnement critique. Une fois ces questions répondues, les équipes ont arrêté de perdre de l'énergie en discussions sans fin et ont pu se concentrer sur le delivery.
Dans une startup, ces questions arrivent plus tard, mais elles arrivent.
Si personne ne peut répondre clairement à ces questions dans votre organisation, vous avez un problème de gouvernance. Et ce problème grossit à mesure que vous scalez. La bonne nouvelle, c'est qu'une gouvernance utile n'a pas besoin d'être lourde. Elle a surtout besoin d'être explicite.
Une nuance importante
Rien de ce que je décris ici ne consiste à transformer une startup en grand groupe. La lourdeur des processus corporate, les comités qui durent trois heures pour ne rien décider, les validations en cascade : tout ça est réel et mortel pour une startup.
Ce qui m'intéresse, c'est l'intention initiale qui se cache derrière chacun de ces dispositifs avant qu'ils ne deviennent caricaturaux. Cadrer, mesurer, documenter, gouverner : ces réflexes méritent d'être récupérés, simplifiés, et adaptés à la réalité d'une équipe qui accélère. C'est ce qui permet de tenir la vitesse dans la durée plutôt que de l'épuiser en quelques trimestres.
Les 4 réflexes à récupérer
- Cadrer avant de développer : 3 questions, 1 page, 2 heures. Pas une spec de 40 pages.
- Mesurer avec 2 ou 3 indicateurs actionnables dès le lancement : pas 200 KPIs six mois après.
- Documenter en continu : l'IA a supprimé l'excuse du temps. Il reste la discipline du relecteur.
- Gouverner explicitement : qui décide de quoi, écrit noir sur blanc, avant que la crise ne force la question.
