En octobre 2008, à New York, Brian Chesky et Joe Gebbia sonnent porte à porte chez les premiers hôtes d'Airbnb, appareil photo emprunté à la main, pour photographier les annonces. Les annonces convertissent mieux dès la semaine suivante. Cinq ans plus tard, en juillet 2013, Paul Graham donne un nom à la tactique dans un essai de 4 346 mots : Do Things that Don't Scale. L'idée contredit tout ce qu'on raconte aux fondateurs : pour qu'une startup décolle, il faut commencer par des choses structurellement non-reproductibles, coûteuses en temps founder, qu'aucune slide ne montre. Recruter ses users un par un, débarquer là où ils sont, en faire plus que promis, mendier des recommandations, faire à la main ce qu'on automatisera plus tard. Suivent les cinq tactiques canoniques, quinze cas documentés, la version 2026, et la seule question que l'essai n'a jamais traitée : quand arrêter.
C'est quoi "do things that don't scale" ?
L'expression vient d'un essai de Paul Graham publié en juillet 2013, après des centaines de batches YC qui répétaient la même erreur : construire un produit, ouvrir l'app store, attendre la croissance organique. Elle n'arrive jamais. Sauf si les fondateurs vont la chercher manuellement, une transaction à la fois.
"Startups take off because the founders make them take off." (Paul Graham, 2013)
Le paradoxe est frontal. Vous concevez tout votre produit pour passer à l'échelle : stack serverless, CRM SaaS, acquisition en performance marketing. La première chose à faire, c'est l'inverse, du travail manuel, individuel, coûteux, parce que la croissance organique n'existe pas encore.
Deux précisions. C'est une phase, parfois longue (HyperSpectral fait encore de l'onboarding white glove à 3,5 M$ ARR), parfois courte (Stripe a arrêté dès que son self-service a tenu). Le pattern : vous n'automatisez rien avant d'avoir compris ce que vous automatisez. La phase n'excuse pas non plus l'absence de produit. Pebble assemblait ses montres à la main, mais Pebble avait un produit. Stripe installait les comptes merchant à la main, mais Stripe avait une API.
Pourquoi votre startup en dépend : trois raisons
1. Vous n'avez pas encore de croissance organique. Personne ne vient.
Au lancement, votre courbe de signups ressemble à un trait plat, parce que personne ne vous connaît. Le "build it and they will come" n'a jamais fonctionné en dehors d'un film de Kevin Costner. Il faut aller chercher les dix premiers users à la main. Puis les cent suivants. Tant que vous n'avez pas atteint votre product market fit, vous allez chercher chaque utilisateur vous-même.
2. Le manuel est de la recherche utilisateur déguisée
Tant que vous codez en isolation, vous projetez. Vous imaginez les frustrations de vos users. Dès que vous installez le produit chez un client à la main, vous voyez où ça coince, quels mots il utilise, ce qu'il loupe. Vous n'obtenez cette information ni dans un dashboard ni dans un questionnaire à 50 questions ; vous l'obtenez en regardant quelqu'un cliquer.
3. Votre startup est fragile, et pour peu de temps
Paul Graham l'écrit noir sur blanc : "Almost all startups are fragile initially." La fenêtre se referme vite. Les semaines que Chesky et Gebbia ont passées à New York à photographier les annonces séparent Airbnb d'un projet enterré dans le cimetière des startups YC.
Les 5 tactiques canoniques (taxonomie Inari et essai PG)
Frank Cretella, fondateur d'Inari (YC S23), a compilé en open-source 86 cas de startups ayant fait des choses qui ne passent pas à l'échelle, et les a classés. En croisant sa taxonomie avec les sept patterns identifiés par Paul Graham, on obtient cinq familles canoniques.
1. Recruter manuellement (pattern PG « Recruit »)
Toutes les startups y passent. La seule question : jusqu'à quel niveau d'inconfort vous descendez.
DoorDash est le cas d'école. Tony Xu et ses co-fondateurs, à Stanford, ont créé en un après-midi une landing page intitulée PaloAltoDelivery.com. Ils y ont collé des PDF de menus trouvés en ligne et leur numéro de portable au bas de la page. Quand le téléphone a sonné pour une commande de Thai food, ils ont sauté dans leur voiture. Avant ça, ils avaient parlé à 150 à 200 propriétaires de petits commerces pour valider le problème (source : Sam Altman, Startup Class lecture 8).
Stripe : Patrick et John Collison installaient eux-mêmes Stripe sur les laptops des premiers merchants. Aucun bouton d'inscription, aucun dashboard self-service. Paul Graham appelle ça la "Collison installation", devenue une expression interne YC.
Levels.fyi a poussé le manuel jusqu'à un endroit improbable : leur version initiale n'avait pas de backend. Toute l'infrastructure tournait sur des Google Sheets.
2. Aller physiquement au-devant de vos users (pattern Inari « Go directly »)
Vous pouvez attendre que vos users viennent à vous. Ils ne viendront pas. Bougez.
Tinder est le cas le plus emblématique. Alexa Mateen Abdi, sur l'équipe fondatrice, a fait le tour des sororities et fraternités de USC, microphone à la main, parfois debout sur un piano dans une frat house. Elle a ensuite codifié la méthode en "Tinder University Program" pour la répliquer : SMU, UT Austin, UCLA. Chaque campus, un humain qui débarque, fait une démo, et compte les downloads en temps réel.
Pinterest organisait des design meetups dans la baie. Etsy allait dans les crafts fairs. Bumble a copié Tinder dans les lecture halls. Le pattern : aller là où votre audience se rassemble déjà, plutôt que de l'agréger par de la publicité payante.
3. Livrer au-delà de la demande (personnaliser jusqu'à l'absurde) (pattern Inari « Insanely delightful »)
Personne n'oublie un service excessif. Et "excessif" est le mot.
Substack faisait un onboarding 1-to-1 manuel avec chaque writer qui ouvrait un compte. Un humain, en visio, qui montre comment configurer une newsletter.
Algolia DocSearch : l'équipe configurait elle-même la recherche pour chaque open-source project demandeur. À la main. Pour chaque projet. Algolia est devenu le standard de facto pour la doc tech.
HyperSpectral, à 3,5 M$ ARR, maintient encore aujourd'hui un onboarding white glove. Le CEO Matt Theurer le revendique : "We still do a lot of white glove service. We'll set up the account for them, help them write their questions, train their team." Sur le papier, ça ruine les marges unitaires. En réalité, les retours qui en sortent nourrissent toute la roadmap produit, et l'équipe y voit son avantage compétitif.
4. Demander de l'aide et des recommandations (pattern Inari « Ask for help »)
Lyft a basé sa croissance initiale sur du parrainage pur : "shares with friends", code parrain, bonus monétaire des deux côtés. Sans ça, pas de masse critique de chauffeurs. Derek Sivers (CD Baby) a personnellement répondu à 6 000 emails en 10 jours au lancement, lui-même, sans répondeur automatique ni assistant, chaque mail.
5. Faire à la main ce qu'on automatisera plus tard (patterns PG « Manual » + « Consult »)
Tactique la plus mal comprise : elle ressemble à une faiblesse alors que c'est une stratégie.
Stripe, encore. Aux débuts, Stripe affichait "instant merchant accounts". La réalité : les fondateurs configuraient manuellement les comptes chez les processeurs traditionnels en arrière-plan. L'utilisateur voyait du software. C'était un humain.
Pebble : avant son Kickstarter à 10 millions de dollars, Eric Migicovsky et son équipe ont assemblé les premières centaines de montres à la main. Dans un garage. Paul Graham raconte qu'Eric en a tiré une leçon inattendue : "how valuable it was to source good screws." Personne n'aurait deviné ça depuis un Gantt chart.
Meraki (l'origine du verbe YC "to pull a Meraki") montait ses routeurs à la main avant que Cisco ne la rachète pour 1,2 milliard de dollars.
Viaweb, la startup de Paul Graham : quand des merchants refusaient de faire leur boutique avec Viaweb, l'équipe répondait "OK on la fait pour vous". PG admet qu'ils se sentaient minables ("we felt pretty lame at the time") à vendre des bagages et des chemises pour le compte d'autres. Viaweb y a gagné la sensibilité produit qui a mené au rachat par Yahoo en 1998.
Pandora : leur recommandation musicale était initialement humaine. Une douzaine de musiciens écoutaient des chansons une par une, attribuaient un score, et Will Glaser, founding CTO, a écrit une macro Excel qui calculait la distance entre chaque chanson. Un an plus tard, l'équipe avait indexé 10 000 chansons, à la main.
Comment l'appliquer concrètement en 2026 (mode tutorial)
Recruter manuellement aujourd'hui
LinkedIn Sales Navigator pour identifier vos 100 premiers prospects par ICP. Apollo ou Clay pour enrichir les emails. Un séquencer (Lemlist, Smartlead, Instantly) pour envoyer trois touches personnalisées. Et surtout : un Loom de 90 secondes par prospect, avec son prénom à l'écran. C'est l'équivalent 2026 du door-to-door de Chesky. Coût marginal : 3 minutes par prospect.
Rejoindre vos users en 2026
Trois canaux. Les Discord et Slack qui regroupent votre ICP : vous ne pitchez pas, vous contribuez 60 jours, puis vous mentionnez ce que vous faites en passant. Reddit : r/SaaS, r/startups, r/marketing concentrent vos futurs early users, soyez utile avant d'être vendeur. Les meetups physiques : Lu.ma a remplacé Eventbrite côté événements tech, allez-y et ramenez vos cartes.
Livrer au-delà de la demande en 2026
Un Loom personnalisé par nouveau signup (J0). Un message Slack Connect ou WhatsApp à J+7. Un check-in en visio à J+30. Vous le faites tant que vous êtes en dessous de 100 users actifs. Au-delà, vous bricolez (Loom enregistré générique, mais avec un humain qui répond aux questions).
Manual / Wizard of Oz en 2026
Zapier + Airtable + Slack pour le routage. Notion API pour le storage. n8n si vous voulez self-host. Un humain dans la boucle au milieu, qui valide chaque action critique. C'est ce qu'on appelle un concierge MVP ou un Wizard of Oz. Le user voit une interface, derrière vous bossez, et vous tenez ainsi le temps de comprendre quoi automatiser.
Consult-to-product en 2026
Un seul design partner payant. Contrat de 8 semaines. Vous codez les features dans son contexte. Ce que vous apprenez devient votre roadmap. C'est un piège (voir section suivante) mais aussi le moyen le plus rapide de toucher le product-market fit en B2B vertical.
Cinq erreurs : d'« unscalable » à « irrécupérable »
Le sheet Inari liste les cas, l'essai PG donne les patterns. Restent les dérapages : cinq signaux que vous faites la mauvaise version du pattern.
Erreur 1. Vous facturez votre temps. Vous êtes devenus une agence.
Paul Graham écrit la phrase-clé : "Consulting is the canonical example of work that doesn't scale. But it's safe to do it so long as you're not being paid to." Dès que le client paye votre temps à l'heure, il achète votre temps. Il n'achète plus votre produit. Vous ne comprenez plus un user pour produire un feature. Vous répondez à une fiche de poste.
Erreur 2. Votre churn manuel est artificiellement bas.
Vous tenez vos users à bout de bras. À chaque incident, visio. À chaque ticket, feature codée dans la nuit. Le churn affiché reste bas tant que vous portez chaque compte ; sans l'effort founder, il grimperait. Vous mesurez votre effort, et non votre produit.
Erreur 3. Le founder time-to-value dépasse 1h par user.
Quand chaque user demande plus d'une heure de votre temps personnel pour devenir productif, et que vous en avez ne serait-ce qu'une douzaine à servir, vous avez perdu votre semaine de produit. Vous faites du manuel pour nourrir le produit, jamais pour le remplacer.
Erreur 4. Vos cas sont trop hétérogènes pour donner un produit.
Vous avez signé dix users, chacun utilise votre produit pour un cas complètement différent. Aucune feature commune émergente. C'est dix mini-projets de service. Pour faire émerger un pattern, il vous faut un ICP serré plutôt que dix ICPs payants pris au hasard.
Erreur 5. Vous repoussez l'automatisation par confort
Le manuel vous donne un retour chaud, gratifiant. Chaque conversation client vous nourrit. Si vous restez en manuel parce que vous aimez être en manuel, vous ne déciderez plus d'automatiser. C'est de l'addiction au retour client.
Quand arrêter ? La règle de Brian Chesky
Brian Chesky a formulé la règle la plus citée : "Do it until it hurts, then automate it away." Quatre signaux concrets que c'est le moment :
Signal 1. Votre LTV/CAC manuel a croisé votre LTV/CAC cible. Si chaque user manuel vous coûte cher en temps founder, ça paraît horrible. Mais si la rétention des comptes accompagnés à la main dépasse nettement celle du self-serve à trois ans, le calcul s'inverse. C'est le cas HyperSpectral à 3,5 M$ ARR.
Signal 2. Le founder retrouve du temps produit. Si vous recommencez à coder un nouveau feature, c'est que vous avez décroché du manuel. C'est ok, à condition d'avoir transmis le manuel à quelqu'un qui le fait avec la même intensité.
Signal 3. Le churn devient stochastique. Au début, vous comprenez chaque churn (vous étiez là). Au-delà d'un certain volume, vous perdez le contexte de chaque départ : c'est le signal pour mettre en place une analyse de churn.
Signal 4. Vous avez fait votre premier hire ops/CS. Vous avez décidé de payer quelqu'un pour faire ce que vous faisiez gratuitement. C'est le moment de découper le process en étapes formelles, sinon vous lui transmettez votre fatigue au lieu de votre méthode.
L'anti-pattern : passer du tout-manuel au tout-automatique d'un coup. Le pattern qui marche, c'est ce que Matt Theurer appelle le "manual co-pilot" : humain plus automation, où l'humain garde la part du travail qui apprend le plus. HyperSpectral à 3,5 M$ ARR garde une partie de son onboarding en manuel, et c'est un choix.
FAQ
Combien de temps doit durer la phase "unscalable" ?
Tant que vous apprenez plus à la main qu'avec un dashboard. HyperSpectral en fait encore à 3,5 M$ ARR. Le critère : tant que le manuel produit du signal produit, ne l'arrêtez pas.
Doing things that don't scale, ça marche aussi pour le B2B ?
Oui, et c'est même là que c'est le plus efficace. Paul Graham appelle ça le pattern "Consult". Vous prenez un seul design partner, vous codez le produit dans son contexte précis, et vous extrapolez. Une seule règle : ne vous faites pas payer à l'heure, sinon vous devenez une agence (cf. Erreur 1).
Et pour le hardware ?
Le pattern PG s'appelle "pulling a Meraki". Vous assemblez vos premières centaines d'unités à la main. Pebble a fait ça avant son Kickstarter à 10 millions de dollars. Avantage caché : vous pouvez itérer le design plus vite parce que vous êtes l'usine. Eric Migicovsky a découvert que la qualité des vis comptait. Ça ne se trouve pas dans un Gantt chart.
Comment on mesure l'efficacité d'une tactique unscalable ?
Avec d'autres mesures que les metrics business standards : (1) le nombre d'enseignements produit générés par semaine, (2) le temps founder par user actif, (3) le taux de conversion manuel contre self-serve quand vous testez en parallèle. Si le manuel ne produit pas plus d'enseignements que vos analytics, arrêtez.
Quel est l'essai original de Paul Graham ?
Paul Graham a publié l'essai Do Things that Don't Scale en juillet 2013 sur paulgraham.com. Il fait 4 346 mots et reste accessible à l'URL d'origine : https://www.paulgraham.com/ds.html. Y Combinator en publie une copie sur sa Startup Library.
Pour aller plus loin
L'essai original de Paul Graham : https://www.paulgraham.com/ds.html. La liste de 86 cas compilée par Frank Cretella (Inari, YC S23) : https://useinari.com/blog/the-definitive-list-of-startups-doing-things-that-didnt-scale. Le cas HyperSpectral détaillé sur Frontlines : https://www.frontlines.io/hyperspectrals-white-glove-onboarding-at-scale-when-things-that-dont-scale-actually-do/.
Si vous lancez et cherchez à structurer votre démarche, notre guide pour trouver une idée de startup prolonge cet article. Pour creuser le côté méthodo, la définition du lean startup explique pourquoi le manuel est en réalité de la recherche utilisateur déguisée. Et si vous en êtes à recruter votre premier CTO, notre guide CTO startup explique pourquoi le founder qui parle aux users vaut un CTO bien recruté.
