J'ai arrêté d'envoyer mes réunions dans le cloud

Il me faut 47 minutes de calcul pour transcrire une heure de réunion, en local sur mon laptop. Ce que j'ai adapté dans Meetily, et ce que ça règle côté RGPD.

Nous n'avons plus besoin de faire de prise de notes et de compte rendu de réunion ! Et ça, c'est une belle avancée... Mais par contre, les principaux outils d'enregistrement et de transcription sont souvent payants et surtout fondés sur un traitement dans le cloud.

Otter fait l'objet depuis 2025 de plusieurs plaintes regroupées devant un tribunal fédéral californien : il lui est reproché d'enregistrer des participants qui n'ont jamais rien signé, et d'avoir utilisé ces contenus pour entraîner ses modèles. Fireflies, que j'utilisais, est visé depuis décembre 2025 par deux actions collectives dans l'Illinois, au motif que sa reconnaissance des locuteurs fabriquerait des empreintes vocales sans le consentement écrit qu'exige la loi locale sur les données biométriques. Rien n'est jugé à ce jour, ce sont des accusations. Mais cela reste un vrai sujet.

Début juillet, j'ai vu passer sur LinkedIn un post qui présentait Meetily, un assistant de réunion open source qui fonctionne sur la machine de son utilisateur. (PS : j'ai voulu retrouver ce post pour citer et remercier l'auteur, mais dans le scroll infini de LinkedIn... impossible !). Et donc, je me suis lancée, et ça me permettait de travailler sur 2 sujets d'un coup : améliorer ma gestion des données confidentielles et enfin essayer de faire tourner un modèle en local.

Maintenant, je suis encore en période de rodage, mais je n'ai plus utilisé de transcription cloud depuis trois semaines et je suis convaincue du résultat. Dans cet article mon partage sur ce sujet.

1. Le problème : des réunions sensibles qui transitent par des serveurs tiers

Les assistants de réunion du marché partagent une architecture commune. Un agent logiciel rejoint la visioconférence ou se branche directement sur l'audio du poste, transmet le son aux serveurs de l'éditeur dans le cloud, où la transcription et le résumé sont produits. Otter, Fireflies et Plaud fonctionnent tous sur ce principe, à des variantes près (Granola, lui, traite l'audio en local et n'envoie que le texte pour le résumé).

Dès qu'on travaille dans un domaine avec des données confidentielles (pour l'entreprise) et/ou sensibles (RGPD), cela pose un problème. Chaque réunion peut mentionner des informations qui n'ont pas vocation à être traitées par un sous-traitant (notre outil de transcription qui fait ses entraînements dessus par exemple !). D'ailleurs, pour info, la voix elle-même est une donnée personnelle, et elle devient une donnée biométrique dès lors qu'elle permet d'identifier une personne (article 9 du RGPD).

Même problème à l'origine de l'initiative de Meetily : un cabinet juridique demandant des comptes rendus assistés par IA tout en excluant tout outil cloud, le secret professionnel exigeant le contrôle complet des données. L'éditeur cite trois publics bloqués par le cloud : cabinets juridiques, professionnels de santé, services financiers.

Maintenant, il me reste à savoir si ça peut tourner sur ma machine...

2. Adaptation de Meetily

2.1 Un fork de Meetily

Avec mon IA préférée (oui, même si je cherche à m'en passer, je fais beaucoup de choses avec elle que je ne serais pas capable de faire sans elle, dont un fork d'un repo git existant !), je clone le code de Meetily et je le fais tourner tel quel en local. Et là, magie, direct, ça marche : l'enregistrement tourne, le texte s'affiche. Et j'identifie tout de suite ce que je voudrais adapter pour que ça corresponde mieux à mon besoin :

