# Actions IA d'une réunion : guide du workflow CommanderGPT

URL: https://commandergpt.app/fr/journal/ia-compte-rendu-reunion-actions
Type: blog
Locale: fr
Published: 2026-07-22
Updated: 2026-07-22

---

> 3 slash commands pour transformer une transcription en actions assignées et datées. Le workflow `/recap → /sync → /notify` remplace 25 minutes de copier-coller par 90 secondes de review.

L'IA compte rendu réunion actions à faire n'existe que si elle franchit les 10 minutes après la fin de l'appel. La plupart ne les franchissent pas. La réunion se termine, tout le monde hoche la tête sur "on se reconnecter", et jeudi, personne ne se souvient plus qui doit faire quoi. Ce guide te livre une IA compte rendu réunion actions à faire , la chaîne exacte de commandes pour transformer une transcription brute en tâches assignées et datées dans Notion ou Linear, sans copier-coller. Elle repose sur trois slash commands et un service de notes au choix.

## Pourquoi les actions à faire disparaissent entre l'appel et le CRM

Personne n'abandonne les actions délibérément. Elles meurent dans le hiatus entre "quelqu'un l'a dit" et "quelqu'un en est responsable". Une transcription capture chaque "on devrait" et "tu peux" de la réunion, mais ce n'est pas une liste de tâches. C'est 4 000 mots de dialogue avec trois vrais engagements enfouis dedans.

