Pourquoi les assistants de réunion ne suffisent pas aux consultants
Comment Sparkier transforme une conversation en livrable client contextualisé
Publié le 1 octobre 2026
Temps de lecture : 15 minutes
Un compte rendu de réunion peut être parfaitement fidèle à ce qui a été dit et pourtant être presque inutile.
Il peut reprendre les bons sujets, identifier quelques actions et produire une synthèse impeccable. Mais s’il ne sait pas pourquoi le rendez-vous a lieu, ce qui a été vendu, ce que le client cherche à accomplir, où en est la mission et quelle expertise le consultant mobilise, il ne comprend qu’une petite partie de la conversation.
C’est le problème que j’ai voulu résoudre avec Sparkier.
Je ne voulais pas ajouter un énième bot à Google Meet. Nous avons intégré l’appel directement au cœur de la mission, puis construit toute la chaîne qui relie la conversation au travail à accomplir : enregistrement par participant, transcription adaptée au vocabulaire de la mission, reconstruction chronologique des échanges, génération contextualisée, édition par le consultant et partage avec le client.
Le résultat n’est pas seulement un résumé de réunion. C’est un brouillon de livrable client, disponible environ une minute après la fin d’un rendez-vous d’une heure — et plus rapidement encore pour les appels plus courts.
Voici pourquoi cela demandait une architecture différente.
Le problème n’est plus de transcrire une réunion
Les outils de transcription ont énormément progressé. Obtenir le texte d’une conversation, une liste de sujets et quelques prochaines actions est devenu relativement accessible.
Mais le métier d’un consultant ne consiste pas à restituer tout ce qui a été dit.
Après un rendez-vous, il faut souvent distinguer :
- ce qui relève d’une simple discussion et ce qui constitue une décision ;
- ce qui était déjà connu de ce qui change la trajectoire de la mission ;
- ce que le client a explicitement demandé de ce dont il a réellement besoin ;
- ce qui incombe au consultant, au client ou à une autre partie prenante ;
- ce qui doit être fait maintenant de ce qui peut attendre ;
- ce qui mérite d’apparaître dans un livrable client de ce qui doit rester une note de travail.
Un transcript ne porte pas seul ces distinctions. Elles dépendent du contexte de la mission.
Prenons une phrase très simple :
« On peut partir là-dessus pour la semaine prochaine. »
Sans contexte, un modèle peut en faire une prochaine action générique. Avec le contexte, cette phrase peut signifier qu’un client vient de valider une recommandation prévue dans l’offre, qu’un livrable doit être adapté, que le consultant s’est engagé sur une échéance et qu’un arbitrage précédent est désormais clos.
Les mots sont les mêmes. Leur valeur professionnelle ne l’est pas.
C’est pourquoi j’ai déplacé la question. Non plus : « Comment produire le meilleur résumé possible ? », mais :
Quelles informations faut-il réunir pour produire le compte rendu qu’un excellent consultant aurait lui-même envie d’envoyer ?
L’appel devait faire partie de la mission
Avant cette évolution, les rendez-vous Sparkier étaient organisés dans Google Meet. Cela fonctionnait pour la visioconférence, mais nous rendait dépendants d’un transcript externe dont nous ne contrôlions ni le démarrage, ni le cycle de vie, ni la reprise en cas d’erreur.
D’un côté se trouvait la mission : son client, son consultant, son offre, son brief, ses rendez-vous et son historique. De l’autre se trouvait l’appel, tenu dans un outil externe.
À la fin de la réunion, il fallait réconcilier ces deux mondes. Et parfois, l’artefact attendu n’était tout simplement pas celui de la véritable conversation.
Prenons un cas extrêmement courant : le consultant ouvre le lien quelques minutes en avance pour vérifier son micro, puis raccroche avant l’arrivée du client. Pour Google Meet, cette première connexion peut constituer une conférence à part entière. La transcription démarre, s’arrête lorsque le consultant quitte l’appel et produit un document vide. Lorsque le vrai rendez-vous commence sur le même lien, la transcription ne repart pas toujours correctement.
Pour l’utilisateur, il ne s’est pourtant rien passé d’exceptionnel. Il a simplement testé son lien avant un rendez-vous. Si ce geste suffit à compromettre le compte rendu, l’architecture n’est pas assez fiable pour devenir une brique centrale du travail du consultant.
Un assistant qui rejoint une visioconférence voit principalement un événement de calendrier, une liste de participants et une conversation. Sparkier connaît déjà la relation dans laquelle cette conversation s’inscrit — et peut faire correspondre le début et la fin de l’enregistrement avec le véritable rendez-vous.
Nous avons donc intégré les appels directement dans l’application avec Stream. Le lien Sparkier est désormais le lieu du rendez-vous. Il ne crée plus de Google Meet en parallèle. Nous contrôlons toute la chaîne, depuis la première piste enregistrée jusqu’au livrable disponible dans le dossier de mission.
Ce choix ne sert pas seulement à proposer une expérience plus intégrée. Il nous permet de connaître, avant même le premier mot prononcé :
- la mission concernée ;
- le type de rendez-vous ;
- l’identité et le rôle des participants ;
- le brief du client ;
- l’éventuelle offre Spark achetée ;
- le profil du consultant ;
- les autres rendez-vous liés à la même mission.
Ce contexte ne doit plus être reconstitué après coup. Il fait partie du système dès le départ.
Principe n° 1 : ne pas demander à l’IA de deviner ce que Sparkier sait déjà
Dans un compte rendu, attribuer une phrase à la mauvaise personne n’est pas une petite imprécision.
« Je m’en occupe pour mardi » peut devenir un engagement du consultant ou une action attendue du client. Une erreur de locuteur suffit alors à transformer une bonne transcription en mauvais outil de pilotage.
Un enregistrement standard de visioconférence mélange généralement toutes les voix dans un même fichier. Il faut ensuite effectuer une diarisation : détecter les différents locuteurs, distribuer les passages entre « Speaker A » et « Speaker B », puis tenter de retrouver qui se cache derrière chaque étiquette.
Google Meet sait associer les prises de parole à ses participants dans les transcripts qu’il génère lui-même. Mais il ne fournit pas, via ses API disponibles à tous, une piste audio complète et persistante par participant que nous pourrions confier à notre propre moteur de transcription. Son accès aux flux audio bruts reste limité à une Media API en preview.
Nous ne voulions ni dépendre du transcript de Google, ni reconstruire des pistes depuis des flux expérimentaux. Nous voulions que la piste individuelle soit la donnée de départ. C’est pourquoi nous avons choisi Stream.
Dans Sparkier, chaque participant est déjà identifié par la plateforme et rattaché à son rôle dans la mission. Stream enregistre nativement une piste individuelle et persistante pour chacun d’eux. L’identité accompagne donc la parole depuis l’appel jusqu’au transcript, puis du transcript jusqu’au livrable.
Nous ne demandons jamais à un modèle de reconnaître la voix du consultant ou de deviner qui est le client. Nous le savons.
Cette décision apporte trois garanties très concrètes :
- les interventions portent immédiatement les bons rôles, sans « Speaker A » ni « Speaker B » ;
- les décisions, engagements et prochaines actions restent associés à la bonne personne ;
- un participant silencieux ne bloque rien : sa piste est simplement enregistrée comme vide pendant que les autres suivent leur traitement.
Depuis le lancement, nous n’avons relevé aucune erreur d’attribution.
Stream cite d’ailleurs le traitement par l’IA et la fiabilité de l’attribution parmi les usages naturels des enregistrements individuels.
C’est un principe que nous avons appliqué à toute l’architecture : la meilleure manière d’améliorer une décision de l’IA est parfois de faire en sorte qu’elle n’ait plus à la prendre.
Principe n° 2 : adapter la transcription à chaque conversation
Nous envoyons chaque piste séparément à AssemblyAI.
La langue est détectée automatiquement pour chaque participant. C’est particulièrement utile dans les missions où les échanges passent naturellement du français à l’anglais, ou lorsque les interlocuteurs ne s’expriment pas tous dans la même langue.
Reste une difficulté plus discrète : une conversation de conseil contient souvent des noms d’entreprise, des produits, des acronymes, des anglicismes et un vocabulaire métier que la reconnaissance vocale rencontre rarement dans le langage courant.
Nous préparons donc des termes clés utiles à la conversation afin d’orienter le modèle de transcription. AssemblyAI recommande ce type de key terms prompting pour les noms propres, acronymes, produits et termes spécialisés dans sa documentation sur les assistants de réunion.
Depuis le lancement, tous les termes métier que nous avions identifiés ont été correctement transcrits. Noms de produits, acronymes, vocabulaire sectoriel : le transcript parle enfin la même langue que le consultant et son client.
Le transcript brut reste stocké afin que nous puissions auditer le résultat, reprendre un traitement interrompu et améliorer la chaîne sans perdre la source initiale.
Principe n° 3 : reconstruire une conversation, pas juxtaposer des monologues
L’enregistrement séparé résout un problème et en crée un autre.
À la fin de la transcription, nous avons une excellente piste du consultant et une excellente piste du client. Mais si nous plaçons simplement l’intégralité du texte du consultant avant celle du client, nous détruisons la conversation.
On obtiendrait quelque chose comme ceci :
Consultant : toutes ses interventions pendant une heure.
Client : toutes ses interventions pendant une heure.
Chaque bloc peut être exact, mais leur combinaison raconte une réunion qui n’a jamais eu lieu. Les questions sont séparées de leurs réponses, les validations de ce qu’elles valident et les objections des arguments auxquels elles répondent.
Nous avons donc construit une étape de recomposition déterministe.
AssemblyAI segmente chaque piste en phrases horodatées. Sparkier fusionne ensuite ces phrases selon leur position réelle dans le temps, en leur attribuant un rôle explicite — Consultant ou Client — et en conservant les chevauchements lorsque deux personnes parlent simultanément.
Le LLM reçoit une conversation chronologique de ce type :
Consultant — 14:03:12 : Si nous priorisons l’onboarding, nous pouvons tester une première version avant la fin du mois.
Client — 14:03:19 : Oui, c’est plus important que le nouveau tableau de bord.
Consultant — 14:03:23 : D’accord. Je modifie la recommandation et je vous envoie le nouveau découpage mardi.
L’ordre n’est pas demandé au LLM. Il est établi avant la génération par une règle reproductible à partir des timestamps.
Cette distinction est importante : nous utilisons les modèles pour interpréter ce qui nécessite du jugement, pas pour reconstruire approximativement des faits que le système peut déterminer.
La même logique fonctionne lorsqu’un rendez-vous comporte plusieurs sessions d’appel, par exemple après une reconnexion. Le livrable reçoit un transcript unique, chronologique et segmenté à l’échelle de l’ensemble du rendez-vous.
Principe n° 4 : donner au modèle le contexte de la mission
Une fois la conversation reconstruite, Sparkier rassemble les informations qui lui donnent du sens.
La génération peut s’appuyer sur quatre grandes sources :
1. Le transcript chronologique
Il contient ce qui a réellement été dit, qui l’a dit et dans quel ordre.
2. L’offre Spark
Lorsqu’une offre est associée à la mission, elle indique la promesse faite au client, le périmètre de l’accompagnement et les résultats attendus. Le modèle peut ainsi distinguer une discussion périphérique d’un élément central du travail vendu.
3. Le brief du client
Il explique le point de départ : le besoin exprimé, les contraintes, le contexte de l’entreprise et les attentes initiales.
4. Le profil du consultant
Il apporte son domaine d’expertise, son positionnement et la manière dont son intervention s’inscrit dans la mission.
Le transcript reste la source de vérité sur la conversation. Les autres éléments ne servent pas à inventer ce qui n’a pas été dit. Ils servent à comprendre pourquoi cela compte.
C’est là que se situe notre différence principale avec un résumé générique. Le modèle n’analyse pas un fichier isolé. Il travaille à l’intérieur d’un dossier de mission.
Nous avons mis les deux approches face à face : un livrable généré à partir du transcript seul, puis le même livrable enrichi du contexte Sparkier. Tous les testeurs ont préféré la version contextualisée.
Le résultat ne se contente pas d’être mieux écrit. Il comprend mieux ce qui compte.
Du résumé au livrable client
Le mot « résumé » suggère une version plus courte de la réunion. Ce n’est pas notre objectif.
Un bon livrable peut omettre une partie importante de la conversation si elle n’apporte rien à la suite. À l’inverse, une décision exprimée en une seule phrase peut mériter une place centrale.
Le compte rendu généré par Sparkier cherche à faire ressortir :
- les insights importants pour la mission ;
- les décisions et arbitrages ;
- les recommandations formulées ;
- les points qui restent ouverts ;
- les prochaines actions ;
- leurs responsables lorsque cela est établi ;
- les éléments utiles à la préparation du prochain rendez-vous.
Le but n’est donc pas l’exhaustivité. C’est la pertinence opérationnelle.
Dans la quasi-totalité des premiers cas, les consultants ont utilisé le livrable tel quel, sans avoir à écrire une ligne. C’est exactement l’expérience que nous cherchions : ouvrir un document déjà utile, plutôt que recevoir une matière brute à retravailler.
Lorsqu’une modification est nécessaire, le consultant peut intervenir directement dans le document ou demander une transformation plus profonde à l’IA. Il peut par exemple changer la structure, préciser un passage, modifier le ton ou réorganiser les prochaines actions sans repartir d’une page blanche.
Le livrable reste néanmoins un brouillon tant que le consultant ne l’a pas validé.
Pourquoi nous ne laissons pas l’IA envoyer seule
Un compte rendu client engage le consultant.
Même lorsque la génération est excellente, nous ne voulons pas qu’un modèle décide seul qu’un document est prêt à être envoyé. Sparkier informe le consultant que le brouillon est disponible. Celui-ci peut le lire, le modifier, le régénérer, le supprimer ou l’envoyer.
Cette validation humaine n’est pas un aveu de faiblesse de l’IA. Elle correspond à la réalité professionnelle du conseil : l’automatisation prépare le travail, mais le consultant conserve la responsabilité de la relation et du message envoyé.
Nous appliquons le même principe lorsqu’une réunion très courte, silencieuse ou atypique ne contient pas assez de matière pour un livrable substantiel. Sparkier ne bloque plus arbitrairement la génération en fonction d’une durée minimale ou d’un nombre de locuteurs. Il produit un brouillon que le consultant peut examiner et écarter.
Le système ne régénère pas non plus silencieusement un document déjà préparé lorsque de nouveaux échanges sont détectés. Il signale qu’une version plus récente est possible et laisse le consultant décider. Un document client ne doit pas changer dans son dos.
Environ une minute après un rendez-vous d’une heure
La génération d’un excellent compte rendu perd une partie de sa valeur si elle arrive le lendemain, lorsque le consultant a déjà dû écrire son email ou préparer la suite.
Nous avons donc conçu la chaîne pour démarrer dès que ses dépendances sont réellement prêtes.
Après la fin de l’appel :
- Stream finalise les pistes individuelles et informe Sparkier de leur disponibilité.
- Chaque piste audio est envoyée à AssemblyAI.
- Les transcriptions sont segmentées en phrases et stockées.
- Sparkier vérifie que tous les artefacts attendus sont prêts, y compris les pistes silencieuses.
- Les phrases sont fusionnées chronologiquement.
- Le contexte de la mission est assemblé.
- Le brouillon est généré et le consultant est notifié.
La génération n’attend pas le prochain passage d’une tâche planifiée à la minute. Un webhook la déclenche dès que le transcript est prêt. Une vérification périodique reste présente comme filet de sécurité lorsqu’un événement externe est retardé ou manque.
Un rendez-vous de 60 minutes produit son brouillon environ une minute après la fin de l’échange. Les appels plus courts sont traités plus rapidement encore.
Cette vitesse vient d’un choix d’architecture : les pistes sont traitées en parallèle et chaque étape déclenche immédiatement la suivante. Aucun traitement n’attend inutilement qu’une horloge lui donne la permission de démarrer.
La partie invisible : concevoir aussi les échecs
Une démo suit toujours le chemin idéal. Un produit utilisé au quotidien doit gérer tout le reste.
Que se passe-t-il si un participant reste silencieux ? Si Stream produit plusieurs artefacts ? Si AssemblyAI refuse un fichier ? Si deux événements essaient de lancer la génération au même moment ? Si la génération réussit mais que l’email de notification échoue ? Si une relance intervient après un timeout ?
Nous avons traité ces cas comme une partie du produit, pas comme une couche technique secondaire.
Une piste silencieuse ne bloque pas la mission
Elle est stockée comme vide et les autres pistes restent utilisables.
Une erreur de transcription échoue explicitement
Le livrable ne reste pas bloqué pendant trente minutes avant d’afficher un timeout générique. Le système remonte la cause connue — soumission, traitement audio ou événement d’enregistrement — afin de permettre une reprise adaptée.
Deux déclenchements ne créent pas deux livrables
La génération est revendiquée de manière atomique. Les événements concurrents ne produisent ni brouillons en double ni notifications multiples.
Une activité en cours n’est pas confondue avec un traitement abandonné
La détection des tâches obsolètes repose sur la dernière activité, et non uniquement sur la date de création. Une relance après timeout ne rééchoue donc pas immédiatement pour la même raison.
Les notifications peuvent être reprises sans être envoyées deux fois
Les emails transactionnels utilisent des clés d’idempotence. Si un envoi a réussi mais que sa confirmation s’est perdue, une relance ne doit pas expédier un doublon au client. Les échecs temporaires sont repris automatiquement pendant une période limitée.
Depuis le lancement, aucun traitement n’a terminé en échec. Mais le plus important se trouve derrière ce chiffre : lorsqu’un incident survient, Sparkier sait où le traitement s’est arrêté, ce qui a déjà réussi et ce qu’il faut relancer. La robustesse ne vient pas de l’absence d’imprévus. Elle vient de la capacité du produit à les absorber.
Enregistrement, conservation et contrôle
Une architecture capable de produire un compte rendu très riche manipule nécessairement des données sensibles. La confiance ne peut pas être ajoutée après coup.
Sur ce sujet, nous avons fait des choix clairs. Les utilisateurs sont informés de l’enregistrement et de ses finalités dès leur inscription. Les enregistrements audio et les transcripts sont conservés pendant deux ans afin de maintenir la continuité de la mission. Leur traitement et leur transit restent dans l’Union européenne. Ils ne sont pas utilisés pour entraîner des modèles d’IA.
Le consultant garde le contrôle. Il peut consulter ces éléments et les supprimer depuis Sparkier. La suppression retire alors les enregistrements audio et les transcripts de l’ensemble du système. Le support n’y accède que lorsque son intervention est nécessaire pour résoudre un problème.
Pour vérifier un échange, le consultant dispose déjà d’un replay audio et d’une recherche dans le transcript. Il peut retrouver une réplique et, en cliquant dessus, rejoindre le passage correspondant dans l’enregistrement.
Nous voulons maintenant prolonger ce parcours jusqu’au compte rendu. La prochaine étape consiste à relier les citations et les affirmations importantes du livrable aux répliques qui les fondent. Le consultant pourra alors partir d’une formulation du compte rendu pour retrouver directement l’échange dont elle est issue.
Ce que montrent nos 10 premiers appels
Les premiers résultats confirment déjà la valeur de cette architecture :
- un appel de 60 minutes transformé en brouillon en une minute environ, et encore moins d’attente pour les appels plus courts ;
- zéro erreur d’attribution ;
- zéro échec final de la chaîne ;
- tous les termes métier identifiés correctement transcrits ;
- des livrables utilisés tels quels dans la quasi-totalité des cas ;
- une préférence unanime pour la génération contextualisée face au transcript seul.
Dix appels, c’est le début. Mais le signal est déjà très clair : la qualité ne vient pas d’un prompt miracle. Elle vient de toute la chaîne construite autour du modèle.
Ce que cette architecture change pour un consultant
La valeur ne se limite pas aux minutes économisées après chaque appel.
La continuité de la mission devient native
Chaque rendez-vous appartient à un même dossier. Les décisions, prochaines étapes et livrables ne sont plus dispersés entre le calendrier, la visioconférence, les notes personnelles et les emails.
Le compte rendu cesse d’être une tâche administrative
Le consultant ne part plus d’un transcript brut ni d’une page blanche. Il reçoit une proposition structurée à valider.
L’expertise reste visible
Un résumé générique peut aplatir la valeur du conseil en donnant autant de poids à chaque sujet abordé. Le contexte de l’offre et du consultant permet de faire ressortir les recommandations qui constituent réellement la prestation.
Le client sait ce qui se passe ensuite
Les décisions et responsabilités ne restent pas enfouies dans la conversation. Elles deviennent des prochaines actions explicites.
La qualité devient plus régulière
La fatigue, l’enchaînement des appels ou le manque de temps ne devraient pas déterminer la qualité du suivi reçu par un client.
Le consultant garde la main
Il choisit ce qui est envoyé, peut modifier le document directement ou avec l’IA, et contrôle les enregistrements associés.
Cette combinaison est essentielle. Une automatisation qui fait gagner du temps mais affaiblit la maîtrise de la relation client n’est pas un progrès.
Nous n’avons pas construit un bot de réunion
Un bot de réunion commence lorsque l’appel débute et termine son travail lorsque le résumé est envoyé.
Sparkier connaît la mission avant l’appel. Il sait dans quel accompagnement le rendez-vous s’inscrit, ce que le client a demandé et ce que le consultant propose. Après l’appel, le compte rendu rejoint le dossier, prépare les prochaines actions et maintient la continuité du travail.
C’est pourquoi la transcription, aussi importante soit-elle, ne constitue qu’un maillon de la chaîne.
La qualité finale vient de l’ensemble :
- une identité connue à la source ;
- des pistes audio séparées ;
- une transcription adaptée au vocabulaire ;
- une chronologie reconstruite de manière déterministe ;
- un contexte métier complet ;
- un modèle chargé d’interpréter, pas de deviner les faits disponibles ;
- une validation humaine ;
- une infrastructure capable de reprendre ses erreurs ;
- un livrable intégré à la mission et accessible au client.
Ma conviction est simple : l’avenir des outils pour consultants ne consiste pas à ajouter de l’IA à chaque étape isolée. Il consiste à donner à l’IA la continuité nécessaire pour comprendre le travail dans son ensemble — tout en laissant le professionnel décider du résultat.
La prochaine fois qu’un rendez-vous se terminera dans Sparkier, le consultant ne retrouvera pas seulement une trace de ce qui vient de se passer.
Il retrouvera la suite de sa mission.