De quoi est constituée une réunion InterMIND

Presque tous les produits sont construits à partir de la même pile par défaut — les grands SaaS propriétaires que tout le monde adopte sans réflexe. C'est le chemin le plus fluide. À chaque couche où les données de votre réunion résident réellement, nous avons pris un autre chemin : notre propre code, ou de l'open source que nous pouvions auto-héberger.

Ceci est le complément de Où s'exécute réellement une réunion InterMIND, qui cartographiait la géographie — où chaque service s'exécute et quelles données le traversent. Ce billet répond à ce qu'une équipe de sécurité demande ensuite : de quoi cette chose est-elle construite — et pouvons-nous la lire, l'auditer et la remplacer ?

Pas où elle s'exécute — de quoi elle est faite, couche par couche.

Les valeurs par défaut, et ce qu'elles coûtent

Chaque produit est une pile de choix. Pour la plupart des produits, la plupart de ces choix sont pris par défaut : Google Analytics, Firebase, l'API Google Translate, Auth0, React. C'est le chemin le plus fluide, et pour la plupart des équipes, c'est un parti pris raisonnable. La contrepartie est que chacun place une partie de votre pile derrière un fournisseur que vous ne pouvez ni lire, ni auditer, ni quitter sans une refonte.

Nous avons fait un choix différent à chaque couche où les données de votre réunion résident réellement : notre propre code, ou un logiciel open source que nous pouvions auto-héberger. Là où une couche ne touche pas au contenu de votre réunion, nous restons pragmatiques et le disons ouvertement. Voici l'image complète.

L'épine dorsale : le moteur est notre code, pas celui d'un tiers

