La souveraineté du client à l'ère de l'IA

La plupart des plateformes d'IA parlent de vos données comme s'il s'agissait d'une ligne de leurs conditions d'utilisation. Nous les traitons comme l'architecture. En 2026, le guide de ByteByteGo sur le multi-tenancy a posé le compromis clairement : un système partagé est moins cher, mais « une fois que de nombreux clients dépendent de la même base de données, des mêmes serveurs et des mêmes tâches en arrière-plan, leurs destins se trouvent liés » (ByteByteGo, « A Guide to Multi-Tenancy: Benefits and Challenges », 2026). Nous avons construit Everythink à l'envers. La souveraineté est la valeur numéro quatre de nos cinq engagements, et sur cette plateforme c'est une fonctionnalité — pas un réglage que vous activez, ni un palier que vous achetez.

Key Takeaways

• Tenancy par réseau, pas un pool partagé : chaque organisation fonctionne avec sa propre tenancy isolée et ses propres credentials (Everythink, en production depuis 2016).
• Le multi-tenancy en pool partagé lie les destins des clients — un voisin bruyant ou un mauvais déploiement peut toucher tout le monde (ByteByteGo, 2026).
• Les outils self-hosted sont désormais notés sur six dimensions, dont l'isolation des tenants et la récupération de données (NocoBase, 2026).
• La souveraineté est étiquetée honnêtement : Whitelabel Network et les campagnes en propres credentials sont Production ✅ ; le wallet et le community credit sont Roadmap 🔵.

Que signifie la souveraineté du client sur une plateforme d'IA ?

La souveraineté signifie que la plateforme peut prouver où vivent vos données et qui peut les toucher, pas seulement le promettre dans un document de politique. En 2026, l'évaluation par NocoBase de plus de 20 outils self-hosted pour entreprises a mesuré le contrôle selon six dimensions — infrastructure, contrôle d'accès, audit et conformité, sécurité et récupération des données, maintenabilité et préparation à l'IA — et a listé « l'isolation des tenants » comme une exigence de contrôle d'accès de premier ordre (NocoBase, « 20+ Best Self Hosted Tools for Enterprises with Full Data Control », 2026). Cela correspond à notre façon de le traiter. La souveraineté n'est pas un réglage ; c'est une propriété conçue dans la topologie, les credentials et le modèle de visibilité.

[PERSONAL EXPERIENCE] Le moteur d'Everythink tourne en production depuis 2016, et la topologie que nous avons bâtie alors — network → community → room, chaque niveau un vrai polygone — a été façonnée par un refus de rassembler les clients dans un pool commun. Un network est la frontière la plus externe d'une organisation sur la plateforme. Tout ce qui se trouve à l'intérieur (communautés, rooms, membres, historique des messages) appartient à la tenancy de ce network. Nous ne mélangeons pas les données de deux networks pour entraîner un modèle partagé, et nous ne routons pas une requête d'un network vers les rooms d'un autre.

C'est le mécanisme derrière l'affirmation « vos données restent vôtres ». Ce n'est pas une clause de DPA que nous espérons voir tenir au tribunal ; c'est la forme du schéma. Quand un acheteur demande où sont ses données, la réponse est la tenancy de son network, pas « le cluster, alongside tout le monde ».

En quoi la tenancy par réseau diffère-t-elle d'un pool partagé ?

La tenancy par réseau donne à chaque organisation son propre espace isolé, tandis qu'un pool partagé met tous les clients dans la même base de données et les sépare avec une logique au niveau des lignes. Le guide de ByteByteGo de 2026 est franc sur le coût du partage : « un client qui lance un rapport lourd peut ralentir le service pour tout le monde à côté de lui. Un seul déploiement défectueux peut tous les impacter d'un coup… et le risque le plus sérieux concerne les fuites de données, où un client voit des données qui appartiennent à un autre » (ByteByteGo, « A Guide to Multi-Tenancy: Benefits and Challenges », 2026). Ce ne sont pas des risques théoriques — ce sont les modes de défaillance documentés du pooling.

[UNIQUE INSIGHT] Le modèle en pool partagé optimise le coût par client du fournisseur, pas l'isolation du client. La tenancy par réseau optimise à l'envers : le rayon d'explosion d'une défaillance est le network, pas la plateforme. Nous acceptons le coût opérationnel de cette frontière parce que c'est la frontière qu'un acheteur veut réellement quand il demande « mes données sont-elles en sécurité ».

Concrètement, sur Everythink :

• Chaque network est son propre tenant. Une requête porte le contexte de tenant depuis l'edge ; ce n'est pas à la couche applicative de s'en souvenir.
• Les communautés et les rooms vivent à l'intérieur du network. L'accès entre networks n'est pas une fonctionnalité manquante, c'est un choix de conception.
• Un job lourd dans un network ne peut pas bloquer un autre, parce qu'ils ne partagent pas le même contexte d'exécution que le font les tenants en pool.

C'est pourquoi nous appelons la souveraineté une fonctionnalité. L'isolation est construite, pas promise — et selon notre Theorem 3 (« une propriété est garantie exactement lorsque son mécanisme est implémenté et mesuré »), une capacité ne gagne le mot « Production » que lorsque le mécanisme qui la sous-tend est à la fois construit et activement mesuré. ✅

