Le batsignal est dans le ciel, merci d’être venu 🦇 !

Dans cette 2de édition, tu vas comprendre comment automatiser la partie speech-to-text !
=> À la fin de la réunion Meet, le visiobot t’enverra la transcription de la réunion par mail.
Pour ce faire, j’ai fait le choix du NoCode avec Make.
Make est une plateforme qui permet d’automatiser des process visuellement, sans avoir à coder.

Si tu souhaites reconstruire ce prototype toi-même, tu trouveras le code source dans les ressources.

Pas de blabla, rentrons dans le vif du sujet ! 👇

Le programme des réjouissances

1. Introduction

2. Le prototype en vidéo

3. Top 5 des trucs à retenir

4. Explication “d’un bout de code”

5. Bonus : l’idée business et pour aller plus loin

6. Le mot de la fin

Introduction

Si tu as raté la 1re édition, je te fais un rapide rappel :
- un visiobot, c’est un programme informatique (un bot) capable de s’inviter dans une visioconférence. Et d’y ajouter des fonctionnalités.
- dans la 1re édition, j’ai mis en place le bot, sans automatiser le speech-to-text.
Si ça t’intéresse => VisioBot Partie 1
Pas besoin de l’avoir suivie pour comprendre la partie d’aujourd’hui.

J’ai fait évoluer le format par rapport à la semaine dernière.
J’ai privilégié une vidéo courte et dynamique ( < 5 min) :
- je te montre le résultat final
- je construis le prototype en accéléré

Et je t’explique les points importants par écrit, directement dans le mail.
N’hésite pas à me dire ce que tu penses de cette méthode !

Le prototype

Schéma

Parce qu’un schéma vaut 1000 mots !
L’architecture du prototype d’aujourd’hui, avec des lego :

Tout l’enjeu c’est de comprendre comment les imbriquer 🙂.

La vidéo

Je te laisse la regarder et on se retrouve après :)

Je t’explique tout ensuite.

Explication : Top 5 de ce que tu dois retenir

1. Pourquoi le service rev.ai ?

Ce qu’il faut comprendre, c’est que ce service peut être remplacé par n’importe quel autre service de speech-to-text : assemblyAI, Whisper, Amazon Transcribe, Azure Speech to text, etc.

J’ai choisi rev.ai car ils ont un SDK* pour Node qui est simple à utiliser.
(Pour rappel, Node, c’est la techno utilisée pour faire ce prototype, avec du Typescript).

*Un SDK (Software Development Kit) est un outil qui facilite l’utilisation d’un service avec du code.
Ça évite de réinventer la roue, tu utilises directement la roue fournie par le service.
Tu gagnes donc du temps !

Ensuite, rev.ai a un bon rapport qualité-prix, même s’il n’est pas toujours très juste pour le français.
Tu as le droit à 5 heures de transcription offertes par mois.
Donc largement de quoi t’amuser pour ton usage personnel !

2. Quand envoyer l’audio à rev.ai ?

Dans l’idéal à la fin du Google Meet si tu arrives à détecter quand le meet se termine.

Quand je fais un prototype, je cherche toujours la solution la plus simple et efficace.
Pas la plus belle.

Puppeteer, la librairie qui permet de scripter le bot, traque pour toi quand une page se ferme, quand le navigateur est ouvert ou fermé … => Bingo !
Quand le Meet est terminé, tu fermes le navigateur du bot.
La solution n’est pas idéale, mais elle fonctionne très bien :

browser.once('disconnected', async () => {
    //les actions que tu veux faire ensuite
  });

Quand Puppeeter perd la connexion avec le navigateur, il envoie un évènement ‘disconnected’.
Cet évènement sert aussi à gérer quand le navigateur plante et que tu souhaites le redémarrer.

3. Synchrone / asynchrone, quésaco ?

Quand tu fais la queue dans un magasin, tu es bloqué et tu dois attendre de passer à la caisse. Tu ne peux rien faire d’autre.
C’est synchrone.

Quand tu souhaites une pizza à emporter, tu commandes, tu t‘occupes et tu vas la chercher quand elle est prête .
C’est asynchrone. Tu peux faire autre chose le temps de la préparation de la pizza.

L’utilisation d’un service speech-to-text est asynchrone.
Tu passes commande pour faire la transcription de ton audio.
Puis tu attends qu’elle soit prête.
Quand elle est prête, tu la récupères.

Petit détail : Le code de début de la doc de rev.ai a une erreur pour cette raison (Doc rev.ai).
Il n’attend pas que la commande soit prête pour la demander et je ne comprenais pas l’erreur au début ^^.
Il faut attendre.

4. C’est quoi un webhook et à quoi ça sert ?

La pêche, tu connais forcément ? C’est pareil.
Le webhook c’est ton hameçon.
Il attend que ça morde.
Le poisson ? C’est la donnée que tu veux récupérer.
Dans notre cas c’est l’id du job qui s’occupe de transcrire notre audio.

Quand ça mord, tu reçois la donnée, elle s’accroche à ton hameçon : le webhook.
Tu tires et tu récupères la donnée.

La technique du Webhook est très utilisée pour transmettre des données entre des outils.
Par exemple, j’ai créé un webhook avec Make, qui permet d’envoyer des données : code du visiobot => Make.

5. Pourquoi avoir utilisé Make ?

