Quatre-vingt-seize heures sont une fenêtre de livraison, pas une promesse universelle
Un produit important ne se compresse pas en quatre jours en tapant plus vite. L’architecture, les besoins inconnus, les intégrations, la conformité, le contenu, les tests et les décisions des parties prenantes demandent toujours du temps. Prétendre le contraire déplace le risque vers une sécurité faible, un code fragile et des comportements inachevés.
Un MVP en 96 heures fonctionne lorsque le projet poursuit un objectif étroit et que les incertitudes principales ont déjà été levées. Il s’agit de livrer une première version fonctionnelle qui démontre un usage utile—pas une version réduite de toutes les fonctions imaginables du produit final.
Ce qui convient généralement
Les projets adaptés partagent une propriété utile : leur réussite peut être formulée en une ou deux phrases et vérifiée en utilisant la version livrée. Une équipe interne peut créer et gérer un dossier défini. Un client peut soumettre et suivre une demande. Un opérateur peut consulter un tableau de bord alimenté par une source existante. Un site peut publier un contenu validé sur un ensemble connu de pages.
Une infrastructure et des API existantes peuvent accélérer la livraison, à condition que leurs accès et comportements soient déjà compris. Une intégration IA fondée sur une API de modèle établie peut convenir si la frontière des données, la tâche, le format de sortie et la validation humaine sont définis. L’entraînement d’un modèle sur mesure ne tient pas dans la même fenêtre.
- Outils internes ciblés et flux CRUD
- Tableaux de bord sur des données accessibles
- Sites corporate et pages d’atterrissage avec contenu prêt
- Portails clients à parcours défini
- Prototypes SaaS ciblés
- Automatisations délimitées et intégrations IA sur modèles existants
Ce qui ne convient pas
Les mauvais candidats contiennent des systèmes non résolus plutôt qu’un premier usage délimité. Une migration d’entreprise dépend de la qualité des données, de la conduite du changement et de plusieurs responsables. Une place de marché combine produit biface, confiance, paiements et opérations. Une plateforme réglementée exige des preuves, des revues et des contrôles qu’un sprint de développement ne peut pas compresser.
Les idées indéfinies conviennent tout aussi peu. Si les deux premiers jours servent à décider qui est l’utilisateur et quel problème résoudre, le projet a besoin d’une phase de découverte avant tout chronomètre. La vitesse devient utile une fois les décisions importantes prises ; elle ne les remplace pas.
- Grandes migrations d’entreprise ou de données
- Concepts produit indéfinis
- Plateformes fortement réglementées
- Places de marché complexes
- Entraînement de modèles sur mesure
- Transformations multi-systèmes
- Travaux bloqués par des validations tierces
Le chronomètre démarre après la préparation
L’évaluation précède la fenêtre de réalisation. Nous confirmons l’adéquation technique, réduisons le périmètre à une version cohérente, identifions les dépendances et définissons ce que signifie « fonctionnel ». Comptes, accès API, éléments de marque, contenus validés et décideurs doivent être disponibles. Les files de validation tierces—comme l’approbation d’un store—restent hors des 96 heures.
Le périmètre obtenu indique explicitement ce qui est inclus et exclu. Cette discipline protège la qualité. L’équipe peut choisir une architecture simple, établir le modèle de données et la frontière de sécurité, construire le parcours principal, le valider face aux critères d’acceptation et livrer une version déployable avec des étapes suivantes connues.
La vitesse vient des décisions, pas des raccourcis
Un périmètre discipliné réduit la coordination et les reprises. La réutilisation de capacités de plateforme fiables évite une ingénierie sans différenciation. Des critères d’acceptation clairs concentrent les tests sur la véritable promesse de la version. Aucun de ces choix n’impose d’abandonner la validation, les contrôles d’identité ou une structure maintenable.
La première version doit produire des preuves. Les utilisateurs peuvent exécuter le vrai processus, l’équipe peut observer les réussites et les échecs, et l’investissement suivant se fonde sur des comportements plutôt que des hypothèses. Voilà le rôle de l’offre 96 heures : transformer en réalité, avec une ingénierie ciblée, un projet techniquement adapté et préparé en amont.
Les 96 heures commencent lorsque périmètre, faisabilité, accès, besoins et ressources sont prêts—pas lorsque l’idée est évoquée pour la première fois.