En quoi envoyer des campagnes avec vos propres credentials vous protège-t-il ?

Les campagnes sur Everythink partent via vos propres credentials email, SMS et push — pas via un compte de pool partagé contrôlé par la plateforme. La revue 2026 de NocoBase des plateformes d'agents IA open-source note le self-hosting sur « contrôle complet des données » et relève que les credentials, les logs d'audit et les permissions au niveau des champs sont ce qui sépare un outil que vous possédez d'un outil qui vous possède (NocoBase, « 8 Open-Source AI Agent Platforms for Building Internal Tools », 2026). La même logique s'applique à la messagerie sortante : si le compte fournisseur de la plateforme envoie vos campagnes, la plateforme est dépositaire de votre liste de relations et de votre réputation d'expéditeur.

Quand vous apportez vos propres credentials :

• Les problèmes de délivrabilité se diagnostiquent dans les logs de votre propre fournisseur, pas via un ticket de support chez nous.
• Votre réputation d'expéditeur appartient à votre domaine, pas à un pool partagé qu'un mauvais acteur dans un autre network peut empoisonner.
• Votre liste d'abonnés n'a jamais à être exportée chez un tiers pour être atteinte — elle reste dans la tenancy de votre network et est envoyée via votre fournisseur.

C'est une décision de souveraineté, et sur Everythink c'est Production ✅. Le module Campaigns, au côté de Social et du Whitelabel Network, est livré aujourd'hui avec le modèle en propres credentials. Nous ne décrivons pas un élément de roadmap ; le mécanisme est construit et en usage.

Il y a un compromis, et nous le disons honnêtement : apporter vos propres credentials signifie que vous provisionnez et payez vos propres comptes fournisseur. Nous ne faisons pas semblant que c'est gratuit. C'est le coût du fait de garder le canal sortant comme vôtre.

La visibilité publique ou privée est-elle une décision que la plateforme devrait imposer ?

Non — et le framework 2026 de NocoBase traite « l'isolation des tenants » comme une exigence de contrôle d'accès précisément parce que la visibilité est une politique que l'opérateur devrait fixer, pas le fournisseur (NocoBase, « 20+ Best Self Hosted Tools for Enterprises with Full Data Control », 2026). Notre page qui-nous-sommes l'énonce comme politique écrite : « Votre network, votre marque, vos données. Visibilité publique ou privée par room, décidée par vous. » Une room est une zone fonctionnelle au sein d'une communauté — la page d'événements d'une antenne, le grand livre interne d'une coopérative, le bureau d'aide aux citoyens d'une municipalité. Certaines rooms sont destinées à être des pages publiques sur l'internet ouvert ; d'autres à une adhésion fermée. La plateforme ne décide pas laquelle est laquelle.

Cela compte parce que la visibilité est l'endroit où la souveraineté cesse d'être abstraite. Une plateforme qui met par défaut chaque room en public a pris une décision sur vos données en votre nom. Une plateforme qui met par défaut chaque room en privé a pris la décision inverse. Nous ne fixons ni l'un ni l'autre — l'opérateur du network règle la visibilité par room, et la topologie l'applique.

[ORIGINAL DATA] À travers les trois niveaux topologiques de la plateforme, la visibilité est une propriété par room, pas par network. Cela signifie qu'un seul network peut faire fonctionner une communauté tournée vers le public (les événements ouverts d'une chambre de commerce) et une communauté privée (les approbations internes de son conseil) sous la même marque et la même identité, sans seconde installation. C'est la configuration, pas le code, qui fait basculer une room de privé à public.

L'étiquette d'honnêteté ici est Production ✅ pour le mécanisme de visibilité lui-même. Les modules qui reposent sur les rooms portent leurs propres états, et nous ne les confondons pas : Matchmaking ⚠️ Partial, Marketplace ⚠️ Partial, Calendar ⚠️ Partial. Chacun est utile aujourd'hui et non terminé, et nous les étiquetons ainsi pour qu'un acheteur n'infère pas une suite aboutie d'une capacité Production.

Quel est le coût de la souveraineté — l'isolation signifie-t-elle une charge de maintenance ?

L'isolation a un coût, mais la configuration plutôt que le code est ce qui l'empêche de devenir une charge de maintenance. Le guide de ByteByteGo de 2026 note que l'alternative au partage — « une copie dédiée par client » — est « facile à raisonner, mais le coût de maintenance de centaines de copies séparées augmente avec chaque nouveau client » (ByteByteGo, « A Guide to Multi-Tenancy: Benefits and Challenges », 2026). C'est vrai quand chaque copie est un déploiement séparé. Ce n'est pas vrai quand chaque tenant est un contexte isolé au sein d'une plateforme configurée.

Le modèle d'Everythink est le second. La plateforme est une base de code ; chaque network est une tenancy, pas un fork. Activer un module dans une room est un réglage, pas un sprint. L'opérateur du network change la forme de son monde sans que nous lancions de release, et sans qu'il écrive du code. C'est ainsi que nous gardons le modèle par network abordable : l'isolation est dans la couche données et credentials, pas dans la couche de déploiement.

