Extraire les action items d'une réunion avec l'IA en 48h

22h, terminal clignotant, une vraie question : qu'est-ce qu'on construit ? Extraire action items réunion IA n'est pas un fantasme. C'est un extracteur d'action items à base d'IA, c'est un projet faisable un weekend. Un transcript, une pile de notes en vrac, et la machine rend une liste propre : qui fait quoi, avant quand. Le code c'est quelques heures de glue API. La question plus dure : tu trouves 20 utilisateurs pour ta version contre les cinq outils payants déjà sur le créneau ?

Ce qu'on entend vraiment par « action items », comme cible de build

Oublie le buzzword. La tâche est étroite : prends du texte non structuré (un transcript, une note vocale passée en texte, des messages Slack en vrac) et sors une liste de {task, owner, due_date, confidence}. Point. Pas de résumé automag, pas d'analyse de sentiment, pas de dashboard. De l'extraction pure dans une forme que ta TODO app peut avaler.

Ce qui change la scope : une « solution d'IA pour réunions » c'est six mois de travail avec transcription en temps réel, sync calendrier, une équipe UI qui va se battre. Extraire des action items c'est une prompt, un schéma JSON, et un endroit où mettre le résultat. Livrable avant que ton café refroidisse.

L'input n'a pas besoin d'être une réunion. Le même schéma sort les engagements d'une thread standup Slack, d'une file de tickets support, d'une note vocale du client qui raconte sa vie. Les réunions c'est la cible évidente parce que les transcripts existent déjà. Ça m'empêche qu'il y ait d'autres marchés.

Le stack qui te met de transcript à liste de tâches en 48h

Voilà le pipeline complet pour une v0 :

1. Input : copie-colle de transcript ou upload .txt / .vtt (pas d'audio live pour v0)
2. LLM : structured output, JSON schema forcé
3. Stockage : table Supabase ou même fichier JSON en v0
4. Output : checklist markdown + webhook optionnel vers Linear/Notion

La prompt d'extraction c'est la seule partie qui exige vraiment de l'itération. Quelque chose comme ça te met à 80% :

Extrais les action items du transcript ci-dessous.
Retourne un array JSON : [{task, owner, due_date, confidence}]
Règles :
- owner = nom mentionné, ou "à assigner"
- due_date = date explicite seulement, sinon null
- écarte les affirmations molles ("on devrait réfléchir à X")
- confidence : 0-1, selon le degré d'engagement réel

Wei-Chen Liao, qui bosse sur les systèmes de recommandation chez Appier à Taipei, le dit bien après un side project similaire : « la qualité d'extraction plafonne à la qualité du transcript, pas celle du model. Passe ton premier weekend à nettoyer l'input, pas à swapper de models ».

Le coût à l'échelle indie frôle zéro. Un transcript d'une heure traverse entre 8 000 et 12 000 tokens pour un appel structured-output. Aux tarifs actuels c'est une fraction de centime par réunion. Le vrai coût c'est la transcription si tu ne pars pas d'un texte déjà exporté.

Résiste à l'envie d'utiliser le model le plus gros. Un model petit, rapide, avec un JSON schema forcé et quelques exemples few-shot sort une extraction qui approche la précision d'un flagship model, avec une fraction de la latence et du coût. Garde le budget du plus gros model pour les cas où confidence revient faible et tu veux une deuxième passe, pas pour chaque appel.

Où le marché vit réellement, et ce n'est pas désert

Avant de coder, sais ce qui t'attend. Une teardown des outils d'extraction d'action items met les tarifs par personne entre 4 et environ 40 euros par mois, clivés en deux camps : extraction seule (notes propres, zéro routing) et full-loop (ticket créé dans Jira, Linear ou Asana avant que l'appel finisse).

Ce clivage c'est la partie utile. Le milieu engorgé c'est extraction-only : notes propres, pas de routing. Les outils qui automat le dernier kilomètre (créer le ticket) sont rares et affichent un prix plus élevé. Si tu scopes une v1, c'est ton coin : personne ne veut un résumé de plus. Ils veulent que le task existe quelque part quand l'appel ferme.

TicNote c'est un bon point de repère ici, pas parce que tu devrais le recommander à la place de coder, mais parce qu'il montre ce que « assez bon pour facturer » ressemble quand c'est petit : ça génère de vrais fichiers, pas juste un résumé balancé dans une fenêtre chat. C'est la barre.

Valide avant de polir la prompt au-delà de ce que quelqu'un demande vraiment. Balance ta v0 sur deux ou trois communautés de freelances ou indie hackers, offre de la lancer sur un vrai appel gratuitement, et regarde ce qu'ils font du résultat. Si personne ne t'envoie un transcript dans la semaine qui suit ta demande, c'est le signal pour changer de niche, pas de model.

Oublie le bot de réunion temps réel. Code la version async d'abord

Chaque tutoriel que tu vas trouver assume que tu codes un bot qui rentre dans l'appel live, écoute, et post sur Slack en direct. Passe ton chemin. Temps réel c'est du streaming audio, de la diarisation (pouvoir dire qui parle), un bot qui reste dans l'appel sans lag. Ça n'est pas un weekend. C'est le truc qui tue les side projects à la semaine trois.

