Transformer une réunion client en prototype avec Granola et Lovable

Peut-on créer un prototype avec l’IA à partir d’une réunion client ?

Oui, si les informations accessibles décrivent suffisamment le produit attendu. Des notes ou une transcription servent de matériau de départ ; elles ne prouvent pas que toutes les décisions sont prises. Avant de construire, vérifiez les utilisateurs concernés, leurs actions et les points encore ouverts.

Une personne qui possède déjà les éléments nécessaires peut commencer sans outil supplémentaire. Granola devient intéressant lorsque les conversations à venir doivent alimenter régulièrement le contexte de construction.

Quelles notes faut-il fournir pour construire le prototype ?

Utilisez une réunion identifiée et les passages décrivant les comportements attendus. Évitez de fournir indistinctement tout l’historique du client. Commencez par le titre, la date, le projet concerné et les décisions pertinentes pour cette première version.

Si vous choisissez Granola pour une prochaine réunion, préparez la capture avant l’échange et informez les participants. La documentation distingue l’application de transcription de l’interface web de consultation des notes.

Référence officielle : Granola — fonctionnement de la transcription.

Les permissions audio, l’installation et les restrictions réseau sont traitées dans notre guide de configuration Granola sur ordinateur professionnel. La préparation commerciale d’un rendez-vous relève de notre guide de découverte client avec l’IA. Ici, nous partons des besoins exprimés pour construire une interface à examiner.

Comment connecter Granola à Lovable pour construire depuis ses réunions ?

Pour donner vos notes à l’IA pendant la construction, choisissez le connecteur de chat personnel. Une application qui doit consulter des notes à l’exécution relève de la connexion API. L’exemple de ce guide n’exige pas que les visiteurs du prototype puissent lire les réunions.

Référence officielle : Lovable — connecteurs personnels de chat et Granola.

Référence officielle : Lovable — connexion Granola pour le chat et l’application.

Procédure pour le connecteur personnel

1. Ouvrez Connectors dans Lovable et sélectionnez Granola.
2. Choisissez Add connection. Si plusieurs types sont proposés, sélectionnez Chat connector.
3. Autorisez la connexion avec votre compte Granola dans le navigateur.
4. Dans le chat du projet, indiquez la réunion par son titre, sa date ou un participant. Demandez d’abord à Lovable de confirmer laquelle il a trouvée.

Les noms de menus sont conservés en anglais pour correspondre à la documentation. Si le connecteur est désactivé dans votre organisation, faites vérifier ce réglage ; une clé partagée ne constitue pas automatiquement un remplacement adapté.

Les notes et la transcription ne donnent pas le même niveau de preuve

Granola Basic permet de consulter les notes personnelles récentes via MCP, avec une fenêtre de 30 jours. Certains outils de recherche, de dossiers et de transcription nécessitent une offre payante. Vérifiez l’accès réel avant de demander des citations exactes.

Référence officielle : Granola — accès MCP, outils et authentification.

Granola décrit séparément les clés API et leurs périmètres d’accès. Choisissez cette architecture si votre produit doit réellement consulter les données de réunion, plutôt que pour générer une simple démonstration.

Référence officielle : Granola — clés API et périmètres d’accès aux notes.

Comment extraire les demandes sans laisser l’IA inventer le périmètre ?

Demandez un tableau d’exigences avant le code. Chaque ligne doit préciser un utilisateur, un comportement attendu, une référence à la réunion et un statut de validation. Une suggestion de réalisation peut être utile sans devenir une demande du client.

Le premier prompt utilise une réunion précise. Remplacez les champs entre crochets ; « le dernier appel » peut sélectionner un autre projet.

Prompt 1 : retrouver la réunion et identifier les comportements demandés

Utilise mes notes Granola pour préparer un prototype destiné au client.

Retrouve la réunion [titre], du [date], avec [client ou participant]. Avant d’exploiter son contenu, indique le titre, la date et l’identifiant de note s’il est disponible. Si plusieurs réunions correspondent, demande-moi de choisir.

Extrais seulement les comportements attendus du produit. Présente un tableau comprenant :
- identifiant de l’exigence ;
- utilisateur et action demandée ;
- passage de la note ou de la transcription qui l’appuie ;
- référence de la source ;
- statut : demande explicite, interprétation proposée ou question ouverte.

Distingue les décisions des suggestions. N’invente pas d’échéance, de budget, d’intégration ni d’objectif de performance. Si tu ne peux lire que le résumé, indique « notes/résumé », sans présenter le passage comme une citation verbatim.

Ne génère pas de code à cette étape.

