Une fois vos transcriptions de réunion accessibles via MCP, la question utile n’est plus « comment brancher tout ça » mais « qu’est-ce que je demande, concrètement ». La réponse à laquelle la plupart des gens arrivent au bout d’une semaine : surtout pas « résume ma dernière réunion ». Celle-là, l’application vous la donne déjà. Les prompts qui justifient l’installation sont ceux qui traversent plusieurs réunions, ou qui relient ce qui a été dit à autre chose sur quoi vous travaillez.
La mécanique compte pour en écrire de bons. Votre assistant ne lit pas toute votre archive. Il cherche, récupère une liste avec de courts aperçus, choisit ce qui paraît pertinent et lit ces éléments en entier — un prompt fonctionne donc mieux quand il donne à la recherche de quoi restreindre (une période, un sujet, une étiquette) et qu’il indique à l’assistant la forme que doit prendre la réponse.
Vingt prompts suivent, groupés par usage, puis ceux qui échouent et pourquoi. Ils sont écrits pour le serveur MCP de Speak-Y, mais rien en eux ne lui est propre : n’importe quel assistant capable de chercher dans des transcriptions et de les lire traitera les mêmes formes.
Cinq commandes lisent votre bibliothèque directement et fonctionnent que l’application soit ouverte ou non : lister les enregistrements, la recherche plein texte, lire une transcription, récupérer l’enregistrement le plus récent et lister vos étiquettes. Le listage et la recherche prennent les mêmes filtres — une plage de dates, une étiquette, les réunions seules, les favoris seuls — et c’est pourquoi « mes réunions de la semaine dernière » est une instruction bon marché quand « tout ce que j’ai jamais dit sur l’onboarding » coûte cher.
Une transcription peut être lue de quatre façons, et le choix change la réponse plus qu’on ne le croit : texte brut, blocs par intervenant, le résumé IA avec les tâches à faire, ou tout à la fois. Pour « qu’avons-nous décidé », le résumé suffit et coûte une fraction du contexte. Pour « qui s’est engagé à quoi », il vous faut les blocs par intervenant : un résumé aplatit l’attribution, et se trompe parfois.
1. Parcours mes réunions des deux dernières semaines et liste chaque engagement que j’ai personnellement pris, avec la réunion d’où il vient.
2. Parmi les tâches issues de mes réunions de ce mois-ci, lesquelles n’ont plus été mentionnées dans aucune réunion ultérieure ? — une approximation correcte de « abandonné en silence ».
3. Compare ce que nous avons dit de la feuille de route du T3 dans les trois derniers appels de planification. Qu’est-ce qui a changé, et quelqu’un a-t-il dit pourquoi ?
4. Lis mes entretiens individuels de ce trimestre et dis-moi quels sujets reviennent avec plus d’une personne.
5. J’ai un point d’avancement à rédiger. Extrais les décisions et les points de blocage de mes réunions de cette semaine et rédige-le en cinq puces.
Le numéro 3 est celui que les managers gardent. Une décision qui a bougé trois fois paraît parfaitement stable dans le dernier résumé ; seule la comparaison entre les appels montre qu’elle a bougé, et les transcriptions sont le seul endroit où le raisonnement a survécu.
6. Trouve mes appels avec Northwind et donne-moi une chronologie de ce qu’ils ont demandé, dans l’ordre.
7. Quelles objections sont apparues dans mes cinq derniers appels de vente, et comment ai-je répondu à chacune ?
8. Avant mon appel avec ce client : que lui avons-nous promis la dernière fois, et qu’est-ce qui reste en suspens ?
9. Lis mes appels de découverte de ce mois-ci et dis-moi quelles questions j’oublie systématiquement de poser.
10. Rédige un e-mail de suivi à partir de l’appel client d’hier — uniquement les points qu’ils ont réellement soulevés, rien d’inventé.
Le numéro 9 est inconfortable et mérite d’être lancé chaque mois. Votre propre schéma d’omissions vous est invisible sur le moment et devient évident sur dix transcriptions. La clause « rien d’inventé » du numéro 10 fait un vrai travail : sans elle, les modèles complètent obligeamment un suivi avec des engagements plausibles que personne n’a pris.
11. Qu’avions-nous convenu de changer dans la logique de réessai, et quelles objections ont été soulevées avant que nous nous mettions d’accord ?
12. Regarde dans mes réunions de cette semaine les bugs que nous avons promis de corriger, puis vérifie si certains sont déjà corrigés dans le dépôt.
13. Transforme les décisions sur l’API prises pendant l’appel de mardi en une courte spécification que je puisse mettre dans le README.
14. Avant que j’ouvre cette PR : avions-nous validé cette approche, ou est-ce la version que nous avions rejetée pendant l’appel ?
Ceux-là paient dans un éditeur, où l’assistant peut lire la transcription et le code dans une même session — la configuration de Cursor traite précisément ce cas. Le numéro 14 attrape une erreur réellement coûteuse : un design rejeté redevient raisonnable une semaine plus tard, parce que le raisonnement qui l’avait tué vivait dans une conversation que personne n’a écrite.
15. Résume tout ce qui a été discuté avec ce client au cours des six derniers mois, groupé par thème plutôt que par date.
16. Qu’est-ce que le client a validé, et qu’a-t-il seulement dit apprécier ? — la distinction qui tranche les disputes de périmètre.
17. Extrais les contraintes et les exigences de l’appel de lancement et confronte-les à ce que nous avons fini par construire.
Le numéro 15 est celui qui justifie à lui seul de garder l’archive. Six mois d’appels groupés par thème, c’est un document que personne n’a eu le temps d’écrire, produit à partir d’une matière qui existait déjà.
18. Étiquette les trois derniers enregistrements comme api-redesign.
19. Renomme Speaker 2 en Marta dans la réunion d’hier, puis relis-la et dis-moi ce sur quoi elle a émis des réserves.
20. Classe l’entretien de mardi dans notre canal de recrutement.
Ce sont les commandes qui modifient quelque chose, et elles se comportent
différemment : elles exigent l’application Speak-Y en cours d’exécution, et
elles sont déclarées à votre client MCP comme modifiant les données, si bien
qu’il demande confirmation avant de les exécuter, sauf autorisation permanente
de votre part. La spécification MCP dit explicitement que les clients
« DEVRAIENT » garder un humain dans la boucle et demander confirmation pour les
opérations sensibles. Le numéro 20 quitte votre machine et ne peut pas être
rappelé depuis la conversation : mieux vaut lire la demande de confirmation que
de cliquer au travers. Si vous préférez qu’un client donné ne puisse rien faire de
tout cela, lancez le serveur avec --read-only dans la configuration de ce
client-là, et les commandes modifiantes ne lui sont plus proposées du tout.
Miser sur une formulation exacte. La recherche est une correspondance de sous-chaîne insensible à la casse sur le texte des transcriptions, les titres, les résumés et les tâches à faire — pas une recherche sémantique. « Trouve la réunion où nous avons parlé de consolidation des fournisseurs » ne renvoie rien si la salle a dit « et si on prenait un seul fournisseur ». Décrivez la période et laissez l’assistant lire les résumés, plutôt que de parier sur la coïncidence entre vos mots et les leurs.
Interroger une réunion qui n’est pas synchronisée. Les enregistrements vivent sur l’appareil qui les a produits et se synchronisent depuis vos autres appareils. Chaque lecture indique la fraîcheur des données ; s’il manque quelque chose dont vous êtes certain, demandez d’abord une synchronisation à l’assistant. Sans cela, « ça n’existe pas » et « c’est sur mon portable » se ressemblent trait pour trait.
Lui demander de supprimer quelque chose. Aucun outil ne retire un enregistrement, un canal ou un espace de travail. La suppression reste dans l’application, délibérément.
Supposer qu’il voit toute l’entreprise. L’assistant lit votre bibliothèque, pas celle de vos collègues. Les réunions qu’un collègue a publiées dans un canal d’équipe partagé sont lisibles par les mêmes outils ; tout le reste de ce qu’il a enregistré ne l’est pas.
Poser une question à laquelle la transcription ne peut pas répondre. « Le client était-il agacé ? » vous vaut une supposition assurée fondée sur le choix des mots. Le ton n’est pas dans le texte, et un modèle ne vous dira pas qu’il devine si vous ne le lui demandez pas.
Les prompts ci-dessus partagent une forme, et elle se transpose :
Périmètre — une période, une étiquette, un nom de client, ou « les réunions seulement ». C’est ce sur quoi la recherche filtre, et l’omettre oblige l’assistant à deviner combien lire.
Source — quoi lire une fois la réunion trouvée : le résumé pour les décisions, les blocs par intervenant pour l’attribution, le texte intégral quand la formulation exacte compte.
Sortie — des puces, un tableau, un brouillon d’e-mail, une spécification. L’énoncer, c’est ce qui transforme un résumé en quelque chose d’utilisable sans retouche.
Périmètre, source, sortie. « Lis mes réunions avec Acme du mois dernier (périmètre), extrais ce qui a été promis et par qui (source), et donne-moi un tableau des engagements ouverts (sortie) » est un meilleur prompt que n’importe quelle phrase astucieuse.
Chaque prompt de cette page tourne sur des réunions auxquelles vous avez personnellement assisté, et c’est là le vrai plafond : l’essentiel du raisonnement derrière une décision s’est joué dans des appels où vous n’étiez pas. Les réunions publiées dans un espace d’équipe étendent les mêmes prompts à ce que vos collègues ont délibérément partagé, chiffré de bout en bout, si bien que « pourquoi avons-nous construit cela ainsi ? » cesse de dépendre de qui était dans la pièce.
Si vous n’avez encore rien connecté, le guide d’installation couvre l’installation en un clic depuis Paramètres → Intégrations, et la documentation MCP contient la référence client par client. Le serveur est gratuit sur toutes les formules, y compris Free.
Tout ce qui se déduit des transcriptions auxquelles il a accès : ce qui a été décidé, ce à quoi vous vous êtes engagé, comment les objections d’un client ont évolué d’un appel à l’autre, quelles tâches restent ouvertes. L’assistant cherche dans vos enregistrements, lit ceux qui paraissent pertinents et répond à partir de leur contenu plutôt que de mémoire.
Non, et cela fonctionne généralement mieux sans. Décrivez la période et le sujet — « mes réunions de cette semaine sur les tarifs » — et laissez l’assistant filtrer par date et lire les résumés. Nommer un fichier n’aide que lorsque vous savez déjà exactement lequel vous voulez.
Trois causes courantes. L’enregistrement se trouve sur un autre appareil et n’est pas encore synchronisé : demandez à l’assistant de synchroniser, puis réessayez. La recherche porte sur le texte littéral et votre formulation n’est jamais apparue dans la transcription. Ou la bibliothèque ne la contient réellement pas — l’assistant voit exactement ce que vous voyez dans l’application, et rien de plus.
Il peut les étiqueter, les renommer, nommer les intervenants d’une réunion, relancer la transcription et publier dans un canal d’équipe — mais seulement avec l’application Speak-Y en cours d’exécution, et ces commandes sont déclarées à votre client MCP comme modifiant les données, si bien qu’il demande confirmation avant de les exécuter. La lecture n’exige rien. Aucun outil ne supprime un enregistrement.
Uniquement ce qui a été partagé délibérément. Votre bibliothèque, c’est ce que vous avez enregistré ; les réunions qu’un collègue a publiées dans un canal d’équipe partagé deviennent lisibles par les mêmes outils, chiffrées de bout en bout, tandis que tout ce qu’il n’a pas partagé reste invisible.