Nutanix rachète Ryax (Lyon) : impacts concrets sur orchestration IA, GPU et hybride

Un rachat local qui vise un problème très terre à terre : la galère des GPU en hybride

Le 22 septembre 2026, Nutanix a annoncé l’acquisition de Ryax Technologies, une société basée à Lyon. Source: communiqué officiel Nutanix. Nutanix dit vouloir intégrer des briques Ryax dans Nutanix Kubernetes Platform (NKP) et Nutanix Enterprise AI (NAI), dans de futures versions. Traduction opérationnelle: pas “magique” demain matin, mais un mouvement clair vers une plateforme IA entreprise plus intégrée.

Pourquoi ça compte pour Lyon et la région AURA? Parce que Ryax est une boîte lyonnaise (siège 254 rue Vendôme, Lyon 3e, RCS Lyon) et parce que les DSI locales ont le même problème que partout: des projets IA qui tournent entre on-prem, cloud, parfois HPC, avec des GPU chers, rares, et mal utilisés si l’orchestration n’est pas carrée.

Le vrai sujet n’est pas “qui a racheté qui”. Le sujet, c’est: quelles briques techniques vont bouger, quels gains plausibles sur les GPU, et quels risques de dépendance si tu construis ta plateforme IA entreprise autour d’une techno qui change de mains.

Rappel factuel: qui rachète quoi, et ce que Nutanix promet exactement

Date: 22 septembre 2026, annonce publique Nutanix.

Objet: acquisition de Ryax Technologies.

Intention produit: intégrer des capacités Ryax (orchestration, smart scheduling, optimisation de l’usage GPU) dans NKP et NAI, ciblées pour de “future releases”. Source: communiqué Nutanix et billet Nutanix associé.

Ancrage local: Ryax est présentée comme “headquartered in Lyon, France”. Source: page “About” Ryax. Côté registre, Ryax est immatriculée au RCS de Lyon (SIREN 833 192 479, inscription 09/11/2017). Source: Pappers.

Point clé: le bénéfice dépend du calendrier réel d’intégration. Tant que ce n’est pas dans ta version NKP/NAI avec une doc et un support, c’est une promesse. Et les promesses ne font pas tourner les jobs GPU.

Ce que Ryax fait, vu “run” et pas “pitch”: les briques d’orchestration IA concernées

1) Pipelines et exécution de workflows: orchestrer la chaîne data vers modèle

Ryax se positionne comme un workflow orchestrator orienté data/IA. En clair: tu décris un pipeline (ETL, feature engineering, entraînement, évaluation, inférence batch, ou même chaînes LLM), et la plateforme exécute, surveille, relance, historise.

Sur le plan technique, Ryax documente une architecture en composants (studio, runner, repository, action-builder, etc.) déployable sur Kubernetes (Helm), avec aussi des possibilités côté HPC (Slurm est mentionné dans le projet open source). Source: documentation Ryax et dépôt GitHub Ryax Engine.

Ce que ça change si Nutanix l’intègre vraiment dans NKP/NAI:

• Standardisation: un même cadre pour exécuter des pipelines IA sur l’infra Nutanix (et potentiellement au-delà), au lieu d’empiler Airflow, Argo, scripts, et bricolages.
• Moins de “glue code”: si les primitives d’exécution (workflows, runners, policies) deviennent natives, tu relies moins de morceaux à la main.
• Mais: risque de “nutanix-isation” du design. Si tes workflows deviennent dépendants de concepts spécifiques NKP/NAI, migrer plus tard peut coûter cher.

2) Scheduling multi-contraintes: arrêter de poser les workloads “au hasard”

Ryax met beaucoup l’accent sur le scheduling. Pas juste “lancer un job”, mais décider où il tourne, selon des contraintes et des objectifs.

Concrètement, Ryax documente des workflows multi-site: une même chaîne peut exécuter certaines actions sur un cluster A, d’autres sur un cluster B, avec:

