Le prototype et le produit : comment savoir quand votre appli créée avec l'IA est vraiment terminée

Il y a quelques semaines, une fondatrice que je connais a construit une appli de prise de rendez-vous pour thérapeutes. Le tout lui a pris quatre jours avec un créateur d’applis avec IA. Ça fait ce dont elle a besoin : les thérapeutes voient leur agenda, les clients prennent rendez-vous, les confirmations partent par e-mail. Ça marche.

Elle la fixe depuis deux semaines et ne l’a pas lancée.

Quand je lui ai demandé pourquoi, elle a répondu : « Ça marche, mais… ça ne donne pas l’impression d’être terminé. »

Je lui ai demandé ce qu’elle changerait. Elle a dit : « Je ne sais pas. C’est ça, le problème. »

C’est le moment le plus difficile dans la création avec un créateur d’applis avec IA. La chose est fonctionnelle, mais il y a un écart entre « fonctionnel » et « je me sentirais à l’aise de demander à de vraies personnes d’utiliser ça ». Comprendre cet écart — et savoir de quel côté vous vous trouvez réellement — fait toute la différence entre livrer et rester bloqué pour toujours dans la phase de la petite voix intérieure.

Ce que veut vraiment dire « terminé »

Voici la distinction qui compte : un prototype, c’est ce qu’on utilise pour tester une idée. Un produit, c’est ce qu’on utilise pour résoudre un problème.

L’appli de prise de rendez-vous pour thérapeutes est un prototype. Elle prouve que le concept fonctionne. Un thérapeute pourrait l’utiliser. Mais il y a dix-sept petites choses qui lui donnent un côté brut :

• Les e-mails de confirmation sont nus. Pas de logo, pas de marque personnalisée, un texte générique.
• Les annulations n’envoient pas de notification. Les clients ne se présentent simplement pas.
• Il n’y a pas de liste d’attente quand un thérapeute est complet.
• Le parcours d’inscription ne collecte pas les spécialités du thérapeute, donc il n’y a aucun moyen de filtrer par type de pratique.
• Il n’y a pas d’e-mail de rappel envoyé 24 heures avant le rendez-vous.

Aucune de ces choses ne casse l’appli. Toutes donnent à un vrai thérapeute l’impression suivante : « Ça ressemble à un truc bricolé en un week-end, pas à quelque chose qu’on me fait payer. »

Ce ressenti est réel, et il compte. Un prototype résout le problème en théorie. Un produit le résout en pratique, pour l’humain réel qui s’en sert.

Trois questions qui séparent le prototype du produit

Voici la partie difficile : vous ne pouvez pas savoir tout ce qui manque. Votre créateur d’applis avec IA ne peut pas le savoir non plus. Il vous faut donc trois questions rapides pour déterminer de quel côté de la ligne vous êtes.

1. L’utiliseriez-vous pour résoudre votre propre problème ?

Celle-ci est honnête, parce que vous devez réellement vivre avec votre propre produit.

Si vous êtes la fondatrice de cette appli de prise de rendez-vous pour thérapeutes, l’utiliseriez-vous pour planifier vos propres séances de thérapie ? Pas « le pourriez-vous » — l’utiliseriez-vous vraiment plutôt qu’un échange d’e-mails ou un Google Doc partagé ?

Si la réponse est non, vous n’avez pas terminé. Vous savez exactement ce qui cloche — vous le ressentez chaque fois que vous ouvrez l’appli. Si la réponse est oui, vous y êtes presque.

La fondatrice que j’ai mentionnée a fait elle-même l’inscription en tant que thérapeute. Elle s’est bloquée au formulaire (il demandait trop d’informations avant de la laisser réserver). Elle a vu l’e-mail de confirmation et l’a trouvé amateur. Elle s’est mise à penser à la façon dont son thérapeute recevrait l’e-mail et à se demander s’il finirait dans les spams.

Elle n’utilisait pas son propre produit comme le ferait un client payant. Quand elle l’a fait, elle a trouvé dix choses à corriger.