C'est aussi pourquoi notre roadmap est publiée, pas cachée. La Federation entre networks 🔵, le token wallet par network 🔵 et le community credit 🔵 sont datés de 2026 et étiquetés Roadmap — pré-revenus, non implémentés, et soumis aux cadres financiers et de valeurs mobilières applicables (par ex., l'analyse Howey) avant tout lancement. Nous ne les présenterons pas comme Production. La souveraineté sur la couche économique du network est une promesse que nous n'avons pas encore gagné le droit de revendiquer, alors nous ne la revendiquons pas.

Comment étiquetons-nous honnêtement le reste de la pile de souveraineté ?

Le même système d'honnêteté qui marque la couche réseau Production marque tout le reste. Theorem 3, issu de notre série académique de 21 papers, dit qu'une propriété est garantie exactement lorsque son mécanisme est implémenté et mesuré. Nous l'appliquons à chaque affirmation sur ce site, y compris celles de cet article.

Capacité	État	Ce que cela signifie
Moteur conversationnel HAI	✅ Production	En production depuis 2016 ; répond avec contexte de room aujourd'hui
Whitelabel Network (web + iOS + Android)	✅ Production	Une marque, une identité, votre app sous votre nom
Social + Campaigns (propres credentials)	✅ Production	Modules combinables, vos propres comptes fournisseur
Matchmaking / Marketplace / Calendar	⚠️ Partial	Utiles aujourd'hui, non terminés — étiquetés en conséquence
Federation entre networks	🔵 Roadmap	Conçu, non construit ; 2026
Wallet, token par network, Community Credit	🔵 Roadmap	Pré-revenus, non implémentés ; soumis à la revue Howey

Nous ne reclassons jamais un élément Partial ou Roadmap en Production pour paraître fini. Si un acheteur demande si le wallet existe aujourd'hui, la réponse est non. La souveraineté inclut le droit qu'on vous dise la vérité sur ce qui est construit.

Foire aux questions

Quelle est la différence entre tenancy par réseau et pool partagé ?

La tenancy par réseau donne à chaque organisation son propre contexte de tenant isolé ; un pool partagé met tous les clients dans la même base de données et les sépare avec une logique au niveau des lignes. Le guide de ByteByteGo de 2026 liste les modes de défaillance du modèle en pool : voisins bruyants, rayon d'explosion partagé, et fuites de données entre tenants. Nous avons choisi la tenancy par réseau pour que le rayon d'explosion d'une défaillance soit le network, pas la plateforme.

Est-ce que j'envoie les campagnes via le compte fournisseur d'Everythink ou le mien ?

Le mien. Campaigns est Production ✅ avec le modèle en propres credentials : vous provisionnez et payez vos comptes fournisseur email, SMS et push, et la plateforme envoie via eux. Votre réputation d'expéditeur et votre liste d'abonnés restent vôtres. Nous ne mettons pas la messagerie sortante en pool entre networks.

Un seul network peut-il faire fonctionner des rooms publiques et privées ?

Oui. La visibilité est une propriété par room, pas par network, et c'est Production ✅. Un network peut faire fonctionner une communauté tournée vers le public (événements ouverts) et une communauté privée (approbations internes) sous la même marque et la même identité, sans seconde installation. L'opérateur fixe la visibilité par room — la plateforme n'impose pas de valeur par défaut.

Le wallet ou le community credit sont-ils disponibles aujourd'hui ?

Non. Le token wallet par network et le community credit sont Roadmap 🔵 — pré-revenus, non implémentés, datés de 2026, et soumis aux cadres financiers et de valeurs mobilières applicables (par ex., l'analyse Howey) avant tout lancement. Nous ne les présenterons pas comme Production, et rien de cette couche n'est en service aujourd'hui.

Comment prouvez-vous la souveraineté au lieu de simplement la revendiquer ?

Selon notre Theorem 3, une propriété est garantie exactement lorsque son mécanisme est implémenté et mesuré. Le mécanisme de la souveraineté est la tenancy par réseau, les campagnes en propres credentials et la visibilité par room — chacun construit et en production. L'isolation vit dans le schéma et la topologie, pas dans un document de politique.

---

Si vous allez construire un monde, construisez-le sur une plateforme qui vous dit où vivent vos données et ce qui est terminé. Créez votre network — ou réservez une démo et demandez-nous de pointer le mécanisme derrière chaque affirmation de cette page.

Sources

• ByteByteGo (Alex Xu), "A Guide to Multi-Tenancy: Benefits and Challenges", retrieved 2026-08-23, https://blog.bytebytego.com/p/a-guide-to-multi-tenancy-benefits
• NocoBase, "20+ Best Self Hosted Tools for Enterprises with Full Data Control", retrieved 2026-08-23, https://www.nocobase.com/en/blog/20-best-self-hosted-tools-for-enterprises
• NocoBase, "8 Open-Source AI Agent Platforms for Building Internal Tools", retrieved 2026-08-23, https://www.nocobase.com/en/blog/8-open-source-ai-agent-platforms-for-internal-tools