• des contraintes (exécuter sur tel site, tel node pool, tel type de ressource),
• des objectifs (pondérer coût, énergie, etc.), arbitrés par le scheduler.

Source: tutoriel multi-site de la doc Ryax.

Pourquoi c’est utile dans une DSI lyonnaise typique:

• Tu as du on-prem pour les données sensibles ou le legacy.
• Tu burst sur du cloud quand il faut entraîner ou faire du batch lourd.
• Tu as parfois un coin HPC ou un cluster dédié data science.

Sans scheduling propre, tu fais du placement “à la main”, ou tu laisses Kubernetes décider avec une vision partielle. Résultat: files d’attente, GPU sous-utilisés, coûts qui dérapent.

3) Optimisation GPU: densité, fractionnement, bin packing

C’est probablement la partie la plus explosive, parce que c’est là que l’argent est. Ryax revendique des mécanismes d’optimisation des ressources (CPU, GPU, RAM), et documente explicitement:

• Bin packing: mieux “tasser” les workloads sur les bons nœuds, éviter les GPU à moitié vides.
• GPU fractioning: partage plus fin des GPU quand c’est pertinent.

Source: concepts Ryax.

De son côté, Nutanix reprend cet angle et parle d’utilisation GPU plus fine et de smart scheduling via NKP et NAI. Source: communiqué Nutanix.

Nutanix cite aussi des chiffres de tests attribués à Ryax (à traiter comme des chiffres éditeur, pas comme une vérité universelle): réduction de node-hours sur des bursts deep learning, et baisse de coût par exécution via fractionnement GPU (exemple avec MIG et H100). Source: billet Nutanix.

À retenir côté terrain: si ton problème n’est pas “j’ai trop de demandes GPU”, mais “je n’ai pas de GPU du tout”, l’orchestration ne crée pas du silicium. Par contre, si tu as déjà des GPU et qu’ils sont mal partagés, l’optimisation peut faire une vraie différence.

Ce que ça peut changer pour les DSI et équipes data à Lyon et en AURA

Roadmap: le mot qui doit te rendre méfiant, c’est “future releases”

Le communiqué Nutanix est clair: intégration Ryax dans NKP/NAI dans de futures versions. Donc si tu es en train de refondre une plateforme IA entreprise (MLOps hybride, GenAI interne, pipelines data), tu dois éviter deux erreurs classiques:

• Designer la cible sur une feature pas sortie.
• Signer des engagements long terme en supposant que l’intégration arrive “vite”.

Ce que tu fais à la place: tu demandes une matrice version par version (NKP X, NAI Y) avec ce qui est livré, ce qui est en preview, et ce qui est juste “targeted”. Et tu écris tes décisions d’archi en conséquence.

Intégration: gain de simplicité… ou nouvel empilement

Deux scénarios plausibles.

Scénario A: Ryax devient une couche vraiment native dans NKP/NAI. Tu gagnes un control plane plus unifié: pipelines, policies de scheduling, optimisation GPU, observabilité, le tout “dans la même famille”. Pour une DSI, c’est séduisant: moins d’outils à maintenir, moins de compétences rares à empiler.

Scénario B: Ryax reste un composant semi-externe, packagé Nutanix, mais avec ses propres concepts, ses propres dépendances, et une intégration partielle. Tu te retrouves avec un empilement de plus. Et tu ajoutes un point de friction au run.

Ta job, c’est d’identifier quel scénario est réel, pas espéré. Et ça se teste sur un pilote concret.

Support et run: acquisition = changements possibles de packaging, SLA et licences

Nutanix indique que l’équipe Ryax rejoindra Nutanix en France. Source: communiqué Nutanix. Ça peut être une bonne nouvelle pour le support en fuseau horaire local. Mais une acquisition, c’est aussi souvent:

