Ce qui compose une réunion InterMIND

Presque tous les produits sont bâtis 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ù les données de votre réunion résident réellement, nous avons fait un autre choix : notre propre code, ou de l'open source que nous pouvions auto-héberger.

C'est le pendant 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 y transitent. Cet article répond à la question suivante d'une équipe sécurité : de quoi est faite cette chose — et pouvons-nous la lire, l'auditer et la remplacer ?

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

Les choix par défaut, et leur coût

Tout 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 un choix raisonnable. La contrepartie, c'est que chacun de ces choix 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ù 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 d'ensemble.

La colonne vertébrale : le moteur, c'est notre code, pas celui d'un tiers

Commençons par la couche qui compte le plus, car c'est par elle que transite la majeure partie de votre réunion. 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 façon habituelle de construire une réunion traduite consiste à brancher un SaaS temps réel (LiveKit) sur une API de traduction (DeepL, Google) ; nous ne faisons tourner ni l'un ni l'autre dans le chemin live. Aucun modèle de traduction tiers n'intervient 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 du pipeline dans À l'intérieur des quatre pipelines de traduction.)

Voici la partie qui n'apparaît pas dans la carte d'exécution : le SDK sur lequel s'exécute 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é de propriété intellectuelle estonienne. Il dialogue avec l'API Mind à api.mind.com, que nous opérons nous-mêmes sur OVH France.

Ce n'est pas un arrangement « source-available » du type « regardez, 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 exactement comment votre audio et votre texte sont capturés, encadrés et diffusés, et auditer cette intégration au regard de vos propres exigences. Le moteur côté serveur avec lequel il dialogue est le nôtre — pas la boîte noire d'un tiers — 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 proposons aujourd'hui. Nous mettrons cet article à jour dès qu'il sera disponible.

Couche par couche : le choix par défaut vs. ce que nous opérons

Deux fils 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'infrastructures — afin que rien ne soit verrouillé sur la tarification ou la posture de conformité d'un fournisseur unique. Postgres peut migrer vers n'importe quel hébergeur Postgres ; le stockage peut migrer vers n'importe quel stockage S3 ; l'authentification se fédère au fournisseur d'identité que vous opérez déjà. La dernière ligne relève d'un troisième axe : le CRM qui héberge les fiches clients est domicilié dans l'UE (Pipedrive, estonien) plutôt qu'une plateforme commerciale américaine — pas open source, mais pas non plus sous juridiction américaine.

Quelques-unes de ces lignes méritent une phrase de plus. PostHog est open source et auto-hébergeable ; nous l'opérons sur le cloud européen de PostHog et le relayons en first-party via notre propre origine, afin que les événements ne soient pas silencieusement bloqués par les ad-blockers et ne transitent pas par un domaine d'analytics tiers. L'authentification ne passe jamais par un SaaS d'authentification tiers qui s'intercalerait entre vous et vos sessions — nous opérons nous-mêmes le flux OIDC et le 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 code est un script offline lié aux ressources de marque, jamais l'application chargée par vos utilisateurs.

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

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

La tuyauterie — l'hébergement et le SSR (Vercel), le calcul du serveur de réunion (Fly.io), les paiements (Stripe), l'email transactionnel (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 du calcul loué : notre propre code y est exécuté, et le serveur de réunion sur Fly gère bien la session en direct et le transcript que lit notre digest — mais il s'agit de notre code sur leurs machines, pas d'un produit fournisseur qui ingérerait votre réunion. Le tout s'exécute dans l'UE au runtime (le sujet de la carte d'exécution).

C'est un arbitrage délibéré et borné : posséder et ouvrir en open source le plan de données ; utiliser le meilleur SaaS disponible pour le plan de contrôle. Le nommer, c'est précisément le point — « 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 d'IA post-réunion, et le plan

Aucun modèle propriétaire domicilié aux États-Unis ne touche aux contenus issus de réunions. Les étapes de modèle de langage qui s'exécutent après l'appel — le digest IA (sujets, décisions, actions à mener), 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 zero-data-retention (atteint via l'AI Gateway de Vercel, épinglé au fournisseur 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 qui sert la voix et le chat en direct. La voix, le chat, les notes et les documents en temps réel ne sont jamais passés par un LLM généraliste, dès le départ.

Le seul modèle américain encore présent dans la boucle évalue notre benchmark de traduction public — il note des traductions automatiques de phrases de référence figées FLORES-200, jamais la réunion de qui que ce soit.

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

Pourquoi cela compte au-delà de nous

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

1. Auditable. Le SDK sur lequel s'exécute votre réunion est du code open source que votre équipe 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 verrouillage propriétaire. Ce qui peut être déplacé n'est lié à aucun fournisseur unique.
3. Auto-hébergeable. Les couches de données à standards ouverts — Postgres, S3, OIDC — s'exécutent déjà sur des infrastructures que vous contrôlez ; un moteur de traduction entièrement auto-hébergé est sur la feuille de route pour le client qui en aura besoin.

Voici l'image au 2026-06-07. Nous la mettrons à jour quand la pile changera — un fournisseur remplacé, une couche reconstruite, le modèle du digest remplacé. La configuration actuelle est vérifiable dans nos vercel.json et nuxt.config.ts ouverts, et dans le dépôt mind-sdk sous licence BSD-3-Clause lié plus haut.

Si une couche vous semble erronée, ou si votre revue 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 vous le voyiez découvert lors d'un audit de code.