Retour d’expérience : passer d’un déploiement ponctuel à une plateforme IA reproductible, sécurisée et exploitable à grande échelle
Déployer une plateforme d’IA sur Kubernetes peut sembler relativement simple sur le papier : un cluster, des GPU, les modèles Mistral AI, quelques composants réseau et une API pour exposer les services.
Mais dans la réalité, faire fonctionner une plateforme une première fois n’est que le début.
Lorsqu’il faut la rendre reproductible, sécurisée, observable, exploitable et capable d’évoluer avec les besoins des utilisateurs, la complexité change d’échelle.
C’est précisément le constat réalisé lors du premier déploiement d’une plateforme Mistral AI Studio pour un client du secteur public. Ce retour d’expérience a permis d’identifier les limites d’un déploiement réalisé de manière largement manuelle, puis de faire évoluer le modèle vers une approche industrialisée reposant sur OUTSCALE Kubernetes Service (OKS).
L’objectif : ne plus simplement réussir un déploiement, mais être capable de redéployer la même plateforme, à l’identique, pour plusieurs clients et différents cas d’usage.
Une plateforme IA ne se résume pas à un cluster Kubernetes
Une plateforme Mistral AI Studio ne consiste pas uniquement à faire tourner un modèle sur un GPU. Elle doit exposer des API, rendre les modèles disponibles et utilisables, et supporter différents usages applicatifs.
Autour du cluster Kubernetes viennent rapidement s’ajouter des briques essentielles : gestion des GPU, accès, certificats, secrets, stockage, logs, supervision, observabilité, configuration et mécanismes de validation.
Kubernetes fournit le socle. Mais le socle ne fait pas encore la plateforme.
Livrer malgré la contrainte avec Talos/RKE2
Lors du premier projet, une contrainte technique s’est présentée : les GPU H200 n’étaient alors pas disponibles sur OKS.
Attendre n’était pas une option. Le besoin client existait déjà.
Le choix a donc été de mettre en place une réponse tactique : déployer un cluster Kubernetes RKE2 basé sur Talos, maîtrisé directement par l’équipe. Les drivers nécessaires ont ensuite été installés pour exploiter les GPU H200, puis la plateforme Mistral AI Studio a été déployée afin de réaliser les premiers tests d’inférence et d’exposer les API.
Cette approche a permis d’obtenir une première plateforme opérationnelle de bout en bout.
Elle a surtout permis d’apprendre.
Car cette première réussite a mis en évidence une difficulté majeure : un déploiement qui fonctionne n’est pas nécessairement un déploiement industrialisable.
Le premier run : un révélateur
Le premier déploiement reposait sur une succession d’étapes encore largement manuelles : construction du cluster, configuration des composants Kubernetes, installation des runtimes NVIDIA, intégration de l’observabilité, exposition des services, puis validation de la plateforme.
Cette approche peut répondre à un premier projet ou à un POC. Elle devient beaucoup plus difficile à maintenir lorsqu’il faut faire évoluer régulièrement la plateforme, ajouter des GPU, déployer de nouveaux modèles ou reproduire le même environnement pour d’autres clients.
À cette complexité s’ajoutent des sujets qui ne peuvent pas être traités comme de simples détails techniques : stockage objet, logs, secrets, supervision des nœuds et des GPU, observabilité, intégration CI/CD et validation du bon fonctionnement de la plateforme.
Le premier run a donc joué un rôle essentiel : il a révélé que la complexité n’était pas dans une seule brique, mais dans l’assemblage de toutes les briques.
C’est aussi à ce moment qu’un enseignement important s’est imposé : dans Kubernetes, voir un pod en état Running est rassurant, mais cela ne suffit pas à démontrer que la plateforme IA fonctionne correctement. Le modèle peut ne pas être chargé, les GPU peuvent ne pas être utilisés, les API peuvent répondre partiellement ou les logs peuvent être insuffisants pour diagnostiquer un incident.
Un pod Running signifie que le conteneur tourne. Pas que la plateforme est prête à l’usage.
Il fallait donc sortir d’une validation “à l’œil” et construire un processus reproductible permettant de démontrer que la plateforme est réellement prête à être exploitée.
Industrialiser toute la chaîne
Le premier déploiement a mis en évidence une forte quantité de configurations manuelles, de dépendances entre composants et de validations réalisées étape par étape. À chaque nouvelle livraison, les mêmes questions risquaient de revenir : quelles configurations utiliser ? Quels paramètres modifier ? Quels secrets gérer ? Quels tests réaliser ? Comment vérifier que l’ensemble fonctionne ?
Cette situation crée progressivement une dette opérationnelle.
Chaque étape non formalisée devient une dette opérationnelle.
L’industrialisation devait donc aller bien au-delà du simple déploiement de Mistral AI. Elle devait couvrir toute la chaîne :
infrastructure → Kubernetes → GPU → plateforme Mistral → sécurité → observabilité → validation → documentation → exploitation.
Entre-temps, les GPU H200 sont devenus disponibles sur OKS. Cette évolution a permis de changer de paradigme : passer d’un cluster Kubernetes construit et maintenu de manière unitaire à un Kubernetes as a Service, sur lequel le socle Kubernetes est managé.
Avec OKS, l’effort se déplace. Il ne s’agit plus de reconstruire et maintenir l’ensemble des composants Kubernetes à chaque projet, mais de se concentrer sur ce qui crée réellement de la valeur : la plateforme IA, les modèles, les usages clients, la sécurité, l’observabilité et l’exploitation.
Talos/RKE2 a permis de livrer malgré la contrainte. OKS permet d’industrialiser après l’apprentissage.
Industrialiser, ce n’est pas simplement automatiser
L’automatisation est un moyen. L’industrialisation est une méthode.
Automatiser une suite de commandes ne suffit pas si l’architecture, les paramètres, les responsabilités et les critères de validation ne sont pas clairement définis.
L’industrialisation commence dès la conception : quels GPU sont nécessaires ? Quelle capacité prévoir ? Quels accès ouvrir ? Quelle exposition réseau autoriser ? Quels paramètres doivent varier selon les clients ? Quels éléments doivent rester standardisés ?
Ces questions permettent de construire un modèle de déploiement paramétrable, plutôt qu’une succession de configurations spécifiques. Le principe devient alors simple :
Ce qui change d’un client à l’autre est paramétré. Le reste est standardisé.
Pour rendre ce modèle reproductible, l’équipe s’est appuyée sur l’Infrastructure as Code, notamment avec Terraform. L’enjeu n’était plus seulement de créer de l’infrastructure, mais de disposer de modules capables de redéployer les différents composants de manière cohérente.
La plateforme Kubernetes est ensuite standardisée à travers les node pools, avec une séparation entre ressources CPU et GPU. Les templates et charts Helm de Mistral permettent enfin de déployer la suite logicielle, avec des valeurs variables selon les paramètres propres à chaque client.
Cette séparation entre variabilité et socle commun est ce qui permet de passer d’un projet réussi à un modèle industriel.
Sécurité, validation et observabilité : les garde-fous du modèle
Industrialiser ne signifie pas aller plus vite au détriment de la sécurité.
Au contraire : plus un déploiement devient rapide et reproductible, plus la sécurité doit être intégrée dès la conception. Modalités d’accès, réseaux autorisés, personnes ou services habilités, responsabilités, certificats, secrets, rotation et utilisation dans le cycle de vie de la plateforme doivent être définis dès l’architecture.
Une plateforme livrée vite mais mal cadrée devient vite une dette sécurité.
La validation suit la même logique. L’objectif n’est plus de vérifier simplement que le cluster est disponible, mais de démontrer que la plateforme IA complète est fonctionnelle : node pools, GPU, services Mistral, API Gateway, tests d’inférence, latence, métriques et logs.
Les tests d’inférence deviennent alors une véritable étape de validation du produit livré.
Enfin, une plateforme prête à être livrée doit être observable. Dashboards, logs et métriques permettent de disposer d’une vision globale de l’environnement, d’identifier l’origine d’un ralentissement ou d’un incident, et de suivre l’utilisation réelle des GPU.
Les logs jouent également un rôle central dans l’exploitation et la sécurité. Centralisés, ils peuvent être intégrés aux outils de supervision et de sécurité du client, notamment à son SIEM, et lui permettre de conserver les traces dans son propre environnement.
Le déploiement se termine donc lorsque le service est consommable, observable et exploitable, pas lorsque les pods sont verts.
De plusieurs semaines à quelques minutes pour ajouter des GPU
L’un des bénéfices les plus concrets du changement de modèle concerne l’évolution de la capacité GPU.
Dans l’approche initiale basée sur RKE2, ajouter des workers GPU impliquait une nouvelle séquence d’installation et pouvait entraîner des délais importants. Avec OKS et une infrastructure davantage modularisée, l’ajout de nouveaux nœuds GPU peut être réalisé beaucoup plus simplement.
L’équipe décrit ainsi un passage de plusieurs semaines à quelques minutes pour ajouter des ressources GPU à une plateforme existante.
Ce gain ne vient pas uniquement de l’automatisation. Il vient surtout de la standardisation du socle : les clusters, les node pools GPU, les templates Helm, les composants de sécurité et les validations sont déjà définis. Ajouter de nouvelles capacités ne revient plus à reconstruire l’infrastructure, mais à assembler des briques déjà maîtrisées.
C’est un point essentiel pour les projets IA : les besoins GPU ne sont jamais figés. Ils évoluent avec les modèles, les usages, les volumes et les performances attendues. Une plateforme IA industrielle doit donc pouvoir évoluer sans remettre en cause toute son architecture.
Livrer une plateforme, c’est aussi livrer son exploitation
Une plateforme opérationnelle ne se résume pas à un endpoint API ou à un accès Kubernetes.
La livraison doit aussi inclure les éléments nécessaires à son exploitation : endpoints API, accès à la plateforme, kubeconfig lorsque cela est pertinent, certificats et secrets, logs et métriques, documentation, procédures de diagnostic, runbooks, escalade et limites connues.
L’objectif est de permettre au client de comprendre la plateforme, de l’exploiter et de diagnostiquer les situations courantes sans dépendre systématiquement de l’équipe qui a réalisé le déploiement initial.
C’est un changement important de perspective :
On ne livre plus simplement une plateforme qui fonctionne. On livre une plateforme que le client peut réellement exploiter.
De “ça marche” à “vous pouvez l’exploiter”
Le passage de RKE2 à OKS a permis de transformer progressivement le modèle de déploiement. D’un côté, le premier projet a fourni un retour d’expérience précieux : dépendances entre composants, configurations manuelles, points de blocage, opérations difficiles à reproduire. De l’autre, OKS a permis de construire un socle standardisé et managé, sur lequel l’infrastructure, les node pools, les templates Helm, les tests et la documentation peuvent être paramétrés et réutilisés.
Le résultat recherché n’est pas de réussir une livraison une fois.
C’est de pouvoir reproduire la même livraison plusieurs fois, avec un niveau de qualité constant.
Ce retour d’expérience montre une évolution essentielle dans les projets d’IA : le déploiement du modèle n’est que le point de départ. Une plateforme IA industrielle doit réunir un socle Kubernetes adapté, des GPU disponibles, une infrastructure reproductible, une sécurité intégrée dès la conception, des tests standardisés, une observabilité complète et une documentation d’exploitation.
Le véritable enjeu n’était donc pas de faire fonctionner Mistral AI une première fois.
Il était de transformer cette première réussite en capacité de livraison industrielle, capable de répondre à une demande qui se répète.