• un changement de modèle de licence (bundle, options, métriques),
• des SLA qui se déplacent (ou se renégocient),
• des canaux support qui changent (portail, process, priorisation),
• une roadmap open source qui peut ralentir ou se fermer.

Donc si tu as déjà Ryax en place, ou si tu l’évalues: tu demandes noir sur blanc comment ça va être supporté, sous quel contrat, et avec quelle garantie de compatibilité.

Orchestration IA et MLOps hybride: où Ryax se positionne dans ta stack

Pour décider, il faut être clair sur ce que tu appelles orchestration IA. Beaucoup de boîtes mélangent orchestrateur de workflows, plateforme d’intégration (iPaaS) et RPA. Si ce sujet est flou chez toi, pose la base ici: https://lyon-ia.com/blog/orchestrateur-ipaas-rpa-differences.

Dans une stack MLOps hybride, tu peux voir Ryax comme:

• une couche pipelines pour enchaîner les étapes data et IA,
• une couche scheduling pour décider où exécuter (multi-cluster, multi-site),
• un levier optimisation GPU pour réduire gaspillage et coûts,
• un point d’intégration possible avec la plateforme Kubernetes (NKP) et la plateforme IA (NAI).

Ce que Nutanix vise, c’est une histoire “IA anywhere” plus cohérente. Le risque, c’est que “cohérent” devienne “captif”.

Le vrai risque après une acquisition: la dépendance fournisseur, pas la techno

Après un Nutanix rachat Ryax, la question n’est pas “est-ce que Ryax est bon”. La question, c’est: qu’est-ce que tu peux encore contrôler si, dans 18 mois, le produit change de cap.

Trois dépendances à mesurer

• Dépendance d’exécution: si tes pipelines sont codés dans un format spécifique (DSL, UI, actions propriétaires), combien coûte la migration?
• Dépendance d’infrastructure: est-ce que l’orchestrateur tourne seulement “bien” sur NKP, ou aussi sur un Kubernetes standard, voire sur d’autres environnements?
• Dépendance GPU: si les optimisations (fractionnement, bin packing) sont liées à un packaging Nutanix, peux-tu les reproduire ailleurs?

Comment tu limites le lock-in (sans te raconter d’histoires)

• Découpe: sépare orchestration, registry, feature store, serving, observabilité. Ne mets pas tout dans un seul panier.
• Contrats: exige des clauses de réversibilité, d’export, et des engagements de support. Si tu veux une base, tu as une checklist utile ici: https://lyon-ia.com/blog/contrat-fournisseur-ia-clauses.
• Tests de sortie: fais un “exit test” dès le pilote. Oui, dès le début. Exemple: ré-exécuter un workflow critique sur une alternative, ou au minimum exporter les définitions et les artefacts.
• Observabilité indépendante: garde des logs et métriques exploitables hors outil, sinon tu perds la capacité d’audit et de comparaison.

Ce que tu dois regarder si ton enjeu prioritaire, c’est l’optimisation GPU

Les GPU se gèrent comme une ressource critique. Si Ryax apporte réellement du smart scheduling et du fractionnement, tu dois évaluer sur des critères concrets, pas sur une démo.

Check rapide côté infra

• Quels GPU (modèles, MIG ou non, hétérogénéité) et quels drivers?
• Quels patterns: entraînement long, batch court, inférence en rafales, jobs interactifs data science?
• Quelles contraintes: données qui ne sortent pas du site, latence, coûts cloud, fenêtres de run?
• Quel niveau de contention: files d’attente, priorités, quotas par équipe?

Ce que tu veux mesurer pendant un pilote

• Taux d’utilisation GPU (pas juste “GPU busy”, mais corrélé à ton throughput utile).
• Temps d’attente moyen avant exécution (queueing).
• Coût par run et coût par résultat (un modèle validé, un lot inféré, etc.).
• Taux d’échec et qualité des reprises (retries, checkpointing, idempotence).

