Nous sommes heureux de vous retrouver sur ce deuxième article dédié à la journée que nous avons passée lors des Cloud Native Days. Enchainons tout de suite sur 3 autres conférences qui nous ont marquées
REX Sellsy : Migrer 50 000 bases de données sans coupure vers PostgreSQL et Kubernetes - Mission (im)possible ?
Quentin Loupot et Alexandre Buisine (Sellsy/Enix) ont présenté l'un des REX les plus ambitieux de la journée : la migration de 50 000 bases de données d'un cluster MariaDB monolithique vers une architecture distribuée PostgreSQL orchestrée par Kubernetes. Le tout, évidemment, sans coupure de service.
Le point de départ : un monolithe MariaDB à bout de souffle
L'architecture de base de données du service SaaS Sellsy reposait sur un cluster MariaDB centralisé et vieillissant, où l'ensemble des données clients cohabitait dans une seule base de données monolithique. Cette approche, fonctionnelle à l'origine, montrait ses limites face à la croissance :
- Scalabilité bloquée : impossible d'ajouter de la capacité sans tout reconstruire
- Maintenance cauchemardesque : chaque mise à jour était un événement à risque
- Dépendance à une infrastructure rigide : des VM bare metal difficiles à faire évoluer
- Risques accrus : un incident pouvait impacter tous les clients simultanément
Face à ces défis, l'équipe a décidé d'opérer une transformation radicale : passer à un modèle distribué basé sur PostgreSQL et orchestré via CNPG (CloudNativePG) et Kubernetes. L'objectif ? Fragmenter cet énorme monolithe en 50 000 bases de données réparties sur 50 clusters PostgreSQL, chacun autonome et résilient.
L'architecture cible : Kubernetes, PostgreSQL et CNPG
L'équipe a opté pour une stack ambitieuse, hébergée chez Scaleway :
- 3 Availability Zones en bare metal : pour optimiser densité et économie
- Proxmox comme hyperviseur
- Talos Linux : distribution Kubernetes immutable et sécurisée
- CloudNativePG (CNPG) : l'opérateur Kubernetes pour PostgreSQL
- NVMe local avec ZFS : pour les performances, avec chiffrement au niveau filesystem (pour que même le cloud provider ne voit jamais les données en clair)
Dimensionnement CNPG : 50 clusters pour 50 000 bases
L'architecture repose sur CloudNativePG, un opérateur opensource de la CNCF, qui commence à avoir une belle maturité et offre une expérience proche d'une base de données managée. La configuration retenue :
- 50 clusters CNPG (1 primary + 2 replicas par cluster)
- 1 000 clients par cluster
- 1 000 connexions maximum par cluster
- 1000 base de données par cluster
Cette répartition permet d'isoler les tenants tout en mutualisant l'infrastructure sous-jacente.
Le choix du bare metal plutôt que du compute classique était avant tout budgétaire : pour une infrastructure de cette envergure, la densité et l'économie offertes par les serveurs dédiés faisaient la différence.
Le planning : 12 mois de marathon technique
Le projet s'est déroulé en trois phases distinctes sur une année complète :
Phase 1 (6 mois) : Préparer l'infrastructure
- Mise en place de l'infrastructure Kubernetes et CNPG
- Création d'une base de données centrale pour la gestion des utilisateurs
- Tests de charge et validation de l'architecture
Phase 2 (6 mois) : Compatibilité des requêtes
- Refactorisation de toutes les requêtes SQL pour passer de MariaDB à PostgreSQL
- Identification des incompatibilités syntaxiques et fonctionnelles
- Mise en place des tests de régression
Phase 3 (3 mois, en parallèle de la compatibilité des requêtes) : Migration
- Migration progressive des 50 000 bases de données
- Monitoring intensif et ajustements en continu
- Possibilité de rollback à tout moment si il y a un soucis
Les problèmes rencontrés : plongée au cœur de PostgreSQL/CNPG
Pour identifier et corriger les problèmes de performance, l'équipe a créé un dashboard dédié permettant de monitorer finement le comportement des 50 clusters PostgreSQL. C'est grâce à cet outil qu'ils ont pu détecter et résoudre plusieurs problèmes critiques.
Problème n°1 : Les sondes de supervision qui tuent les performances
Le premier gros loup : des temps de réponse des sondes de supervision atteignant 6 secondes. L'équipe constate également une consommation CPU anormalement élevée à vide et un empoisonnement du cache générant 3 000 IOPS.
Le coupable ? La fonction pg_database_size() qui effectue un stat() sur l'intégralité de /var/lib/postgresql. Cette fonction était appelée deux fois :
- Par l'opérateur CNPG
- Par la supervision en haute disponibilité
Le fix d'urgence : désactiver temporairement pg_database_size() et "faker" la taille des bases de données, le temps de trouver une solution pérenne.
Le fix plus long terme : Contribuer au projet CNPG pour le faire évoluer et vérifier la taille des bases de données en consommant moins de CPU.
Problème n°2 : L'empoisonnement du cache ZFS ARC
Second souci : le cache ZFS ARC (Adaptive Replacement Cache) n'était pas correctement configuré, limitant les performances de lecture.
Pour comprendre : ZFS ARC est un cache filesystem qui n'est pas dans le pod. Il n'utilise donc pas le budget mémoire alloué au pod PostgreSQL. Ce cache fonctionne au niveau des nœuds Kubernetes et par défaut, il consomme 50% de la RAM du nœud.
Le problème ? Cette configuration par défaut ne laissait pas assez de place au système. Il fallait utiliser le paramètre arc_sys_free (ou équivalent) pour réserver suffisamment de mémoire au système d'exploitation et aux autres composants.
Une fois correctement configuré, ZFS ARC a révélé tout son potentiel :
- Débit de lecture multiplié par 3 ou 4 grâce au cache en RAM
- Cache mutualisé entre toutes les bases de données du nœud : chaque pod PostgreSQL bénéficie du cache des autres
- Compression efficace : la taille effective des bases en mémoire est divisée par 3 à 4
Management et gestion de projet : les vraies leçons
Au-delà des aspects techniques, les speakers ont insisté sur plusieurs points cruciaux qui ont fait la différence :
Embarquer la direction dès le début Le projet a été présenté et vendu comme un projet d'entreprise, porteur de croissance et de valeur ajoutée. Cette adhésion de la direction a été déterminante pour obtenir les ressources nécessaires et tenir le cap sur 12 mois.
Vigilance sur le bien-être des équipes Un conseil martelé avec insistance : être vigilant par rapport au burn-out. Un projet de cette ampleur génère une pression énorme. Il est essentiel de faire en sorte que la migration soit reproductible et qu’on puisse rollback à tout moment pour réduire le stress des équipes.
L'impact budgétaire : un investissement qui paie rapidement L'équipe a partagé les chiffres concrets de l'impact budgétaire. Dès l'année 2, l'infrastructure permet de rentabiliser l'investissement. On peut ensuite migrer progressivement d'autres workloads et faire du FinOps pour optimiser encore davantage les coûts. Le bare metal fait ici toute la différence face au pricing des solutions managées.
Les bénéfices : des gains de performance mesurés
Finalement, quels sont les résultats concrets obtenus ?
- Scaling horizontal : ajout de capacité sans friction
- Incidents plus courts et maîtrisés : meilleure observabilité et isolation des problèmes (un incident n'impacte qu'un cluster, soit 1 000 clients maximum au lieu de 50 000)
- Meilleurs backups : grâce aux mécanismes natifs de CNPG
- Montée de version PostgreSQL en 5 minutes : sur les 50 clusters en parallèle
- Haute disponibilité : 3 réplicas par cluster (1 primary + 2 replicas)
- Gains de performance mesurés : grâce à l'isolation et à l'optimisation du cache ZFS
Conclusion : CNPG, une vraie alternative aux bases managées
Ce REX, fruit de la collaboration entre Sellsy et Enix, démontre que CloudNativePG a atteint une maturité suffisante pour gérer des workloads de production critiques à très grande échelle. L'expérience utilisateur se rapproche fortement de celle d'une base de données managée sur les grands cloud providers, mais avec la maîtrise totale de la stack et des économies substantielles grâce au bare metal.
Le message est clair : migrer des dizaines de milliers de bases de données d'un monolithe MariaDB vers une architecture distribuée PostgreSQL/Kubernetes, c'est possible. À condition d'avoir une vision long terme, d'embarquer toute l'entreprise, de créer les bons outils de monitoring, et surtout, de prendre soin de ses équipes tout au long du voyage.
REX Ubisoft : Quand et comment partager un cluster
Lors du Cloud Native Days France,Vincent Behar et Corentin Closs d’Ubisoft ont présenté un retour d’expérience sur la manière dont l’éditeur de jeux vidéo a structuré et industrialisé l’usage de Kubernetes à l’échelle mondiale.
Un Kubernetes omniprésent, mais difficile à opérer
Ubisoft opère aujourd’hui une infrastructure massive, répartie sur une trentaine de régions et plusieurs centaines de clusters, aussi bien sur AWS et Azure que sur un cloud interne basé sur OpenStack. Trois grandes entités interviennent sur ces environnements : les équipes Online Services, le Technical Group et l’IT.
Si la création de clusters Kubernetes s’est largement démocratisée, leur exploitation reste en revanche l’affaire de quelques experts. Ce déséquilibre a rapidement montré ses limites : multiplication des clusters, hétérogénéité des pratiques, et forte dépendance à un nombre réduit d’administrateurs.
Pour répondre à ces enjeux, Ubisoft a lancé UKS, pour Ubisoft Kubernetes as a Service. L’ambition était claire : proposer une offre Kubernetes interne, multi-cloud et multi-tenant, capable de servir l’ensemble des équipes sans leur imposer la complexité opérationnelle sous-jacente.
Rationaliser une plateforme devenue trop complexe
Un retour en arrière permet de mesurer le chemin parcouru : en 2019, l’infrastructure reposait sur Rancher et OpenStack, avec seulement quelques clusters, des centaines de projets et de namespaces, et déjà des milliers de pods, le tout administré par une seule personne. Ce modèle a rapidement atteint ses limites, notamment lors des montées de version Kubernetes, de la gestion réseau ou encore de l’évolution des CRDs.
Au fil du temps, l’empilement des outils et des cas d’usage a rendu la plateforme difficile à maintenir. Ubisoft a alors fait le choix d’utiliser Fleet, destiné à devenir le point d’entrée principal pour les utilisateurs. Cette simplification a permis de reprendre le contrôle, mais Fleet ne fonctionnait que pour des clusters dédiés.
Les limites du cluster partagé global
Le cluster partagé unique s’est révélé être un frein à l’évolutivité. Les besoins des équipes divergent fortement, notamment autour des opérateurs Kubernetes, des extensions ou des CRDs. Dans un cluster global, satisfaire tout le monde devient impossible.
L’idée d’un cluster partagé par département a alors émergé, afin de conserver une mutualisation raisonnable tout en offrant davantage de liberté aux équipes. Mais cela posait une nouvelle question centrale : comment gérer efficacement le multi-tenancy sans exploser la complexité opérationnelle ?
Choisir la bonne approche de multi-tenancy
Plusieurs solutions ont été étudiées. Des outils comme KCP ou vCluster proposent une virtualisation poussée de la couche API Kubernetes, offrant une isolation très forte, mais au prix d’une complexité élevée et d’un coût opérationnel important.
Ubisoft a finalement opté pour Capsule, un opérateur Kubernetes dédié au multi-tenancy. Dans leur contexte, l’absence d’isolation des CRDs n’était pas bloquante. En revanche, Capsule offrait une API stable, une intégration simple et une communauté active, des critères essentiels pour une plateforme interne destinée à durer.
Capsule Proxy, la pièce maîtresse de l’expérience utilisateur
L’élément déterminant du choix de Capsule est sans doute Capsule Proxy. Ce composant agit comme un reverse proxy placé devant l’API Server Kubernetes et donne à chaque utilisateur l’impression de disposer de son propre cluster.
Les requêtes sont interceptées, filtrées et restituées de manière isolée, offrant une expérience très proche de celle d’un administrateur de cluster, sans jamais accorder de privilèges globaux. Cette approche permet de concilier sécurité, isolation logique et confort d’utilisation.
En complément, la plateforme permet le déploiement d’outils standards comme Argo CD ou OpenCost, afin de proposer une expérience cohérente et complète aux équipes.
Une Internal Developer Platform comme socle
Capsule s’intègre dans une Internal Developer Platform développée en interne. Cette plateforme centralise la configuration des tenants, la gestion des droits et la définition des propriétaires de clusters.
Un besoin spécifique est rapidement apparu : disposer d’un niveau de gouvernance supérieur au namespace. Pour y répondre, Ubisoft a développé un opérateur Workspace, qui permet aux équipes de gérer leurs namespaces à l’intérieur d’un périmètre logique clairement défini. Ce modèle améliore à la fois la lisibilité, la gouvernance et l’autonomie des utilisateurs.
Et maintenant ?
Le développement de la solution est aujourd’hui terminé. Les principaux défis à venir concernent la migration des environnements existants, qu’il s’agisse des clusters Kubernetes ou des CRDs déjà en place. L’intégration complète de cette solution dans l’API de la plateforme interne, ainsi que son exposition via une interface graphique, constituent également des étapes clés pour faciliter l’adoption à grande échelle.
Conclusion
Ce retour d’expérience d’Ubisoft met en lumière une réalité souvent sous-estimée : à grande échelle, la réussite d’une plateforme Kubernetes repose autant sur les choix d’architecture que sur le pragmatisme et la compréhension fine des besoins des équipes.
Plutôt que de choisir la solution la plus sophistiquée, Ubisoft a privilégié une approche équilibrée, combinant Capsule, Capsule Proxy et une Internal Developer Platform sur mesure. Le résultat est une plateforme multi-cloud, multi-tenant et scalable, capable de servir des centaines d’équipes tout en restant opérable par une équipe réduite.
Voici une reformulation structurée et fluide de tes notes sous forme d’article, avec un ton “retour d’expérience” clair et pédagogique, adapté à un contexte conférence / tech publique.
REX INSEE – De l’expérimentation à la mise en production de modèles d’IA : le MLOps dans une administration
À l’INSEE, l’intelligence artificielle n’est pas un sujet théorique. Elle répond à un besoin très concret : automatiser l’association de codes et de nomenclatures aux activités des entreprises françaises. Derrière cet enjeu technique se cache un pilier essentiel de la statistique publique et du fonctionnement économique du pays. Durant cette conférence, Hugo Simon et Nathan Randriamanana nous ont présenté le chantier MLOps auxquel ils ont participé pour industrialiser l'entrainement et la mise à disposition de modèles de machine Learning au sein de l'INSEE.
Un besoin fondamental : caractériser l’activité des entreprises
L’INSEE gère plusieurs nomenclatures de référence : COICOP, NA2008, PCS2020 ou encore la NAF (Nomenclature d’Activités Françaises). Cette dernière est sans doute la plus connue, car elle est directement liée au code APE (Activité Principale Exercée) attribué à chaque entreprise.
Concrètement, ce code permet de répondre à des questions simples mais structurantes pour l’action publique :
- Combien y a-t-il de boulangeries, de salons de coiffure ou de cabinets de conseil informatique en France ?
- Quelles conventions collectives ou quels droits s’appliquent à une entreprise ?
- Quelles aides ou politiques publiques peuvent être ciblées sur un secteur donné ?
- Comment représenter fidèlement le tissu économique français ?
Sans code APE, il n’y aurait tout simplement pas de statistiques sectorielles fiables.
D’un travail d’experts à l’automatisation
Historiquement, l’attribution des codes NAF était réalisée manuellement par des experts de l’INSEE. Un travail précis, mais complexe : les entreprises décrivent leur activité avec une infinité d’intitulés, de formulations et de labels différents. Identifier l’activité principale – souvent celle générant le plus de chiffre d’affaires – devient rapidement un casse-tête à grande échelle.
L’idée d’automatiser cette classification n’est pas nouvelle. Dès 1981, des premiers systèmes de codification automatique voient le jour. Mais c’est surtout à partir de 2019, avec la loi PACTE, puis en 2020 avec la mise en œuvre du guichet unique des entreprises porté par l’INPI, que le sujet prend une nouvelle ampleur. Fin 2022 marque un tournant : le déploiement du premier modèle de machine learning en production.
Les limites du modèle « classique »
Très vite, les équipes se heurtent à un problème récurrent. Une nouvelle tendance ou un nouveau métier apparaît. Le modèle ne sait pas le reconnaître. Les équipes sont perdues, le script d’entraînement aussi. S’ensuit alors un long travail manuel : pendant plusieurs mois, il faut imaginer toutes les formulations possibles de cette nouvelle activité, forcer certains exemples dans l’entraînement, réentraîner le modèle, puis redéployer une nouvelle version.
Ce cycle est coûteux, lent et peu scalable.
Un enjeu organisationnel avant d’être technique
Le problème n’est pas seulement algorithmique. Il est aussi profondément organisationnel. À l’INSEE, comme dans beaucoup d’administrations (et d’entreprises), les équipes sont organisées en silos : data scientists, développeurs applicatifs, équipes de production.
Premier chantier : casser le mur entre les développeurs et les Ops. Puis un second mur apparaît : celui entre développeurs et data scientists. Les uns développent des modèles en Python, les autres des applications en Java. Ils n’ont pas la même culture, pas les mêmes outils, pas le même langage.
La réponse : construire une véritable plateforme MLOps, pensée et développée conjointement par des développeurs et des data scientists. Mais cela implique d’accepter une réalité : un data scientist n’est pas un développeur, et inversement.
Étape 1 : parler la même langue
La première brique consiste à créer un socle commun. Cela passe par :
- la mise en place d’outils techniques standards,
- le développement de profils hybrides capables de faire le lien,
- la formation croisée des agents (IT pour les statisticiens, statistiques pour les informaticiens),
- des mobilités plus fréquentes entre métiers et DSI,
- et une politique de recrutement ouverte à des profils externes.
Sur le plan technique, l’objectif est la reproductibilité et la portabilité. La conteneurisation permet notamment de faire coexister Java et Python dans un même environnement, sans friction.
Étape 2 : fluidifier l’expérience et industrialiser
Le deuxième axe porte sur l’outillage et l’expérience utilisateur. Des outils comme Argo Workflows sont utilisés pour automatiser les pipelines de bout en bout. La sécurité n’est pas oubliée : MODELSCAN, équivalent du Trivy pour les modèles ML, permet de détecter d’éventuelles injections de code malveillant dans les artefacts de modèles.
Une approche plateforme assumée
Un constat s’impose : les API d’inférence de modèles se ressemblent énormément. L’INSEE adopte donc une logique plateforme :
- un chart Helm unique pour uniformiser les déploiements,
- une automatisation de l’intégration des modèles dans des API,
- une équipe dédiée à l’outillage MLOps.
Un premier cas d’usage pilote illustre cette approche : une plateforme de qualification des performances des modèles de machine learning. Elle permet aux data scientists de tester facilement la latence, le débit (requêtes par seconde), de vérifier le respect des SLA et d’identifier les modèles compatibles avec l’infrastructure existante (par exemple l’optimisation pour CPU Intel).
Et après ? Le défi de la boucle complète
Un point clé reste encore à renforcer : la supervision des modèles en production. Contrairement à l’observabilité classique, il ne s’agit pas seulement de surveiller des métriques techniques, mais aussi la qualité des prédictions elles-mêmes. Sans cela, le risque de dérive de modèle (model drift) est bien réel.
La boucle MLOps n’est réellement complète que lorsque l’on observe, mesure et ajuste en continu les performances et les résultats des modèles. Un défi majeur… mais incontournable pour une IA publique robuste, fiable et durable.
Conclusion
Ce deuxième article vient clore notre résumé des conférences qui nous ont le plus marqués au cours de cette journée. Et le moins que l’on puisse dire, c’est que ces Cloud Native Days France 2026 ont été une véritable réussite : des interventions de grande qualité, un niveau technique particulièrement appréciable à une époque où certaines conférences privilégient davantage les enjeux business, ainsi qu’une organisation globale irréprochable.
Pour autant, le sujet ne s’arrête pas ici : de nombreuses présentations nous ont donné envie d’explorer certains thèmes plus en profondeur, et nos collègues y reviendront dans de prochains articles.