2. L’avez-vous montrée à trois personnes qui ne sont pas vous ?

Parler à des utilisateurs potentiels est plus difficile que de construire, et la plupart des fondateurs sautent cette étape parce qu’ils veulent surprendre les gens au lancement. C’est une erreur.

Vous n’avez pas besoin d’un groupe de discussion. Vous avez besoin de trois personnes qui ressemblent à ce que vous pensez être votre client. Pour l’appli de thérapeutes, ce sont trois vrais thérapeutes.

Voici ce que vous cherchez : où se perdent-ils ? Où hésitent-ils ? Que demandent-ils ? Pas « qu’en pensent-ils ? » (les gens sont trop gentils). Demandez-leur de faire réellement la chose — prendre un rendez-vous, envoyer un e-mail de confirmation, annuler quelque chose.

Quand la fondatrice a montré son appli de thérapeutes à trois thérapeutes, deux d’entre eux ont demandé : « Est-ce que je peux fixer des règles pour mes disponibilités ? Genre, je ne reçois de nouveaux clients que le jeudi, et je ne fais pas de double rendez-vous avant 14 h. » L’appli avait un agenda, mais pas de règles. Elle avait construit le prototype selon la façon dont elle pensait que la prise de rendez-vous fonctionnait, pas selon la façon dont les thérapeutes travaillent vraiment.

Ça, c’est de l’information produit. Vous ne pouviez pas la deviner à partir d’un cahier des charges.

3. Qu’est-ce qui casserait si vous la confiiez à dix vrais utilisateurs ?

C’est la question la plus difficile, parce qu’elle vous oblige à vraiment réfléchir à vos cas limites.

Pour l’appli de thérapeutes :

• Que se passe-t-il si un client essaie de prendre deux rendez-vous à la même heure ? (L’appli ne vérifie pas.)
• Que se passe-t-il si un thérapeute annule un rendez-vous ? Les clients sont-ils prévenus automatiquement ? (Non.)
• Et si l’adresse e-mail d’un client est fausse ? Y a-t-il un moyen de la corriger sans tout recommencer ? (Non.)
• Et si un thérapeute a un jour de maladie et doit fermer son agenda pour une semaine ? (Elle devrait supprimer manuellement chaque rendez-vous.)

Ce ne sont pas des bugs. L’appli ne plante pas. Mais ce sont des coupures de papier. Avec dix vrais utilisateurs et de vrais cas limites, vous les rencontrerez tous dès la première semaine.

Un produit gère les cas limites. Pas tous — certaines choses peuvent attendre. Mais celles qui surviennent dans les deux premières semaines avec de vrais utilisateurs, celles-là doivent fonctionner.

Comment décider : le test à trois couches

Servez-vous-en pour déterminer où vous en êtes :

Couche 1 : parcours principal — Le chemin idéal fonctionne-t-il ? Un utilisateur peut-il accomplir la chose principale pour laquelle votre appli est conçue ?

Pour l’agenda des thérapeutes : oui. Quelqu’un peut s’inscrire, prendre un rendez-vous, recevoir une confirmation. Ça marche.

Couche 2 : cas limites de l’usage réel — Vous l’avez montrée à trois vrais utilisateurs. Ont-ils rencontré quelque chose que vous n’aviez pas prévu ? Se sont-ils perdus quelque part ?

Pour l’agenda des thérapeutes : oui. Les trois thérapeutes voulaient des disponibilités à base de règles. L’un s’est perdu parce que l’e-mail de confirmation avait l’air trop générique. L’un a essayé de supprimer des rendez-vous en masse et n’a pas pu.

Couche 3 : finition et professionnalisme — Est-ce qu’on sent que vous y tenez ? Ou est-ce qu’on a l’impression que vous l’avez bricolée ?

Pour l’agenda des thérapeutes : ça fait bricolé. Les e-mails de confirmation sont nus. Il n’y a pas de marque personnalisée. Il n’y a pas de message d’erreur si quelque chose tourne mal, donc en cas de panne, l’utilisateur n’a aucune idée de ce qui s’est passé.