Tu veux une décision platform? Mesure avant et après. C’est basique, mais beaucoup ne le font pas. Si tu veux une méthode simple, tu peux reprendre le principe “avant/après” ici: https://lyon-ia.com/blog/mesurer-gain-reel-usage-ia.

Grille de questions à poser avant de bâtir ou refondre une plateforme IA hybride autour de ces composants

Tu veux construire une plateforme IA entreprise et tu regardes Ryax Lyon via Nutanix? Pose ces questions. Et exige des réponses testables.

1) Roadmap et disponibilité

• Dans quelle version NKP et NAI l’intégration Ryax est-elle disponible, précisément?
• Qu’est-ce qui est GA, qu’est-ce qui est preview, qu’est-ce qui est “planned”?
• Quels sont les prérequis (GPU spécifiques, MIG, versions Kubernetes, drivers)?

2) Orchestration IA: workflows et portabilité

• Comment sont définis les workflows: YAML, code, UI, DSL propriétaire?
• Peut-on exporter workflows, logs d’exécution, artefacts, et historiques?
• Quelle stratégie pour gérer les erreurs, reprises, idempotence, et traçabilité?

3) Scheduling multi-sites et contraintes “réelles”

• Peut-on imposer des contraintes fortes: données localisées, conformité, réseau, latence?
• Comment sont gérées les priorités, quotas, et la préemption?
• Le placement prend-il en compte des objectifs (coût, énergie) et comment sont-ils paramétrés?

4) Optimisation GPU: promesses vs métriques

• Quelles optimisations sont disponibles: bin packing, GPU fractioning, intégration MIG, etc.?
• Quels indicateurs sont fournis pour prouver le gain (utilisation, queue time, coût/run)?
• Peut-on simuler des politiques de scheduling avant de les appliquer en prod?

5) Sécurité, isolation, conformité

• Comment sont gérés secrets, identités, accès aux données, séparation des environnements?
• Quelles capacités d’audit: logs immuables, traçabilité des actions, export SIEM?
• Où résident les métadonnées et journaux: on-prem, cloud, options?

6) Support, SLA, et exploitation

• Qui supporte quoi: Nutanix, ex-équipe Ryax, partenaire?
• Quels SLA sur incidents bloquants, et quelles fenêtres de maintenance?
• Quel effort jour 2: upgrades, compatibilités Kubernetes, gestion des dépendances?

7) Risque de dépendance fournisseur et réversibilité

• Quel est ton plan de sortie si la roadmap change ou si les coûts explosent?
• Quelle réversibilité contractuelle: export, assistance à migration, conservation des données?
• Quelles parties de ta stack restent standards (Kubernetes vanilla, formats ouverts) et lesquelles deviennent propriétaires?

Ce que tu peux faire dès maintenant (même si l’intégration n’est pas encore livrée)

Si tu es DSI, platform engineer, data engineer, ML engineer à Lyon ou en AURA, tu peux agir tout de suite:

• Cartographie tes workloads IA: lesquels sont GPU-bound, lesquels sont CPU-bound, lesquels peuvent être mutualisés.
• Mesure ton gaspillage: temps d’attente, GPU idle, coûts cloud, reprises ratées.
• Formalise tes contraintes hybrides: données, réseau, latence, conformité, disponibilité.
• Prépare un pilote orienté métriques, pas orienté “démo”.
• Verrouille le sujet contractuel avant l’archi cible, surtout sur réversibilité et support. Point d’appui utile: https://lyon-ia.com/blog/apres-la-conference-a-lyon-7-actions-j30-pour-securiser-cloud-genai-et-contrats.

Le rachat de Ryax Lyon par Nutanix peut déboucher sur une brique solide d’orchestration IA et d’optimisation GPU pour du MLOps hybride. Mais la seule manière sérieuse de le prendre, c’est: roadmap vérifiée, pilote mesuré, et plan de sortie écrit. Sinon tu construis une plateforme IA entreprise sur une promesse, et tu payes la facture plus tard.