Construire un produit SaaS en 90 jours : étroit, honnête, livré

Un produit SaaS en 90 jours, ce n'est pas une promesse marketing, c'est une discipline. Le délai force des décisions qui prendraient sinon des mois. Trois jours de débat sur le pricing deviennent trois heures. Un atelier roadmap de quatre semaines devient quatre jours. Ce qui ne rentre pas est coupé. Ce n'est pas un manque, c'est du focus.

Le plus dur, ce n'est pas le plan, c'est la coupe. Shape Up de 37signals décrit le même pattern : des cycles courts et fixes qui forcent de vraies décisions, pas de longs sprints qui promettent tout.

Ce que tu retiens :

• La coupe des 90 jours : ce qui reste dedans, ce qui reste dehors.
• L'équipe : trois personnes plus des agents.
• La logique hebdomadaire : ce qui doit être livré aux semaines 4, 8 et 12.
• Les illusions qui transforment 90 jours en neuf mois.

La thèse

Tu construis un produit SaaS en 90 jours en coupant le problème étroit, avec une équipe de trois plus des agents IA, et en livrant par blocs hebdomadaires fixes. Pas tout ce que tu veux, mais la partie pour laquelle les gens paient.

Qu'est-ce qui doit passer la coupe des 90 jours?

Quatre choses doivent passer la coupe : un problème clairement délimité, un setup de pilote payant, la fonction minimale qui résout le problème, et un onboarding qui fonctionne sans call. Tout le reste, c'est la phase deux. La phase deux commence au jour 91.

Concrètement : pas "on construit une plateforme de marketing automation", mais "on résout la friction récurrente du forecast de pipeline entre marketing et vente pour les équipes mid-market du DACH". Plus la coupe est étroite, plus le build est réaliste.

Le pilote payant est le plus important des 4 points. Il te force à poser la question du pricing avant le build, pas après. Celui qui ne veut pas payer de forfait pilote n'achètera pas de licence plus tard. Comment affûter la coupe avec des mots, c'est dans le positionnement produit pour le B2B.

À quoi ressemble l'équipe?

Trois personnes : le décideur produit (fondateur), l'engineering lead, un designer avec des compétences frontend. Plus quatre à six rôles d'agents : rédacteur de specs, QA, rédacteur de release notes, synthétiseur d'interviews clients, opérateur d'assets marketing. Pas de SDR, pas d'account management, pas de chef de projet.

Ce n'est pas une variante réduite d'une équipe enterprise. C'est la forme naturelle quand des agents IA portent les tâches routinières. Trois au lieu de trente, ce n'est pas un slogan, c'est la question de savoir quelles tâches restent.

Les rôles d'agents ne sont pas de la décoration. Le rédacteur de specs transforme chaque interview en ticket testable. L'agent QA vérifie chaque build avant qu'un humain le regarde. Comment cette façon de travailler s'assemble, je le montre dans From Vibe Coding to Agentic Engineering.

Comment s'articule la logique hebdomadaire?

Tu travailles en trois blocs de 30 jours : discovery, build, activate. La discovery (semaines 1 à 4) clarifie le problème, l'ICP et le pricing avec 10 à 15 interviews. Le build (semaines 5 à 8) livre la fonction minimale plus l'onboarding. L'activate (semaines 9 à 12) décroche 3 à 5 pilotes payants et une release honnête.

Démo courte chaque vendredi, décision sur la coupe toutes les deux semaines. Si tu ne peux pas faire de démo le vendredi, c'est que tu as mal coupé le lundi.

Les interviews de discovery ne sont pas une formalité. Elles produisent l'ICP, le profil client idéal : les entreprises où le problème coûte le plus cher. Sans ce profil, tu construis pour tout le monde dès la semaine 5, donc pour personne. Avec, tu sais exactement qui appeler en semaine 9.

Quelles sont les illusions les plus fréquentes?

Trois reviennent. Un : "il nous faut une bêta avec cent utilisateurs". Faux, il te faut trois utilisateurs payants avec un vrai problème. Deux : "on le construit nous-mêmes, moins cher que d'acheter un outil". Rarement vrai en 90 jours. Trois : "on doit d'abord s'aligner sur le branding". Le branding vient du shipping, pas d'un atelier.

Qu'est-ce qui n'a PAS sa place dans les 90 premiers jours?

Hors scope : le SSO, les intégrations pour des logos que tu n'as pas, les admin panels, le deuxième persona, les concepts de rôles et de permissions, et tout ce qui porte l'étiquette "enterprise-ready". Rien de tout ça ne te gagne le premier pilote payant. Tout ça mange des semaines.

Le SSO est le meilleur exemple. Le single sign-on sonne obligatoire. En vérité, il répond à un service achats à qui tu ne parles même pas encore. Construis-le quand un client payant en fait une condition. Avant ça, c'est de la procrastination avec bonne conscience.

Pareil pour les intégrations. Une intégration par pilote réel, ça se défend. 5 intégrations pour des logos sur une liste de souhaits, c'est 4 de trop. Et un admin panel pour 3 clients pilotes se remplace par un accès à la base de données et une heure de travail manuel par semaine.

