Quinze jours. C'est le délai dans lequel nous nous engageons à livrer un MVP fonctionnel à nos clients. Pas un prototype Figma, pas une démo cliquable : un produit en ligne, hébergé, utilisable par de vrais utilisateurs. Cet article démontre comment c'est possible — et surtout, pourquoi ça ne sacrifie ni la qualité ni l'évolutivité.
Le mythe qu'il faut casser : « Vite = bâclé »
Depuis vingt ans, l'industrie du développement web a gravé dans le marbre une idée fausse : un projet qualitatif demande du temps. Beaucoup de temps. Six mois minimum, dit-on. Un an, plus prudemment. Trois ans pour un projet « sérieux ».
Cette croyance arrange tout le monde — sauf le client. Elle arrange les agences qui facturent au temps passé. Elle arrange les développeurs qui peuvent gold-plater sans rendre de comptes. Elle rassure les directions qui confondent durée et rigueur.
La réalité, c'est que la qualité d'un produit digital ne dépend ni de sa durée de fabrication, ni de la taille de l'équipe. Elle dépend de trois choses : la clarté du périmètre, la rigueur de l'exécution, et la capacité à dire non aux fonctionnalités inutiles. Aucune de ces trois choses n'a besoin de temps. Elles ont besoin de discipline.
Ce que veut dire « MVP » — et ce que ça ne veut PAS dire
Un MVP, c'est un Minimum Viable Product. Trois mots, dont un piège : « minimum ». Beaucoup d'agences l'interprètent comme « le moins possible ». C'est une erreur stratégique. Le minimum, ce n'est pas l'absence de fonctionnalités. C'est l'absence de fonctionnalités qui n'apportent pas de valeur immédiate.
Pour HWS, un MVP livré en 15 jours doit cocher trois cases :
- Viable : un vrai utilisateur peut l'utiliser pour résoudre un vrai problème, sans bug bloquant.
- Mesurable : on peut tracker l'usage, lire des métriques, mesurer le ROI dès la première semaine.
- Évolutif : l'architecture pose les fondations pour les 18 prochains mois — pas un château de cartes à refaire.
Ce que ce n'est pas : un prototype, une maquette, un site vitrine déguisé. Quand on parle de MVP, on parle d'un logiciel ou d'une plateforme métier, pas d'une page d'atterrissage.
La méthode HWS, jour par jour
Pour tenir les 15 jours, nous suivons un séquencement précis. Ce n'est pas une promesse marketing : c'est un process opérationnel, écrit, partagé avec le client, mesuré à la sortie.
Jours 1 à 3 — Cadrage et architecture
Trois jours d'atelier intensif avec le client. Pas de devis vague, pas de cahier des charges de cinquante pages. Un seul livrable : un document de cadrage de quatre pages qui répond à quatre questions :
- Quel est le problème métier précis qu'on résout ?
- Qui sont les trois personas utilisateurs (pas plus) ?
- Quelles sont les cinq fonctionnalités cœur indispensables au lancement ?
- Comment mesurer le succès dans 30 jours ?
En parallèle, nous arrêtons l'architecture technique : choix du framework, base de données, hébergement, services tiers. Ces décisions sont prises une fois, puis figées. Aucune remise en question pendant les 12 jours suivants.
Jours 4 à 6 — Design
Trois jours pour produire les écrans clés en Figma, validés par le client à la fin du jour 6. Pas de Design System exhaustif : juste les composants nécessaires aux fonctionnalités du MVP. Le reste sera créé au fil de l'eau lors des itérations post-lancement.
Notre règle : un seul aller-retour client par écran. Pas trois, pas cinq. Cela impose une discipline d'écoute en amont, mais évite l'effet « ping-pong » qui fait dériver les projets.
Jours 7 à 12 — Build
Six jours de développement en sprint serré. Un chef de projet, deux développeurs, une checklist quotidienne. Chaque soir, une démo interne. Chaque deux jours, une démo client.
Notre stack par défaut : Next.js + TypeScript + base PostgreSQL + déploiement Vercel ou Scaleway selon les contraintes RGPD. Cette stack n'est pas négociable. Pourquoi ? Parce qu'à chaque projet où on l'a remise en cause, on a perdu 4 à 7 jours en setup. Quinze jours ne pardonnent pas ce gaspillage.
Jours 13 et 14 — Tests et polish
Deux jours dédiés à : QA fonctionnelle, tests d'accessibilité (au minimum WCAG 2.1 AA), audit de sécurité, optimisation des Core Web Vitals, et configuration des analytics. C'est aussi le moment de la dernière passe UI : micro-animations, états de chargement, messages d'erreur clairs.
Beaucoup d'agences sautent cette étape pour gagner du temps. Nous la considérons comme la plus importante des 15 jours. Un produit livré sans tests est un produit livré buggé.
Jour 15 — Mise en ligne
Déploiement en production le matin, formation client l'après-midi, monitoring activé en soirée. Le lendemain, le client peut envoyer ses premiers utilisateurs.
Les quatre non-négociables qui garantissent la qualité
Tenir 15 jours n'est pas la fin en soi. La vraie question est : comment éviter que la rapidité ne dégrade le code, l'expérience, ou la maintenabilité ? Quatre règles internes :
- Code review systématique. Aucun commit ne part en production sans relecture par un second développeur. Aucune exception, même pour un fix mineur.
- Tests automatisés sur les flux critiques. Les fonctionnalités cœur — authentification, paiement, formulaire de contact, dashboard principal — sont couvertes par des tests end-to-end dès le jour 12.
- Documentation technique vivante. Le README du dépôt explique l'architecture, les variables d'environnement et les procédures de déploiement. Si quelqu'un d'extérieur reprend le projet dans six mois, il doit pouvoir le faire en moins de deux heures.
- Backup et plan de reprise. Sauvegarde quotidienne automatisée, procédure de rollback documentée, monitoring d'uptime configuré dès le jour 14.
Trois pièges qu'on évite (et qui font dérailler la plupart des projets MVP)
Piège n°1 : le scope creep
« Et si on ajoutait juste cette petite fonction ? » C'est la phrase qui tue les MVP. Notre parade : à partir du jour 4, toute nouvelle demande va dans une liste « v2 ». Aucune exception, même si le client insiste. Nous l'avons appris à nos dépens.
Piège n°2 : le perfectionnisme prématuré
Une équipe technique a tendance à vouloir résoudre tous les problèmes maintenant : optimiser les performances avant d'avoir des utilisateurs, anticiper la scalabilité avant le premier client payant, refactoriser avant d'avoir mesuré. Nous appliquons une règle simple : premium quand ça compte, suffisant ailleurs. Le code de l'authentification est blindé. Le code de l'admin interne, fonctionnel, on l'améliorera plus tard.
Piège n°3 : la dépendance à des prestataires externes
Attendre une charte graphique, un texte SEO, une intégration API tierce : autant de blocages qui font basculer un projet à 20 jours, puis 30. Notre principe : tout ce qui peut bloquer le projet est livré ou décidé avant le jour 4. Sinon, on prend une décision interne provisoire et on avance.
Un cas concret : 14 jours pour Solea
Solea, une scale-up toulousaine spécialisée dans la gestion énergétique des bâtiments tertiaires, nous a contactés en septembre. Besoin : un dashboard interne pour visualiser la consommation en temps réel de leurs 120 sites clients, déployé avant une démo investisseurs prévue trois semaines plus tard.
Délai contraint, périmètre clair, équipe motivée. Tous les ingrédients étaient réunis pour appliquer notre méthode. Résultat : MVP livré le 14e jour, démo investisseur réussie, série A bouclée trois mois plus tard. La v2 (ajout de l'export Excel et du système d'alertes par email) a été développée en parallèle des premières utilisations terrain — et nourrie par les retours des opérateurs Solea, pas par des suppositions.
Après le jour 15 : itérer ou scaler ?
Un MVP n'est pas une fin : c'est un début. La phase post-lancement est aussi importante que les 15 jours initiaux. Trois scénarios typiques :
- Itération : sprints de 5 jours pour ajouter les fonctionnalités v2 priorisées par les retours utilisateurs réels.
- Scale : si le produit décolle, montée en charge de l'infrastructure, optimisation des performances, recrutement d'une équipe interne.
- Pivot : si les métriques montrent que la valeur n'est pas là où on pensait, on réoriente. C'est précieux d'avoir investi 15 jours plutôt que six mois pour le découvrir.
Ce qu'il faut retenir
Livrer un MVP en 15 jours, ce n'est pas magique. C'est l'application disciplinée d'une méthode éprouvée, par une équipe qui a fait ses erreurs et en a tiré des règles. La rapidité ne vient pas du fait de couper les coins ronds : elle vient du fait de ne jamais avoir à revenir en arrière.
Si votre projet digital prend six mois à démarrer, ce n'est pas que c'est un projet complexe. C'est que personne n'a pris la décision de le démarrer.
Vous avez un projet d'application métier, de plateforme interne ou de produit SaaS à lancer rapidement ? Discutons-en en 30 minutes, sans engagement.
