Vous annoncez une app. Créez une page. Collectez des adresses e-mail. Promettez quelque chose d’enthousiasmant.
Pendant ce temps, quelqu’un voit la même occasion, ouvre un agent de programmation et se met au travail.
Quand vous envoyez votre message « On y est presque », vos clients potentiels utilisent peut-être déjà autre chose.
Voilà ce qui me gêne dans les listes d’attente à l’ère du développement avec des agents. Le délai entre l’idée et une version utile a changé. Je suis moins convaincu que les conseils de lancement aient suivi.
Si vous pouvez offrir quelque chose d’utile aujourd’hui, pourquoi demander de revenir plus tard ?
L’ancienne méthode avait sa raison d’être
Quand créer un produit exigeait des mois d’ingénierie, une liste permettait d’exploiter l’intérêt initial : tester les messages, recruter des utilisateurs bêta et rassembler un public pendant le développement.
Linear et Superhuman sont des exemples connus. Linear sélectionnait des utilisateurs sur une liste et améliorait le produit par petits groupes. Superhuman investissait beaucoup dans l’accompagnement individuel. Les deux approches permettaient d’apprendre auprès des clients.
Mais ces stratégies précèdent les agents de programmation actuels. Elles expliquent l’origine de la méthode. Elles ne prouvent pas que les mêmes compromis restent pertinents.
Quand livrer une expérience fonctionnelle coûte moins cher, recueillir seulement des manifestations d’intérêt devient moins facile à justifier.
Une adresse e-mail signifie qu’une promesse a plu assez pour remplir un formulaire. Une personne qui utilise votre app peut montrer où cette promesse se brise.
Vous donnez aussi du temps aux concurrents
Une liste publique annonce une occasion avant que vous ayez nécessairement gagné un client.
Cela compte surtout si les fonctions principales sont relativement faciles à reproduire. L’annonce décrit le problème, la démo esquisse la solution et le nombre d’inscrits signale l’intérêt.
Un concurrent n’a pas besoin de reproduire toute votre feuille de route. Il lui suffit de résoudre assez du problème pour devenir utile avant vous.
C’est un risque concurrentiel, pas une loi établie. Je n’ai pas trouvé de recherche démontrant que les listes font régulièrement perdre leur marché aux startups. Sortir le premier ne garantit pas non plus de gagner.
Mais prolonger volontairement le délai entre « Je le veux » et « Je peux l’utiliser » mérite d’être interrogé.
Le problème du client existe maintenant. Le calendrier de lancement vous appartient.
Que disent les exemples récents ?
Dans son bilan, Lovable décrit deux lancements ratés en 2024, l’admission progressive depuis une liste et une IA qui se bloquait trop souvent. L’entreprise attribue son décollage aux améliorations du produit, au changement de marque et à une meilleure communication. La liste existait avant ; elle n’a pas suffi.
Manus complique l’idée que les lancements restreints seraient morts. Les tests sur invitation ont commencé en mars 2025 ; l’entreprise a ensuite annoncé 100 millions de dollars de revenus récurrents annuels. Cela établit un succès commercial après un lancement restreint. Cela ne prouve ni que la restriction l’a causé, ni qu’ouvrir plus tôt aurait moins bien fonctionné.
Appliquons le même critère dans les deux sens. Une entreprise prospère ayant utilisé une liste ne prouve pas son efficacité. Une entreprise qui échoue ne prouve pas que sa liste était le problème.
Inviter dans un produit est différent
Recueillir de l’intérêt pour une idée et contrôler l’accès à un produit déjà utilisé sont deux choses différentes.
Instinct illustre le modèle d’invitation : sa page publique propose un lien pour inviter un ami. Cela n’explique pas pourquoi l’entreprise limite l’accès, mais suggère une autre interaction : un utilisateur peut faire entrer quelqu’un dans l’expérience.
Cela me paraît plus crédible quand l’invitation mène à un produit fonctionnel.
Il existe des contraintes raisonnables. Vous ne pouvez peut-être accompagner que quelques nouveaux clients par semaine. Les agents peuvent coûter cher à exploiter. Il faut parfois observer les défaillances avant d’accueillir davantage de monde.
Les invitations peuvent aussi fabriquer de la rareté. Le mécanisme ne tranche pas la question. La raison de la restriction, oui.
La meilleure défense : trouver des clients demande toujours du travail
Développer plus vite ne crée pas automatiquement un canal d’acquisition.
Un témoignage récent l’illustre. Le fondateur de Hado SEO déclare avoir recueilli 80 adresses, puis converti cinq inscrits en clients payants pendant la semaine du lancement. Avant cela, il aidait des clients potentiels dans des communautés et affinait son offre. Ce sont des résultats autodéclarés, mais ils portent sur la conversion plutôt que sur un gros total d’inscriptions.
C’est un argument valable pour une courte préparation : découvrir où les clients se retrouvent, comment ils décrivent leur problème et si vous pouvez les atteindre.
Une question reste pourtant ouverte : apprendriez-vous davantage en leur proposant un petit produit fonctionnel ?
À mesure que le développement accélère, cette possibilité devient plus réaliste.
L’attente doit se justifier
Je me méfie des listes dont le principal objectif est de rendre désirable une app encore indisponible.
Une liste utile devrait correspondre à quelque chose de concret : une capacité limitée, une expérience avec des clients, une dépendance ou une limite du produit que vous corrigez. Il faut une raison d’attendre et une condition d’admission.
« Créer de l’engouement » est une réponse beaucoup plus faible.
Avant d’ajouter ce formulaire, demandez-vous ce que vous pourriez livrer. Un processus. Une fonction utile. Une version limitée qui fait bien une chose.
Vous pourrez alors mesurer si les gens l’utilisent, reviennent et s’intéressent aux améliorations.
Si quelqu’un peut livrer une version utile de votre idée avant que vous ayez fini de susciter l’attente, qu’attendez-vous exactement ?