Où se déroule concrètement une réunion InterMIND

Toute conversation sérieuse d'achat en entreprise finit par aboutir à la même question : « Où vont ces données ? » Le DPO veut une liste de sous-traitants. Le 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 que vous ayez une vision complète plutôt que de vous l'envoyer morceau par morceau par e-mail. Voici donc le chemin des données d'une réunion — chaque service externe qu'elle sollicite, 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 le contenu de la réunion se situe dans l'UE lors de l'exécution — y compris les étapes d'IA post-réunion, que nous avions l'habitude de signaler comme le seul manque et que nous avons depuis déplacées vers des processeurs européens. Nous indiquons clairement où se trouve l'unique modèle américain restant, et pourquoi il ne voit jamais votre réunion.

Cet article cartographie où se déroule votre réunion. Son pendant, De quoi est constituée une réunion InterMIND, cartographie de quoi elle est constituée — quelles couches sont notre propre code, lesquelles sont open-source, et où nous sommes pragmatiques vis-à-vis du SaaS propriétaire.

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

Deux choses sont souvent confondues dans les conversations sur la souveraineté et elles ne sont pas identiques :

1. Exécution / chemin des données. Où les octets de votre réunion sont physiquement traités pendant la requête. C'est de cela que traitent réellement les réglementations sur la résidence des données et la plupart des DPA.
2. Domicile social du fournisseur. Où le fournisseur SaaS est légalement constitué. C'est de cela que traitent les discussions sur le CLOUD Act — la portée théorique d'une injonction américaine contre 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 ? » est en réalité l'une de ces deux questions, posée de manière 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, de la connexion à l'e-mail 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 lors de l'exécution.
2. Le WebSocket se connecte à notre serveur de réunion à Paris (cdg). L'orchestration de la réunion, la présence, la signalisation — le tout dans l'UE.
3. La reconnaissance vocale s'exécute dans le navigateur du locuteur. En local. Ne quitte jamais l'appareil jusqu'à ce que la transcription résultante soit envoyée pour traduction. (Nous avons expliqué pourquoi dans À l'intérieur des quatre pipelines de traduction.)
4. La traduction de la voix et du chat sollicite notre propre moteur sur OVH France. Il s'agit de mind-sdk + l'API Mind — notre code, nos serveurs, en France. Aucun modèle tiers n'est dans la boucle. Budget inférieur à une seconde, pool WebSocket par langue, résident dans l'UE à chaque saut.
5. Un document déposé dans le chat (PDF, DOCX, PPTX, XLSX) passe côté serveur, du serveur ws de Paris à DeepL à Cologne. Société 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 dans Neon Postgres sur AWS Francfort (eu-central-1). Les instantanés dans la même région.
7. Les enregistrements, pièces jointes et exports sont stockés sur Tigris, un stockage compatible S3 sur Fly. Répliqué en edge ; le bucket est configurable en multi-région UE pour les locataires qui ont besoin qu'il soit davantage épinglé.
8. Les erreurs et les traces de performance vont à l'instance européenne de Sentry (de.sentry.io). L'organisation américaine a été retirée en mai.
9. Les analyses de produit vont à PostHog EU (eu.i.posthog.com).
10. L'e-mail transactionnel (liens magiques, invitations, reçus) passe par Resend depuis eu-west-1 (Irlande).

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

La carte des fournisseurs

Les deux flux de données les plus lourds en volume — la traduction voix/chat via notre propre moteur sur OVH et la traduction de documents via DeepL — se trouvent également être les deux fournisseurs dont l'entité mère est dans l'UE. Cela couvre la majeure partie du contenu de la réunion. La liste complète des sous-traitants avec le détail du domicile social est intégrée au DPA selon la pratique standard ; le tableau ci-dessus est la vue d'exécution, qui est ce dont traitent la plupart des clauses de résidence des données.

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

Une fois l'appel terminé, nous exécutons quelques étapes de modèle de langage sur ce qui a été dit : l'AI digest (sujets, décisions, points d'action, questions ouvertes), le post-meeting summary, et l'AI note-editor (traduire une note, ou la corriger / l'étendre / la simplifier). Ce sont les seuls endroits où un modèle à usage général touche du contenu dérivé de la réunion — et tous s'exécutent désormais sur des processeurs européens :

• L'AI digest s'exécute sur Mistral hébergé dans l'UE (mistral-large-3, mistral-medium-3.5 en repli), atteint via l'AI Gateway de Vercel épinglée au fournisseur Mistral avec zero-data-retention — la requête échoue plutôt que de basculer vers un hôte non-ZDR ou américain.
• Le post-meeting summary et l'action translate de l'éditeur passent par notre propre moteur européen sur OVH — le même que celui 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 s'est déjà déroulée.
• 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 + zero-data-retention que l'AI digest.

La voix en temps réel, le chat en temps réel, les notes et la traduction de documents ne passent jamais par l'un de ceux-ci — ils étaient résidents dans l'UE dès le départ.

Le seul endroit où un modèle domicilié aux États-Unis est encore dans la boucle ne touche aucune donnée de réunion : notre benchmark public de qualité de traduction utilise un modèle de pointe comme juge automatisé, évaluant des traductions automatiques de phrases de référence FLORES-200. Il s'agit d'un jeu de données fixe et public — pas de la réunion de quiconque.

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

Ce que cela signifie pour votre DPA

Pour la plupart des acheteurs européens — le Mittelstand allemand, les industries réglementées qui exécutent des DPA RGPD standard — le tableau ci-dessus répond directement à la question de la résidence des données : chaque saut d'exécution effectué par votre réunion se situe dans l'UE. Le domicile du fournisseur est divulgué dans la liste des sous-traitants selon la pratique normale ; rien de surprenant à cela. La carte de résidence n'est qu'un élément ; 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 avons traité chaque point dans le code.

Pour la souveraineté numérique à la française et les achats de niveau SecNumCloud, le domicile social du fournisseur fait lui-même partie du critère, et pas seulement le lieu d'exécution. C'est une conversation différente — une topologie de déploiement alternative qui maintient chaque composant auprès de fournisseurs relevant de la juridiction européenne. Nous ne l'exécutons pas par défaut ; nous le mettrons en place pour un locataire qui en a besoin et lorsque le contrat justifie cet aménagement.

Pour les acheteurs nationaux américains et la plupart des acheteurs de la zone 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 opérons en région unique dans fra1. Si votre trafic justifie un edge américain, nous le planifierons avec vous.

Ce à quoi cet article nous engage

C'est l'état des lieux au 2026-05-28. Nous le mettrons à jour lorsque la pile changera — changement de fournisseur, migration de région, un nouveau service externe. La configuration actuelle est vérifiable dans notre fichier vercel.json open source, le moteur mind-sdk + API Mind en cours d'exécution sur OVH France, et le tableau de bord de chaque fournisseur.

Si quelque chose ici vous 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 laisser découvrir lors d'une revue de contrat.

Sources : régions d'exécution et routage des modèles vérifiés par rapport à la configuration déployée (vercel.json, fly.toml) et au code livré ; Vercel AI Gateway (le chemin d'épinglage du fournisseur de l'AI digest), FLORES-200 ; vérifié en août 2026.