Une chercheuse en sécurité a découvert 181 874 enregistrements de réunions accessibles sans aucune restriction ni mot de passe sur l’Internet public, à la portée de n’importe quel utilisateur inscrit. Bien qu’elle ait signalé la faille à l’éditeur dès le 28 janvier, le CTO de l’entreprise n’a répondu à aucun de ses e-mails pendant six mois. Lors de sa dernière vérification le 22 juillet, les données étaient toujours parfaitement accessibles.
L’outil concerné s’appelle tl;dv, un assistant de réunion IA très populaire revendiquant plus de 2 millions d’utilisateurs. Lors des visioconférences, le service intègre un robot dans Google Meet, Zoom ou Teams pour enregistrer, transcrire et synthétiser automatiquement les échanges.
Ces outils ne capturent pas de simples discussions informelles : appels commerciaux, entretiens d’embauche, évaluations RH et réunions stratégiques s’y trouvent stockés. Une phrase du rapport de recherche résume parfaitement la situation : quelqu’un annonce dans la réunion “cet appel est enregistré”, tout le monde esquisse un sourire gêné, puis l’on enchaîne sur 45 minutes de secrets d’affaires.
Le problème : Qui a le droit d’accès ?
tl;dv stocke les comptes rendus de réunions dans une base de données cloud régie par des règles de sécurité censées contrôler les autorisations d’accès. Ces règles devaient garantir l’isolation stricte des utilisateurs — chacun ne devant voir que ses propres réunions. En pratique, la configuration active permettait à tout utilisateur inscrit de requêter et d’obtenir l’intégralité des enregistrements de l’ensemble des clients de la plateforme.
Pour employer une métaphore : c’est comme un immeuble où chaque porte d’appartement est verrouillée, mais où l’armoire d’archives de la conciergerie dans le hall reste grande ouverte — permettant à n’importe quel résident de consulter les fiches de tous les voisins. Pire encore, les dossiers indiquaient l’emplacement des clés de secours : chaque fiche de réunion contenait le lien direct de la visioconférence, et pour les sessions en cours d’enregistrement, les liens étaient bel et bien actifs.
Figure : Interface de requête des enregistrements de réunions exposés. Source : bobdahacker.com
La chercheuse a constaté qu’à tout moment, environ 1 000 réunions étaient enregistrées en direct avec des liens pleinement fonctionnels. Lors d’une démonstration, elle a utilisé l’un de ces liens pour s’introduire sans invitation dans une conférence en ligne du ministère de l’Éducation de Malaisie réunissant plus de 157 participants. Elle s’est également invitée dans une réunion de projet entrepreneurial d’étudiants américains, où 21 personnes partageaient leur écran avec du code source et des prototypes non publiés.
Figure : Capture d’écran lors de l’accès à la réunion du ministère malaisien. Source : bobdahacker.com
Figure : Partage d’écran durant la réunion d’étudiants entrepreneurs. Source : bobdahacker.com
Tout ce processus s’est déroulé sans exploit, sans logiciel malveillant et sans identifiants volés. Il manquait simplement une ligne de code dans les règles d’accès de la base de données. Derrière le chiffre de 181 874 enregistrements ne se cachait aucune cyberattaque sophistiquée — la surface d’attaque était tout simplement l’Internet public.
L’ampleur : Des gouvernements aux universités et entreprises cotées
L’exposition dépassait largement les simples liens de réunion. Les 181 874 enregistrements appartenaient à 84 312 utilisateurs répartis sur 35 003 domaines d’entreprises et d’institutions. Des réunions gouvernementales de 23 pays y figuraient, dont le Brésil, l’Ukraine, les États-Unis, le Japon et la Malaisie. Côté académique, des institutions comme UC Berkeley et l’Université de Tokyo étaient concernées. Parmi les entreprises affectées figuraient des noms majeurs tels que HubSpot, Confluent ou Mitsui Fudosan. Le pic a été atteint en juillet 2025, avec 43 000 nouvelles réunions enregistrées sur un seul mois.
Sur un échantillon de 27 334 réunions paramétrées en mode “public”, plus de 1 000 permettaient de consulter directement l’intégralité du contenu, exposant au passage 715 adresses e-mail de participants. Confier ses réunions à un outil configuré de la sorte revient à remettre les clés de ses salles de conseil aux paramètres par défaut de l’éditeur.
La réponse de l’entreprise et une chronologie contradictoire
tl;dv a fini par réagir, mais uniquement après la parution d’articles dans la presse. Le 5 août, le CTO Allan Bettarel a publié un communiqué apportant plusieurs précisions : la fuite aurait été “strictement limitée aux métadonnées”, sans accès aux enregistrements audio, aux transcriptions ni aux synthèses IA ; la faille signalée en janvier avait été corrigée ; le chemin d’accès vérifié en juillet constituait une nouvelle faille distincte colmatée en 24 heures ; et l’entreprise a décidé de retirer intégralement Firebase de sa pile technique. Le CTO a reconnu : “J’assume l’entière responsabilité du défaut de suivi continu du rapport de la chercheuse en début d’année.”
Les versions des deux parties s’opposent néanmoins frontalement. La chronologie documentée par la chercheuse fait état d’un signalement initial le 28 janvier suivi de sept relances restées sans réponse de la part du CTO, la vulnérabilité demeurant réplicable le 22 juillet. L’entreprise soutient au contraire qu’il s’agissait de deux vulnérabilités indépendantes, corrigées rapidement. Sur le forum technique Lobsters, de nombreux ingénieurs ont qualifié la réponse de l’éditeur de “gaslighting” — sans nier les faits, la communication s’efforce de minimiser la gravité réelle.
Pour un observateur extérieur, il est difficile de trancher entre les deux récits. Un fait demeure incontestable : la page sécurité de l’entreprise affichait fièrement des badges de conformité SOC2 et GDPR ainsi qu’un engagement de “réponse sous 24 heures de notre équipe sécurité”, tout en ignorant les e-mails d’une chercheuse pendant six mois. Les certifications de conformité prouvent l’existence de procédures théoriques, pas la sécurité réelle des données.
Précipiter la conquête du marché au détriment de la sécurité
Le marché des comptes rendus de réunions par IA est l’un des secteurs SaaS les plus disputés du moment. Des acteurs comme Fathom, Otter, Fireflies et tl;dv s’y disputent les mêmes clients. La vitesse de conquête commerciale dépasse généralement le rythme des corrections de sécurité. La trajectoire classique de ces start-ups consiste à ouvrir très largement les autorisations par défaut pour fluidifier l’expérience utilisateur, quitte à configurer les règles de sécurité après le lancement du produit.
Un détail marquant du rapport d’investigation illustre bien la posture de sécurité interne : tl;dv hébergeait un mini-jeu de pronostics pour la Coupe du Monde sur un sous-domaine public sans aucune authentification — exposant les noms et e-mails professionnels de 19 employés via des points d’accès API. Une entreprise chargée de conserver les enregistrements de 2 millions d’utilisateurs n’a pas su protéger son propre annuaire d’employés. Plus que n’importe quel rapport d’audit, cela démontre que la culture de la sécurité n’était pas intégrée au sein de l’organisation.
Ce que cela implique pour les utilisateurs
Chaque mot prononcé lors d’une réunion assistée par IA est d’abord transmis aux serveurs de l’éditeur, transcrit, injecté dans des modèles d’IA et enregistré en base de données. La sécurité de ces données repose sur les configurations par défaut définies par l’éditeur, que presque aucune entreprise cliente ne prend le temps d’auditer. Les acheteurs se focalisent sur les démos de fonctionnalités, les tarifs et les arguments commerciaux ; les questions essentielles — où sont stockées les données, qui y a accès, comment s’effectue la suppression — restent souvent sans réponse, car les commerciaux eux-mêmes ne savent pas y répondre.
Si les marges de manœuvre individuelles sont limitées, quelques règles de précaution s’imposent : renoncer aux outils de compte rendu IA lors des réunions traitant de rémunérations, de RH ou de stratégie de fusion-acquisition ; vérifier dans les paramètres de ses outils si les réunions passées ne sont pas marquées comme “publiques” et restreindre les accès ; et au niveau de l’entreprise, exiger des garanties claires sur le stockage, les accès et la suppression avant toute souscription. Peu d’éditeurs apporteront immédiatement des réponses satisfaisantes, mais c’est cette exigence qui les poussera à sécuriser leurs configurations par défaut.
L’exposition de 180 000 réunions appartient désormais au passé. Que la prochaine génération d’outils IA réitère ou non ces erreurs de configuration dépendra de la capacité des utilisateurs à poser ces questions fondamentales. Les éditeurs font leur calcul entre praticité et confidentialité — aux utilisateurs d’apprendre à faire le leur.
Liens de référence :
- Rapport de recherche de BobDaHacker : 181 874 réunions exposées sur l’Internet public
- Discussion sur Lobsters (s/97laur)
- Réponse officielle de tl;dv : Clarification sur la couverture de DarkReading (CTO Allan Bettarel)
- Discussion sur Hacker News (item?id=49188723)
