Des experts des startups expliquent pourquoi il faut faire des choses qui ne passent pas à l’échelle
- Aisha Washington
- il y a 1 jour
- 9 min de lecture
Les fondateurs en phase de démarrage sont souvent encouragés à penser à la montée en charge dès le début. On leur demande comment leurs systèmes pourront servir des millions d’utilisateurs, comment l’acquisition de clients deviendra reproductible et comment les opérations pourront se développer sans que les coûts augmentent au même rythme. Ce sont des questions légitimes — mais les experts des startups réunis dans cette discussion de Y Combinator estiment qu’elles sont souvent posées trop tôt.
Les intervenants reviennent sur l’essai influent de Paul Graham, « Do Things That Don’t Scale », et expliquent pourquoi son message reste essentiel pour bâtir une entreprise à partir de zéro. En s’appuyant notamment sur Airbnb, Fleek, Stripe, Algolia, Instacart et DoorDash, ils défendent l’idée que l’effort manuel n’est pas simplement un compromis temporaire acceptable. Lorsqu’il est utilisé délibérément, c’est un moyen puissant de tester la demande, de comprendre les clients et de découvrir quelles composantes d’une entreprise méritent réellement d’être mises à l’échelle.
Pourquoi l’univers des startups avait besoin d’une autre méthode
Selon les intervenants, l’enthousiasme de la Silicon Valley pour les systèmes scalables provient en partie de l’observation d’entreprises internet au succès exceptionnel. Google a démontré que les logiciels et la distribution en ligne pouvaient atteindre d’immenses audiences avec relativement peu d’effort additionnel. Les fondateurs et les investisseurs ont donc naturellement commencé à rechercher des modèles de croissance tout aussi reproductibles.
Cette ambition est progressivement devenue une contrainte. Les entrepreneurs ressentaient la pression de présenter une solution scalable avant même d’avoir prouvé que quelqu’un en avait besoin. Ils pouvaient passer des mois à concevoir des systèmes automatisés pour une demande hypothétique tout en restant éloignés des vrais clients.
L’essai de Paul Graham a remis cette séquence en question. Comme l’expliquent les membres du panel, la plupart des jeunes startups ne sont pas menacées par une demande excessive ou par l’effondrement de leur infrastructure. Leur risque immédiat est bien plus simple : elles pourraient ne jamais attirer suffisamment d’utilisateurs, ou construire quelque chose que les gens ne valorisent pas.
La priorité pratique consiste donc à résoudre directement le problème, même si la première méthode demande beaucoup de travail. La scalabilité finira par compter, mais seulement après que l’entreprise aura trouvé quelque chose qui mérite d’être mis à l’échelle.
Passer de zéro à un vient d’abord
La discussion présente la progression d’une startup comme une succession de contraintes immédiates. Au départ, le défi n’est pas de servir efficacement le millionième client. Il consiste à gagner le premier client, à produire le premier résultat concluant et à comprendre pourquoi cette personne a choisi le produit.
Cela change la manière dont les fondateurs devraient évaluer leur travail initial. Une tâche qui paraît inefficace dans une entreprise mature peut être parfaitement rationnelle si elle répond rapidement à une question cruciale. Accompagner personnellement un client lors de son onboarding, assembler manuellement un service ou improviser un processus interne peut révéler davantage que plusieurs semaines consacrées à construire une infrastructure en vase clos.
Les intervenants utilisent Airbnb comme exemple emblématique. Ses fondateurs avaient besoin de meilleures annonces ; ils ont donc aidé les hôtes à produire des photographies de meilleure qualité. Se rendre dans les logements et améliorer chaque annonce individuellement ne pouvait pas devenir le modèle opérationnel permanent. Pourtant, cela répondait au problème urgent de l’entreprise : rendre la marketplace plus attrayante et générer suffisamment d’activité pour que la croissance puisse commencer.
La leçon n’est pas que chaque fondateur devrait reproduire la tactique d’Airbnb. Elle est que les fondateurs doivent identifier l’obstacle qui se trouve directement devant eux et être prêts à le résoudre sans attendre un système élégant.
Fleek a compris la marketplace avant de la construire
Fleek offre une illustration particulièrement parlante de l’apprentissage par les opérations manuelles. L’entreprise a démarré sans site web finalisé, sans stock de vêtements et sans infrastructure de marketplace sophistiquée. À la place, ses fondateurs se sont rendus chez des grossistes londoniens, ont noué des relations et ont directement mis en relation l’offre avec des magasins.
Le panel raconte que l’équipe transportait même des vêtements entre les grossistes et les détaillants. Du point de vue de l’efficacité conventionnelle, voir les fondateurs transporter eux-mêmes des marchandises ressemble à un échec de processus. Du point de vue de l’apprentissage, cela les plaçait toutefois au cœur de la transaction.
En participant au travail, Fleek pouvait observer ce que voulaient les détaillants, comment se comportaient les grossistes, quels prix fonctionnaient et comment la demande réagissait aux changements. Il ne s’agissait pas de réponses abstraites à des sondages. C’étaient des enseignements recueillis en aidant de vrais acheteurs et vendeurs à conclure de vrais achats.
Après environ quatre mois d’opérations manuelles, les fondateurs disposaient de suffisamment de connaissances pour transférer l’activité en ligne. La marketplace reposait sur des comportements que l’équipe avait déjà observés, plutôt que sur des hypothèses concernant la manière dont le marché était censé fonctionner.
Un onboarding pratique permet de créer de meilleurs produits
Les intervenants citent Stripe et Algolia comme autres exemples de fondateurs ayant réduit l’écart entre le développement produit et la réalité des clients. Les fondateurs de Stripe ont aidé les premiers utilisateurs à installer leur logiciel de paiement au lieu de se contenter d’envoyer de la documentation et d’attendre. De la même manière, Algolia a aidé Product Hunt à mettre en œuvre sa recherche.
L’implémentation directe permet bien plus que l’activation d’un nouveau compte. Elle met au jour les étapes de configuration confuses, les dépendances techniques cachées et les écarts entre ce que les clients disent vouloir et ce qui leur pose réellement problème dans la pratique.
Elle peut aussi transformer la relation. Un client qui a travaillé aux côtés d’un fondateur sera plus enclin à partager un retour franc qu’une personne qui envoie un ticket de support à une entreprise qu’elle ne connaît pas. Cette confiance donne à la startup accès à une compréhension plus fine du produit.
Les membres du panel décrivent cette attention personnelle — le « FaceTime » des fondateurs — comme un avantage que les entreprises établies ne peuvent souvent pas égaler. Un grand concurrent peut disposer de davantage de ressources, mais il est généralement incapable d’avoir ses fondateurs personnellement engagés dans la réussite de chaque petit client. Pour une startup au produit incomplet et à la crédibilité limitée, cette attention visible peut devenir une partie de la proposition de valeur.
Optimiser le travail initial pour apprendre
L’argument central de la discussion est que les fondateurs devraient optimiser la phase initiale pour l’apprentissage plutôt que pour l’élégance opérationnelle. La prestation manuelle permet d’établir si le résultat promis a réellement de la valeur avant que l’équipe n’intègre ce processus dans un logiciel.
Ce principe peut se traduire par une séquence simple :
Identifier l’incertitude la plus importante dans l’entreprise.
Concevoir le moyen crédible le plus rapide de la tester auprès de vrais clients.
Effectuer le travail manuellement lorsque l’automatisation retarderait la réponse.
Consigner ce qui crée régulièrement de la valeur ou génère des frictions.
Construire des systèmes seulement une fois que la tendance devient claire.
Cela ne signifie pas qu’il faut considérer chaque processus improvisé comme la preuve d’une entreprise viable. Le travail manuel est utile lorsqu’il produit des éléments probants. Les fondateurs doivent encore déterminer si la demande se répète, si les clients paieront et si le service sous-jacent peut, à terme, soutenir un modèle économique attractif.
Ce qu’ils devraient éviter, c’est de confondre le raffinement technique avec la validation. Une plateforme magnifiquement conçue ne peut pas compenser un produit dont personne ne veut.
Instacart et DoorDash ont testé la demande avec des outils improvisés
L’histoire d’Instacart montre comment des fondateurs peuvent tester une marketplace avant d’obtenir tous les partenariats qu’exigerait une version mature. Comme le raconte la vidéo, l’entreprise s’est lancée sans relations formelles avec les magasins d’alimentation. L’équipe achetait des articles chez Trader Joe’s, les photographiait et les mettait en ligne afin de voir si des clients commanderaient des courses livrées à domicile.
Cette approche évitait un cycle potentiellement long de négociations de partenariats. Au lieu de demander aux détaillants de soutenir un concept non prouvé, les fondateurs ont d’abord recueilli des preuves que les consommateurs voulaient ce service.
DoorDash a adopté une approche tout aussi pragmatique. Les intervenants décrivent son premier produit comme quelque chose assemblé en une seule journée avec des outils ordinaires, notamment Google Drive et Find My Friends. L’objectif n’était pas de créer immédiatement une plateforme logistique durable. Il s’agissait de découvrir si les consommateurs locaux commanderaient des livraisons de restaurants et si les fondateurs pouvaient honorer ces commandes.
Ces expérimentations exploitaient un véritable avantage des startups : les petites équipes peuvent temporairement coordonner le travail de façons qui seraient peu pratiques pour les grandes organisations. Elles ont moins de processus à protéger, moins d’infrastructures à intégrer et davantage de liberté pour changer de direction après chaque résultat.
Les systèmes imparfaits accélèrent l’adaptation
Faire les choses manuellement permet à une équipe de revoir l’expérience sans reconstruire un produit entier. Si les clients n’aiment pas une étape, les fondateurs peuvent la modifier dès la commande suivante. Si une hypothèse s’avère fausse, ils peuvent l’abandonner avant qu’elle ne se retrouve intégrée dans des mois de travail d’ingénierie.
Les intervenants soutiennent également que les fondateurs ne devraient pas avoir une peur excessive des erreurs opérationnelles initiales. Les problèmes créés par une demande croissante engendrent souvent de fortes incitations à trouver rapidement des solutions. Lorsqu’une startup a enfin plus d’utilisateurs que son processus improvisé ne peut en gérer, le besoin d’automatisation devient concret, urgent et plus facile à définir.
C’est pourquoi les startups échouent rarement parce qu’elles ont attiré trop de clients et n’ont pas pu passer à l’échelle. Les problèmes de capacité sont douloureux, mais ils s’accompagnent de preuves de demande. Le manque d’utilisateurs est bien plus dangereux, car il n’apporte ni revenus ni raison claire de continuer à construire.
L’implication pour l’ingénierie est importante : reporter l’infrastructure peut être une forme de vitesse, et non de négligence, à condition que les raccourcis soient compris et qu’ils ne créent pas de risques inacceptables pour les clients.
Savoir quand construire pour passer à l’échelle
Le travail non scalable est une méthode de découverte, pas une philosophie permanente. Lorsqu’une startup comprend le travail récurrent à accomplir, constate une demande durable et rencontre des goulots d’étranglement manuels, elle doit commencer à transformer ce qu’elle a appris en systèmes reproductibles.
Le panel souligne que des conseillers et investisseurs expérimentés peuvent aider les fondateurs à reconnaître cette transition. Passer à l’échelle trop tôt gaspille des ressources sur des hypothèses non vérifiées. Le faire trop tard peut dégrader la qualité du service, épuiser l’équipe et empêcher l’entreprise de capter la demande.
La répétition est un signal utile. Si les fondateurs résolvent sans cesse le même problème à peu près de la même façon, un logiciel peut être en mesure de standardiser le processus. Le coût d’opportunité en est un autre : lorsque la prestation manuelle consomme du temps qui pourrait produire davantage d’apprentissage ou de croissance, l’automatisation devient de plus en plus attrayante.
L’objectif n’est pas d’éliminer l’intervention humaine pour elle-même. Il consiste à automatiser les parties désormais comprises tout en préservant une relation étroite là où les clients enseignent encore quelque chose d’important à l’entreprise.
Le conseil peut servir de passerelle, mais pas de destination
Les intervenants abordent également la frontière entre une startup logicielle et une société de conseil. Une jeune entreprise peut générer des revenus en fournissant des services pratiques à des entreprises, et son premier produit peut simplement rendre ce service plus rapide ou plus fiable.
Cela peut constituer un point de départ productif. Le travail de conseil expose les fondateurs à de véritables environnements opérationnels et leur donne une connaissance détaillée des problèmes des clients. Il peut également financer le développement initial.
Cependant, le panel avertit que les revenus de services ne suffisent pas à eux seuls à créer une entreprise logicielle à forte croissance. Le travail sur mesure se développe principalement en ajoutant des personnes, tandis qu’un produit scalable peut servir bien davantage de clients sans croissance proportionnelle des effectifs. Des objectifs de croissance ambitieux aident à imposer cette distinction : si l’entreprise doit croître d’un ordre de grandeur, les fondateurs doivent finir par transformer une expertise répétée en produit, plutôt que de vendre indéfiniment du travail sur mesure.
L’avantage durable de l’effort des fondateurs
Le message de conclusion de la vidéo est que la volonté d’accomplir des tâches maladroites, manuelles ou apparemment mineures constitue l’un des plus grands avantages d’une startup sur des concurrents établis. Ce travail rapproche les fondateurs des clients, accélère les expérimentations et crée des occasions de fournir un service exceptionnellement attentif.
Le principe plus profond n’est pas une célébration de l’inefficacité. C’est un enchaînement discipliné. Commencez par apprendre ce dont les gens ont besoin. Prouvez ensuite qu’ils agiront en fonction de ce besoin. Fournissez le résultat par toute méthode responsable disponible, étudiez le schéma récurrent, puis investissez seulement alors dans sa reproductibilité.
La scalabilité devient précieuse lorsque la demande l’a méritée. Avant ce moment, le système le plus efficace du fondateur peut simplement être sa curiosité, son sens de l’urgence et sa volonté de faire le travail personnellement.
