Valider son idée d’application avec Margaux, avant de construire

Entre une idée séduisante et un problème confirmé, il manque souvent une enquête. Préparez vos observations, travaillez le brief avec Margaux et décidez quoi vérifier avant de lancer la construction.

Margaux peut vous aider à préciser une idée d'application et à en faire un brief compréhensible. Elle ne peut pas décider à la place des futurs utilisateurs si leur problème mérite un nouveau logiciel. Une proposition bien écrite reste une proposition : pour la valider, il faut la confronter à ce qui se passe réellement.

Notre exemple est fictif. Lina loue des décors pour des événements. Elle pense créer une application permettant aux clients de suivre leur commande. Son collègue Hugo prépare les départs et les retours. Personnes, entreprise et observations sont inventées pour expliquer la méthode ; il ne s'agit ni d'un client Maestro ni d'une enquête réellement menée.

1. Séparer l'idée de solution du problème à vérifier

« Une application de suivi des locations » décrit une solution. La phrase ne dit pas encore pourquoi quelqu'un changerait ses habitudes pour l'utiliser. Lina doit revenir à un événement : un client demande si un élément est disponible ; elle lui répond avec un état du stock qui n'intègre pas un retour incomplet.

Plusieurs problèmes peuvent se cacher derrière cette situation. Le client manque peut-être d'informations. L'équipe ne sait peut-être pas si le matériel revenu est prêt à repartir. Ou personne n'a la responsabilité de confirmer l'état du retour. Une application destinée aux clients traiterait seulement une partie de ces possibilités.

Écrivez donc deux phrases séparées : « Je voudrais construire… » et « Le problème que je veux vérifier est… ». Pour Lina, la seconde devient : « Nous risquons de promettre un décor disponible alors qu'il n'a pas été contrôlé après son retour. » Elle peut maintenant chercher si ce problème existe, quand il survient et comment il est géré.

Dans Maestro, le rôle de Margaux est le cadrage : clarifier le problème, les personnes concernées, la valeur attendue, les objectifs et les risques. La présentation de l'équipe situe cette étape dans le parcours. Utilisez-la pour ordonner vos questions, en gardant la décision métier de votre côté.

2. Faire l'inventaire de ce que vous savez vraiment

Avant de demander un avis à l'IA, préparez une note en trois parties : faits observés, explications possibles, questions ouvertes. Cette séparation évite qu'une reformulation transforme votre intuition en certitude. Une donnée peut être précise sans être représentative ; indiquez toujours d'où elle vient et à quelle situation elle correspond.

Un fait fictif de notre exemple serait : « Lors du dernier retour, deux éléments du décor n'étaient pas prêts à repartir lorsque la réservation suivante a été préparée. » Une explication possible : « L'état disponible a été rétabli trop tôt. » Une question ouverte : « Qui a besoin de confirmer le contrôle avant une nouvelle promesse au client ? »

Ne remplacez pas ces détails par « notre gestion est inefficace ». Cette formule peut convenir à plusieurs problèmes opposés. Décrivez le moment, l'information absente et la décision rendue difficile. Si vous n'avez jamais vu la situation vous-même, notez « rapporté par… » plutôt que de la présenter comme une observation directe.

3. Choisir les bonnes personnes pour en parler

Lina doit entendre plusieurs points de vue. Hugo connaît les retours et les pièces manquantes ; la personne qui confirme les réservations connaît les engagements pris ; un client connaît les informations dont il a besoin. Ces rôles peuvent se retrouver chez une seule personne dans une petite structure, mais leurs questions restent différentes.

Commencez par les personnes qui rencontrent réellement la situation. Des proches enthousiastes pour votre projet peuvent vous encourager sans connaître le travail. Cherchez également un cas qui contredit votre intuition : une personne qui gère les retours sans difficulté ou un client qui ne veut pas d'un compte supplémentaire.

Expliquez le sujet simplement : vous cherchez à comprendre une situation, pas à vendre une application déjà décidée. Demandez un exemple récent que la personne accepte de raconter. Proposez un échange assez court pour être facile à accepter, et adaptez la durée au récit plutôt que de promettre une enquête complète en quelques minutes.

Le guide d'entretien de GOV.UK recommande des questions ouvertes et neutres, centrées sur des récits et des exemples réels. Pour notre cas, cela conduit à demander comment un retour s'est passé, avant de présenter l'écran imaginé par Lina.

4. Préparer un échange qui ne souffle pas la réponse

« Vous aimeriez une application qui vous ferait gagner du temps ? » invite à approuver une promesse. « Racontez-moi le dernier retour de matériel que vous avez traité » permet d'examiner un travail. La seconde formulation ne garantit pas une réponse complète ; elle vous donne une situation sur laquelle revenir avec précision.

