Où s'exécute réellement une réunion InterMIND

Toute discussion sérieuse d'achat en entreprise finit par poser la même question : « Où vont ces données ? » Le DPO veut une liste de sous-traitants. La DSI veut savoir quels fournisseurs sont domiciliés aux États-Unis. Le service juridique veut un schéma avec des flèches.

Nous préférons vous donner la vision d'ensemble plutôt que de la livrer par bribes par courriel. Voici donc le chemin des données d'une réunion — chaque service externe qu'elle touche, où chacun s'exécute, et quelles données y transitent. Vérifié par rapport à la configuration de déploiement réelle au 2026-05-28.

Chaque chemin qui touche au contenu d'une réunion est européen à l'exécution — y compris les étapes d'IA post-réunion, que nous signalions auparavant comme le seul angle mort et que nous avons depuis transférées chez des sous-traitants européens. Nous indiquons clairement où se trouve le seul modèle américain restant, et pourquoi il ne voit jamais votre réunion.

Cet article cartographie où s'exécute votre réunion. Son article compagnon, De quoi est faite une réunion InterMIND, cartographie de quoi elle est faite — quelles couches sont notre propre code, lesquelles sont open source, et où nous sommes pragmatiques quant aux SaaS propriétaires.

Ce que « où ça s'exécute » signifie réellement

Deux choses sont régulièrement confondues dans les discussions de souveraineté, et ce n'est pas la même chose :

1. Exécution / chemin des données. L'endroit où les octets de votre réunion sont physiquement traités pendant la requête. C'est de cela que parlent les réglementations sur la résidence des données et la plupart des DPA.
2. Domiciliation de l'entreprise fournisseur. L'endroit où le fournisseur SaaS est légalement constitué. C'est de cela que parlent les discussions sur le CLOUD Act — la portée théorique d'une contrainte américaine sur l'entité mère du fournisseur, indépendamment de l'endroit où la charge de travail s'exécute.

Presque chaque question « est-ce européen ? » relève en réalité de l'une de ces deux dimensions, posée de façon imprécise. Nous y répondons séparément pour chaque fournisseur ci-dessous.

Le chemin des données d'une réunion

Suivons un appel, du moment où l'on rejoint la réunion jusqu'au courriel de suivi :

1. Le navigateur ouvre la page de la réunion. Le SSR s'exécute sur Vercel, épinglé à fra1 (Francfort). Toutes les données de requête/réponse — cookies de session, charges utiles d'API, HTML rendu côté serveur — sont traitées dans l'UE à l'exécution.
2. Le WebSocket se connecte à notre serveur de réunion à Paris (cdg). Orchestration de réunion, présence, signalisation — tout est dans l'UE.
3. La reconnaissance vocale s'exécute dans le navigateur du locuteur. Locale. Elle ne quitte jamais l'appareil tant que la transcription résultante n'est pas envoyée pour traduction. (Nous avons expliqué pourquoi dans À l'intérieur des quatre pipelines de traduction.)
4. La traduction vocale et de chat passe par notre propre moteur sur OVH France. Il s'agit de mind-sdk + l'API Mind — notre code, nos hôtes, en France. Aucun modèle tiers n'est dans la boucle. Budget sous la seconde, pool WebSocket par langue, résidence européenne à chaque saut.
5. Un document déposé dans le chat (PDF, DOCX, PPTX, XLSX) part côté serveur du ws-server de Paris vers DeepL à Cologne. Entreprise allemande, traitement allemand. La voix et le chat ne touchent pas DeepL.
6. Les données applicatives — utilisateurs, équipes, messages, métadonnées de réunion — résident sur Neon Postgres sur AWS Frankfurt (eu-central-1). Les instantanés sont dans la même région.
7. Les enregistrements, pièces jointes et exports sont stockés sur Tigris, stockage compatible S3 sur Fly. Réplication edge ; le bucket est configurable en multi-région UE pour les locataires qui ont besoin d'une fixation plus stricte.
8. Les erreurs et traces de performance vont vers l'instance UE de Sentry (de.sentry.io). L'organisation américaine a été retirée en mai.
9. L'analytique produit va vers PostHog EU (eu.i.posthog.com).
10. Les courriels transactionnels (liens magiques, invitations, reçus) passent par Resend depuis eu-west-1 (Irlande).

Tout ce qui précède est dans l'UE à l'exécution. Le moteur de traduction — la partie par laquelle transite réellement la majorité de vos données — est également notre propre code, pas celui d'un tiers. Le SDK client sur lequel il s'appuie est open source (BSD-3-Clause) et auditable dès aujourd'hui ; l'auto-hébergement du moteur lui-même figure sur la feuille de route pour un client qui en aurait besoin.

La carte des fournisseurs

