De quoi est faite une réunion InterMIND

Presque tous les produits sont construits sur la même pile par défaut : les grands SaaS propriétaires vers lesquels tout le monde se tourne. C'est la voie sans friction. À chaque couche où vivent réellement les données de vos réunions, nous en avons pris une autre : notre propre code, ou de l'open source que nous pouvions héberger nous-mêmes.

Cet article est le complément de Où une réunion InterMIND s'exécute réellement, qui cartographiait la géographie : où chaque service s'exécute et quelles données le traversent. Ici, nous répondons à la question que pose ensuite une équipe sécurité : de quoi ce produit est-il fait, et pouvons-nous le lire, l'auditer et le remplacer ?

Non pas où il s'exécute, mais de quoi il est fait, couche par couche.

Les choix par défaut, et ce qu'ils coûtent

Chaque produit est un empilement de choix. Pour la plupart des produits, la plupart de ces choix sont faits par défaut : Google Analytics, Firebase, l'API Google Translate, Auth0, React. C'est la voie sans friction, et pour la plupart des équipes, c'est une décision raisonnable. Le revers, c'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 autre choix à chaque couche où vivent réellement les données de vos réunions : notre propre code, ou des logiciels open source que nous pouvions héberger nous-mêmes. Lorsqu'une couche ne touche pas au contenu de vos réunions, nous restons pragmatiques et nous le disons. Voici le tableau complet.

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

Commençons par la couche la plus importante, car l'essentiel 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 + la Mind API, notre propre moteur, chez OVH France. La façon habituelle de construire une réunion traduite consiste à greffer un SaaS temps réel (LiveKit) sur une API de traduction (DeepL, Google) ; nous n'utilisons ni l'un ni l'autre dans le flux en direct. Aucun modèle de traduction tiers n'intervient. (Nous utilisons bien DeepL, mais uniquement pour les documents déposés dans le chat, pas pour le flux voix/chat en direct ; voir la carte d'exécution. Nous avons détaillé le fonctionnement des pipelines dans Au cœur des quatre pipelines de traduction.)

Voici ce que la carte d'exécution ne dit pas : le SDK sur lequel repose votre réunion 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é estonienne de propriété intellectuelle. Il dialogue avec la Mind API à l'adresse api.mind.com, que nous exploitons nous-mêmes chez OVH France.

Il ne s'agit pas d'un arrangement « code source visible, mais ne touchez pas ». La licence BSD 3-Clause est une licence permissive, approuvée par l'OSI. Votre équipe sécurité peut cloner le SDK, lire précisément comment votre audio et votre texte sont capturés, découpés en trames et diffusés en flux, et auditer cette intégration au regard de vos propres exigences. Le moteur côté serveur auquel il se connecte est le nôtre, pas la boîte noire d'un tiers. Un moteur entièrement auto-hébergeable pour un tenant qui en a besoin figure sur notre feuille de route ; nous ne le proposons pas aujourd'hui. Nous mettrons cet article à jour dès sa disponibilité.

Couche par couche : le choix par défaut et ce que nous exploitons

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 enfermé dans la tarification ou la posture de conformité d'un seul fournisseur. Postgres peut migrer vers n'importe quel hébergeur Postgres ; le stockage 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 relève d'un troisième axe : le CRM qui détient les fiches clients est domicilié dans l'UE (Pipedrive, estonien) plutôt que sur une plateforme commerciale américaine. Il n'est pas open source, mais il n'est pas non plus soumis à la juridiction américaine.

Quelques-uns de ces choix méritent une phrase de plus. PostHog est open source et auto-hébergeable ; nous l'exploitons sur le cloud européen de PostHog et le relayons 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 par aucun domaine d'analytique tiers. L'authentification ne passe jamais par un SaaS d'authentification tiers qui s'interposerait entre vous et vos sessions : nous exploitons nous-mêmes le flux OIDC et le fédérons à votre identité Google ou Microsoft existante. Enfin, les polices de chaque page sont servies depuis notre propre domaine ; la seule occurrence de Google Fonts dans notre code se trouve dans un script hors ligne de ressources de marque, jamais dans l'application que chargent vos utilisateurs.

Là où nous sommes pragmatiques : dit franchement

Nous ne prétendons pas que toute la pile soit développée à la main ou non américaine. Ce n'est pas le cas, et un article qui l'affirmerait serait contredit par notre propre carte d'exécution.

La plomberie (hébergement et SSR avec Vercel, calcul du serveur de réunion avec Fly.io, paiements avec Stripe, e-mail transactionnel avec Resend) repose 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 de la puissance de calcul louée : notre propre code s'y exécute, et le serveur de réunion sur Fly traite bien la session en direct ainsi que la transcription que lit notre digest ; mais c'est notre code sur leurs machines, pas un produit d'éditeur qui ingère votre réunion. Tout cela s'exécute dans l'UE au moment de l'exécution (c'est l'objet de la carte d'exécution).

C'est un compromis délibéré et borné : posséder et ouvrir le plan de données en open source ; utiliser le meilleur SaaS disponible pour le plan de contrôle. Le nommer est justement le but : la « souveraineté » ne veut pas dire grand-chose si les exceptions ne sont pas posées sur la table à côté des réussites.

Les étapes IA, et ce qui a été livré

Les étapes reposant sur un modèle de langage (le digest IA : sujets, décisions, action items ; 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 choisit votre organisation : Azure OpenAI dans l'EU Data Zone par défaut, Vertex AI sur le endpoint multirégion européen ou Amazon Bedrock à Francfort au choix, chacun dans notre propre tenant, sans aucune conservation des données et sans entraînement sur le contenu client ; ou votre propre endpoint compatible OpenAI, qui garde le modèle sur une infrastructure que vous contrôlez. Le résumé après réunion et l'action traduire de l'éditeur passent par la chaîne de traduction, pas par le modèle de langage. La voix, le chat, les notes et les documents en temps réel n'ont de toute façon jamais approché un LLM généraliste.

Voilà 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 européennes. C'est le même compromis que pour la plomberie ci-dessus, énoncé à côté plutôt que dissimulé. À la place d'un modèle auto-hébergé qui nous appartiendrait, nous avons livré le choix : une organisation peut désactiver entièrement l'IA (la transcription et la traduction continuent de fonctionner), et elle peut diriger chaque fonction IA vers son propre endpoint (vLLM dans son propre centre de données, un déploiement dans son propre tenant), 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 noté par un LLM juge (Gemini, avec Claude en secours) sur des phrases de référence FLORES-200 fixes, jamais sur la réunion de qui que ce soit.

Pourquoi cela compte au-delà de nous

Il ne s'agit pas d'ingénierie pour elle-même. La raison de construire une pile de cette façon se voit de votre côté du contrat :

1. Auditable. Le SDK sur lequel repose votre réunion est du code open source que votre équipe sécurité peut lire, et le moteur qui le soutient 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 enfermement propriétaire. Ce qui peut être déplacé n'est pas attaché à un seul fournisseur.
3. Auto-hébergeable. Les couches de données à standards ouverts (Postgres, S3, OIDC) fonctionnent déjà sur une infrastructure que vous contrôlez ; un moteur de traduction entièrement auto-hébergé est sur la feuille de route pour le tenant qui en a besoin.

Voici le tableau au 2026-06-07. Nous le mettrons à jour lorsque la pile changera : changement de fournisseur, couche reconstruite, modèle du digest remplacé. La configuration actuelle est vérifiable dans notre vercel.json ouvert, notre nuxt.config.ts et le dépôt mind-sdk sous BSD-3-Clause lié plus haut.

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

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