De quoi est constituée une réunion InterMIND

Presque chaque produit est construit à partir de la même pile par défaut — les grands SaaS propriétaires que tout le monde choisit par défaut. C'est le chemin le plus simple. À chaque couche où les données de votre réunion résident réellement, nous avons pris un chemin différent : notre propre code, ou de l'open-source que nous pouvions auto-héberger.

Ceci est le volet 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. Cet article 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 simple, et pour la plupart des équipes, c'est un choix raisonnable. Le compromis est que chacun place une partie de votre pile derrière un fournisseur que vous ne pouvez ni lire, ni auditer, ni quitter sans tout réécrire.

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 des logiciels open-source que nous pouvions auto-héberger. Lorsqu'une couche ne touche pas au contenu de votre réunion, nous restons pragmatiques et le disons. Voici l'image complète.

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

Commencez par la couche qui compte le plus, car la majeure partie de votre réunion la traverse. Le transport en temps réel et la traduction vocale/chat fonctionnent tous deux sur mind-sdk + l'API Mind — notre propre moteur, sur OVH France. La méthode classique pour construire une réunion traduite consiste à greffer un SaaS en 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 vocal/chat en direct ; voir la carte d'exécution. Nous avons couvert la mécanique du pipeline dans Au cœur des quatre pipelines de traduction.)

Voici la partie qui ne figure pas sur la carte d'exécution : le SDK sur lequel votre réunion s'exécute est open-source sous la 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 exploitons nous-mêmes sur OVH France.

Il ne s'agit pas d'un arrangement « regardez mais ne touchez pas » avec code consultable. La licence 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 parle est le nôtre — pas une boîte noire tierce — et un moteur entièrement auto-hébergeable pour un client qui en aurait besoin figure sur notre feuille de route, ce n'est pas quelque chose que nous offrons aujourd'hui. Nous mettrons à jour cet article dès qu'il sera livré.

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

Deux fils conducteurs traversent ce tableau. L'open-source là où l'outil traite vos données — afin qu'il puisse être audité et, en principe, auto-hébergé. Les standards ouverts (Postgres, l'API S3, OIDC) là où nous dépendons d'une infrastructure — afin que rien ne soit verrouillé sur la tarification ou la posture de conformité d'un seul fournisseur. Postgres peut être déplacé vers n'importe quel hôte Postgres ; le stockage peut être déplacé 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 repose sur un troisième axe : le CRM qui contient les enregistrements clients est domicilié dans l'UE (Pipedrive, estonien) plutôt que sur une plateforme de ventes américaine — non 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 proxifions en first-party via notre propre origine, de sorte que les événements ne sont pas silencieusement bloqués par les bloqueurs de publicités et ne transitent pas par un domaine d'analytique tiers. L'authentification ne passe jamais par un SaaS d'authentification tiers qui se situerait entre vous et vos sessions — nous exécutons nous-mêmes le flux OIDC et nous nous fédérons à votre Google ou Microsoft existant. 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 pour les ressources de marque, jamais dans l'application que vos utilisateurs chargent.

Là où nous sommes pragmatiques — dit à voix haute

Nous ne prétendons pas que toute la pile est développée en interne ou non-américaine. Elle ne l'est pas, et un article qui prétendrait le contraire serait contredit par notre propre carte d'exécution.

La plomberie — l'hébergement et le SSR (Vercel), le calcul du serveur de réunions (Fly.io), les paiements (Stripe), l'e-mail transactionnel (Resend) — s'exécute sur des SaaS domiciliés 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 calcul loué : notre propre code s'y exécute, et le serveur de réunions sur Fly gère bien la session en direct et la transcription que notre synthèse lit — mais c'est notre code sur leurs machines, pas un produit fournisseur qui ingère votre réunion. Tout cela s'exécute dans l'UE à l'exécution (le sujet de la carte d'exécution).

C'est un compromis délibéré et délimité : posséder et ouvrir le code du plan de données ; utiliser le meilleur SaaS disponible pour le plan de contrôle. Le nommer est le but — la « souveraineté » signifie peu si les exceptions ne sont pas sur la table à côté des succès.

Les étapes IA, et le plan livré

Les étapes du modèle de langage — la synthèse IA (sujets, décisions, tâches), les résumés de documents, les actions génératives de l'éditeur de notes IA, Ask AI et Mia — s'exécutent sur la passerelle IA que votre organisation sélectionne : Azure OpenAI dans l'EU Data Zone par défaut, Vertex AI sur l'endpoint multi-région UE ou Amazon Bedrock à Francfort au choix, chacun dans notre propre client avec zéro rétention de données et aucun entraînement sur le contenu client — ou votre propre endpoint compatible OpenAI, qui maintient le modèle sur une infrastructure que vous contrôlez. La synthèse post-réunion et l'action traduire de l'éditeur passent par le tract de traduction, pas par le modèle de langage. La voix en temps réel, le chat, les notes et les documents n'ont jamais approché un LLM à usage général en premier lieu.

C'est la forme honnête de cette couche : les modèles sont propriétaires, et leurs fournisseurs sont des entreprises américaines qui exploitent des régions UE — le même compromis que la plomberie ci-dessus, énoncé à côté d'elle plutôt que caché. Ce qui a été livré au lieu d'un modèle auto-hébergé de notre cru, c'est le choix : une organisation peut désactiver l'IA entièrement (la transcription et la traduction continuent de fonctionner), et elle peut pointer chaque fonctionnalité IA vers son propre endpoint — vLLM dans son propre centre de données, un deployment dans son propre client — ce qui place cette couche sur le même axe ouvert-et-auto-hébergeable que le reste du plan de données. Notre benchmark de traduction public est évalué par un juge LLM (Gemini, avec Claude en repli) sur des phrases de référence FLORES-200 fixes — jamais la réunion de qui que ce soit.

Pourquoi cela compte au-delà de nous

Ce n'est pas de l'ingénierie pour le plaisir d'ingénierier. La raison de construire une pile de cette façon se manifeste de votre côté du contrat :

1. Auditable. Le SDK sur lequel votre réunion s'exécute est du code open-source que votre équipe de sécurité peut lire, et le moteur derrière lui est le nôtre — pas une boîte noire tierce.
2. Portable. Des standards ouverts à chaque couche de données — Postgres, S3, OIDC — signifient aucun verrouillage 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 figure sur la feuille de route pour le client qui en a besoin.

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

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

Sources : le dépôt mind-sdk (BSD-3-Clause), FLORES-200 ; faits de la 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.