• supprimer la partie compte-rendu. J'ai déjà tout un process à part qui le gère. Je ne vous détaille pas cette suppression, ce n'est pas la partie la plus intéressante.
• ajouter de la diarisation (ok, je ne connaissais pas ce mot avant non plus, c'est juste pour dire « reconnaître qui parle »).

Je vérifie les conditions de la licence de Meetily : elle est en MIT, j'ai le droit d'adapter le code, y compris pour un usage professionnel.

GO !

2.2 Renoncer à la transcription en direct

Essai 1 : le modèle par défaut ne donne vraiment pas de bons résultats en français. Je change alors de modèle et teste Whisper large-v3-turbo en temps réel, qui demande environ 8 secondes de traitement pour 5 à 6 secondes de parole sur un GPU intégré. La file d'attente s'allonge donc à mesure que la réunion avance, et la latence dépasse rapidement 15 secondes... Ce n'est pas viable.

J'ai donc décidé de lâcher l'idée d'avoir une transcription live et fidèle, car je suis dans la réunion, je n'ai pas besoin de lire la transcription en direct.

Je modifie l'outil pour pouvoir lancer la transcription, tranquillement, après mes réunions. Ça marche, et ce n'est même pas trop long : environ 8 minutes pour 1 h de réunion.

2.3 Donner du contexte

Essai 2 : J'enregistre en parallèle en local et avec mes outils cloud habituels. Et je compare la qualité de la transcription... mais je ne suis pas impressionnée. C'est même carrément nul sur les noms propres (passe encore, il n'y en a aucun qui transcrit correctement ce type de mots) mais par contre, il se rate sur tout le vocabulaire technique (« backlog » devient « patelot ») !

Je fais plusieurs améliorations en même temps :

1. Je change de modèle, je suis passée sur Whisper large-v3 (et plus le turbo).
2. Même si je ne suis pas une spécialiste, je me dis qu'en lui fournissant plus de contexte, ce sera plus efficace. Petit développement pour me proposer automatiquement les infos de mon calendrier pour valider le nom de l'entreprise et celui des participants (c'est magique comme idée !). ➜ les métadonnées
3. Et je me demande si je ne peux pas inclure un dictionnaire de mes termes techniques. En fait, l'espace disponible à l'amorçage de Whisper est minuscule (400 caractères). Ce que je fais tout de même, c'est extraire, de mes transcriptions existantes, mon vocabulaire (ex : HDS, je suis dans les MedTech). ➜ le glossaire

OK... c'est vraiment plus long pour chaque transcription. Mais ça marche super bien !!! À partir du moment où je passe moins de temps, sur une journée, en réunion que pas en réunion... c'est jouable.

2.4 Diariser

Je suis lancée, plus rien ne m'arrête dans mes tests. Et pourquoi pas reconnaître les locuteurs. Je sais que c'est une action compliquée. Mais, comme mes outils cloud ne sont pas fantastiques, autant faire du « pas fantastique » local.

Essai 3 : Petit état de l'art réalisé et je suis partie sur pyannote.audio 4 (le modèle speaker-diarization-community-1, gratuit et sous licence CC-BY). Après quelques enregistrements de réunion, petit comparatif entre Fireflies, Google Meet et le local. Fireflies s'en sort un peu mieux, mais sans non plus être extraordinaire. Donc, ma version locale me convient, sauf pour le temps que ça prenait avec mon CPU. J'ai un GPU Intel (pauvre de moi !), mais il existe une version de PyTorch qui sait s'en servir. J'ai basculé la diarisation dessus et là... de nouveau... magie ! Trois fois et demie plus rapide, et j'ai vérifié que le résultat était rigoureusement identique, octet pour octet. C'est utilisable ! (Dommage, je ne sais pas faire pareil avec Whisper : la brique qu'il utilise en dessous ne sait pas parler à un GPU Intel.)

Je n'ai pas cherché à faire reconnaître automatiquement les locuteurs. Je le fais à la main pour chaque réunion. Ce sera peut-être ma prochaine amélioration (mais comme je voudrais toujours vérifier si l'association est correcte, ça me prendra peut-être autant de temps de vérifier que de le faire).

3. Les Bonus - en vrac

• Je me suis fait un petit dashboard qui me permet d'avoir les informations qui m'intéressent vraiment (et celles juste pour le fun !). ➜ Par exemple, le temps de parole par locuteur.
• C'est complètement intégré dans mon process de RAG (Second Brain). ➜ par exemple l'indication que le CR a été intégré.
• J'ai réussi à ce que ça marche aussi bien sans casque qu'avec (et oui, la piste audio n'arrive pas de la même façon). Mais je n'ai pas testé de changer de matériel pendant le meeting... pas sûr que mon enregistrement audio me suive bien.
• Je gère moi-même la politique de rétention de mes fichiers (vous la voyez, votre fin d'abonnement qui fait que vous perdez l'accès à vos fichiers ?)
• Pas de transfert de data hors UE et pas d'entraînement de modèle avec mes données.

4. Résultats

Mon laptop : ordinateur portable équipé d'un processeur Intel Core Ultra 7 258V (8 cœurs), 32 Go de mémoire, GPU intégré Intel Arc 140V.

Le temps de traitement :

Durée de chaque étape, pour une heure de réunion.

Durée totale entre la fin de la réunion et un texte attribué aux locuteurs. La diarisation s'ajoute à la transcription, elle ne la remplace pas.

5. Sources

Si vous voulez vous aussi vous lancer :

• le repo git de Meetily : github.com/Zackriya-Solutions/meetily
• pour utiliser pyannote : huggingface.co/pyannote

Sur les procédures en cours, si le sujet vous intéresse :

• l'action contre Otter.ai (In re Otter.AI Privacy Litigation, N.D. Cal., n° 5:25-cv-06911), résumée par le National Law Review : natlawreview.com
• la plainte contre Fireflies.AI et ce qu'elle dit des empreintes vocales, analysée par Epstein Becker Green : ebglaw.com

Amusez-vous bien !!

À lire ensuite

Build in Public

J'ai voulu construire mon app sans savoir coder

IA & Santé

L'IA en santé : chronique d'un été