MVP et POC IA : de vrais utilisateurs en douze semaines

Un MVP est la première version d’un produit : assez complète pour que de vrais utilisateurs s’en servent avec de vraies données, assez réduite pour être construite en douze semaines. Chez Bonne Idée, il répond à une seule question, celle de savoir si le produit mérite d’aller plus loin.

Le POC répond à « est-ce techniquement possible avec vos données ? ». Le prototype répond à « est-ce que les gens comprennent ? ». Le MVP répond à « est-ce que les gens s’en servent ? ». Les confondre revient à payer un produit complet pour une question qu’un prototype aurait tranchée.

Nous écrivons avec vous la question que la première version doit trancher et nous coupons tout ce qui n’y répond pas. Nous concevons les parcours, construisons en no-code, en low-code ou en code selon ce que le produit demande, et intégrons l’IA là où elle apporte quelque chose. Un MVP sans IA se construit avec la même équipe et la même méthode. Puis l’outil passe entre de vraies mains, et nous regardons ce que font les utilisateurs plutôt que ce qu’ils disent.

Au bout des douze semaines, vous avez un produit en ligne, utilisé avec de vraies données, et une réponse sur la suite. Vous n’avez rédigé aucun cahier des charges ni recruté personne avant d’avoir la réponse.

Douze semaines, c’est le délai entre le début du cadrage et le moment où de vrais utilisateurs ont le produit entre les mains. Voici comment elles se répartissent sur un projet type.

• Semaines 1 et 2 : le cadrage.
• Semaines 3 et 4 : le prototype.
• Semaines 5 à 10 : trois sprints de construction.
• Semaines 11 et 12 : les premiers utilisateurs.

Ce découpage bouge à la marge selon le produit. Deux choses restent fixes : une version utilisable tous les quinze jours, et une décision prise sur ce que font les utilisateurs.

Quand le produit repose sur un modèle d’IA, une question précède toutes les autres : le modèle sait-il faire la tâche avec vos données ? Le POC y répond avant d’engager la construction.

On prend un échantillon de vos données réelles, on teste plusieurs modèles sur la tâche visée, et on mesure le taux de réponses utilisables. Si le résultat est bon, le MVP se construit sur une base vérifiée. S’il ne l’est pas, vous l’apprenez en quelques semaines, et nous cherchons un autre angle : une tâche plus étroite, une relecture humaine, ou un produit sans IA.

Le POC repose sur le même banc d’essai qu’une intégration LLM.

Les deux se construisent avec la même méthode et répondent à deux situations différentes.

• Le MVP sert quand vous ne savez pas encore si le produit sera utilisé : un nouveau service, un produit à vendre, un outil dont l’usage reste une hypothèse. Douze semaines pour le savoir.
• L’application métier sert quand l’usage est connu et que vos équipes attendent l’outil : un processus interne à outiller, des droits à gérer, des données à reprendre. Quatre mois pour un outil utilisable.

En cas de doute, le cadrage tranche. Un éditeur qui lance un produit commence presque toujours par un MVP, comme nous le décrivons pour les éditeurs SaaS B2B. Une PME qui outille un processus existant va directement à l’application. Si l’interface compte autant que la fonction, le design UX du pôle Digital s’y ajoute.

Un MVP peut conclure qu’il faut s’arrêter. Ce que vous avez payé reste utile : le code, les comptes et les données sont à votre nom, les parcours testés et les règles métier sont écrits, et les données d’usage disent pourquoi.

Si vous devez convaincre des investisseurs, le MVP apporte ce qu’une démonstration n’apporte pas : des données d’usage réelles. Il ne prouve en revanche ni la tenue en charge ni le coût d’acquisition à grande échelle, puisque les premiers utilisateurs viennent presque toujours de votre réseau. Le présenter comme une preuve de passage à l’échelle se retourne contre celui qui le présente.

Si la décision est d’aller plus loin, vous pouvez nous confier la suite, la confier à une autre équipe ou recruter : tout est documenté pour que la reprise ne commence pas par une enquête.

Prenons une situation type : une PME qui reçoit les commandes de ses clients professionnels par e-mail et par téléphone, et qui se demande si un portail de commande en ligne serait utilisé.

• La question écrite au cadrage : des clients qui commandent chaque semaine passeront-ils par le portail plutôt que par l’e-mail, au point de libérer le temps de saisie ?
• Le prototype montre le parcours de commande à quelques clients choisis, avant d’écrire une ligne de code.
• La construction se limite à ce parcours, avec l’IA là où elle sert : lire une commande envoyée en pièce jointe et la proposer pré-remplie.
• Les premiers utilisateurs sont une poignée de vrais clients, et l’on regarde combien reviennent commander par le portail.

Si peu reviennent, le portail ne mérite pas d’être étendu, et vous l’avez appris en douze semaines. S’ils reviennent, la suite se chiffre sur des données d’usage.

Nous appliquons cette méthode à notre propre produit, CoBIos, l’agent IA que nous avons co-construit avec le Greffe du Tribunal de commerce d’Orléans pour les cabinets comptables et juridiques.

• Le besoin est venu du Greffe : des équipes qui passent une grande part de la journée à chercher, vérifier et citer un texte, et pour qui une réponse sans source est inutilisable.
• La règle a été tranchée d’abord : répondre à partir des textes, citer la source à chaque fois, et dire quand la réponse n’est pas dans les sources.
• Le produit compte aujourd’hui quatre modules déployables séparément : la recherche avec source, la vérification d’une pièce, les relances, la préparation des dossiers de revue.
• Il s’ouvre aujourd’hui à des cabinets pilotes : chaque pilote porte sur un module et une équipe restreinte, et la suite se décide sur le temps réellement gagné.

C’est le chemin que nous vous proposons pour votre produit : une question précise, de vrais utilisateurs, une décision prise sur ce qu’ils font. Ses usages en cabinet sont détaillés sur la page IA pour cabinets d’expertise comptable.

Un MVP manipule de vraies données dès les premières semaines, et nous les traitons comme celles d’un produit en production. Un accord de sous-traitance des données (DPA) est signé avec le contrat, l’hébergement est en France par défaut, ou sur votre infrastructure quand la sensibilité des données l’exige, et aucun modèle n’est entraîné sur vos données. Le POC se fait sur un échantillon que vous choisissez, anonymisé si nécessaire.

Le RGPD, l’AI Act et ce qui se passe quand le modèle se trompe sont détaillés sur notre page garanties IA et souveraineté des données.