Comme je te l’ai dit sur la partie synchrone / asynchrone : quand tu fais ta commande pour transcrire ton audio, tu dois attendre qu’elle soit prête.
Sauf que rev.ai est feignant et ne te le dit pas** :/ (en fait si, je t’explique plus bas).
Tu dois donc lui demander régulièrement quand c’est prêt.

Avec Make, c’est facile de lancer une tâche toutes les N minutes.
Tu crées un scénario et voilà !

Après avoir reçu la transcription, tu décides de l’envoyer par mail.
Mais ça peut vite être prise de tête de le faire avec du code.
L’avantage, c’est que Make le fait pour toi et ça t’évite de réinventer la roue !
Pragmatisme, encore et toujours ! :P

Entre nous, configurer Make pour qu’il puisse envoyer un mail depuis un gmail perso, ce n’est pas si simple :/
Le tuto est ici : Make et Gmail (Integromat, c’est l’ancien nom de Make).
Ce n’est pas très compliqué, mais tu as quand même une manip’ non évidente à faire.

À part cette petite mésaventure pour configurer le mail, l’algorithmique est plutôt simple :

• Il faut mettre en place un webhook pour recevoir l’id du job (qui processe la transcription de l’audio).

• Quand le webhook reçoit l’id (à la fin d’une visio), il stocke cet id dans le data store de Make. C’est une base de données intégrée.

• À chaque minute, un scénario vérifie les id du data store.

  • Et il regarde si le transcript est prêt :

    • C’est prêt : il envoie mail avec le texte et supprime l’id dans le store (car on n’en n’aura plus besoin)

    • Ce n’est pas prêt : on attend.
      

** Je me suis rendu compte (jeudi dernier) qu’il y avait une solution plus simple. Je n’ai pas eu le temps de changer le code.
Quand tu envoies l’audio pour la transcription, tu peux aussi donner l’url d’un webhook. Quand le travail est terminé, rev.ai envoie le résultat directement à ce webhook.
C’est donc beaucoup plus simple !
Dans la doc de rev.ai Rev.ai Doc, c’est le paramètre “notification_config”.
Si tu souhaites refaire ce prototype, je t’invite plutôt à partir sur cette solution 🙂

Explication “d’un bout de code”

try {
    //Ton code
  } catch (error) {
    console.log(error);
}

Ce bout de code sert à gérer les erreurs dans ton code et éviter que ton programme plante sauvagement.
S’il plante, tu peux gérer l’erreur, contrôler le comportement de ton programme et afficher un message que TU as décidé.

Bonus

L’idée business

Problème ?
Tu veux ajouter des fonctionnalités à tes réunions visios mais c’est compliqué :
- transcription puis services tiers (indexation des visios, prise de note, remplissage auto de formulaire, etc.)
- système de commande vocale
- mesure de l’attention des participants et actions
Bref, beaucoup de possibilités, mais les outils visios (Zoom, Meet, Teams) ont des API très peu permissives.
Tu es donc limité par ce qu’ils proposent.

Solution ?
Tu proposes un service de visiobot à la demande.
Le chatbot est aux messageries ce que le visiobot est aux visioconférences.
Ton but n’est pas de construire des visiobots mais de permettre aux autres d’en faire, facilement. Tu mets à disposition les fondations pour que d’autres construisent dessus.

Je laisse ça là.
Si je ne venais pas de lancer cette newsletter, je pense que je testerais cette idée.
Mon intuition d’entrepreneur me dit qu’il y a quelque chose à creuser.
Et si tu lances ce business grâce à La Batcave, alors j’aurais réussi mon pari !
Mais stp dis-le-moi :)

Pour aller plus loin

• Au moment de te loguer au compte Google, tu peux enregistrer les cookies.
  À la prochaine connexion, il te suffit de charger les cookies et d’actualiser la page. Tu seras directement logué :).
  C’est aussi un bon moyen d’éviter le captcha qui peut survenir à force de te loguer trop souvent.

• Au lieu d’envoyer par mail, tu peux aussi stocker dans Google Drive ou autre.

• Dans le mail envoyé, ajouter des infos en plus : la date, l’heure, les participants, etc.
  Pour ça, tu dois transmettre ces infos en même temps que tu envoies l’id du job à Make (pour récupérer la transcription).

• Tu peux aussi créer une fonctionnalité avec l’agenda et les invitations.
  Tu invites le visiobot et il arrive automatiquement quand c’est l’heure.
  Plus besoin de lui transmettre l’URL.

Ressources

Code source :

• La Batcave #1

• La Batcave #2

Sources :

• Revai Doc Node => pour débuter avec le SDK

• Redvai Doc GetTranscript => la doc de la requête pour récupérer la transcription

Le mot de la fin

J’espère que ce format t’a plu ! N’hésite pas à me répondre directement à la suite de ce mail pour me donner ton avis :).
Un like fait toujours plaisir pour me montrer que tu as apprécié et m’encourager à continuer.

La semaine prochaine, nous allons continuer à explorer le speech-to-text avec un cas d’usage très pratique.
Et ce sera en NoCode.

N’hésite pas à me dire si ce format (vidéo courte + écrit) te convient !
J’ai encore plein d’idées pour l’améliorer, mais je suis encore en phase d’itération.

Vincent 🦇