Les deux flux de données les plus volumineux — la traduction voix/chat via notre propre moteur sur OVH et la traduction de documents via DeepL — sont aussi les deux fournisseurs dont l'entité mère est dans l'UE. Cela couvre l'essentiel du contenu des réunions. La liste complète des sous-traitants avec le détail de leur domiciliation figure dans le DPA comme c'est la pratique habituelle ; le tableau ci-dessus est la vue d'exécution, qui est ce dont parlent la plupart des clauses de résidence des données.

Les étapes d'IA post-réunion, nommées clairement

Après la fin de l'appel, nous exécutons quelques étapes de modèle de langage sur ce qui a été dit : le digest IA (sujets, décisions, actions, questions ouvertes), le résumé post-réunion et l'éditeur de notes IA (traduire une note, ou la corriger / l'étendre / la simplifier). Ce sont les seuls endroits où un modèle généraliste touche à du contenu issu des réunions — et ils s'exécutent désormais tous sur des sous-traitants européens :

• Le digest s'exécute sur Mistral hébergé dans l'UE (mistral-large-3, avec mistral-medium-3.5 en repli), accessible via l'AI Gateway de Vercel épinglé au fournisseur Mistral avec zéro rétention de données — la requête échoue plutôt que de basculer vers un hôte non-ZDR ou américain.
• Le résumé et l'action traduire de l'éditeur passent par notre propre moteur européen sur OVH — celui-là même qui traduit la voix et le chat en direct — de sorte que le résumé ne quitte jamais le plan de données dans lequel la réunion avait déjà vécu.
• Les actions génératives de l'éditeur (corriger, étendre, réduire, simplifier, résumer) ne peuvent pas s'exécuter sur un moteur de traduction ; elles empruntent donc le même chemin Mistral UE + zéro rétention de données que le digest.

La voix en temps réel, le chat en temps réel, les notes et la traduction de documents ne passent jamais par aucune de ces étapes — ils étaient à résidence européenne dès le départ.

Le seul endroit où un modèle domicilié aux États-Unis reste dans la boucle ne touche aucune donnée de réunion : notre banc d'essai public de qualité de traduction utilise un modèle frontière comme juge automatisé, qui note les traductions automatiques des phrases de référence de FLORES-200. Il s'agit d'un jeu de données figé et public — pas de la réunion de qui que ce soit.

Nous allons encore plus loin sur les étapes Mistral UE : un opt-out contrôlé par le propriétaire est prévu pour désactiver entièrement le digest, ainsi qu'un modèle open-weights auto-hébergé (de classe Kimi) sur OVH pour remplacer le Mistral externe sur les tâches de résumé qui n'ont pas besoin d'un raisonneur frontière. Les deux figurent sur la feuille de route, pas en production ; nous mettrons à jour cet article lorsqu'ils seront livrés.

Ce que cela signifie pour votre DPA

Pour la plupart des acheteurs européens — Mittelstand allemand, industries régulées appliquant des DPA RGPD standards — l'image ci-dessus répond directement à la question de la résidence des données : chaque saut d'exécution de votre réunion a lieu dans l'UE. La domiciliation des fournisseurs est divulguée dans la liste des sous-traitants selon la pratique normale ; rien de surprenant. La carte de résidence n'est qu'une pièce ; pour le reste des obligations de protection des données — effacement, conservation, portabilité, consentement — nous avons soumis la base de code à un audit complet et clos chaque point dans le code.

Pour la souveraineté numérique française et les achats de niveau SecNumCloud, la domiciliation de l'entreprise fournisseur fait elle-même partie du critère, et pas seulement l'emplacement d'exécution. C'est une autre conversation — une topologie de déploiement alternative qui maintient chaque composant chez des fournisseurs sous juridiction européenne. Nous ne la déployons pas par défaut ; nous la mettons en place pour un locataire qui en a besoin et là où le contrat justifie l'effort de construction.

Pour les acheteurs nord-américains et la plupart des acheteurs APAC, l'inverse est généralement vrai — ils veulent une faible latence depuis leur région, ce qui est un problème différent. Aujourd'hui, nous fonctionnons en mono-région sur fra1. Si votre trafic justifie un edge américain, nous le planifierons avec vous.

Ce à quoi cet article nous engage

Voici l'image au 2026-05-28. Nous la mettrons à jour quand la stack changera — changement de fournisseur, migration de région, nouveau service externe. La configuration actuelle est vérifiable dans notre vercel.json ouvert, le moteur mind-sdk + API Mind tournant sur OVH France, et le tableau de bord de chaque fournisseur.

Si quelque chose ici semble incorrect, ou si votre DPO a besoin d'une réponse que cette carte ne fournit pas, écrivez-nous. Nous préférons corriger un détail manquant plutôt que de vous le faire découvrir lors d'une revue contractuelle.