Si l’IA ne peut lire qu’un résumé enrichi, elle doit le présenter comme tel. Elle ne doit pas fabriquer un verbatim, un horodatage ou une attribution à un participant. Pour une exigence importante, consultez le passage original lorsqu’il est accessible et vérifiez son contexte.

Le statut compte autant que la formulation : « demandé » et « proposé par l’IA » ne déclenchent pas la même décision. Le premier peut entrer dans le périmètre après examen ; le second exige votre validation.

Exemple : un portail de validation de livrables pour une agence

Exemple fictif, sans test client revendiqué : une agence veut montrer un livrable, recueillir un commentaire et permettre une demande de correction. Les phrases suivantes sont inventées pour illustrer la méthode.

La demande REQ-03 ne précise pas où la correction doit parvenir. Dans une démonstration, proposez une confirmation visible et identifiée comme simulée. N’affirmez pas qu’un email a été envoyé ou qu’un ticket a été créé sans mécanisme réel et contrôle du résultat.

Notre périmètre initial proposé est limité : une vue de livrable, un champ commentaire et une interaction de demande de correction. Ce choix permet d’examiner le parcours avec le client ; ce n’est pas une obligation imposée par Granola ou Lovable.

Faut-il faire valider un plan avant de générer le prototype ?

Oui, lorsque le périmètre ou le fonctionnement restent ambigus. Le mode Plan de Lovable prépare une proposition avant la modification du code. Utilisez cette étape pour examiner les écrans, les interactions et les décisions qui n’étaient pas explicites dans la réunion.

Référence officielle : Lovable — examiner un plan avant de modifier le code.

Prompt 2 : proposer un prototype limité et contrôlable

À partir du tableau que nous avons examiné, propose le périmètre d’un petit prototype à faire valider par le client.

Exemple : portail de validation de livrables pour une agence.
Comportements approuvés : afficher un livrable, saisir un commentaire et demander une correction.
Utilise des données de démonstration fictives. Liste les écrans, le comportement des commandes et les identifiants d’exigence couverts.

Sépare :
1. Le périmètre confirmé.
2. Tes choix de réalisation proposés.
3. Les décisions encore attendues du client.
4. Les éléments exclus de cette première version.

Pour chaque comportement confirmé, propose un contrôle observable. Ces contrôles restent des propositions jusqu’à mon accord. N’ajoute ni facturation, ni CRM, ni email, ni authentification, ni intégration externe si le périmètre approuvé ne le demande pas.

Attends ma validation du plan avant de modifier le code.

Faites aussi approuver les contrôles. « Le client peut demander une correction » ne suffit pas pour vérifier le résultat. Un contrôle proposé serait : lorsque l’explication manque, la demande n’est pas soumise et l’interface demande de compléter le champ. Cette règle n’apparaît pas dans notre conversation fictive ; elle doit donc rester une proposition à confirmer.

Une fois le périmètre approuvé, conservez ses objectifs et contraintes dans le contexte propre au projet. Lovable documente ce contexte persistant dans Project settings → Knowledge. Un résumé validé est plus utile ici que toute la transcription déposée comme instruction permanente.

Référence officielle : Lovable — contexte persistant propre au projet.

Comment construire et vérifier le prototype dans Lovable ?

Construisez une interaction, examinez-la, puis passez à la suivante. Lovable recommande des modifications précises et des vérifications dans l’aperçu. Une demande qui ajoute simultanément interface, accès utilisateurs, notifications, facturation et statistiques rend le contrôle du périmètre plus difficile.

Référence officielle : Lovable — construire par étapes et vérifier le résultat.

Prompt 3 : construire uniquement le périmètre approuvé

Construis uniquement le prototype défini dans le plan approuvé.

Commence par la vue du livrable et la saisie du commentaire. Après cette étape, indique les changements, les identifiants d’exigence couverts et les éléments encore absents. Ajoute ensuite la demande de correction dans une étape distincte.

Utilise uniquement des noms, livrables et commentaires fictifs. Distingue les interactions simulées des données réellement conservées. N’affirme pas qu’un email a été envoyé ou qu’une demande a été enregistrée sur un serveur si ce fonctionnement n’existe pas et n’a pas été vérifié.

Contrôle les critères approuvés et indique pour chacun : réussi, échoué ou non testé. Inclue les états vides et les champs obligatoires manquants. Ne présente pas le prototype comme prêt pour la production et ne le publie pas automatiquement.

Notez les résultats réels : réussi, échoué ou non testé. Un contrôle proposé dans ce guide n’est pas un test déjà exécuté. Si vous ajoutez ensuite un serveur et des comptes, vérifiez séparément la conservation des données et les accès de plusieurs utilisateurs.

