Développement SaaS rapide : livrer en 7 jours, la méthode
Livrer un SaaS fonctionnel en 7 jours n'est pas un exploit sportif. C'est la conséquence mécanique de trois choix faits avant d'écrire la première ligne de code : un périmètre verrouillé sur une page, une stack unique maîtrisée par cœur, et des templates déjà éprouvés en production. Quand ces trois conditions sont réunies, les sept jours servent à construire. Quand elles manquent, les mêmes sept jours se dissolvent en réunions et en choix techniques. Voici la méthode, et ses limites assumées.
Où passent les mois d'un projet classique
Regardez le calendrier d'un projet de trois mois : le temps de développement effectif y occupe rarement la moitié. Le reste se répartit entre le cadrage qui s'éternise, les choix techniques rediscutés à chaque sprint, les points hebdomadaires qui mobilisent cinq personnes pour en faire avancer une, et l'attente — attente d'une validation, d'une maquette, d'un accès, d'une réponse.
Aucun de ces postes n'est du travail de construction. Ce sont des coûts de coordination et d'indécision. La compression d'un délai ne consiste donc pas à coder plus vite, mais à supprimer ce qui n'est pas du code. C'est une discipline d'organisation, pas une prouesse technique.
Ce constat n'accuse personne. La coordination est le coût normal d'une équipe nombreuse sur un périmètre mouvant. Mais quand le périmètre est petit et stable, garder la même machinerie revient à payer l'organisation d'un chantier d'immeuble pour monter une cuisine.
Condition 1 : un brief d'une page, verrouillé
Tout commence par un périmètre fermé avant le premier jour. Un brief d'une page suffit s'il répond à quatre questions : qui sont les utilisateurs, quel est le workflow principal, quelles données entrent et sortent, quelles intégrations sont nécessaires. Ce document est signé, au sens propre. Ce qui n'y figure pas n'est pas dans la livraison.
Ce verrou paraît rigide. Il est en réalité protecteur, pour les deux parties : le client sait exactement ce qu'il paie, le développeur ne découvre pas de « petite fonctionnalité en plus » au jour 5. Les idées qui émergent en cours de route — il y en a toujours — sont notées pour une itération suivante, chiffrée séparément, au lieu de faire dériver le délai en silence.
Écrire ce brief prend une à deux heures de votre côté, pas des semaines. La difficulté n'est pas rédactionnelle : elle consiste à choisir, donc à renoncer. Un bon prestataire vous aide à couper — c'est même un signal de sérieux quand il refuse d'ajouter.
Condition 2 : une stack unique, jamais rediscutée
Le deuxième gisement de temps est le choix technique. Chaque décision d'architecture prise en cours de projet coûte des heures de comparaison, puis des heures d'apprentissage. La parade est radicale : la même stack sur tous les projets, sans exception. Chez Épure, par exemple, c'est Next.js, Supabase, Stripe et Claude — imposés, non négociables, précisément parce que c'est cette contrainte qui rend le délai de 7 jours tenable.
Une stack unique change la nature du travail. Les problèmes d'authentification, de paiement, de déploiement ont déjà été résolus dix fois ; les pièges sont connus, les patterns posés. Le développeur ne défriche pas, il assemble et adapte. C'est exactement ce qu'un client achète quand il achète un délai court.
Condition 3 : des templates éprouvés et zéro réunion
Troisième pilier : ne jamais repartir d'une page blanche. L'authentification, la facturation, le tableau de bord, les emails transactionnels — ces fondations sont identiques d'un SaaS à l'autre. Des templates testés en production en couvrent l'essentiel dès le premier jour, et le temps se concentre sur ce qui est réellement spécifique au métier du client.
Reste la coordination. Le format qui fonctionne :
- Un seul appel de cadrage au lancement, une demi-heure, pas de point hebdomadaire.
- Tout le reste en asynchrone : messages écrits, captures vidéo courtes pour montrer l'avancement, tickets visibles par le client.
- Des livraisons visibles chaque jour sur une URL de test, plutôt qu'une démo théâtrale au dernier jour.
Sept jours sans réunion produisent plus que dix jours hachés. La transparence remplace le reporting : le client regarde l'avancement quand il veut, au lieu d'attendre qu'on le lui raconte.
Ce que 7 jours excluent, honnêtement
Ce modèle a un domaine de validité, et il faut le dire clairement. Sept jours ne suffisent pas pour un produit grand public à fort trafic, une marketplace à deux faces, un système temps réel complexe, ou un secteur à conformité lourde. Ils n'incluent pas non plus la découverte produit : si vous ne savez pas encore ce que vos utilisateurs veulent, c'est une phase de recherche qu'il vous faut, pas un sprint de construction.
Méfiez-vous enfin des promesses de vitesse sans cadre : un « MVP en une semaine » sans périmètre écrit ni pénalité de retard n'engage que vous. La vitesse honnête se reconnaît à ses conditions affichées — ce qu'elle inclut, ce qu'elle exclut, ce qu'elle coûte à celui qui la promet s'il échoue.
Le délai court livre une version 1 solide d'un périmètre standard : le produit qui permet de vendre, d'opérer, de tester en conditions réelles. La version 2 se nourrit ensuite de l'usage constaté — et c'est précisément parce que la V1 arrive en semaine 1 plutôt qu'en mois 4 que cet apprentissage commence tôt. Un délai contractuel avec pénalité écrite — 5 % par jour de retard chez Épure — garantit que la promesse de vitesse engage celui qui la fait, pas celui qui la croit. Le détail du modèle est sur la page méthode.