Étude de cas : Charges de travail réelles, un seul plan de contrôle

Nous n'avons pas encore de mur de logos de clients. Ce que nous avons à la place, c'est notre propre infrastructure, exécutant des charges de travail de production et quasi-production sous Odysseus chaque jour &mdash ; et nous l'avons mesurée plutôt que décrite de mémoire.

L'hôte, mesuré le 21 août 2026

123
Conteneurs sous la gestion d'Odysseus
8 / 23
Cœurs / Go RAM, VPS unique
30d
Uptime de l'hôte au moment de la mesure

123 conteneurs n'est pas un benchmark synthétique ou un cluster de démo lancé pour faire bien paraître un chiffre &mdash ; c'est le comptage de docker ps sur la machine sur laquelle s'exécute le plan de contrôle de ce site lui-même, au moment où nous avons écrit cette page. Cela inclut les charges de travail ci-dessous plus tout le reste que ce nœud exécute : le plan de contrôle lui-même, le site marketing, la surveillance et des projets clients sans rapport.

Charge de travail A : une plateforme de traitement de documents réglementée

L'identité de ce locataire est sous NDA, donc ce qui suit décrit la forme de la charge de travail, pas qui l'exécute. C'est une plateforme réelle et multi-services pour le traitement et la vérification de documents réglementés &mdash ; le genre de pile qui serait une application Kubernetes complète dans la plupart des entreprises, s'exécutant ici en tant que 23 conteneurs sous un seul locataire Odysseus :

C'est une architecture de microservices avec un vrai graphe de dépendances &mdash ; une base de données, un stockage objet, un journal de transparence avec sa propre topologie de cinq conteneurs, et une douzaine de workers mis à l'échelle indépendamment &mdash ; s'exécutant en tant qu'un seul locataire Odysseus, sur un seul plan de contrôle, sans orchestrateur séparé superposé en dessous.

Charge de travail B : un backend multi-locataire SaaS

Un second locataire, sans rapport, sur le même nœud exécute 36 conteneurs : des services backend et frontend, un pipeline d'ingestion et d'extraction de documents, des embeddings, une passerelle et un constructeur MCP, une paire de console super-admin et tenant-admin (chacune avec son propre backend et frontend), MongoDB, Redis, RabbitMQ, et un petit cluster interne de relais de base de données. C'est une application entièrement séparée avec une forme entièrement séparée, isolée du Workload A par la même limite de locataire décrite sur la page Conformité &mdash ; pas une variation de la même pile.

Surcharge du plan de contrôle à cette échelle

Rien de tout cela n'exécute un plan de contrôle plus lourd à gérer. L'empreinte mémoire résidente propre d'Odysseus est mesurée &mdash ; pas modélisée &mdash ; à 47&ndash ;51 Mo en production et 49&ndash ;64 Mo en développement, échantillonnée sur une fenêtre de 14 minutes à travers 18&ndash ;19 lectures par environnement le 20 août 2026, publiée dans la note méthodologique de la page d'accueil. Une vérification ponctuelle sur ce même nœud le 21 août 2026 a indiqué 57 Mo résidents &mdash ; à l'intérieur de cette plage mesurée, pas une nouvelle affirmation.

Ce que cela montre, et ce que cela ne montre pas

Ceci est un seul nœud, pas un benchmark à l'échelle d'une flotte, et nous le présentons comme tel : une preuve qu'Odysseus tient le coup sous une charge de travail réelle, multi-services et sensible à la sécurité, s'exécutant aux côtés d'un backend multi-locataires sans rapport SaaS &mdash ; pas une affirmation sur les plafonds. Pour savoir où le plan de contrôle de la plateforme s'exécute sur une infrastructure réellement séparée, voir la page preuve multi-cloud.

Comment ces chiffres et ces affirmations ont été obtenus

  1. Les décomptes de conteneurs ont été pris directement depuis docker ps sur l'hôte où ce site est exécuté, le 21 août 2026 : docker ps -a --format '{{.Names}}' | wc -l pour le total, et un filtre par préfixe de nom par locataire pour les décomptes des deux charges de travail. Ils ne proviennent pas d'un document de conception ou d'une description antérieure de l'une ou l'autre pile. Exécution indépendante répétée une seconde fois le même jour : 123 au total, 23 et 36 pour les deux charges de travail, inchangé.
  2. Les noms spécifiques des conteneurs pour le Workload A et le Workload B (la liste des workers, les composants du journal de transparence, la liste des services du backend SaaS) ont été lus depuis la même sortie docker ps, et non supposés à partir d'un document d'architecture, de sorte qu'un nom que nous n'avons pas pu trouver en cours d'exécution n'est pas listé comme s'il l'était.
  3. La mémoire du plan de contrôle n'est pas re-mesurée sur cette page. Elle est citée à partir du chiffre daté et sourcé méthodologiquement de la page d'accueil elle-même, avec une vérification ponctuelle le même jour notée comme corroboration et non présentée comme une seconde mesure indépendante.
  4. Le temps de disponibilité du nœud et les chiffres des cœurs/RAM proviennent de uptime, nproc et free -h exécutés sur le même nœud au même moment que les comptages de conteneurs.