Le poste le plus cher, c'est le deuxième persona, un deuxième rôle utilisateur avec ses propres besoins. Il double tout en silence : deuxième onboarding, deuxième logique de pricing, deuxième roadmap. Un persona, un problème, un prix. Le reste, c'est le jour 91.

D'où viennent les premiers pilotes payants?

De ton réseau, pas de la pub et pas de l'outbound, c'est-à-dire l'approche à froid d'inconnus. Les premiers clients sont des design partners : des entreprises qui connaissent le problème, te font confiance et paient pour ça. Petit en montant, sérieux en engagement.

Mark Roberge, premier patron des ventes de HubSpot, décrit ça comme une phase à part entière dans The Science of Scaling. Selon Roberge, les premiers clients viennent du réseau personnel et des recommandations. L'objectif de cette phase, c'est l'apprentissage, pas le revenu.

Son deuxième point est inconfortable : fixe le prix pour l'engagement, pas pour le profit. Le gratuit attire les non-engagés, dit Roberge. Un forfait symbolique bat le gratuit, parce que seule une facture force un oui ou un non honnête. Un pilote qui ne coûte rien ne livre aucun signal.

Comme premier objectif d'apprentissage, Roberge cite environ 20 clients. C'est plus que ce qui rentre dans 90 jours, et ce n'est pas grave. Les 3 à 5 pilotes du bloc activate sont le début de cette courbe d'apprentissage, pas sa fin. L'expérience de Roberge vient du SaaS américain. Comme point de repère, elle fonctionne quand même, aussi dans le DACH.

La comparaison dure : 90 jours contre 9 mois

Un projet de neuf mois avec douze personnes coûte en Suisse entre CHF 800'000 et 1'500'000 environ, selon la séniorité. Un projet de 90 jours avec trois personnes plus des agents coûte une fraction de ça et répond tôt à la question centrale : est-ce que quelqu'un paiera pour ça? Si non, tu économises huit mois. Si oui, tu as huit mois d'avance.

Ce n'est pas de la spéculation. CB Insights liste "no market need" comme la raison la plus fréquente d'échec des startups. Une coupe de 90 jours teste exactement cette question avant que ça devienne cher.

Jour 91 : quelle base vient ensuite?

La deuxième : le product-market fit, PMF en abrégé, la preuve que les clients paient et restent. Stijn Hendrikse décrit le chemin dans T2D3 comme un tour des bases : première base le MVP, la première version vendable, deuxième base le PMF, troisième base le scaling. Et tu ne peux pas sauter de base.

Saute quand même et, selon Hendrikse, tu devras revenir en arrière et réparer. Ça colle avec ce que je vois. Une équipe qui scale la vente au jour 91 scale généralement un produit que personne ne veut encore garder. Les 90 jours t'amènent à la première base. Pas plus loin, mais honnêtement.

Hendrikse rend le PMF mesurable avec une checklist de 10 jalons. Les 3 derniers sont les plus durs : 10 clients payants, 10 témoignages publics de clients payants, 10 nouveaux clients payants par recommandation. Alors seulement, dit-il, le PMF est atteint. C'est la ligne d'arrivée honnête après les 90 jours.

Ses jalons viennent de sa propre expérience avec ses clients, ce ne sont pas des lois de la nature. Mais comme checklist, ils sont utiles, justement parce qu'ils sont inconfortables. Ils t'empêchent de confondre "on a lancé" avec "on a un business". Plus de savoir-faire pour cette phase dans le hub software product management.

Outro

✅ Ce qui marche. Coupe étroite plus petite équipe plus deadline fixe, et ça livre. Chaque fois que la discipline tient.

❌ Ce qui ne marche pas. Vouloir caser chaque souhait de stakeholder dans 90 jours. C'est la phase deux, pas la phase une.

⚠️ Attention. "On prolonge juste de deux semaines", c'est le début des neuf mois. Coupe avant de prolonger.

Le point plus profond : une coupe de 90 jours n'est pas un truc de vitesse, c'est un truc de vérité. La deadline force les décisions que tu ne prendrais jamais sans elle. C'est là qu'on a commencé : couper au lieu de construire.

Si tu veux voir à quoi ressemble un plan de 90 jours en détail, lis notre process.

Questions fréquentes

Trois personnes peuvent vraiment y arriver?

Oui, quand la coupe est étroite et que les agents portent les tâches routinières. Ajouter des gens en 90 jours n'aide pas, ça ralentit les décisions.

Et si le problème est plus gros?

Alors tu coupes. Un problème plus gros peut presque toujours être découpé en un sous-problème payant plus petit. Sinon, ce n'est pas un problème SaaS.

Combien ça coûte?

En Suisse, environ CHF 150'000 à 350'000 pour 90 jours avec trois personnes plus un stack d'agents. Une fraction d'un projet classique.

Et si au jour 90 il n'y a pas de pilote?

Alors la discovery était fausse. Arrête, note honnêtement ce que tu as appris, et décide consciemment si tu finances la phase deux.

Quand un setup plus grand se justifie-t-il?

Quand trois pilotes payants confirment la demande et que le goulot d'étranglement est manifestement la capacité d'engineering, pas les décisions. Avant ça, plus de headcount accélère le mauvais chemin.