Voici l’heuristique :

• Les trois couches fonctionnent ? Vous êtes un produit. Lancez.
• Couches 1 et 2, mais pas la 3 ? Vous êtes à 80 %. Passez une journée sur la finition.
• Couche 1 qui fonctionne, couches 2 et 3 non ? Vous êtes un prototype. Ne lancez pas encore.
• La couche 1 n’est pas solide ? Vous n’avez pas terminé. Continuez à construire.

L’appli de thérapeutes était coincée à la frontière entre la couche 1 et la couche 2. Le parcours principal fonctionnait, mais de vrais thérapeutes lui trouvaient des manques. La fondatrice avait donc un choix : passer une semaine de plus avec son créateur d’applis avec IA à ajouter les fonctionnalités dont les thérapeutes ont réellement besoin, ou lancer avec ce qu’elle avait et les ajouter plus tard.

(Elle les a ajoutées. Ça a pris trois jours. Maintenant, c’est un produit.)

Ce qui rend ça difficile

La raison pour laquelle tant de fondateurs restent coincés ici, c’est que construire est amusant et que lancer fait peur.

Construire, c’est une conversation avec votre outil d’IA. Vous avez une idée, vous la décrivez, l’outil l’exécute. Il y a une boucle de feedback qui prend quelques minutes. Lancer, c’est différent. Vous cliquez sur publier, et si quelque chose cloche, de vrais humains le découvrent. Pas de seconde chance.

Alors on se trouve des raisons de ne pas lancer. « Ce n’est pas assez fini. » « Je devrais ajouter une fonctionnalité de plus. » « Et si les polices ne sont pas les bonnes ? » Et six semaines plus tard, vous êtes encore assis sur quelque chose qui marche mais ne donne pas l’impression d’être terminé, et vous vous êtes convaincu que c’est à cause des polices.

Ce n’est pas les polices.

C’est généralement que vous n’avez pas passé de temps avec un vrai utilisateur, ou que vous avez construit quelque chose qui avait du sens dans votre tête mais ne colle pas tout à fait à la façon dont les vraies personnes travaillent. Ça, c’est réparable. Il suffit juste d’admettre que vous ne savez pas ce que vous ne savez pas, puis d’aller parler à quelqu’un qui, lui, le sait.

La checklist de prêt-au-lancement

Servez-vous-en. Elle est courte et honnête.

• Je l’ai utilisée moi-même pour faire la vraie tâche, et ça a marché (pas façon mode démo, mais pour de vrai).
• Je l’ai montrée à trois personnes qui l’utiliseraient vraiment, et j’ai corrigé les choses qui les ont perdues.
• Chaque erreur qui peut survenir a un message qui dit à l’utilisateur quoi faire (pas « erreur », mais un vrai conseil).
• Je serais d’accord si c’était la dernière version pendant six mois (autrement dit : elle est assez complète pour être utile même si je n’y touche plus jamais).
• Je suis plus enthousiaste à l’idée de ce que j’apprendrai de vrais utilisateurs qu’à celle d’ajouter des fonctionnalités dans le vide.

Si vous pouvez cocher les cinq cases, vous avez terminé. Lancez.

Si vous ne pouvez pas, ne lancez pas. Mais soyez précis sur le pourquoi. « Ça ne donne pas l’impression d’être terminé » n’est pas une raison. « De vrais thérapeutes ont besoin de règles de disponibilité et je ne les ai pas encore construites » est une raison. C’est actionnable. C’est réparable. C’est la différence entre être bloqué et être sur un chemin.

La fondatrice de l’appli de thérapeutes l’a lancée hier. Elle a son premier client payant. Le produit n’est pas parfait, mais il est réel, et sa cliente lui dit déjà quoi construire ensuite. C’est là qu’on sait qu’on a terminé : pas quand l’appli est parfaite, mais quand on est prêt à apprendre ce que « parfait » veut vraiment dire pour les gens qui s’en servent.