Une première version (MVP) en production en 6 semaines, pas à pas
À quoi ressemble une première version en 3 à 6 semaines vue de l'intérieur : le cadrage écrit, une démo par semaine, votre part du travail et ce qu'on retire.
6 min de lecture
La plupart des projets produit n'échouent pas à la fin. Ils échouent au deuxième mois, quand le cahier des charges a grossi, que la première démo est toujours prévue « au prochain sprint » et que personne ne sait dire ce qui sera en ligne avant l'été.
Vous avez sans doute déjà vécu la version où le devis annonçait quatre mois, l'équipe en annonçait six, et le comité de direction demandait une date que personne ne pouvait donner.
Nous visons une première version en production 3 à 6 semaines après le lancement. Appelez-la MVP si vous voulez. Nous disons première version, parce qu'elle tourne en production avec de vrais utilisateurs, pas dans une démo.
Six semaines, c'est le haut de la fourchette : un produit avec quelques intégrations et de vrais utilisateurs dès le premier jour. Voici à quoi ressemblent ces semaines : ce que nous livrons, et ce que vous faites.
Avant la semaine 1 : le cadrage est écrit
Rien ne démarre sans un cadrage écrit. Il tient en quelques pages et répond à trois questions : ce que nous construisons, ce que nous ne construisons pas, et quand ça part en production.
La deuxième liste compte plus que la première. « Pas de back-office dans la première version, les exports partent dans un tableur » : cette phrase fait gagner deux semaines. L'écrire avant le lancement évite d'en débattre en semaine quatre.
Le cadrage nomme aussi une personne de votre côté qui peut trancher. Pas un comité. Quelqu'un qui peut dire oui ou non à un écran dans la journée.
Si personne chez vous n'a ce temps, six semaines deviennent douze. Nous préférons vous le dire pendant l'audit qu'en semaine quatre.
De notre côté, c'est pareil : les personnes présentes à l'audit sont celles qui construisent. Personne n'arrive en semaine trois pour redemander le contexte.
Si vous avez fait un audit gratuit avec nous, son document sert de point de départ : l'opportunité est déjà choisie, les données sont déjà localisées.
Semaines 1 et 2 : en ligne, presque vide
La première semaine va à ce que personne ne voit. Les comptes, les environnements, la chaîne de déploiement, les accès à vos outils et à vos données. À la fin de la semaine, quelque chose est déployé en production, même si c'est un écran de connexion et une page vide.
Déployer dès la première semaine, c'est ce qui tient la date. Les équipes qui gardent le déploiement pour la fin découvrent la revue de sécurité, le délai de validation des stores ou la règle de pare-feu en semaine six. Et la date glisse.
La première démo arrive à la fin de la semaine deux ; ensuite, chaque semaine se termine par une démo. Elle montre le parcours principal qui fonctionne sur des données réelles, avec ses aspérités. Pour une fonctionnalité IA, c'est le modèle qui répond sur vos vrais documents ou vos vrais tickets, pas sur un échantillon choisi par nous.
Ce que vous faites pendant ces deux semaines :
- donner les accès : dépôts de code, comptes cloud, outils à connecter
- nommer les utilisateurs qui testeront, et les prévenir
- envoyer les vrais exemples : les fichiers en désordre, les cas limites, l'e-mail qui casse toujours le processus
Semaines 3 à 6 : le cœur, puis de vrais utilisateurs
Semaines 3 et 4 : le parcours principal, montré chaque semaine
Chaque semaine se termine par une démo de ce qui a changé, dans le vrai produit, pas sur des slides. Vous cliquez vous-même.
C'est en démo que se prennent les décisions de périmètre. Vous voyez un écran, vous vous rendez compte que la moitié ne sert à rien, et nous la retirons le jour même. Vous voyez un parcours, vous vous rendez compte qu'il manque une étape, et nous décidons ensemble si elle entre maintenant ou après la mise en production.
Quand quelque chose de prévu s'avère plus difficile que dans le cadrage, vous l'apprenez à cette démo, avec deux options : le retirer ou décaler la date. Vous ne l'apprenez pas en semaine six.
Pour les fonctionnalités IA, c'est aussi le moment de mesurer. À quelle fréquence la réponse est juste, à quelle fréquence il faut un humain, combien de temps ça prend et combien coûte chaque appel. Un chiffre mesuré sur un jeu de test construit à partir de vos propres cas vaut plus qu'une bonne impression en réunion.
Ce que vous faites pendant ces deux semaines :
- venir à la démo
- répondre aux questions dans la journée : une question qui attend une semaine coûte une semaine
- dire ce qu'il faut retirer
Semaines 5 et 6 : un petit groupe de vrais utilisateurs
Le groupe nommé dans le cadrage teste en premier, jamais toute l'entreprise.
Ces semaines servent à ce que les utilisateurs trouvent et que nous n'avions pas vu : la formulation qui embrouille, le cas que personne n'a mentionné, l'étape que tout le monde saute. Nous corrigeons ce qui les bloque et notons le reste pour l'itération suivante.
À la fin de la semaine six, la première version tourne en production, avec un monitoring en place, et ses utilisateurs savent où signaler un problème. L'itération suivante se planifie à partir de ce qu'ils ont réellement fait dans le produit.
Ce que vous faites pendant ces deux semaines :
- briefer le groupe de test
- centraliser leurs retours au même endroit
- décider de ce qui entre dans l'itération suivante
Les six semaines sur une page :
| Semaine | Ce que nous livrons | Ce que vous faites |
|---|---|---|
| Avant la semaine 1 | Cadrage écrit : ce que nous construisons, ce que nous ne construisons pas, la date | Nommer la personne qui tranche |
| 1-2 | En ligne en production (vide), première démo sur données réelles | Les accès, les testeurs, les exemples en désordre |
| 3-4 | Le parcours principal, une démo par semaine, l'IA mesurée sur vos cas | Venir à la démo, répondre dans la journée |
| 5-6 | Première version avec de vrais utilisateurs, monitoring | Briefer les utilisateurs, trier leurs retours |
Ce qu'on retire d'un MVP pour tenir le délai
Le calendrier tient parce que des choses sortent de la première version. Ce sont presque toujours les mêmes :
- Le back-office. Un export dans un tableur ou un accès direct à la base couvre les premiers mois.
- Tous les rôles et toutes les permissions. Un ou deux rôles au lancement ; la matrice fine vient quand quelqu'un en a besoin.
- Les cas limites qui arrivent deux fois par an. Ils se traitent à la main jusqu'à ce que le volume justifie autre chose.
- La deuxième plateforme. Web d'abord ou mobile d'abord, rarement les deux dans la première version.
- L'automatisation complète. Une fonctionnalité IA qui prépare et laisse une personne valider part plus vite en production, et apprend davantage qu'une fonctionnalité qui agit seule.
Les tests, la sécurité, les règles sur les données et les choix d'hébergement ne vont jamais sur cette liste. Vos données restent là où vous le décidez : hébergées en Europe, dans votre cloud ou sur site.
Quand c'est trois semaines, et quand c'est plus long
Trois semaines, c'est réaliste pour une fonctionnalité IA ajoutée à un produit qui existe déjà, ou pour un outil interne avec un seul parcours et une seule intégration. L'infrastructure est là, les utilisateurs sont connus, le périmètre est étroit.
Six semaines, c'est le cas décrit plus haut : un nouveau produit, quelques intégrations, des utilisateurs hors de l'équipe.
Certains projets prennent plus longtemps, et nous le disons avant le lancement : une plateforme avec paiements, un secteur réglementé, un système existant sans API. Dans ces cas, la première version en production est une tranche plus petite, et le cadrage dit laquelle.
La question suivante, c'est le budget. Il suit le cadrage, pas le calendrier. Le détail est dans ce que coûte un projet IA.
Par où commencer
Si vous avez un produit en tête et une date à ne pas manquer, réservez un audit gratuit. Une heure sur votre activité, puis un document court : ce qui vaut la peine d'être construit en premier, ce qui ne l'est pas, et si une première version tient en quelques semaines ou demande plus.