Commençons par la couche qui compte le plus, parce que la majeure partie de votre réunion y transite. Le transport en temps réel et la traduction voix/chat s'exécutent tous deux sur mind-sdk + l'API Mind — notre propre moteur, sur OVH France. La manière par défaut de construire une réunion traduite consiste à greffer un SaaS temps réel (LiveKit) sur une API de traduction (DeepL, Google) ; nous n'exécutons ni l'un ni l'autre dans le chemin en direct. Aucun modèle de traduction tiers n'est dans la boucle. (Nous utilisons bien DeepL — mais uniquement pour les documents déposés dans le chat, pas pour le chemin voix/chat en direct ; voir la carte d'exécution. Nous avons détaillé la mécanique des pipelines dans Inside the four translation pipelines.)

Voici la partie qui n'est pas dans la carte d'exécution : le SDK sur lequel votre réunion s'exécute est open source sous licence BSD 3-Clause — le client mind-sdk est public sur gitlab.com/mindlabs/api/sdk, copyright MindMeeting OÜ, notre entité de propriété intellectuelle estonienne. Il communique avec l'API Mind à l'adresse api.mind.com, que nous opérons nous-mêmes sur OVH France.

Il ne s'agit pas d'un arrangement « regardez, mais ne touchez pas » avec un code source disponible. BSD 3-Clause est une licence permissive approuvée par l'OSI. Votre équipe de sécurité peut cloner le SDK, lire exactement comment votre audio et votre texte sont capturés, encapsulés et diffusés, et auditer cette intégration par rapport à vos propres exigences. Le moteur côté serveur auquel il s'adresse est le nôtre — pas la boîte noire d'un tiers — et un moteur entièrement auto-hébergeable pour un tenant qui en aurait besoin figure sur notre feuille de route, ce n'est pas quelque chose que nous proposons aujourd'hui. Nous mettrons à jour ce billet dès sa livraison.

Couche par couche : la valeur par défaut vs. ce que nous exécutons

Deux fils conducteurs traversent ce tableau. Open source là où l'outil traite vos données — afin qu'il puisse être audité et, en principe, auto-hébergé. Standards ouverts (Postgres, l'API S3, OIDC) là où nous dépendons d'infrastructure — afin que rien ne soit verrouillé sur le pricing ou la posture de conformité d'un seul fournisseur. Postgres peut migrer vers n'importe quel hôte Postgres ; le stockage peut migrer vers n'importe quel stockage S3 ; l'authentification se fédère au fournisseur d'identité que vous exploitez déjà. La dernière ligne se situe sur un troisième axe : le CRM qui détient les enregistrements clients est domicilié dans l'UE (Pipedrive, estonien) plutôt que sur une plateforme de ventes américaine — pas open source, mais non soumis à la juridiction américaine non plus.

Quelques-unes méritent une phrase de plus. PostHog est open source et auto-hébergeable ; nous l'exécutons sur le cloud européen de PostHog et le proxy en first-party via notre propre origine, de sorte que les événements ne sont pas silencieusement bloqués par les bloqueurs de publicité et ne transitent pas par un domaine d'analyse tiers. L'authentification ne passe jamais par un SaaS d'authentification tiers qui s'intercalerait entre vous et vos sessions — nous exécutons nous-mêmes le flux OIDC et nous fédérons à votre identité Google ou Microsoft existante. Et les polices de chaque page sont servies depuis notre propre domaine ; le seul endroit où Google Fonts apparaît dans notre codebase est un script hors ligne d'assets de marque, jamais dans l'application que vos utilisateurs chargent.

Là où nous restons pragmatiques — dit ouvertement

Nous ne prétendons pas que toute la pile est écrite main ou non-américaine. Elle ne l'est pas, et un billet qui affirmerait le contraire serait contredit par notre propre carte d'exécution.

La tuyauterie — hébergement et SSR (Vercel), le compute du serveur de réunion (Fly.io), les paiements (Stripe), l'email transactionnel (Resend) — s'exécute sur du SaaS domicilié aux États-Unis. Stripe et Resend gèrent la facturation et les invitations et ne voient jamais le contenu des réunions. Vercel et Fly sont du compute loué : notre propre code s'y exécute, et le serveur de réunion sur Fly gère bien la session en direct et la transcription que notre digest lit — mais c'est notre code sur leurs machines, pas un produit fournisseur qui ingère votre réunion. Tout s'exécute dans l'UE au runtime (le sujet de la carte d'exécution).

C'est un compromis délibéré et borné : posséder et ouvrir le data plane ; utiliser le meilleur SaaS disponible pour le control plane. Le nommer est précisément le but — la « souveraineté » ne signifie pas grand-chose si les exceptions ne sont pas sur la table à côté des réussites.

Les étapes IA post-réunion, et le plan

Aucun modèle propriétaire domicilié aux États-Unis ne touche au contenu dérivé de la réunion. Les étapes de modèle de langage qui s'exécutent après l'appel — le digest IA (sujets, décisions, actions), le résumé post-réunion, et l'éditeur de notes IA — reposent toutes sur des processeurs européens. Le digest et les actions génératives de l'éditeur s'exécutent sur Mistral hébergé dans l'UE avec zéro rétention de données (atteint via l'AI Gateway de Vercel, épinglé au provider Mistral). Le résumé et l'action traduire de l'éditeur s'exécutent sur notre propre moteur européen sur OVH — le même que celui derrière la voix et le chat en direct. La voix, le chat, les notes et les documents en temps réel n'ont jamais approché un LLM à usage général.

Le seul modèle américain encore dans la boucle juge notre benchmark de traduction public — il évalue des traductions automatiques de phrases de référence FLORES-200 fixes, jamais la réunion de quiconque.

Nous allons encore plus loin sur les étapes EU-Mistral : un opt-out contrôlé par le propriétaire pour désactiver entièrement le digest, et un modèle de résumé auto-hébergé à poids ouverts sur OVH (classe Kimi) pour remplacer le Mistral externe. L'enjeu de la voie à poids ouverts n'est pas de savoir de quel laboratoire les poids ont été entraînés — c'est que des poids ouverts peuvent s'exécuter sur une infrastructure que nous contrôlons, ce qui la maintient sur le même axe ouvert et auto-hébergeable que le reste du data plane. Les deux sont sur la feuille de route, pas livrés ; nous mettrons à jour ce billet lorsqu'ils arriveront.

Pourquoi cela compte au-delà de nous

Ce n'est pas de l'ingénierie pour elle-même. La raison de construire une pile de cette façon se manifeste du votre côté du contrat :

1. Auditable. Le SDK sur lequel votre réunion s'exécute est un code open source que votre équipe de sécurité peut lire, et le moteur derrière est le nôtre — pas la boîte noire d'un tiers.
2. Portable. Des standards ouverts à chaque couche de données — Postgres, S3, OIDC — signifient aucun lock-in propriétaire. Ce qui peut être déplacé n'est pas lié à un seul fournisseur.
3. Auto-hébergeable. Les couches de données en standard ouvert — Postgres, S3, OIDC — s'exécutent déjà sur une infrastructure que vous contrôlez ; un moteur de traduction entièrement auto-hébergeable est sur la feuille de route pour le tenant qui en a besoin.

C'est l'image au 2026-06-07. Nous la mettrons à jour lorsque la pile changera — un changement de fournisseur, une couche reconstruite, le modèle de digest remplacé. La configuration actuelle est vérifiable dans notre vercel.json ouvert, notre nuxt.config.ts, et le dépôt mind-sdk en BSD-3-Clause lié ci-dessus.

Si une couche ici vous semble erronée, ou si votre revue de sécurité a besoin d'une réponse que cette carte n'apporte pas, écrivez-nous. Nous préférons corriger un détail manquant plutôt que de vous le laisser découvrir lors d'un audit de code.

Sources : le dépôt mind-sdk (BSD-3-Clause), FLORES-200 ; les faits de pile vérifiés par rapport à la configuration déployée (vercel.json, nuxt.config.ts) et au code livré, vérifiés en août 2026.