La solution ne réside pas dans un meilleur outil. C'est une commande qui lit la transcription comme un ops lead le ferait : en cherchant un verbe, un propriétaire et une date, et en signalant tout ce qui manque de l'un de ces trois comme "flou" au lieu de deviner. [Le décorticage de Fellow sur le fonctionnement des agents IA en réunion](https://fellow.ai/blog/ai-agent-meeting-notes-to-tasks/) fait le même point côté éditeur : les outils qui gagnent ne sont pas ceux avec la plus belle transcription, ce sont ceux qui te remettent une liste de tâches à valider plutôt qu'à rebâtir.

La plupart des équipes possèdent déjà un outil de prise de notes. Ce qui leur manque, c'est la couche intermédiaire : l'étape entre "voici un résumé" et "voici une tâche dans le système que mon équipe utilise vraiment". Cette couche intermédiaire est une slash command, pas un nouveau SaaS, et c'est la partie que ce guide va effectivement construire.

## Étape 1 : Choisis l'outil de notes qui extrait vraiment le propriétaire et la date limite

Avant que la slash command ne touche à quoi que ce soit, tu as besoin d'une transcription structurée. Pas tous les outils de prise de notes n'extraient les actions à faire de la même façon, et la différence compte bien plus que le score de précision de transcription affiché sur la page d'accueil.

**Briefing, 30 secondes** : si un bot qui rejoins l'appel change ce que les gens sont prêts à dire dans un deal review, oublie les outils basés sur un bot et vise sans bot. Sinon, optimise sur la clarté avec laquelle l'outil sépare décisions et actions à faire.

La structure de résumé de Fathom est ce que tu veux obtenir d'emblée : elle sépare décisions, actions à faire et questions ouvertes en blocs distincts au lieu d'un mur de texte. C'est le format que ta commande `/recap` va parser à l'étape 2.

Fireflies penche sales-ops : il pousse les actions à faire directement vers les champs HubSpot ou Salesforce, ce qui est utile si tes actions à faire sont vraiment "les prochaines étapes de cette affaire" plutôt que des tâches internes.

Granola n'envoie pas de bot dans l'appel. Il transcrit localement et empile tes propres notes tapées sur la transcription, donc les actions à faire qu'il extrait sont ancrées à ce que tu as marqué comme important, pas juste à ce que l'IA a cru qui importait.

Choisis-en un. N'en lance pas deux sur le même appel en espérant cross-vérifier la précision. Ça double le travail de cleanup et la commande `/recap` ci-dessous compte sur une seule transcription canonique, pas deux qui se contredisent.

![Close-up of hands typing a slash command on a keyboard with a command palette on screen](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/commandergpt/2026-07/6b3b39-inline1-detail.webp)

## Étape 2 : Construis la commande /recap qui transforme la transcription en liste de tâches

Dans CommanderGPT, ouvre le Workflow Builder et crée une nouvelle commande appelée `/recap`. Le prompt fait trois choses, dans l'ordre :

- 
Récupère la transcription (colle-la, ou pointe la commande sur le lien d'export de l'outil si ton plan supporte l'export API)

- 
Extrait chaque phrase correspondant à un engagement : "je vais", "on devrait", "tu peux", "commençons"

- 
Pour chaque correspondance, affiche trois champs : tâche, propriétaire, date limite. Si le propriétaire ou la date limite manque, affiche "flou" au lieu de deviner

Cette troisième règle est celle que les équipes esquivent, et c'est celle qui compte. Une IA qui devine un propriétaire quand la transcription n'en nomme pas un déplace juste l'ambiguïté en aval ; tu découvres trois jours après que "l'équipe" ne l'a pas fait parce que personne dans l'équipe croyait que c'était le sien.

Voici le corps exact de la commande qu'un RevOps lead lance sur des call de deal review :

`/recap [colle transcription]
→ Extrait les actions à faire comme : - [ ] Tâche | Propriétaire | Date limite
→ Signale "flou" si le propriétaire ou la date manque, ne devinez pas
→ Ignore les décisions et les FYI, affiche uniquement les engagements actionnables`Lance-la une fois sur une vraie transcription avant de la faire confiance sur un vrai deal review. La première passe sur un appel de 45 minutes avec six participants a généralement besoin d'un tour de correction manuel : quelqu'un aura dit "tu peux regarder la tarification" sans nommer un "tu", et la commande devrait le signaler, pas silencieusement l'assigner à celui qui a parlé en dernier.

## Étape 3 : Achemine les actions à faire dans Notion ou Linear sans copier-coller

Une fois que `/recap` affiche une liste nette, la deuxième commande de la chaîne, `/sync`, prend cette liste et crée les vraies tâches. C'est l'étape que la plupart des équipes font à la main, et c'est celle qui coûte le plus de temps : copier six lignes d'un email récapitulatif dans six rangées Notion distinctes.

Si ton équipe vit déjà dans Notion, `/sync` mappe chaque ligne extraite à une entrée de base de données : nom de la tâche, propriétaire (associé à ta liste des membres), date limite et un lien vers l'enregistrement de la réunion. Pour les équipes d'ops proches de l'engineering qui roulent sur Linear, la même commande crée un problème à la place d'une rangée de base de données, tagué avec la date de la réunion pour qu'on puisse le tracer après.

L'association n'est pas automatique au premier lancement. `/sync` doit savoir quel champ Notion détient le nom du propriétaire et lequel détient la date limite, et Linear a besoin d'une équipe par défaut et d'un template de problème avant d'accepter un nouveau problème d'une commande au lieu d'un humain cliquant "New Issue". Oublie cette setup et la commande échoue silencieusement ou, pire, crée des problèmes dans le mauvais backlog d'équipe.

Le coût de setup est réel : compte 20 à 30 minutes pour mapper tes champs de base de données Notion ou tes templates de problème Linear la première fois. Après, c'est zéro entrée manuelle par réunion. Une équipe CS ops qu'on a vue lancer ça sur un appel de QBR prep hebdomadaire a coupé un nettoyage post-réunion de 25 minutes en une étape de review-and-approve de 90 secondes. Ce n'est pas un chiffre universel, ton propre temps de nettoyage dépend du nombre d'actions à faire qu'un appel type produit, mais c'est la forme de la victoire : des minutes d'examen remplaçant des minutes de re-frappe.

![Overhead flat-lay of a phone task list, notebook with checkmarks, and coffee on a desk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/commandergpt/2026-07/0ec777-inline3-flatlay.webp)

## Enchaîner /recap → /sync → /notify : le workflow qui se lance tout seul

La chaîne complète comprend trois commandes, pas deux. La troisième, `/notify`, envoie un DM Slack à chaque propriétaire avec ses actions à faire spécifiques et la date limite, juste après que `/sync` finisse d'écrire dans Notion ou Linear.

Enchaînées dans le Workflow Builder, la séquence ressemble à ceci : transcription entrante, `/recap` extrait, `/sync` crée les tâches, `/notify` ping les propriétaires. Aucun tableau de bord à consulter, aucun email récapitulatif à scanner. La personne qui possède la tâche l'apprend en moins d'une minute après la fin de l'appel, quand le contexte est encore assez frais pour qu'elle n'ait pas besoin de relire toute la transcription pour se souvenir pourquoi.

C'est ici que l'idée "3 commandes, 1 workflow, 0 friction" fait ses preuves : chaque commande remplit un rôle, et tu peux en swapper n'importe laquelle (un outil de notes différent, une destination différente, un canal de notification différent) sans rebâtir la chaîne.

![Small ops team standup meeting looking at a kanban board on a wall screen](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/commandergpt/2026-07/396092-inline4-ambiance.webp)

## Où ça casse : réunions récurrentes, gens discrets et verbes flous

Trois modes de défaillance à connaître avant de déployer ça sur toute une équipe, pas après.

Les réunions récurrentes dupliquent les tâches si `/sync` ne vérifie pas l'existence d'un élément ouvert portant le même nom de tâche avant d'en créer un nouveau. Ajoute un test de déduplication contre les tâches ouvertes des 14 derniers jours, ou tu vas te retrouver avec une base Notion pleine de rangées "suivre avec juridique" de six semaines différentes.

Les gens discrets se font sauter. Si quelqu'un s'engage à quelque chose dans un commentaire en marge ou un message de chat pendant l'appel plutôt que à voix haute, la transcription ne le voit jamais et `/recap` non plus. C'est un vrai creux, pas un problème d'ajustement : la commande extrait ce qui a été dit, pas ce qui était prévu.

Les verbes flous produisent des tâches floues. "Réfléchissons à la tarification" n'est pas une action à faire, c'est un sujet de discussion, et un `/recap` bien ajusté devrait le signaler comme flou plutôt que de fabriquer un faux propriétaire et une fausse date. Si ta commande produit des listes de tâches anormalement complètes à partir de réunions floues, elle déduit, elle n'extrait pas, et ça vaut la peine d'auditer.

## Ce qu'il faut mesurer après 30 jours

Ne prends pas juste la parole du workflow sur le fait qu'il marche. Deux chiffres à pister 30 jours après le déploiement : **taux de complétude** (des actions que `/recap` a extraites, combien ont été vraiment faites à leur date limite) et **taux de correction manuelle** (combien de fois tu as dû corriger un propriétaire ou une date que la commande a mal compris).

Si le taux de complétude reste plat par rapport à ta baseline pré-automation, le goulot n'est pas l'extraction, c'est le suivi, et aucune quantité d'enchaînement de slash command ne corrige un problème de responsabilité. Si le taux de correction manuelle est plus d'un sur cinq éléments extraits après les deux premières semaines, ton prompt `/recap` a besoin d'être resserré, pas ton outil de notes échangé. [Le guide de Fellow sur le tracking des actions à faire jusqu'à la complétude](https://fellow.ai/blog/how-to-track-action-items-steps-to-ensure-follow-through/) a un framework décent pour la partie taux de complétude si tu n'en as pas déjà un.

On ne te remet pas de benchmark du réseau ici. Mesure ta propre baseline dans la première semaine, puis compare.

## Prochaine commande à mettre en place

Commence par `/recap` seule. Lance-la sur ton prochain call de deal review ou QBR prep, copie manuellement la sortie dans Notion une fois, et vois combien de correction elle a besoin avant de câbler `/sync`. Enchaîner les trois commandes le jour un, avant de faire confiance à l'extraction, revient juste à automatiser la mauvaise liste de tâches plus rapidement.

Une fois que `/recap` produit des paires propriétaire-et-date nettes sur trois appels consécutifs avec moins de 20 % de correction, ajoute `/sync`. Ajoute `/notify` en dernier, une fois que la destination est bonne. Recon complète avant d'envoyer la chaîne entière à une équipe de 10 personnes.

## FAQ

### Le /recap command va-t-il deviner les propriétaires qui ne sont pas nommés explicitement ?

Non. Si un propriétaire ou une date manque, le command la signale comme 'flou' au lieu de inventer. Deviner déplace juste l'ambiguïté en aval — tu découvres trois jours après que personne ne savait que c'était le sien.

### Quelle est la différence entre Fathom, Fireflies et Granola pour ce workflow ?

Fathom sépare nativement décisions, actions et questions en blocs distincts (le format idéal). Fireflies pousse vers HubSpot/Salesforce (sales-ops focus). Granola transcrit localement et laisse toi-même annoter la transcription. N'en lance qu'un pour éviter dupliquer le cleanup work.

### Combien de temps coûte le setup du /sync command pour Notion ou Linear ?

20-30 minutes la première fois pour mapper tes champs Notion ou configurer tes templates Linear. Après, c'est zéro entrée manuelle par meeting — une CS ops team a coupé 25 minutes de cleanup en 90 secondes de review.

### Que faire si /notify envoie des Slack DMs mais que les gens ne font pas les tâches ?

L'extraction n'a jamais été le goulot. Mesure ton taux de complétude avant et après 30 jours. Si ça stagne, le problème est la responsabilité, pas la notification. Le /recap command t'aide juste à clarifier qui doit quoi — le reste est sur l'équipe.

### Comment éviter les doublons de tâches sur les réunions récurrentes ?

Ajoute un test de déduplication dans /sync : vérifie les tâches ouvertes avec le même nom depuis 14 jours. Si une existe, met à jour la date limite au lieu de créer une nouvelle.

### Puis-je lancer /recap, /sync et /notify en parallèle ou faut-il les chaîner ?

Chaîne-les : /recap d'abord (extrait la liste), puis /sync (crée les tâches), puis /notify (ping les owners). /sync a besoin de la sortie de /recap. C'est pour ça que le Workflow Builder existe — zéro frotte, tu lances une fois.