Lina peut préparer les questions suivantes pour Hugo. Elles servent de repères, pas de questionnaire à dérouler si une réponse importante demande d'être approfondie. L'objectif est de reconstruire le parcours et de repérer ce qui manque au moment où une décision doit être prise.

• Quel matériel est revenu lors du dernier événement ?
• Où avez-vous noté ce qui manquait ou devait être réparé ?
• Qui a été informé et comment avez-vous su que le message était compris ?
• À quel moment le matériel a-t-il été considéré comme disponible ?
• Que s'est-il passé lorsque la réservation suivante a été préparée ?
• Qu'avez-vous fait pour résoudre le problème avec les moyens actuels ?

Demandez un exemple de document seulement si la personne peut le montrer sans exposer d'informations confidentielles. Prenez des notes utiles au problème. Un enregistrement n'est pas nécessaire par défaut ; si vous envisagez d'en faire un, expliquez son usage et obtenez l'accord de la personne avant de commencer.

Réservez la fin de l'échange à votre idée. Présentez-la comme une possibilité, puis demandez ce qu'elle ne résoudrait pas. Un « ce serait pratique » vaut moins, pour décider du prochain essai, qu'une difficulté précise : « Je ne pourrai pas renseigner ce formulaire pendant que je décharge le camion. »

5. Transformer les retours en hypothèses testables

Relisez vos notes sans tout faire entrer dans l'idée de départ. Dans notre scénario inventé, Hugo explique qu'il sait ce qui manque, mais que cette information n'arrive pas à la personne qui confirme les disponibilités. Lina découvre alors que le premier sujet pourrait être une confirmation interne du retour, avant le suivi côté client.

Formulez une hypothèse avec une condition observable : « Si l'état d'un retour n'est confirmé qu'après contrôle, la personne qui réserve pourra distinguer le matériel prêt du matériel à vérifier. » Il reste à voir si l'équipe peut tenir cette règle dans son travail quotidien. La formulation ne prouve pas qu'elle le fera.

Séparez également l'importance du problème et la volonté d'utiliser votre solution. Une difficulté peut être réelle sans justifier un nouvel outil. L'équipe peut préférer une règle commune, une case dans son fichier actuel ou un logiciel existant. Demandez ce qui a déjà été essayé et pourquoi cela a été conservé ou abandonné.

Ne transformez pas quelques échanges en pourcentage de marché. Notez plutôt ce qui revient, ce qui varie selon les rôles et les contre-exemples. Un groupe de personnes que vous connaissez déjà ne représente pas automatiquement tous les loueurs. Le premier objectif est de choisir un essai pertinent, pas d'annoncer une demande commerciale démontrée.

6. Donner à Margaux un dossier court et honnête

À ce stade, vous disposez d'une matière plus utile qu'une liste de fonctions. Vous pouvez transmettre un résumé du contexte, quelques faits rendus anonymes, vos hypothèses et les limites de l'enquête. Évitez les transcriptions complètes lorsqu'un extrait suffit. Le guide sur les données rappelle la différence entre projet conservé localement et contexte transmis à un assistant IA.

Voici une demande préparée pour notre exemple : « Je loue des décors. Je pensais créer un suivi pour les clients, mais les premiers échanges suggèrent un problème de confirmation des retours. Nous ne savons pas encore si une application est nécessaire. Aide-moi à distinguer ce qui est observé, ce qui est supposé et ce qu'il faut vérifier. »

Ajoutez la matière : « Situation rapportée : du matériel a été promis avant vérification du retour. Hypothèse : la personne qui réserve manque d'un état fiable. Autre explication possible : la règle existe, mais personne n'est chargé de la tenir. Limite : nous avons seulement exploré notre organisation, pas le marché des loueurs. »

Terminez par le résultat attendu : « Propose un brief court avec le problème, les personnes concernées, une première expérience, les risques et ce qui reste hors périmètre. N'invente pas de gain de temps ni de demande client. Marque les décisions qui nécessitent mon arbitrage. » Cette demande dirige la réflexion sans transformer l'IA en témoin des événements.

7. Relire le brief comme une proposition à corriger

Le brief produit par Margaux doit être confronté à vos notes. Cherchez d'abord les changements de sens. « Les clients réclament un suivi en temps réel » serait faux si personne ne l'a demandé. « L'équipe manque d'une confirmation fiable avant de promettre le matériel » reste plus proche du problème décrit dans notre exemple.

