Orchestration d'entreprise.
Pas de Kubernetes requis.

Comment ces chiffres et affirmations ont été obtenus

1. La résidence géographique des données est un filtre de placement, et elle est livrée désactivée. Un déploiement porte odysseus.io/data-residency-country — un code ISO 3166-1 alpha-2 tel que CA ou DE — ou odysseus.io/data-residency-region, qui nomme un ensemble défini par l'opérateur de ces codes, ou odysseus.io/blocked-countries. L'ordonnanceur compare chaque valeur aux étiquettes de pays et de région du nœud avant de placer quoi que ce soit, et un nœud qui ne satisfait pas l'exigence est retiré de l'ensemble des candidats — ainsi le déploiement ne peut pas atterrir en dehors de sa géographie permise, plutôt que d'y être trouvé ensuite. Elle est activée par installation dans la configuration du plan de contrôle et est désactivée par défaut ; les régions sont les définitions propres de l'opérateur, pas les nôtres. Kubernetes peut exprimer la même contrainte : il livre topology.kubernetes.io/region et topology.kubernetes.io/zone comme étiquettes de nœud bien connues, et l'affinité de nœud pour sélectionner sur elles, mais pas d'étiquette de pays ou de résidence propre — donc la résidence y est assemblée à partir d'étiquettes personnalisées et de règles d'affinité — kubernetes.io. La différence réside dans l'endroit où le concept vit, pas dans la possibilité de le faire. Nomad n'a pas besoin d'un tel assemblage et cette ligne n'est pas un différenciateur contre lui : region et datacenter sont des citoyens de premier plan dans son architecture, et un job contraint le placement sur ${node.datacenter}, ${node.region} ou toute valeur ${meta.<key>} définie par l'opérateur. Ce qui diffère là-bas est le vocabulaire plutôt que la puissance — le nôtre est une étiquette de résidence nommée portant des codes pays ISO et l'appartenance à une région, le leur une contrainte à usage général pointée vers ce que l'opérateur a écrit sur le nœud.
2. Les chiffres de mémoire d'Odysseus sont mesurés, pas modélisés. Les deux correspondent à la mémoire résidente (RSS) du processus en cours d'exécution, échantillonnée sur une fenêtre de 14 minutes le 20 août 2026 sur deux installations en direct : production (plan de contrôle 47–51 Mo sur 19 échantillons, agent de nœud 26–28 Mo) et développement (plan de contrôle 49–64 Mo sur 18 échantillons, agent de nœud 26–28 Mo). Le plan de contrôle s'exécute une fois par installation ; l'agent s'exécute une fois par nœud. Le plan de contrôle publie lui-même le chiffre en tant que process_resident_memory_bytes sur son point de terminaison Prometheus /metrics, afin qu'il puisse être vérifié directement plutôt que cru sur parole. Nous citons la RSS plutôt que docker stats car ce dernier inclut le cache de pages récupérable, qui sur un conteneur fraîchement démarré affiche une valeur plusieurs fois supérieure sans qu'aucune n'appartienne à l'orchestrateur. Le chiffre pour Kubernetes est le minimum documenté dans le guide d'installation kubeadm en amont : « 2 Go ou plus de RAM par machine » — kubernetes.io.
3. Comparaison par nœud. Kubernetes en amont ne publie aucune réserve par défaut pour ses agents de nœud — kubeReserved et systemReserved fournissent tous deux une valeur vide — il n'y a donc pas de chiffre officiel unique à citer. Le chiffre profilé est le profilage des ressources K3s publié par SUSE, qui place les composants Kubernetes sur un nœud agent (travailleur) — selon ses termes, « le kubelet et l'agent k3s » — à 275 Mo sur un Intel 8375C, à partir de lectures au 95e percentile en régime permanent — docs.k3s.io. K3s est un binaire unique fusionné avec son propre runtime intégré, ceci constitue donc un minimum pour Kubernetes en amont exécutant les mêmes composants en tant que processus distincts, et non un équivalent. Les chiffres réservés représentent une capacité que les fournisseurs gérés retiennent sur chaque nœud travailleur avant qu'un conteneur d'application ne soit planifié, calculée à partir de leurs propres formules publiées : AWS EKS réserve (11 × max-pods) + 255 Mio (574 Mio sur un m5.large, qui supporte 29 pods) — docs.aws.amazon.com ; Google GKE réserve 25 % des premiers 4 Gio et 20 % des 4 Gio suivants plus 100 Mio (≈1,9 Gio sur un nœud de 8 Gio) — cloud.google.com. La capacité réservée est une allocation que le planificateur retient, et non une consommation mesurée ; nous l'étiquetons comme telle car les deux ne sont pas la même chose.
4. Les nombres de conteneurs sont par nœud, et le nôtre est une déclaration d'adéquation, pas une limite. La plage décrit où Odysseus est conçu pour se situer — au-dessus du point où Docker Compose atteint ses limites, en dessous du point où Kubernetes justifie sa complexité. Il s'agit d'un positionnement, pas d'un résultat de benchmark, et nous ne le présentons pas comme tel. Un total de plateforme est ce chiffre par nœud réparti sur l'ensemble des nœuds qu'un plan de contrôle gère — une conséquence architecturale, pas quelque chose que nous avons mesuré à l'échelle de la flotte, nous ne publions donc pas non plus de chiffre pour la flotte. Le chiffre de Kubernetes est le plafond documenté par ce projet lui-même pour un cluster pris en charge : « Pas plus de 110 pods par nœud », énoncé aux côtés de « Pas plus de 5 000 nœuds » et « Pas plus de 300 000 conteneurs au total » — kubernetes.io. Les deux colonnes ne comptent pas la même unité — Kubernetes limite les pods, un pod contient un ou plusieurs conteneurs, et nous comptons les conteneurs — lisez-les donc comme adjacents plutôt que interchangeables. Nous ne faisons pas de conversion entre eux, car le ratio dépend de la manière dont les pods sont construits. Les distributions gérées imposent des limites encore plus basses : AWS EKS dérive la limite de pods par nœud à partir des interfaces réseau de la machine plutôt que de ce chiffre documenté, et son propre exemple détaillé est de 29 pods sur une machine à deux vCPU — le document cité dans la note 3. Nomad ne publie aucune limite par nœud, c'est pourquoi sa cellule l'indique plutôt que d'afficher un chiffre. La plus grande exécution que HashiCorp publie est sa propre démonstration : 2 000 000 de conteneurs répartis sur 6 100 clients — le terme de Nomad pour un nœud exécutant son agent — dans 10 régions AWS, planifiés en 22 minutes par trois serveurs — hashicorp.com — soit une moyenne d'environ 330 conteneurs par client. Il s'agit d'une démonstration plutôt que d'une limite prise en charge, et c'est un nombre plus grand que tout ce que nous avons exécuté.
5. La colonne Nomad est sourcée, et elle remporte plusieurs lignes. Nomad est le pair le plus proche d'Odysseus dans ce tableau — un unique binaire, léger en ressources, et conçu pour s'intégrer avec le même Consul sur lequel cette plateforme fonctionne — donc un cadrage qui fonctionne contre Kubernetes serait injuste ici, et nous n'en avons pas utilisé un. Les mises à jour progressives, les canaris avec auto_promote, le retour automatique d'un déploiement échoué et le retour au dernier job stable sont tous dans le bloc update de la spécification du job dans l'Édition Communautaire — developer.hashicorp.com. L'autoscaling est réel, et arrive sous la forme d'un second démon à exécuter : le Nomad Autoscaler est « construit et publié séparément de Nomad », couvre la mise à l'échelle horizontale des applications et du cluster, et lit Prometheus parmi ses sources de métriques — developer.hashicorp.com. La gestion des secrets est au moins notre égale : le répertoire secrets/ d'une tâche est soutenu par un système de fichiers en mémoire et monté noexec — developer.hashicorp.com. Les politiques et rôles ACL sont dans l'Édition Communautaire. Ce qui ne l'est pas : la journalisation d'audit, les quotas de ressources et la politique Sentinel sont dans Nomad Enterprise, tout comme le déploiement d'un job sur des régions fédérées — la fédération des régions elles-mêmes ne l'est pas — developer.hashicorp.com. Les espaces de noms sont dans l'Édition Communautaire, et ils segmentent les jobs, les allocations, les déploiements et les évaluations ; la documentation est explicite sur le fait que « Nomad ne met pas en espace de noms les objets partagés entre plusieurs espaces de noms. Cela inclut les nœuds » — developer.hashicorp.com. Kubernetes trace la même ligne — « les ressources de bas niveau, telles que les Nœuds … ne sont dans aucun espace de noms » — kubernetes.io; sur cette plateforme, un nœud est inscrit à un locataire, ce que cette ligne enregistre. Le chiffre des serveurs est l'architecture de référence propre à HashiCorp — « Un cluster Nomad comprend typiquement trois ou cinq serveurs », avec 2 à 4 cœurs et 8 à 16 Go de mémoire chacun pour un petit déploiement de production — developer.hashicorp.com. Il s'agit d'un dimensionnement machine qu'un lecteur devrait traiter de la même manière que nous traitons le chiffre Kubernetes dans la note 2 : une recommandation, pas une mesure de mémoire processus. Nous n'avons trouvé aucun chiffre publié pour l'agent client, donc la colonne indique qu'il n'y en a pas plutôt que d'en deviner un, et la ligne sur la courbe d'apprentissage est notre estimation plutôt que la mesure de quiconque.
6. Le nombre d'outils Athena est un nombre de sites d'appel, pas un nombre rond. Il s'agit de server.registerTool( sites d'appel dans athena-mcp/src/tools/*.ts — 80 au moment de la rédaction — avec deux corrections appliquées par-dessus : la paire cronjob_suspend/cronjob_resume est enregistrée depuis un seul site d'appel à l'intérieur d'une boucle (un site, deux outils, donc +1), et les trois assistants de découverte (search_tools, describe_tool, request_tool) sont enregistrés séparément par makeDiscoveryTools() dans server.ts plutôt que par un appel correspondant à ce modèle (+3). 80 − 1 + 2 + 3 = 84. N'importe qui peut reproduire le chiffre de base avec grep -rc "server.registerTool(" athena-mcp/src/tools/*.ts sur la version taguée et redériver le même total à partir des deux corrections ci-dessus.