La fidélité à la demande et le fonctionnement technique sont deux contrôles complémentaires : une interface peut fonctionner tout en réalisant une fonction que le client n’avait pas demandée.

Comment intégrer la prochaine revue du prototype sans étendre le projet par accident ?

Classez les retours sur cette version en correction, nouvelle demande ou décision ouverte. Une correction rétablit le comportement approuvé. Une nouvelle demande élargit potentiellement le périmètre. Une question ouverte ne doit pas déclencher automatiquement une construction.

• Correction : l’explication manque dans la confirmation alors que le plan approuvé la prévoyait.
• Nouvelle demande : le client souhaite maintenant des emails de notification.
• Décision ouverte : différents relecteurs doivent avoir des accès distincts, mais les rôles ne sont pas définis.

Si la revue est capturée dans Granola, référencez cette réunion par son titre et sa date. Demandez une proposition de changements liée aux identifiants REQ existants et une liste séparée des ajouts. Une remarque récente ne doit pas effacer silencieusement une décision approuvée.

Conservez un relevé court des décisions : périmètre accepté, personne qui l’a confirmé, date et exigences modifiées. C’est notre méthode proposée pour ce projet ; elle ne signifie pas que les outils certifient automatiquement l’accord du client.

Que vérifier si Lovable ne retrouve pas la bonne réunion Granola ?

Référence officielle : Granola — accès MCP, outils et authentification.

Référence officielle : Lovable — connexion Granola pour le chat et l’application.

Ces vérifications concernent le contexte utilisé pour la construction. Les problèmes de capture sur le poste restent traités dans notre guide de configuration Granola.

Questions sur le prototype IA à partir d’une réunion client

Faut-il Granola si l’on possède déjà une transcription utilisable ?

Non. Vous pouvez fournir les passages nécessaires directement ou via une connexion existante adaptée. Granola est une option pour capturer les prochaines réunions et retrouver leur contexte.

Une clé API Granola est-elle nécessaire pour construire dans Lovable ?

Le connecteur personnel de chat utilise le parcours d’autorisation MCP. La connexion Granola pour le chat et l’application est différente et utilise une clé API.

Les notes Granola gratuites suffisent-elles pour ce prototype ?

Basic donne accès aux notes personnelles des 30 derniers jours via MCP. Certains outils de recherche, de dossiers et de transcription exigent une offre payante. Vérifiez l’entrée réellement disponible pour votre projet.

Le client aura-t-il accès à ma connexion Granola dans le prototype publié ?

Le connecteur personnel de chat ne fait pas partie de l’application publiée. Contrôlez toutefois le code, les textes et les données de démonstration pour vérifier qu’aucune information de réunion n’y a été recopiée.

Mon collègue peut-il réutiliser ma connexion personnelle ?

Non. Chaque personne établit sa connexion de chat et doit disposer des droits nécessaires sur les notes utiles.

Granola construit-il directement le prototype ?

Dans ce parcours, Granola fournit le contexte accessible de la réunion. Lovable prépare et construit le prototype à partir de ce contexte.

Que faire si une exigence ne renvoie à aucun passage de la réunion ?

Présentez-la comme une interprétation ou une question ouverte, puis faites-la confirmer. Ne lui attribuez pas une source inventée ni le statut de demande explicite.

Le prototype obtenu est-il immédiatement prêt pour un usage réel ?

Pas automatiquement. Vérifiez le périmètre approuvé, le comportement des interactions et, si vous ajoutez un serveur et des comptes, la conservation et les droits d’accès aux données.

Sources et limites de la méthode

Guide préparé à partir de la documentation officielle Granola et Lovable consultée le 10 octobre 2026. L’exemple d’agence est fictif. Les prompts, le tableau d’exigences et les contrôles constituent notre méthode proposée. Nous n’avons pas réalisé de construction authentifiée de bout en bout ni mesuré un gain de temps.

• Lovable — connecteurs personnels de chat et Granola
• Granola — accès MCP, outils et authentification
• Lovable — connexion Granola pour le chat et l’application
• Granola — clés API et périmètres d’accès aux notes
• Lovable — construire à partir du contexte des réunions Granola
• Lovable — examiner un plan avant de modifier le code
• Lovable — contexte persistant propre au projet
• Lovable — construire par étapes et vérifier le résultat
• Granola — fonctionnement de la transcription

Les connexions et droits peuvent évoluer. Rendre une réunion accessible à l’IA ne certifie ni l’exactitude de l’exigence ni la préparation de l’application pour un usage réel.