Vérifiez ensuite les rôles. Qui saisit le retour ? Qui peut confirmer qu'un élément est prêt ? Qui consulte cette information avant de répondre au client ? Un mot comme « utilisateur » peut cacher trois responsabilités différentes. Demandez une reformulation dans votre langage de travail avant de laisser cette ambiguïté devenir une règle de l'application.

Regardez aussi ce qui a été ajouté : paiement, signature, messages automatiques, statistiques. Une fonction proposée peut être intéressante sans être nécessaire au premier essai. Placez-la dans les possibilités futures si aucune observation ne la rend indispensable. Vous protégez ainsi la question que vous cherchez réellement à résoudre.

Une correction complète contient la phrase à changer, la raison et la version attendue. Par exemple : « Remplace “le client confirme le retour” par “Hugo constate le retour, puis Lina confirme la disponibilité après vérification”. Le client ne contrôle pas l'état du matériel dans notre organisation. » Relisez ensuite l'ensemble pour repérer une autre phrase restée contradictoire.

8. Choisir une expérience avant de construire davantage

Le brief peut déboucher sur un essai sans application : pendant quelques retours, l'équipe distingue explicitement reçu, à vérifier et prêt à repartir dans son support habituel. Elle examine si cette distinction aide la personne qui prend les réservations. Cette proposition est une méthode pour le cas fictif, pas un résultat déjà obtenu.

Lina peut aussi préparer un écran simple avec des décors inventés. Elle demande à Hugo de retrouver ce qui peut partir, puis de traiter un retour incomplet. Si elle doit expliquer chaque libellé, il reste du travail sur les mots et la logique avant d'ajouter des fonctions. Une jolie maquette ne répond pas à elle seule à cette difficulté.

Écrivez le critère avant l'essai. Par exemple : « La personne qui confirme une location doit distinguer, sans demander à Hugo, le matériel contrôlé de celui qui reste à vérifier. » Précisez quand et avec quels exemples vous observerez ce comportement. Si vous souhaitez mesurer un gain de temps, commencez par mesurer la situation actuelle.

Gardez également un critère d'arrêt : si la mise à jour demande un effort que l'équipe ne peut pas tenir, revoyez le parcours. Ajouter des rappels automatiques ne résout pas forcément une responsabilité absente. Le prochain apprentissage peut consister à changer l'organisation avant de choisir un logiciel.

9. Décider : poursuivre, corriger ou laisser l'idée de côté

Rassemblez les faits appris, les difficultés restantes et les options. Poursuivre peut vouloir dire construire une petite version ; cela peut aussi signifier rencontrer un autre rôle ou essayer un outil existant. Dites quelle incertitude chaque option permet de réduire. Vous éviterez de confondre avancer avec produire davantage d'écrans.

Corriger l'idée est normal. Lina est partie d'un suivi client ; elle explore désormais une confirmation interne des retours. La première idée a servi à ouvrir la discussion. Si le problème est rare, déjà bien traité ou sans conséquence suffisante, le mettre de côté peut être la décision la plus utile.

Pour une application destinée à être vendue, ajoutez une question distincte : qui déciderait de l'achat et sur quel budget ? La personne qui aime utiliser un outil n'est pas forcément celle qui peut l'acheter. Un accord pour essayer ne prouve pas un engagement à payer ; gardez ces niveaux séparés dans votre conclusion.

10. Conserver une décision que l'équipe pourra retrouver

Votre note finale peut tenir sur une page : problème retenu, personnes concernées, faits qui soutiennent la décision, hypothèses restantes, première expérience et date de réexamen. Ajoutez les fonctions écartées et pourquoi. Cette trace évite de réintroduire une idée abandonnée sans s'apercevoir que la question avait déjà été discutée.

Dans le cas de Lina, le résultat n'est pas « notre application est validée ». C'est : « Nous allons vérifier une règle de confirmation des retours avant de construire un espace client. Hugo montre comment un retour est traité ; Lina observe la décision de disponibilité ; nous examinons ensuite les difficultés rencontrées. » Chacun sait ce qu'il doit apporter.

Lorsque ce besoin est suffisamment clair, le cahier des charges non technique aide à décrire ce qu'il faudra construire et vérifier. Le guide de création sans savoir coder suit les étapes suivantes. Vous passez ainsi d'une décision sur le problème à un travail sur la solution.

Vous pouvez commencer cette enquête sans attendre Maestro. Écrivez un événement concret et demandez à une personne concernée de le raconter de son point de vue. Pour travailler ensuite le cadrage avec Margaux, l'accès à Maestro se demande sur invitation, sur Mac. L'application est gratuite pendant la beta ; l'usage IA reste à prévoir auprès du fournisseur choisi.

Revenir au sommaire