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 shooter les annonces. Les listings convertissent ×3 dans la semaine. 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, surdélivrer, mendier des referrals, faire à la main ce qu'on automatisera plus tard. Voici 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. Tout votre produit est censé scaler. Stack serverless, CRM SaaS, acquisition performance marketing. La première chose à faire, c'est l'inverse : du travail manuel, individuel, coûteux. Pas par nostalgie. Par nécessité.
Deux précisions sur ce que ce n'est pas. Ce n'est pas une stratégie pour toujours, c'est une phase. Parfois longue (HyperSpectral fait du white glove à 3,5 M$ ARR), parfois courte (six mois pour Stripe). Le pattern n'est pas "ne jamais automatiser", c'est "ne pas automatiser avant d'avoir compris ce qu'on automatise". Ce n'est pas non plus une excuse pour ne pas construire 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 (les 3 vraies raisons)
1. Vous n'avez pas encore de croissance organique. Personne ne vient.
Au lancement, votre courbe de signups ressemble à un trait plat. Pas parce que votre produit est mauvais. 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.
2. Vous ne savez pas ce qui marche. Le manuel = 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. Cette information ne s'obtient ni dans un dashboard ni dans un survey à 50 questions. Elle s'obtient en regardant quelqu'un cliquer.
3. Votre startup est fragile. Ces 30 jours peuvent tout changer.
Paul Graham l'écrit noir sur blanc : "Almost all startups are fragile initially." Cette fragilité a une date de péremption. Les 30 jours que Chesky et Gebbia ont passés à NYC à shooter les listings ont fait la différence entre Airbnb et un projet enterré dans le cimetière des startups YC.
Les 5 tactiques canoniques (taxonomie sheet useinari + essai PG)
Frank Cretella, fondateur d'Inari (YC S23), a compilé en open-source 86 cas de startups ayant fait des choses qui ne scalent pas, 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 question n'est pas "faut-il le faire ?" mais "à 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. Pas de "sign up here", pas de 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. Aujourd'hui le site fait 1 à 2 millions de visiteurs uniques par mois.
2. Aller physiquement là où sont 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 où votre audience est déjà rassemblée, plutôt que de l'agréger via du paid ads.
3. Surdélivrer (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. À 50 writers, c'est ce qui a tout changé.
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 détruit la unit economics. En réalité, le feedback loop qui en sort informe toute la roadmap produit. C'est leur avantage compétitif.
4. Demander de l'aide et des referrals (pattern Inari « Ask for help »)
Personne ne le fait. C'est pour ça que ça marche.
Lyft a basé sa croissance initiale sur du referral 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. Pas un autoresponder. Pas un VA. Lui. Chaque mail. Devinez combien d'entre eux ont parlé de CD Baby à leur entourage.
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 d'être racheté par Cisco 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. C'est ce qui a donné à Viaweb la sensibilité produit qui a permis le 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, 10 000 chansons étaient indexées. À 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. ROI : un taux de réponse qui passe de 2 % à 25 %.
Aller où sont vos users en 2026
Trois canaux. Premièrement, Discord et Slack qui regroupent votre ICP. Vous ne pitchez pas. Vous contribuez 60 jours, puis vous mentionnez ce que vous faites en passant. Deuxièmement, Reddit. r/SaaS, r/startups, r/marketing concentrent vos futurs early users. Soyez utile avant d'être vendeur. Troisièmement, les meetups physiques. Lu.ma a remplacé Eventbrite côté events tech founder. Allez-y. Ramenez vos cartes.
Surdélivrer 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. Le temps de comprendre quoi automatiser, c'est exactement ce qu'il faut.
Consult-to-product en 2026
Un seul design partner payant. Contrat de 8 semaines. Vous codez les features dans son contexte. Les learnings deviennent 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.
Les 5 erreurs qui transforment "unscalable" en "irrécupérable"
Le sheet Inari liste les cas. L'essai PG donne les patterns. Aucune source ne couvre 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. Churn affiché : 1 %. Vrai churn sans l'effort founder : 30 %. Vous mesurez votre cargo cult, pas 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. Le manuel informe le produit. Il ne le remplace pas.
Erreur 4. Vos cas sont trop hétérogènes pour être productisés.
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 faut un ICP serré, pas dix ICPs payants au hasard.
Erreur 5. Vous repoussez l'automatisation par confort, pas par stratégie.
Le manuel donne un feedback 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 l'addiction au feedback, pas la stratégie.
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 coûte 5 000 $ en temps founder et paie 10 000 $/an, ça paraît horrible. Mais si la rétention manuelle vous donne 95 % à 36 mois contre 60 % en self-serve, la math se renverse. C'est le cas HyperSpectral à 3,5 M$ ARR.
Signal 2. Le founder n'a plus zéro heure pour le 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, plus le contexte de chaque départ. Signal pour mettre en place une vraie analyse.
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, pas 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 reste sur les 10 % qui produisent 90 % de l'insight. HyperSpectral à 3,5 M$ ARR garde une partie de son onboarding en manuel, par stratégie, pas par défaut.
FAQ
Combien de temps doit durer la phase "unscalable" ?
Tant que vous apprenez plus à la main qu'avec un dashboard. En pratique : entre 6 mois (consumer SaaS rapide) et 3-5 ans (B2B vertical). Stripe a fait sa Collison installation pendant environ 18 mois. 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. La règle d'or : ne pas se faire 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 ?
Pas avec des metrics business standards. Vous mesurez : (1) le nombre d'insights produit générés par semaine, (2) le temps founder par user actif, (3) le taux de conversion manuel vs self-serve quand vous testez en parallèle. Si le manuel ne produit pas plus d'insights que vos analytics, arrêtez.
Quel est l'essai original de Paul Graham ?
L'essai Do Things that Don't Scale a été publié 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é.