La version async c'est la même logique moins les trucs durs : quelqu'un copie-colle un transcript (issu du built-in Zoom, d'Otter, d'un run Whisper sur un enregistrement) et récupère une liste de tâches en 30 secondes. C'est moins flash en démo vidéo. C'est aussi la version que tu peux réellement finir.

Il existe déjà un template n8n qui combine AssemblyAI et GPT-4 vers Google Sheets pour exactement ça. Ça vaut le coup d'étudier avant de toucher du code, et ça vaut le coup d'ignorer comme produit final : tout va dans un tableur, qui s'effondre au-delà de quelques douzaines de lignes et ne te donne rien sur quoi facturer.

Ce qu'un freelance à Bangkok veut que Jira n'offre pas

La version générique du truc c'est fait pour les équipes dans Jira ou Linear déjà. C'est un couloir engorgé et bien financé. La tranche mal servie c'est les consultants solo et les freelances, le type de personne que Napat Charoenwong écrit en tournant son studio à Bangkok, qui prend cinq appels client par semaine et n'a pas ou ne veut pas d'outil de PM du tout.

Pour cette personne, le win ce n'est pas le routing de ticket. C'est une liste de tâches qui débarque dans WhatsApp ou email après l'appel, étiquetée par client, avec zéro config à faire. Trois appels client bruts par semaine ça vaut mille sièges enterprise que tu fermeras jamais comme solo dev sans équipe sales.

C'est une vraie décision de scope, pas un nice-to-have : choisis un canal de livraison (digeste email c'est le moins cher à coder) et une seule persona étroite (freelances, coachs, consultants, quiconque facture à l'appel) avant de toucher à une deuxième intégration.

L'économie marche différemment selon les régions aussi. Un outil à 9 euros par mois ça semble trivial du point de vue US et ça ressemble à une facture réelle à Manille ou Bangkok, où le même freelance gagne assez par heure pour que le temps admin perdu c'est vraiment quelque chose. Fixe le prix sur la valeur de l'heure que tu économises, pas sur ce qu'une SaaS de la Silicon Valley affiche.

Pourquoi la version no-code plafonne avant la version payante

La route n8n-et-spreadsheet c'est le bon point de départ, mais elle a un plafond : des rate limits sur l'API transcription, un spreadsheet qui devient illisible au-delà de quelques douzaines de lignes, et aucun endroit pour mettre une login ou un abonnement. C'est un prototype, pas un produit.

Le move une fois que tu valides la demande : remplace le spreadsheet par une vraie table (Supabase ça marche bien à cette échelle), ajoute une auth, et mets un prix dessus. Tu n'as pas besoin de réécrire la logique d'extraction. Tu as besoin de ne plus stocker l'état dans un endroit où personne ne peut te payer.

Vaut de noter avant de s'enfoncer dans le pipeline : une audio de merde produit un transcript de merde, et un transcript de merde produit des action items de merde peu importe combien bien ta prompt est. Si tes utilisateurs cibles sont sur des appels pourris (mauvais wifi, bruit de fond, anglais avec accent à travers une team distribuée), une étape de cleanup audio genre Krisp en amont de la transcription te fera gagner plus de debug que de tuner la prompt d'extraction.

Tu factorises ou tu intègres ailleurs ?

Passe si tu espères que ça devient une SaaS standalone avec des chiffres venture. La catégorie affiche des prix bas (4 à 10 euros par personne c'est le plancher réaliste une fois que tu concurrence sur prix) et les géants ont déjà calendrier sync, apps mobiles, équipes sales. Un solo dev ne gagne pas ça de front.

Ça vaut le coup de coder si tu le traites comme une feature, pas comme une boîte : colle-le à une pratique de consulting comme valeur ajoutée, ship-le à 9 euros par mois pour une seule niche étroite que tu comprends déjà, ou utilise-le comme le cœur technique d'une portfolio piece qui te branche du freelance LLM integration work. Les trois sont des résultats réalistes pour un build weekend. « Battre Otter.ai » ce n'est pas le cas.

Si l'outil d'extraction c'est une pièce d'un toolkit plus gros que tu assembles pour tes clients, quelque chose comme Skywork ça vaut le coup de checker pour les livrables autour : le doc résumé client ou le one-pager que tu construirais d'habitude à la main autour de la liste brute de tâches.

Ce qu'on shippe réellement en premier

Une single page app : copie-colle un transcript, reçois une checklist, exporte en email ou copie en markdown. Pas de login en v0. Pas d'intégrations. Teste-le sur tes propres appels deux semaines avant de le montrer à quelqu'un, parce que la prompt d'extraction a besoin de vrais transcripts pour se casser dessus, pas de données test que tu as écrit toi-même.

Si ça survit tes propres appels sans louper un engagement évident, mets-le devant cinq freelances ou consultants que tu connais vraiment. Pas un post Reddit, pas un Product Hunt launch. Cinq personnes dont tu peux regarder les appels quand le résultat foire. C'est le programme complet du premier mois.

Que besoindraient tes dix premiers transcripts que le truc ne couvre pas encore ?