Quand une infrastructure grandit, le monitoring devient un sujet d’architecture. Il ne s’agit plus seulement de vérifier qu’un service répond, mais de comprendre ce qui se passe, où, et pourquoi.

Dans ce rapport, nous nous intéressons à une question centrale : faut-il tout uniformiser avec une brique unique, ou garder des outils spécialisés tout en centralisant la visualisation dans Grafana ?

I. Pourquoi monitorer une infrastructure ?

Mettre une infrastructure en production ne suffit pas : il faut pouvoir suivre son état dans le temps, qu’il s’agisse de bare metal, de VMs, de Clusters Kubernetes, de ressources cloud ou d’équipements réseau. Le monitoring permet d’observer les signaux essentiels comme la disponibilité, la latence, les erreurs, le trafic ou la saturation.

Cette visibilité permet de détecter les incidents plus rapidement, mais aussi d’anticiper certaines dégradations avant qu’elles ne deviennent critiques. Une partition qui se remplit, une latence qui augmente ou une consommation mémoire anormale sont autant de signaux faibles qu’il faut pouvoir identifier tôt

II. la complexité du monitoring

La difficulté vient du fait qu’une infrastructure moderne produit des données très différentes : métriques système, logs applicatifs, événements, traces ou informations issues du réseau. Le défi n’est donc pas seulement de collecter ces données, mais de les rendre cohérentes et exploitables.

C’est là que se pose la question de l’architecture : faut-il centraliser toute la collecte dans une même chaîne, ou garder des pipelines spécialisés selon le type de donnée ?

III. Comprendre les signaux et la chaîne de monitoring

Avant de parler d’outils, il faut comprendre ce que l’on cherche réellement à observer. Une infrastructure produit en permanence différents types de données : certaines donnent une vision globale de l’état du système, d’autres permettent d’analyser précisément ce qui s’est passé lors d’un incident.

On distingue généralement trois grands signaux : les métriques, les logs et les traces.

Les métriques

Les métriques sont des valeurs chiffrées mesurées dans le temps. Elles permettent de suivre l’évolution d’un système et de détecter rapidement une anomalie.

Exemples :

utilisation CPU ; consommation mémoire ; espace disque ; trafic réseau ; latence ; taux d’erreur ; nombre de requêtes ; disponibilité d’un service.

Les métriques sont particulièrement utiles pour créer des dashboards et des alertes. Elles permettent par exemple d’identifier une saturation progressive ou une hausse anormale des erreurs.

Les logs

Les logs sont les événements produits par un système, une application ou un service. Ils permettent de comprendre ce qui s’est passé à un moment précis.

Exemples :

erreurs applicatives ; logs système ; logs d’accès HTTP ; événements de sécurité ; messages de debug ; événements Kubernetes ; changements d’état d’un service.

Là où une métrique peut montrer qu’un problème existe, un log aide souvent à comprendre pourquoi il s’est produit.

Les traces

Les traces permettent de suivre le parcours d’une requête entre plusieurs services. Elles sont surtout utiles dans les architectures distribuées, où une action utilisateur peut traverser plusieurs composants avant d’obtenir une réponse.

Elles permettent notamment d’identifier :

les services appelés ; le temps passé dans chaque composant ; les dépendances entre applications ; le service responsable d’un ralentissement ; le chemin complet d’une requête.

Les traces sont donc très utiles pour analyser les performances applicatives, mais elles demandent souvent une instrumentation plus poussée que les métriques ou les logs

Ces visuels montrent que les outils d’observabilité ne se placent pas tous au même niveau. Certains, comme OpenTelemetry Collector ou Grafana Alloy , peuvent couvrir plusieurs usages et s’intégrer dans une chaîne plus large. Ils simplifient l’architecture en donnant un cadre commun, mais créent aussi une dépendance plus forte à un même pipeline.

À l’inverse, des briques comme Prometheus, Thanos ou Loki sont plus spécialisées. Elles font moins de choses, mais les font très bien. La vraie question n’est donc pas seulement de choisir un outil, mais de comprendre où chaque brique se positionne dans le parcours de la donnée : collecte, transport, stockage, visualisation ou alerting.

IV. De la collecte à la visualisation : la chaîne du monitoring

Une fois les signaux produits, ils doivent être collectés, acheminés, stockés, analysés puis visualisés. C’est cette circulation de la donnée qui forme la chaîne de monitoring. L’objectif est de transformer un événement brut, généré par une application, une machine ou un équipement réseau, en une information lisible et exploitable par les équipes.

On retrouve généralement plusieurs rôles dans cette chaîne :

Producteurs : applications, serveurs bare metal, machines virtuelles, bases de données, clusters Kubernetes, équipements réseau ou services cloud. Ce sont eux qui génèrent les métriques, les logs ou les traces.

Exporters : composants qui exposent des métriques dans un format exploitable, souvent pour Prometheus. Par exemple : Node Exporter pour les métriques système, Blackbox Exporter pour tester la disponibilité d’un service, ou encore des exporters spécifiques pour les bases de données, le réseau ou certaines applications.

Collecteurs / agents : composants qui récupèrent, filtrent, enrichissent ou redirigent les données vers les bons backends. On peut citer Fluent Bit pour les logs, OpenTelemetry Collector pour une approche multi-signaux, ou Grafana Alloy pour une collecte plus unifiée dans l’écosystème Grafana.

Backends : systèmes chargés de stocker et de requêter les données. Selon le type de signal, on peut retrouver Prometheus, Thanos ou VictoriaMetrics pour les métriques, Loki ou OpenSearch pour les logs, et Tempo, Jaeger ou Zipkin pour les traces.

Visualisateurs : outils qui rendent les données exploitables à travers des dashboards, des vues d’exploration ou des recherches. Grafana est souvent utilisé pour centraliser cette visualisation, car il peut interroger plusieurs datasources depuis une même interface.

Alerting : mécanismes qui déclenchent une notification lorsqu’un comportement anormal est détecté. Cela peut passer par Grafana Alerting, Prometheus Alertmanager, ou des intégrations vers Slack, Teams, PagerDuty ou Opsgenie.

Cette séparation est importante, car elle montre qu’une stack de monitoring ne repose pas forcément sur un seul outil. Une même architecture peut combiner plusieurs pipelines spécialisés : un pour les métriques, un pour les logs, un pour les traces, tout en centralisant l’exploitation dans une interface commune comme Grafana.

V. Étude de l’existant chez Steamulo

Chez Steamulo, l’infrastructure repose sur un écosystème assez hétérogène. On retrouve des serveurs bare metal hébergeant des environnements Proxmox, sur lesquels peuvent tourner des machines virtuelles applicatives ou des clusters Kubernetes. À côté de cette infrastructure locale, certaines applications ou certains services peuvent aussi être déployés chez des cloud providers comme OVH, Scaleway, AWS ou d’autres plateformes externes.

Cette diversité rend l’environnement puissant et flexible, mais elle complexifie aussi sa supervision. Les sources à monitorer ne sont pas toutes au même endroit, ne produisent pas les mêmes types de données et ne se supervisent pas toujours avec les mêmes outils. Une VM, un cluster Kubernetes, un service cloud, une base de données ou un équipement réseau n’exposent pas les mêmes métriques ni les mêmes logs.

Le problème n’est donc pas seulement de mettre en place du monitoring, mais de réussir à construire une vision cohérente de l’ensemble. Sans centralisation claire, les informations peuvent vite se retrouver dispersées entre plusieurs dashboards, plusieurs sources de logs ou plusieurs outils de supervision. Cela rend le diagnostic plus long, surtout lorsqu’un incident peut venir aussi bien d’une application, d’un cluster Kubernetes, d’une VM, d’un nœud Proxmox ou d’une dépendance cloud.

VI. Notre approche : une visualisation centralisée avec des briques spécialisées

Notre approche a été de centraliser au maximum la visualisation des données dans Grafana. L’objectif n’est pas forcément de faire passer toutes les métriques et tous les logs par un seul collecteur, mais de permettre aux équipes de retrouver les informations importantes depuis une interface commune. Pour cela, plusieurs datasources sont connectées à Grafana, avec une organisation par dossiers et par services. Cette structure permet de rendre les dashboards plus lisibles, mais aussi de mieux gérer les accès grâce aux teams et aux permissions Grafana. Grafana permet justement d’utiliser les équipes pour mutualiser les droits d’accès aux dashboards et aux datasources, ainsi que des permissions par dossiers pour structurer l’accès aux contenus.

Pour le reste de l’architecture, nous avons choisi de conserver des composants spécialisés selon le type de donnée. Les métriques sont gérées avec une approche Prometheus / Thanos, afin de garder un socle robuste pour la collecte, les requêtes et la rétention. Plusieurs exporters sont utilisés selon les besoins : des exporters orientés Kubernetes, Node Exporter pour l’état des machines, ainsi que d’autres exporters spécifiques selon les services à superviser .

Pour les logs, la logique est similaire : Loki reste le backend principal, car il s’intègre bien avec Grafana et répond au besoin de centralisation des journaux. La partie collecte a cependant évolué. Historiquement, Promtail était utilisé pour récupérer les logs et les envoyer vers Loki. Mais Promtail est désormais annoncé en fin de vie, avec les futurs développements orientés vers Grafana Alloy.

Dans notre cas, le choix a été de migrer vers Fluent Bit plutôt que vers Alloy. Ce choix correspond à notre philosophie d’architecture : garder des outils spécialisés, performants et maîtrisables pour chaque besoin, plutôt que de tout regrouper dans une seule brique multi-usage. Alloy reste intéressant pour une approche unifiée, puisqu’il permet de collecter plusieurs types de signaux, mais cette approche peut aussi créer une dépendance plus forte à un pipeline unique et une moins bonne performance.

Notre choix se résume donc ainsi : centraliser l’exploitation dans Grafana, mais conserver des pipelines spécialisés pour les métriques et les logs. Grafana sert de point d’entrée commun, tandis que Prometheus / Thanos, Loki et Fluent Bit gardent chacun un rôle clair dans la chaîne de monitoring.

Les traces ne sont pas encore intégrées aujourd’hui, mais elles représentent une évolution logique pour aller plus loin dans l’observabilité, notamment sur le suivi des requêtes entre services et l’analyse des lenteurs applicatives.

VII. Évolutions permanentes et derniers travaux

Le monitoring n’est pas une brique figée : il évolue avec l’infrastructure, les besoins des équipes et les changements dans l’écosystème des outils. Ces derniers mois, plusieurs travaux ont été menés pour rendre la stack plus robuste, plus lisible et plus simple à maintenir :

**Migration de Loki vers **une architecture distribuée : passage d’un simple deployment à un mode distribué afin de mieux séparer l’ingestion, le stockage et les requêtes de logs.

**Migration de Promtail vers **Fluent Bit : remplacement de Promtail par un agent de collecte plus léger et spécialisé, dans la continuité de l’arrêt progressif de Promtail.

Fusion de deux instances Grafana en une seule : centralisation de la visualisation pour réduire la fragmentation des dashboards et simplifier l’accès aux données.

Déploiement d’un** Varnish Exporter** : mise en place d’un exporter dédié pour extraire les métriques Varnish, notamment autour du cache, du trafic, des erreurs HTTP et de l’état des backends.

Création de nouveaux dashboards : ajout de dashboards dédiés à Trivy et Varnish afin d’améliorer la visibilité sur la sécurité et les métriques Varnish.

Mise à jour des composants de la stack : montée de version de Grafana, Loki, Prometheus et Thanos pour bénéficier des corrections, améliorations de performance et nouvelles fonctionnalités.

POC autour de Proxmox Datacenter Manager : expérimentation en cours pour évaluer son intérêt dans la supervision et l’administration centralisée de l’environnement Proxmox.

VIII. Le Futur

Les prochaines évolutions s’inscrivent dans la continuité du travail déjà réalisé. L’objectif est d’étendre progressivement la couverture du monitoring, tout en gardant une architecture lisible, maintenable et adaptée aux besoins réels de l’infrastructure.

Mise en place de nouveaux exporters spécialisés : ajout progressif d’exporters pour des composants encore peu ou pas supervisés, notamment le réseau, certaines bases de données ou des services internes spécifiques.

Intégration progressive des traces : ajout d’un pipeline de tracing afin de suivre le parcours des requêtes entre plusieurs services et d’analyser plus finement les problèmes de performance applicative.

Amélioration continue de l’existant : enrichissement des dashboards, ajustement des alertes, mise à jour des composants et amélioration des conventions de labels pour garder une stack exploitable dans le temps.

IX. Les points importants à garder en tête

Centraliser le monitoring ne veut pas forcément dire tout faire passer par un seul outil. L’approche retenue consiste surtout à centraliser la visualisation dans Grafana.

Les pipelines spécialisés restent pertinents. Prometheus / Thanos pour les métriques, Loki pour les logs et Fluent Bit pour la collecte permettent de garder des briques adaptées à leur usage.

Les outils unifiés comme Alloy ou OpenTelemetry Collector sont intéressants, mais ils ne doivent pas être choisis uniquement parce qu’ils savent tout faire. Le choix dépend du besoin, de la maintenabilité et du niveau de maîtrise attendu.

La qualité du monitoring dépend aussi de son organisation. Des dashboards clairs, des datasources bien rangées, des labels cohérents et des alertes pertinentes sont aussi importants que les outils utilisés.

X. Conclusion

Centraliser le monitoring, ce n’est pas forcément tout faire passer dans une seule brique : c’est surtout construire une vision exploitable de l’infrastructure dans le temps. Dans un environnement hétérogène, entre bare metal, Proxmox, VMs, Kubernetes, cloud providers,** applications** et services transverses, le vrai sujet n’est pas seulement de collecter plus de données, mais de rendre ces données lisibles, corrélables et utiles au quotidien.

L’objectif est de garder une architecture maîtrisable, capable d’évoluer sans tout reconstruire à chaque nouveau besoin, tout en conservant des briques optimisées pour leur usage.

Monitoring centralisé : visualisation unifiée, collecte spécialisée was originally published in STEAMULO Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Stack de monitoring HA pour Kubernetes : de Prometheus à Thanos

Sous le capot du cloud #4

Dans les premiers volets de Sous le capot du cloud, nous avons posé les fondations de notre cloud interne :

Kubernetes comme socle d’hébergement. Une architecture de cluster HA pour tenir nos objectifs de disponibilité. Un hyperviseur Proxmox pour industrialiser la couche infra.

Une fois cette base en place, une autre question est vite devenue centrale :

Comment voir ce qui se passe réellement dans nos clusters, sur la durée, sans exploser les ressources ni perdre l’équipe dans la complexité ?

Comme beaucoup, nous avons commencé “simple” : un Prometheus et un Loki dans le cluster, quelques dashboards Grafana, et l’impression rassurante d’avoir “de l’observabilité”. La réalité nous a vite rattrapés : 20 GiB de RAM pour Prometheus, 20 GiB pour Loki, une rétention de 30 jours à peine tenable, aucun point central pour plusieurs clusters, et un monitoring qui devenait lui-même un risque.

Dans cet article, on raconte comment nous sommes passés :

d’un Prometheus “monolithique” dans un seul cluster, à une stack de monitoring HA basée sur Prometheus, Loki, Grafana… et surtout Thanos comme point central multi-clusters, avec stockage long terme sur S3.

I. Pourquoi l’observabilité mérite un article à part

Tant que l’on déploie quelques workloads sur un cluster unique, un Prometheus “par défaut” et deux dashboards paraissent suffisants. Mais dans notre cas, le contexte a changé très vite :

Un cluster Kubernetes HA, Un cloud interne qui héberge plusieurs environnements Des SLA à tenir et des incidents à expliquer à des clients.

À ce stade, l’observabilité ne se résume plus à “avoir des graphiques” : c’est la capacité à comprendre ce qui se passe, à corréler un incident à un comportement, à prouver un SLA, et à détecter en amont ce qui va casser.

Pour nous, cela voulait dire :

Des métriques fiables (Prometheus),

Des logs exploitables (Loki),

Une visualisation accessible (Grafana), Et, surtout, une stack capable de tenir dans le temps : montée en charge, ajout de nouveaux clusters, rétention plus longue… sans transformer le monitoring en “monolithe incontrôlable”.

II. Notre premier setup : un Prometheus “simple” dans le cluster

Le schéma classique d’un prometheus server monolithique (provenance de DevOpsCube)Comme beaucoup d’équipes, nous avons commencé avec un schéma très classique :

Un Prometheus déployé dans le même cluster que nos workloads, sur un namespace dédié. Environ 400 pods monitorés. Une rétention de 30 jours configurée pour ne pas perdre trop vite l’historique.

Grafana branché sur ce Prometheus pour les dashboards.

Loki déjà présent, également dans le cluster, pour collecter les logs.

Sur le papier, tout était là : des métriques, des logs, des beaux graphs et une stack “standard” supportée par le chart Prometheus Operator.

Et dans les premiers temps, ça faisait le job. Mais à mesure que la plateforme montait en puissance, le setup a montré ses limites.

III. Les limites rencontrées : RAM, rétention et vision globale

Les symptômes sont apparus assez vite, et ils sont parlants.

**Prometheus qui dévore la RAM.**Pour environ 400 pods monitorés, avec 30 jours de rétention, notre Prometheus consommait déjà 20 GiB de RAM. En soi, ce n’est pas choquant pour de gros environnements, mais à notre échelle (et avec la croissance prévue), c’était un signal faible important : si nous continuions sur ce modèle, chaque nouveau cluster ou chaque montée de volumétrie se paierait immédiatement en RAM.

**Loki dans le même cas.**Le Loki in-cluster tournait lui aussi autour de 20 GiB de RAM, pour gérer les logs applicatifs et cluster. Là encore, acceptable au début… mais difficilement tenable dans un modèle où l’on veut : davantage de pods, davantage d’environnements et à terme plusieurs clusters.

**Un seul cluster, une seule vision.**Autre limite structurelle : toute cette observabilité était liée à un seul cluster. Tout allait bien tant que nous n’avions qu’un cluster principal. Mais très vite, notre trajectoire nous a amenés à :

multiplier les clusters Kubernetes, vouloir corréler des comportements entre eux, et disposer d’un point central pour tout voir et alerter.

**Un monitoring qui devient lui-même un point de fragilité.**Dernier constat : lorsque Prometheus et Loki se trouvent dans le même cluster que les workloads, on se retrouve avec un paradoxe : si le cluster a un problème sévère, il devient justement plus dur d’accéder aux métriques et aux logs, alors que c’est à ce moment-là qu’on en a le plus besoin.

Bref, notre setup initial nous a permis de démarrer — mais il ne passait pas à l’échelle de notre cloud interne multi-clusters et de nos exigences d’hébergeur.

IV. Passer à une stack dédiée : un cluster de monitoring

À partir du moment où Prometheus et Loki ont commencé à consommer chacun ~20 GiB de RAM pour un seul cluster (~400 pods, 30 jours de rétention), la conclusion était assez évidente :

Si on continue comme ça, le monitoring va devenir plus lourd que ce qu’il observe.

Plutôt que d’optimiser à la marge, nous avons fait un choix structurant : sortir la brique d’observabilité critique dans un cluster Kubernetes dédié au monitoring.

Le cluster de monitoring host Thanos (en haut) qui gères les infos de plusieurs PrometheusAujourd’hui, notre architecture ressemble à ceci :

Nous avons 4 clusters Kubernetes “métiers”. Dans chaque cluster, un Prometheus local scrute les workloads (metrics kube, nodes, applicatifs). Dans chaque cluster, un Loki distribué (via Helm) collecte les logs — ce qui permet de bien distinguer les journaux cluster par cluster, tout en restant scalable. Un cluster de monitoring dédié agrège tout cela, avec Thanos comme brique centrale pour les métriques et Grafana en HA comme couche de visualisation.

Concrètement :

Prometheus reste proche des workloads, ce qui simplifie le scrape et limite les problèmes réseau.

Thanos vient se greffer dessus (sidecar/remote-write) pour récupérer les données et les rendre disponibles dans un plan de contrôle metrics global. Les blocs Thanos sont stockés sur un bucket S3 compatible, ce qui assure la rétention long terme sans saturer la RAM des Prometheus.

Ce changement a deux effets immédiats :

On arrête de se battre avec la RAM : la charge mémoire de chaque Prometheus reste raisonnable, Thanos et l’object storage prennent le relais pour l’historique.

On gagne un vrai point central : un seul endroit pour interroger les métriques de tous les clusters et croiser les comportements.

Et surtout, le monitoring ne vit plus dans l’ombre du cluster qu’il est censé aider à diagnostiquer : il devient une plateforme à part entière, avec ses propres garanties de disponibilité.

V. Thanos : le point central HA et multi-clusters

Thanos est souvent présenté comme “un Prometheus pour plusieurs Prometheus”. Ce n’est pas totalement faux… mais c’est un peu réducteur.

Dans notre cas, Thanos joue trois rôles clés :

Vue globale multi-clusters

Chaque Prometheus expose ses données à un sidecar Thanos. Les composants Thanos (en particulier le Querier et le Store Gateway) permettent de requêter l’ensemble des clusters comme si c’était une seule source. Grafana se branche sur cette couche, ce qui donne une vision unifiée des métriques, avec possibilité de filtrer par cluster, environnement, application…

2. Rétention long terme

Thanos archive les séries temporelles en blocs dans un object storage S3. Cela permet de conserver des données sur des périodes beaucoup plus longues qu’un simple Prometheus in-cluster, sans exploser la RAM ni le stockage local.

Schéma qui résume chaque composants de Thanos (issue de la doc AWS)3. Haute disponibilité de la couche métriques

Avec plusieurs Prometheus (un par cluster) et Thanos par-dessus, on tolère la perte d’une instance tant que les sidecars et le stockage restent accessibles. Le Thanos Querier dé-duplique les séries lorsqu’il y a des Prometheus redondants, ce qui évite les doublons dans les dashboards.

Au final, Prometheus se concentre sur ce qu’il fait de mieux : scraper et stocker localement sur une période raisonnable. Thanos prend le relais pour la vue globale, la rétention, et la robustesse d’ensemble. C’est cette combinaison qui nous donne une stack de metrics à la fois scalable, résiliente et exploitable dans le temps.

VI. Logs, dashboards et alertes

Les métriques ne suffisent pas : dès qu’un incident devient sérieux, tout le monde finit par dire “OK, maintenant montre-moi les logs”.

Côté logs, nous utilisons Loki en mode distribué, un déploiement par cluster. Cela nous permet :

de garder une séparation naturelle des journaux (un Loki par cluster), de bénéficier d’une architecture conçue pour être horizontale et distribuée, adaptée aux environnements Kubernetes modernes.

À terme, une évolution naturelle sera de centraliser l’ingestion (un point d’entrée commun pour tous les logs), mais aujourd’hui ce découpage par cluster colle bien à notre organisation.

Côté visualisation, Grafana est déployé en HA sur le cluster de monitoring :

Plusieurs réplicas, stockage persistant, backup régulier. Un câblage direct vers Thanos pour les métriques et vers Loki pour les logs, ce qui nous donne une console unique d’observabilité multi-clusters.

Sur les dashboards, nous adoptons une approche pragmatique :

Dashboards officiels (issus notamment du stack Prometheus / kube-prometheus) pour tout ce qui est santé cluster, nodes, workloads — on ne réinvente pas la roue.

Dashboards custom pour les sujets qui nous concernent directement : visualisation fine des logs (filtrés par app/namespace/cluster), trafic Traefik (routes, codes retour, erreurs 4xx/5xx, latence), vues orientées “hébergeur” (environnements de démo, clusters clients, etc.).

Je vous conseille ce lien si vous souahitez mettre en place des dashboards professionnelle et bien détaillé sans perdre du temps pour monitorer vos cluster Kubernetes: https://grafana.com/orgs/imrtfm

Enfin, toute cette observabilité ne servirait pas à grand-chose sans alerting :

Les Prometheus Rules permettent de détecter automatiquement les dégradations (latence qui monte, erreurs, saturation CPU/RAM/storage…). Les alertes sont forward vers Alertmanager, qui se charge du routing (bon canal, bonne équipe, bon niveau de criticité).

Pareil que pour les dashboards Grafana, je vous donne ce site vous permettant de récupérer un grand nombre de rules pour des tout types d’exporters: https://samber.github.io/awesome-prometheus-alerts/rules.html

VII. Conclusion & suite

Passer d’un Prometheus “simple” dans un cluster à une stack de monitoring HA basée sur Prometheus + Loki + Grafana + Thanos nous a permis de changer d’échelle :

nous avons une vue centralisée sur 4 clusters (et plus demain), une rétention long terme des métriques grâce à Thanos et au stockage S3, des logs distribués mais lisibles, des dashboards qui parlent autant aux ops qu’aux développeurs, et une chaîne d’alerting qui détecte les problèmes avant nos utilisateurs.

Comme pour le reste de notre cloud interne, l’objectif n’était pas d’avoir “les bons logos” mais une plateforme observable, qui nous aide à tenir nos engagements d’hébergeur.

Dans la suite de Sous le capot du cloud, nous continuerons à descendre dans les couches :

Stockage avancé : SAN + Longhorn, classes de stockage, snapshots et backups. Bref, l’observabilité n’est pas un “plus” autour de Kubernetes : c’est ce qui permet de prouver que l’infra fait ce qu’on lui demande. On garde le cap… et on continue d’ouvrir le capot.

Stack de monitoring HA pour Kubernetes : de Prometheus à Thanos was originally published in STEAMULO Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Choix de l’infra et hyperviseur, Pourquoi Proxmox ? Choix de l’hyperviseur pour notre cloud interne

Sous le capot du cloud #3

Dans les deux premiers volets, on a posé le décor : Kubernetes est notre socle et on a montré comment faire de la vraie HA on-prem. Reste la fondation sous le cluster : l’hyperviseur. C’est lui qui nous permet de provisionner vite, d’isoler proprement les briques (control plane, workers, services d’appoint) et d’absorber les opérations sans interruption.

Après étude de plusieurs options, nous avons choisi Proxmox VE pour construire notre cloud interne : ouvert, simple à opérer, taillé pour la HA (migration à chaud, bascule automatisée), intégrable à nos pipelines, et cohérent avec nos choix de stockage et de réseau. Voici notre raisonnement… et notre design de référence.

Les hyperviseurs les plus utilisées dans le monde actuellement (référence 2025)I. Ce que l’on attendait de l’hyperviseur

Avant de parler d’outils, nous avons défini ce dont nous avions besoin au quotidien. L’objectif : une couche d’hyperviseur fiable, rapide et opérable par une équipe à taille humaine.

Disponibilité : continuer à servir même pendant les opérations (maintenance, mises à jour), avec bascule automatique en cas de panne d’un hôte.

Vitesse et routine : créer une VM en quelque minutes, à partir de modèles cloud-init ; cloner, étendre, migrer sans gymnastique.

Interopérabilité et ouverture : Une API propre, une intégration Terraform/Ansible, des images standard (KVM/QEMU), et un support de VLAN et réseaux dédiés (mgmt, stockage, données).

Sauvegarde et reprise : sauvegardes natives : Des backups dé-dupliqués, restaurables (pas juste la conf) — et faciles à tester.

Lisible pour une équipe humaine : UI claire et pilotable en infra-as-code.

Ces critères ont servi de référence pour comparer les solutions et guider l’architecture.

II. Le banc des candidats

Nous avons regardé les options du marché et de l’open-source, avec un prisme très “hébergeur on-premise” :

vSphere/ESXi : référence historique, riche et robuste, mais forte friction de licences et un modèle d’écosystème qui ne colle pas à notre volonté d’ouverture et d’**industrialisation IAC **(Infrastructure As Code).

Hyper-V : intégré Windows, bon pour des parcs déjà Microsoft-centrés ; chez nous, l’empreinte Linux/Kube fait que l’adéquation est moindre.

OpenStack : plateforme cloud complète ; puissante, mais lourde à opérer pour notre taille, alors que nous voulons une couche d’hyperviseur simple, standard et rapide à maîtriser.

Si vous souhaitez comparer plus précisément ces différents hyperviseurs, je vous conseille de regarder le lien ci-dessous.

Best Hypervisor for Home Lab in 2025 - Tested & Compared

III. Pourquoi Proxmox ?

Après plusieurs années d’utilisation de la solution, il était évident pour nous de nous tourner vers cette solution. Cependant, il est intéressant de se pencher sur pourquoi nous l’avons adopté. Je vous ai décliné cela en 7 points.

Ouvert & standard : basé sur KVM/QEMU (VM) et LXC (conteneurs système), images standards, pas de format propriétaire.

HA en natif : cluster Proxmox, PVE HA Manager pour relancer/migrer une VM si un hôte tombe ; live migration (migration à chaud) pour opérer **sans couper en cas de MAJ **d’un serveur Proxmox.

Réseau clair : bridges Linux, VLAN par projet/usage, séparation gestion / stockage / données, facile à auditer et à tracer.

Stockage flexible : s’intègre à iSCSI, NFS, ZFS, Ceph ; chez nous, interopérabilité à un SAN TrueNAS (iSCSI), parfaitement compatible avec nos choix **Kubernetes + Longhorn **comme évoqué dans l’article Sous le capot du Cloud #2.

Sauvegardes sérieuses : Proxmox Backup Server (dédup/compression),

Automatisable : API complète, Terraform provider, cloud-init pour générer des nœuds prêts à rejoindre le cluster Kube ; intégration fluide avec nos pipelines.

Lisibilité & coût : interface sobre, et un modèle open-source qui nous évite les surprises de licences tout en restant souverain sur l’outillage.

Pour les personnes souhaitant mettre en place leur propre cluster Proxmox, je ne peux que vous recommander la vidéo explicative de la chaine @HomeNetworkGuy. Cette dernière est en anglais, mais rentre dans les détails hardware et software de la solution.

https://medium.com/media/439f002db981c9751bfd014ec2eef7a7/hrefIV. Notre design de référence

Afin d’héberger un cluster Kubernetes On-Premise privatisé, nous mettons en place le même design de référence. Ce dernier est, vous le remarquerez surement, assez imposants, mais nos clusters sont amenés à héberger en général entre 500 et 2000 pods.

L’architecture type minimum que nous déployons pour nos clusters On-PremiseCluster Proxmox : Minimum 3 hôtes formant le socle HA de notre cloud interne. La gestion (Corosync/API/UI) est séparée du trafic de données et du stockage.

Réseaux :

Management (accès Proxmox, corosync) — réseau dédié, segmenté.

Stockage (iSCSI) — VLAN isolé vers le SAN TrueNAS pour garantir débit/latence.

Données (VM) — réseaux applicatifs (VLAN par projet, si besoin).

Stockage : LUN iSCSI exposées par TrueNAS ; côté Kubernetes, la persistance “flottante” est assurée par Longhorn (attachement/ détachement, réplication, snapshots).

HA opérationnel : si un hôte sort, les VMs critiques (control planes, ingress, etc.) redémarrent ailleurs ; la migration à chaud nous permet de planifier des maintenances sans impact.

V. Notre Infrastructure As Code

Nous avons industrialisé Proxmox en Infrastructure as Code avec Terraform (provider bpg/proxmox) en décrivant de manière déclarative le cluster, les nœuds et les workloads (tailles, réseaux, placements multinœuds).

Le flux met en place un template Ubuntu Cloud réutilisable, puis clone les VMs depuis ce template en leur appliquant une configuration cloud‑init générée dynamiquement et injectée via l’API. Les adresses IP et la répartition des VMs sont calculées et validées par des expressions et préconditions Terraform, tandis qu’un script d’orchestration encadre les phases d’initialisation, plan, apply et destroy.

Cette approche apporte **reproductibilité et traçabilité **(état/versionning Terraform), cohérence de configuration, rapidité de provisioning, contrôle fin du placement multinœuds, gestion déclarative des réseaux/IPs et une montée en charge simplifiée en ajustant uniquement les variables.

Malheureusement il n’y a pas vraiment de tuto récent utilisant le provider bpg/proxmox, mais un ancien permettant de comprendre le principe est celui de Stéphane Robert qui est disponible sur le lien ci-dessous.

Provisionner des VM avec Terraform

VI. Les points importants à garder en tête

Pour moi, ces points ne sont pas des “options”, mais des habitudes qui évitent 90 % des surprises.

Séparer les plans de trafic (gestion, stockage, données) et documenter les VLAN/passerelles.

Tester les restores sur Proxmox Backup Server (une sauvegarde non testée n’est pas une sauvegarde).

Versionner / cadencer les mises à jour (kernel/hyperviseur) et migrer à chaud avant toute opération intrusive.

Surveiller la latence du stockage (iSCSI) et le taux de sur-utilisation CPU/RAM ; alerter avant les seuils.

Tracer les attributions IP/VLAN (éviter les chevauchements qui font perdre des heures). Pour éviter cela, nous avons désactivé le serveur DHCP.

VII. Conclusion & suite de la série

PChoisir Proxmox n’a rien d’un “plus produit” : c’est une discipline d’infrastructure. Un hyperviseur ouvert, HA et automatisable qui garantit le provisioning rapide, la migration à chaud, la bascule automatique en cas de panne, et la séparation nette des réseaux et du stockage. Une fois ce socle posé, faire grandir la plateforme (davantage d’hôtes, de nœuds, de charge) devient surtout une question de capacité, pas une refonte.

Si nous isolons les sujets, c’est volontaire : chaque brique doit être reproductible. Prochaine étape : voir ce que fait la plateforme et le prouver dans le temps.

**Prochain volet — Observabilité & monitoring (HA)**De Prometheus à Thanos : métriques, logs et alertes hautement disponibles, tableaux de bord actionnables, rétention longue et agrégation multi-clusters. Concrètement : Prometheus/Alertmanager en HA, Loki + Grafana, et Thanos pour la vision globale.

Bref, transformer une pile d’outils en plateforme fiable ne tient pas à un nom, mais à l’assemblage maîtrisé de ces décisions. On garde le cap… et on ouvre le capot sur l’observabilité dans le prochain volet.

Choix de l’infra et hyperviseur, Pourquoi Proxmox ? Choix de l’hyperviseur pour notre cloud interne was originally published in STEAMULO Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Architectures de cluster : Standalone vs HA — comment concevoir (et opérer) une HA Kubernetes on-premise

Sous le Capot du Cloud — #2

Dans l’épisode #1, nous avons montré pourquoi — chiffres à l’appui — Kubernetes est devenu le socle d’hébergement que nous avons choisi pour bâtir notre propre cloud (lire : Sous le Capot du Cloud — #1)

Reste la question centrale : comment concevoir et opérer la haute disponibilité (HA) d’un cluster Kubernetes on-premise — c’est-à-dire la capacité à rester disponible même quand des composants tombent (nœud, control plane, stockage, réseau) et à mettre à jour sans interruption ?

Dans ce volet, nous explorons les bases d’un cluster HA, proposons un design de référence on-premise et expliquons les choix structurants à arrêter dès le départ pour viser 99,99 % de disponibilité perçue (SLA). Nous évoquerons les bases fondamentales de notre HA (principes, architecture, choix stratégiques) ; les détails d’implémentation : stockage, mises à jour sans coupure, observabilité multi-clusters

I. Contexte & objectifs de disponibilité

Notre cible est claire : 99,99 % de disponibilité. Concrètement, cela veut dire que le service reste accessible si un nœud tombe, pendant une mise à jour, et quand on déploie une nouvelle version — sans que l’utilisateur le remarque, et sans mobiliser une armée d’ingénieurs DevOps.

Pour y parvenir, on applique quelques règles simples à comprendre :

La majorité doit survivre : le “cerveau” du cluster (etcd) fonctionne par majorité, donc on prévoit au moins trois instances pour qu’il continue à décider si l’une tombe.

On ne met pas tous les œufs dans le même panier : les workloads importants sont répliqués et répartis (anti-affinity) pour qu’une panne locale n’ait aucun effet visible.

La porte d’entrée ne doit pas être unique : l’API et l’Ingress passent par une adresse virtuelle portée par plusieurs points d’accès (VIP + HAProxy/Keepalived), afin que la bascule soit instantanée.

Les données doivent encaisser les accidents : le stockage est répliqué et tolérant aux pannes, pour redémarrer ailleurs sans perte.

Dit autrement : la haute disponibilité n’est pas “plus de machines”, c’est plus d’occasions de ne pas tomber — par conception.

Si vous le souhaitez, vous pouvez jeter un oeil sur la documentation officielle de Kubernetes qui parle de façon plus globale de la HA sur Kube. II. Les fondations d’un cluster HA qui tient vraiment

Nous sommes en HA. Pour que cela tienne dans la durée, quelques fondations ne sont pas négociables — elles conditionnent la disponibilité perçue :

Cluster etcd : Le « cerveau » du cluster décide par majorité. En pratique, on vise trois nœuds etcd (et cinq si l’on s’étend multi-site) et une latence courte et stable entre control planes. C’est ce qui permet au cluster de continuer à décider quand un nœud disparaît.

Control plane dimensionné : L’API, le scheduler et les controllers doivent tenir les pics (déploiements, autoscaling, reconvergences). On leur réserve du CPU/RAM et on évite qu’ils soient perturbés par les workloads applicatifs. Un control plane sous-dimensionné transforme la moindre opération en risque.

La répartition intelligente des pods : On ne met pas tous les réplicas au même endroit : anti-affinity, PodDisruptionBudgets (PDB) et probes bien réglées empêchent qu’une maintenance, un drain ou une panne locale n’éteigne un service répliqué.

III. Assurer la dispo de l’API

La haute dispo d’un cluster commence… par l’API Kubernetes. Beaucoup “redondent” les control planes et posent un load balancer devant. Problème : ce load balancer devient le SPOF. S’il tombe (ou s’il dérive), tout le cluster est muet, peu importe le nombre de control planes derrière.

Notre design évite ce piège :

Trois control planes avec **etcd sur la node **→ le cluster encaisse donc la perte d’un nœud.

Pas de point unique : HAProxy et Keepalived tournent sur plusieurs nœuds, ce qui réplique la porte d’entrée.

Keepalived porte une VIP (Virtual IP) via VRRP. Si le nœud actif disparaît ou si les checks échouent, la VIP bascule instantanément vers un pair.

HAProxy, de son côté, sonde les API servers et ne relaie que vers les backends sains.

Schéma représentant le cluster d’etcd sur les nodes Control Plane (le modèle que nous avons choisi d’appliquer)Résultat : les clients (kubectl, nœuds, contrôleurs) ne parlent qu’à la VIP ; en cas de panne d’un control plane ou d’une maintenance, la bascule est transparente. Pas de boîtier unique, pas de dépendance exotique : de l’open source éprouvé, versionné comme le reste, opérable par une équipe à taille humaine. Autrement dit, l’API reste joignable quand un nœud tombe, et pendant les mises à jour du plan de contrôle.

IV. Réseau & répartition du trafic : concrètement, comment ça circule ?

Dans un cluster Kubernetes, il y a deux portes d’entrée selon le type d’appli :

**1) Des IPs “publiques” pour des services bruts (TCP/UDP).**Quand on veut exposer, par exemple, une base ou un service TCP interne à des partenaires, on a besoin d’une adresse IP dédiée qui “flotte” vers l’instance en bonne santé. C’est le rôle de MetalLB : il attribue des IPs dans un pool que vous réservez et les annonce sur le réseau local.

Mode L2 : il publie l’IP via les annonces de voisinage du réseau (l’équivalent d’ARP/ND) — simple, efficace si votre réseau est plat.

Mode BGP : il parle routage avec vos routeurs — plus propre si vous avez plusieurs segments ou des équipements réseau avancés.

L’idée à retenir : l’IP suit le service. Si un nœud tombe, l’IP bouge automatiquement avec le service.

Schéma représentant l’utilisation de MetalLB pour la couche réseau L2 de notre cluster Kube2) Une entrée HTTP/HTTPS pour les applis web.

Pour tout ce qui est web, on passe par un Ingress Controller. Nous utilisons Traefik : il reçoit les requêtes HTTP/HTTPS, termine le TLS (certificats), et redirige vers les bons services en fonction du nom de domaine et du chemin.

Gestion des certificats : automatisable (ACME/Let’s Encrypt) ou via votre PKI interne.

Haute dispo : Traefik tourne en réplicas sur plusieurs nœuds ; si un pod tombe, un autre prend le relais.

Schéma du cluster HA de Traefik qui assure la distribution des requêtes à nos applicationsNous resterons volontairement au-dessus de la mécanique (choix précis du mode MetalLB, politiques réseau, MTU fine, etc.). Tout cela fera l’objet d’un article dédié “réseau & load balancing”, avec schémas et paramètres détaillés. V. Stockage & persistance : retrouver des “volumes flottants”… on-prem

Chez un cloud provider, on attache un disque à une VM, on le détache, on le rattache ailleurs : le stockage « suit » la charge. C’est exactement ce que nous voulions reproduire on-prem.

Notre recette, en deux couches claires :

Le socle SAN : un TrueNAS dédié qui expose des volumes bloc via iSCSI sur un réseau séparé. Concrètement, le stockage arrive aux nœuds Kubernetes comme s’il s’agissait de disques locaux, mais par le réseau, avec les contrôles et la qualité de service du SAN.

La couche Kubernetes : Longhorn orchestre ces volumes du côté cluster. Il présente des Persistent Volumes aux applications, gère l’attachement/détachement au bon nœud, pilote la réplication, les snapshots et la reconstruction si un nœud disparaît. Résultat : les données restent disponibles et le volume se ré-attache là où le pod redémarre.

Au quotidien, cela nous donne des volumes “flottants” comparables à ceux d’un cloud public, mais sous contrôle : classes de stockage adaptées, isolation réseau du trafic iSCSI, et une exploitation opérable par une équipe à taille humaine.

👉 Nous consacrerons un article dédié à ce sujet : pourquoi ce choix TrueNAS + Longhorn, quelles alternatives (et leurs compromis), comment dimensionner et tester les performances, et comment bâtir une stratégie de snapshots / sauvegardes cohérente avec les exigences d’un hébergeur. https://medium.com/media/e3c40b04361187159915c7d2b23b85af/hrefVI. Mises à jour sans interruption : pourquoi la HA change tout

En production, on met à jour tout le temps : correctifs de sécurité, nouvelles versions, montées d’OS… Sans haute disponibilité, chaque mise à jour impose une fenêtre de maintenance — donc un impact client. Avec une architecture HA, l’objectif devient l’inverse : faire évoluer le cluster sans que personne ne le voie.

Concrètement, on dédouble ce qui sert le trafic (plusieurs réplicas de chaque service, plusieurs nœuds) et on fait évoluer par petites touches : on met un nœud de côté (on « vide » les applications qui y tournent), on le met à jour, puis on le réintègre. Pendant ce temps, le trafic reste porté par les autres nœuds. Côté applications, on démarre la nouvelle version à côté de l’ancienne, on vérifie qu’elle répond bien, puis on bascule progressivement. Si quelque chose cloche, on revient en arrière immédiatement.

Nous détaillerons le pas-à-pas (outils, paramètres, check-list de vérification) dans un article dédié — ici, retenez l’essentiel : la HA n’est pas un luxe, c’est ce qui rend les mises à jour invisibles pour vos utilisateurs. VII. Tests d’acceptation : vérifier les promesses de la HA

Avant chaque mise en service (et régulièrement ensuite), nous simulons des pannes et observons le comportement du cluster. Trois scénarios suffisent à valider l’essentiel.

Panne d’un control planeNous arrêtons volontairement un nœud du plan de contrôle. La VIP portée par Keepalived/HAProxy bascule automatiquement vers un autre nœud actif ; l’API reste joignable et les commandes kubectl répondent normalement. Résultat : aucune interruption visible (les caches applicatifs masquent la transition).

Panne d’un nœud workerNous mettons hors ligne un worker. Le scheduler reprogramme les pods ailleurs et les services répliqués continuent de répondre. Nos bases de données en cluster (master/slave) étant réparties sur plusieurs workers, elles restent disponibles. Résultat : pas d’impact fonctionnel côté utilisateurs.

Mise à jour contrôléeNous effectuons des montées de version par étapes : on vide un nœud, on le met à jour, on le réintègre, puis on passe au suivant ; côté applications, la nouvelle version est lancée à côté de l’ancienne et la bascule est progressive. Résultat : pas de coupure perçue.

Le détail (méthode complète, points de contrôle, retour arrière) fera l’objet d’un article dédié. Conclusion & suite de la série

La HA on-premise n’est pas un bouton magique : c’est une discipline faite de choix simples mais stricts (cluster, VIP API, anti-affinity, réplication, supervision). Une fois le cap HA posé, faire évoluer la taille du cluster (plus de CP, plus de workers) est surtout une affaire de capacité, pas de refonte.

Si nous “teasons” plusieurs sujets au fil du texte, c’est volontaire : chaque brique mérite son propre focus pour bâtir une base solide et reproductible. Dans les prochains volets de Sous le capot du cloud, nous détaillerons, pas à pas :

Réseau & répartition du trafic : MetalLB, Ingress, bonnes pratiques réseau

Stockage avancé : SAN + Longhorn, classes, snapshots

Mises à jour invisibles : runbooks, paramètres, garde-fous

Observabilité multi-clusters : cap vers Thanos

Tests & “chaos” léger : pannes simulées, critères d’acceptation

Bref, transformer un cluster en plateforme fiable ne tient pas à un outil, mais à l’assemblage maîtrisé de ces décisions. On ouvre le capot, et on continue.

Architectures de cluster : Standalone vs HA — comment concevoir (et opérer) une HA Kubernetes… was originally published in STEAMULO Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

**Pourquoi Kubernetes est devenu incontournable pour les hébergeurs (2025) — **HA, scalabilité, observabilité : le trio gagnant.

Sous le Capot du Cloud — #1

Pendant des années, nous avons fait « à l’ancienne » : une VM par projet, plusieurs VMs pour la haute disponibilité, déploiements Ansible via SSH, socles à rejouer pour chaque environnement. À mesure que prod, préprod, recette et démo se multipliaient, la mécanique s’est alourdie : délais qui s’étirent, écarts entre fournisseurs, factures qui gonflent, complexité qui s’accumule.

En 2024, nous avons pris le temps de nous former en profondeur, d’étudier les options et de monter un lab reproduisant nos contraintes réelles. Le verdict a été clair : pour standardiser le delivery, garantir la disponibilité, renforcer l’observabilité et reprendre la main sur les coûts, Kubernetes s’imposait. Nous avons donc amorcé la migration et, dans cet article, nous expliquons ce que ce changement implique — et en quoi il nous rend plus efficients et compétitifs aujourd’hui.

Un programme ne peut s’exécuter avec succès que s’il peut être déployé de manière fiable sur la machine où il doit fonctionner. — Brendan Burn, Corporate Vice President de Microsoft Ce modèle a tenu la charge… jusqu’à ce que l’échelle et l’hétérogénéité le rendent coûteux et lent :

Time-to-environment : min. 1,5 jour, médian 2–3 jours, max 5–6 jours par environnement.

Volume infra : 150–200 VMs actives/mois sur 6 cloud providers.

Densité : 1 à 5 VMs par environnement (base de données dédiée, front/back séparés, Load-balancers, etc.).

Non-prod (démos/POC) : > 15 000 € / mois.

Déploiements : 2 à 3 nouveaux environnements/semaine, en parallèle d’autres missions.

SLA perçu : ~99,9 %, mais avec des fenêtres de maintenance longues (ex. déploiements Drupal, vidage de cache), donc des downtimes programmés de plus en plus difficiles à accepter en 2024.

Côté outillage, Jenkins est devenu le maillon fragile : une constellation de plug-ins à mettre à jour manuellement, des dépendances peu cohérentes entre elles, et une maintenance chronophage (scripts de mise à jour, curl d’artefacts, désinstallation/réinstallation). À l’échelle, la plateforme CI elle-même finissait par ralentir le delivery.

Référence (public) : notre repo d’initialisation VM Linux (socle) : https://github.com/steamulo/steamulo.basic

Variabilité entre fournisseurs (images, réseaux, load balancers, storage classes managées) ⇒ autant d’exceptions dans Terraform/Ansible.

Drift de configuration au fil des mises à jour et hotfixes : deux environnements “identiques” ne l’étaient plus tout à fait.

Jenkins devenu difficile à maintenir : superposition de centaines de plugins, dépendances hétérogènes, dette de mise à jour, fragilité des pipelines.

Schéma de l’ancienne pipeline DevOps utiliséeII. Le nœud du problème : lenteur, complexité, facture (et fenêtres de maintenance)

A) Le temps : un goulot devenu structurel

Même avec des playbooks Ansible prêts à l’emploi, l’ouverture d’un environnement restait lente : 1,5 à 3 jours dans la plupart des cas, et 5 à 6 jours dès que la configuration se complexifiait — avant même la préparation applicative.

Deux exemples parlent d’eux-mêmes : pour une architecture avec load balancer, base de données en mode primaire/réplique et application distribuée derrière le load balancer, la seule mise à disposition des machines virtuelles et leur configuration prenaient 5 à 6 jours.

Même des déploiements a priori “copier-coller”, comme un Matomo en cluster à partir de nos modèles Terraform/Ansible, mobilisaient encore environ 3 jours.

À raison de 2 à 3 environnements créés chaque semaine, ce délai incompressible finissait par peser sur le planning de l’équipe et freiner le delivery.

B) La complexité opérationnelle : hétérogénéité et dette outillage

Multi-cloud : 6 fournisseurs, 6 types de réseaux, d’images, de load balancers, de stockage → autant d’exceptions Terraform/Ansible à maintenir.

Chaîne CI vieillissante : Jenkins et ses plug-ins formaient une dette difficile à automatiser et à fiabiliser, avec une communauté moins active et des cycles de mise à jour lourds.

Observabilité fragmentée : métriques/logs/traces attachés à des briques différentes selon le provider, ajoutées a posteriori.

C) Les coûts directs… et les coûts cachés

Sur-provisionnement pour “acheter” la haute disponibilité (VMs, volumes, IPs, load balancers managés).

Non-prod qui s’accumule (démos/POC) : > 15 000 € / mois.

Coûts d’intégration liés aux variations inter-providers.

Downtimes planifiés (MEP, opérations applicatives) devenus commercialement inacceptables en 2024.

Évolution du temps MCO consacré au vu du nombre de projets grandissantsIII. Quelles solutions possibles ?

Point d’inflexion (2024) : nous avons pris un temps dédié pour nous former, étudier les options et monter un lab reproduisant nos contraintes (nombre limité de pods, matériel modeste). Objectif : standardiser le delivery, réduire les interruptions, densifier intelligemment et unifier l’observabilité — bref, reprendre la main sans dépendre d’un empilement de plug-ins ou d’exceptions par cloud.

Pendant cette période de recherches, un nom s’imposait : Kubernetes. Dans la foulée, nous avons assisté à KubeCon + CloudNativeCon Europe à Paris (19–22 mars 2024) avec nos ingénieurs — l’envergure de l’écosystème et le niveau de professionnalisme ont confirmé notre intuition. L’événement a réuni plus de 12 000 personnes, signe d’une maturité désormais industrielle.

IV. Notre lab : valider en conditions réalistes… sur du matériel modeste

Objectif. Avant d’engager une migration à grande échelle, on a voulu prouver trois choses :

ouvrir un environnement en heures (plus en jours) ; faire des mises à jour sans interruption perçue ;

tenir la charge sans multiplier les machines ni la complexité.

Matériel & périmètre. Pas de serveurs flambant neufs : des tours PC réemployées (mélange 16–32 Go de RAM et ≈4 CPU par machine), un cluster de 5 nœuds (2 control planes, 3 workers) et moins de 100 pods en charge normale. Le stockage reposait sur un NAS Synology en NFS — un choix volontairement simple pour le lab (nous reviendrons plus tard sur l’architecture de stockage “sérieuse”).

Image de notre premier lab local avec des PCs de récupérationCe qu’on a testé.

Pannes simulées : chute d’un control plane → 0 interruption perçue grâce à la redondance ; chute d’un pod avec réplicas → 0 ; chute d’un nœud worker avec anti-affinity → 0 (le rescheduling a absorbé l’incident côté utilisateur).

Mises à jour : rolling update et blue/green sur service web → pas de coupure ressentie, rollback immédiat si besoin.

Environnements éphémères : création/suppression en quelques heures, industrialisées via templates (manifests/Helm), observabilité branchée dès le départ.

**Limites observées.**Passé ~100 pods, certaines machines chutaient : les écritures disque locales saturaient. Verdict : matériel vieillissant, pas un défaut de Kubernetes. C’était d’ailleurs l’un des buts du lab : exposer les goulots pour dimensionner correctement la future plateforme.

Ce que le lab nous a appris.

La HA “par design” de Kubernetes (réplicas, probes, anti-affinity, control planes redondants) tient ses promesses : on atteint des niveaux théoriques de dispo très élevés (bien au-delà de notre ancien ~99,9 %), avec la nuance habituelle : la disponibilité vécue se mesure en prod avec des SLO et de l’observabilité. L’ouverture d’un environnement bascule dans une logique déclarative et reproductible : on “décrit”, on déploie, on observe — sans réinventer le monde à chaque fois. Le stockage est structurant : le NFS du lab nous a suffi pour prouver les patterns, mais il a confirmé la nécessité d’un SAN iSCSI et d’un orchestrateur de volumes (Longhorn) pour la vraie plateforme (on détaillera ce volet dans un article dédié). Surtout, le lab nous a donné les ordres de grandeur pour choisir nos CPU/RAM, notre réseau, et notre système de fichiers cibles — bref, de quoi sizer l’infra sans sur/sous-provisionner.

V. Business plan & ROI : moins d’OPEX, plus de valeur… vite

Côté non-prod, nous passions plus de** 15 k€ / mois** en multi-cloud pour tenir nos démos/POC. En basculant sur un cluster self-host dimensionné “juste ce qu’il faut” ( 3 serveurs hébergeant 12 nœuds au total), l’équation change : un CAPEX de 12 k€ (serveurs) amorti en 4–6 mois intégrant le coût de mise en œuvre, puis un OPEX résiduel limité à ≈ 1 kVA en data center. En parallèle, le MCO (Maintien en Condition Applicative) a été divisé par deux (-50 %), car l’effort se déplace vers le maintien à jour et en sécurité du cluster — ce qui renforce la fiabilité globale.

Notre baie de serveur contenant nos trois hyperviseurs et notre NAS TrueNasOpérationnellement, nous avons déjà migré > 60 % de nos environnements de démo sur le cluster, qui fait tourner ≈ 500 pods à 50–60 % de RAM et 30–40 % de CPU : il reste donc de la marge pour multiplier les POC/MVP sans sur-provisionner. Enfin, les fenêtres de downtime ont disparu en non-prod : 0 % de coupure perçue lors des mises à jour (cordon/drain, réplicas), et une disponibilité cible théorique au-delà de 99,9999 % sur les workloads répliqués (les SLO affineront cette réalité côté production). Résultat : un point mort atteint entre le 4ᵉ et le 6ᵉ mois, puis une dépense mensuelle structurellement abaissée et un cadre d’hébergement plus robuste, qui accélère la preuve de valeur projet par projet.

VI. Mise en place du cluster ?

Nos constats, nos tests et nos chiffres convergent : Kubernetes est devenu notre solution d’hébergement. Nous gagnons en vitesse de delivery, en disponibilité perçue et en pilotage des coûts, tout en recentrant l’effort humain là où il crée de la valeur.

Mais soyons clairs : cela ne répond pas, à lui seul, à la promesse de Sous le capot du cloud. Opérer Kubernetes on-premise n’a rien de magique : la valeur vient d’un ensemble de choix d’architecture et de pratiques de run exigeantes.

Dès le prochain volet, nous ouvrons le capot pièce par pièce : haute disponibilité, stockage, load balancing, mises en prod sans coupure, observabilité, sécurité, gouvernance des coûts… bref, tout ce qui transforme un cluster en plateforme fiable.

Prochain article (#2)

Architectures de cluster : Standalone vs HA — Architecture HA pour Kubernetes on-premise : design et implémentation

Pourquoi Kubernetes est devenu incontournable pour les hébergeurs (2025) — HA, scalabilité, … was originally published in STEAMULO Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Vos modèles IA méritent mieux : pourquoi Kubernetes change la donne

L’orchestration de modèles d’intelligence artificielle (IA) sur Kubernetes suscite un vif débat dans la communauté technique. Le sujet était activement abordé lors de la KubeCon Paris 2024. Kubernetes est aujourd’hui l’orchestrateur en vogue, mais est-il adapté pour héberger des LLM (Large Language Models) extrêmement gourmands en ressources, ainsi que des modèles IA plus spécialisées et fine-tune pour des tâches précises (IA agentique) ? Faut-il continuer à auto-héberger nos modèles sur des instances dédiées équipées de GPU coûteux, ou bien adopter une approche cloud-native sur Kubernetes permettant d’amortir les coûts via une meilleure mutualisation ? Dans cet article technique, nous explorerons ces questions en profondeur, en nous appuyant sur des sources récentes et des cas d’usage concrets. Nous aborderons dans un premier temps l’hébergement des LLM sur Kubernetes, puis celui de **modèles spécialisés **fine-tune, et nous tirerons une conclusion sur la plus-value d’un hébergement Kubernetes ou non pour l’IA de demain.

I. Défis et solutions pour héberger des LLM sur Kubernetes

Vous utilisez surement l’IA quotidiennement et plus précisément des Large Language Models (LLM) comme GPT-4, PaLM 2 ou Llama 2. Vous avez donc sûrement remarqué qu’ils ne sont pas toujours faciles à déployer. Ces modèles exigent des GPU très performants (A100, H100, etc.) et posent des défis techniques particuliers en production. Contrairement aux micro-services traditionnels qui traitent des requêtes courtes et stateless, les inférences LLM sont souvent longues, gourmandes en ressources, et nécessitent de maintenir un état en mémoire (cache de tokens, contexte de conversation…).

Imaginez par exemple un serveur GPU qui doit gérer simultanément plusieurs conversations, chacune avec son propre contexte stocké dans un cache mémoire (KV cache). Ce type de charge atypique pose trois défis principaux :

Charge longue et variable : Une simple génération de texte de 1000 tokens peut occuper un GPU pendant plusieurs secondes. Les répartiteurs de charge classiques, comme le round-robin, ne suffisent pas, car ils ne tiennent pas compte de l’identité du modèle ou de la priorité des requêtes (ex. chat urgent vs tâche batch). Résultat ? Risque de déséquilibre de charge et de latences élevées.

Utilisation inefficace du GPU : Une inférence LLM se déroule en deux phases distinctes : une phase intensive en calcul (prefilling, calcul des embeddings du prompt stocké en cache), suivie d’une phase de décodage plus légère en calcul, mais intensive en mémoire. Pendant cette seconde phase, de précieuses ressources GPU restent souvent inutilisées. C’est un véritable gaspillage.

Coût élevé et difficulté à scaler : Les modèles LLM, de plus en plus grands, deviennent rapidement très coûteux à servir. Ils nécessitent parfois de distribuer leur charge sur plusieurs GPUs ou machines, ce qui rend leur déploiement complexe sur Kubernetes. Sans optimisation, les coûts peuvent exploser, car beaucoup de ressources GPU restent immobilisées sans être pleinement exploitées.

Face à ces défis, Kubernetes a récemment évolué pour mieux supporter les LLM en production. En 2025, une extension notable du **Gateway API **Kubernetes a été introduite pour gérer spécifiquement ces workloads. Cette extension fournit un routage intelligent, capable de sélectionner le meilleur pod pour chaque requête en fonction de paramètres temps réel tels que la longueur des files d’attente ou la présence en cache de parties du prompt.

Deux nouvelles ressources Kubernetes facilitent désormais ce travail :

InferencePool : Géré par vos équipes infrastructure, ce pool regroupe des pods de serveurs de modèles GPU similaires, assurant une utilisation cohérente et optimale des ressources GPU disponibles.

InferenceModel : Géré par vos équipes IA, il permet de définir clairement quels modèles sont servis, comment router les requêtes vers les pools adaptés, et même de gérer la priorité des requêtes ou des déploiements progressifs (rollouts).

Deux nouveaux CRDs introduit par Kube: https://shorturl.at/hMPKTEn combinant ces ressources, vous obtenez une véritable architecture “Model-as-a-Service” : vos data scientists choisissent les modèles et leurs versions, tandis que vos équipes Ops optimisent le déploiement et la scalabilité.

Des benchmarks récents montrent clairement les bénéfices : la latence est réduite significativement, en particulier à fort trafic. Autrement dit, vos requêtes sont traitées plus vite et plus efficacement grâce à cette intelligence de routage.

On peut rapidement remarquer la différence de latence avec la mise en place de l’extension de la sélection d’endpoint (en bleu) introduit par Kubernetes.En parallèle, des projets open-source tels que llm-d (LLM Distributed), lancé par Red Hat, Google et IBM, proposent des optimisations supplémentaires très intéressantes :

Désagrégation des phases d’inférence : En séparant les phases de prefilling et de décodage sur différents GPUs, vous optimisez leur utilisation selon leurs points forts respectifs.

Mise en cache avancée : Les préfixes de prompts déjà traités sont réutilisés pour éviter les recalculs inutiles, réduisant encore davantage les coûts et les temps de traitement.

Lors de la présentation de ce projet en mai 2025, l’affirmation suivante a été énoncée lors de la conférence de presse :

The escalating resource demands of increasingly sophisticated and larger reasoning models limits the viability of centralized inference and threatens to bottleneck AI innovation with prohibitive costs and crippling latency. Ces améliorations offrent jusqu’à trois fois plus de performance, tout en permettant un meilleur contrôle des coûts d’inférence, essentiels pour déployer durablement des LLM à grande échelle.

Schéma expliquant la parallélisation des deux phases de prefill et decoding afin d’améliorer l’exploitation des ressourcesÉvidemment, l’auto-hébergement de LLM n’est pas toujours la solution la moins chère face aux API externes (comme OpenAI), surtout pour des usages ponctuels. Mais pour des raisons de souveraineté des données, de personnalisation poussée ou simplement d’indépendance technologique, l’hébergement interne reste souvent incontournable.

Enfin, Kubernetes facilite une gestion dynamique des ressources via des mécanismes comme KEDA (Kubernetes Event-Driven Autoscaler), permettant de scaler automatiquement vos pods en fonction du trafic, voire de les réduire à zéro lorsque l’activité est faible. Ainsi, vous payez uniquement pour les ressources que vous utilisez réellement, ce qui constitue un avantage économique majeur pour la gestion de vos modèles IA.

II. Hébergement de modèles fine-tunés et spécialisés sur Kubernetes

En dehors des grands LLM généralistes, vous utilisez probablement au quotidien des modèles IA spécialisés et plus légers : extraction d’informations dans des CV, classification automatique d’images, ou encore recommandation personnalisée. Contrairement aux gigantesques LLM, ces modèles sont généralement plus petits, parfois ne pesant que quelques centaines de Mo. Ils nécessitent donc moins de ressources, ce qui les rend parfaits pour être hébergés ensemble sur un même cluster.

La question légitime est donc pourquoi choisir Kubernetes pour ces modèles spécialisés ?

Taille et ressources réduites : Ces modèles peuvent tourner efficacement sur des GPU moins coûteux (comme les NVIDIA T4) ou même simplement sur des CPU. Cela signifie que vous pouvez facilement mutualiser plusieurs modèles sur la même infrastructure, ce qui optimise considérablement vos coûts.

Nombre élevé de modèles : Dans une organisation typique, vous avez souvent besoin de déployer des dizaines, voire des centaines, de modèles IA différents, chacun dédié à une tâche spécifique ou à un client particulier. Avec Kubernetes, la gestion centralisée et homogène devient beaucoup plus simple.

Gestion dynamique des charges : La demande pour vos modèles peut varier fortement dans le temps. Certains modèles reçoivent quelques requêtes par heure, tandis que d’autres en traitent des centaines en continu. Kubernetes vous permet de gérer dynamiquement le nombre de pods actifs, ajustant ainsi automatiquement vos ressources aux besoins réels. Vous pouvez même réduire automatiquement à zéro les ressources pour les modèles peu utilisés.

Pour faciliter davantage ces scénarios, plusieurs outils spécialisés de l’écosystème Kubernetes existent. Prenez par exemple le NVIDIA Triton Inference Server : ce serveur d’inférence permet d’héberger plusieurs modèles simultanément, même s’ils utilisent différents frameworks comme TensorFlow ou PyTorch. En regroupant plusieurs modèles dans un seul pod Triton, vous augmentez fortement la densité de déploiement et optimisez l’utilisation de vos GPU.

D’autres solutions telles que KServe ou Seldon Core simplifient encore plus votre vie en automatisant entièrement le déploiement et le scaling de vos modèles. Avec KServe, il suffit de décrire chaque modèle via des ressources Kubernetes (InferenceService) et le reste est pris en charge automatiquement : configuration serveur, autoscaling, vérification de santé, et même gestion avancée du scaling GPU ou du scale-to-zero. En clair, Kubernetes gère la complexité opérationnelle pour vous, vous laissant libre de vous concentrer uniquement sur l’optimisation de vos modèles.

Diagramme expliquant la place de Kserve dans le workflow KubernetesUn cas particulièrement intéressant est celui du multi-modèle haute densité. Pour éviter de réserver inutilement des ressources à des modèles rarement sollicités, KServe propose ModelMesh. Imaginez un pool partagé de pods capables de charger à la demande les modèles nécessaires depuis un stockage externe (comme S3), en fonction des requêtes reçues. Ce système intelligent libère automatiquement la mémoire occupée par des modèles peu utilisés, maximisant ainsi l’utilisation des ressources GPU et CPU à l’échelle du cluster.

Diagramme détaillé du fonctionnement du composant ModelMesh de KserveEn résumé, pour vos modèles spécialisés, Kubernetes représente aujourd’hui une solution idéale : simple, flexible, économique, et incroyablement efficace. Plutôt que d’allouer des ressources inutilisées, vous optimisez continuellement vos coûts tout en améliorant votre capacité à déployer rapidement et efficacement de nouveaux modèles. Pour vous donner un ordre d’idée, avant ces innovations sorti en 2025, près de 48% des entreprises avaient adopté Kubernetes pour leurs applications IA en 2023.

III. Quelles conclusions en tirer ?

En résumé, Kubernetes possède aujourd’hui tous les atouts pour devenir votre plateforme privilégiée pour l’hébergement de modèles IA, qu’il s’agisse de grands modèles LLM ou de modèles spécialisés plus légers.

Le choix d’une infrastructure adaptée (on-premise, cloud ou hybride) dépendra principalement de vos contraintes spécifiques : budget, compétences internes, besoin de scalabilité, ou encore sécurité des données. Cette question mérite une analyse approfondie à elle seule, et c’est justement ce que nous aborderons prochainement dans un nouvel article dédié.

Dans tous les cas, Kubernetes apparaît désormais incontournable pour optimiser efficacement et durablement vos déploiements IA. L’évolution rapide de l’écosystème ces deux dernières années montre clairement que Kubernetes n’est pas seulement une tendance, mais une véritable révolution en matière d’hébergement IA.

IV. Sources

Cet article étant un papier technique sur toutes les innovations en termes d’hébergement IA sur Kubernetes, ce dernier s’appuie sur un grand nombre de sources. Si vous souhaitez rentrer dans les détails, les voici :

Introducing Gateway API Inference Extension | Kubernetes Solo.io Blog | llm-d: Distributed Inference Serving on Kubernetes | Solo.io Renting GPU time (vast AI) is much more expensive than APIs (openai, m, anth) : r/LocalLLaMA Seeking Cost-Efficient Kubernetes GPU Solution for Multiple Fine-Tuned Models (GKE) : r/kubernetes Scale to zero using KEDA | Kubernetes Engine | Google Cloud Introduction | Kubeflow ModelMesh Overview — KServe Documentation Website Managed K8s & GPU Worker Nodes for Faster AI/ML Inference | Gcore Kubernetes Total Cost of Ownership: Self-Managed vs … — Gcore

Vos modèles IA méritent mieux : pourquoi Kubernetes change la donne was originally published in STEAMULO Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

L’IA sous votre contrôle avec Autoscribe

Imaginez réduire de 90% le temps consacré à la rédaction de comptes-rendus de réunions, tout en garantissant que vos données restent sous votre contrôle total. Avec Autoscribe, une solution d’IA auto-hébergée, ce rêve devient réalité. Ces dernières semaines, j’ai eu l’opportunité de tester l’auto-hébergement de modèles d’IA pour Steamulo** **et son projet interne Autoscribe, en explorant l’auto-hébergement de Modèles de Langage (LLM) et des modèles de Speech to Text (STT) sur une instance Scaleway équipée d’un GPU L40S.

Mon objectif : évaluer comment ces technologies peuvent transformer nos processus tout en garantissant sécurité et souveraineté des données. Les résultats de ces tests ont été bluffants. Dans cet article, je partage mon expérience, nos résultats et les leçons apprises au cours de ce processus.

Architecture agentique d’Autoscribe

L’architecture d’Autoscribe repose sur une approche agentique décentralisée, conçue pour optimiser la transcription d’audio et la génération de comptes-rendus de manière autonome et efficace. Au cœur du système, l’Agent Orchestrateur supervise et coordonne l’ensemble du processus. Il s’appuie sur une mémoire partagée et des outils (comme l’accès à des bases de données ou des API) pour gérer les interactions entre les agents spécialisés et les ressources.

Architecture agentique d’Autoscribe

Agent Transcription : Responsable de la conversion des fichiers audio en texte, cet agent utilise des modèles de Speech to Text pour réaliser des transcriptions. Il intègre une mémoire pour stocker les transcriptions intermédiaires et des outils pour prétraiter les données audio (ex. : segmentation, normalisation).

Agent Résumé : Chargé de générer des comptes-rendus pertinents à partir des transcriptions, cet agent exploite des modèles LLM permettant de synthétiser les points clés des transcritpions fournies. Il dispose d’une mémoire dédiée pour conserver les résumés produits et utilise des outils pour structurer le texte (ex. : extraction de points clés, formatage). Les différents modèles d’IA et les options de génération permettent une personnalisation selon les besoins.

L’Agent Orchestrateur centralise les flux de données entre ces agents, en s’appuyant sur une mémoire globale (pour le contexte et l’historique) et des outils communs (ex. : gestion des erreurs, notifications). L’objectif de cet article est d’étudier une transition vers des modèles auto-hébergés avec cette architecture modulaire, afin de garantir une souveraineté des données tout en offrant une flexibilité pour intégrer de nouveaux modèles ou fonctionnalités. Le diagramme ci-dessus illustre cette organisation, mettant en évidence les interactions entre agents, mémoires et outils pour un workflow fluide et performant.

Comment tester et évaluer : La méthode derrière les résultats

Pour ce projet, nous avons choisi une instance Scaleway L40S, équipée d’un GPU NVIDIA L40S avec 96 Go de mémoire. À 1,4 €/heure, elle offre un excellent rapport performance-prix comparée à des alternatives comme la H100. Voici comment nous avons procédé :

Instance utilisée pour réaliser les testsÉvaluation des modèles de Speech to Text (STT)

Le cas du Speech to Text est délicat car même l’état de l’art apporte des résultats contenant des erreurs, il faut donc trouver le modèle apportant le moins d’erreurs pour notre cas d’usage. Insanely Fast Whisper est un modèle open source très rapide et performant qui parait convenir parfaitement à notre cas d’usage, il est adapté du très connu Whisper d’Open AI.

Illustration de l’agent de transcriptionIl faut maintenant le comparer aux différents modèles propriétaires, j’ai donc regroupé un ensemble d’audios regroupant nos cas d’usages les plus fréquents, des audios de réunions, d’entretiens d’embauches et de conversations. En écrivant la transcription exacte moi-même pour chacun des audios, je pourrai ensuite comparer les résultats des modèles à ce résultat théorique.

Exemples de fichiers audio utilisés pour le benchmark, accompagnés de leur transcriptionLes métriques utilisées pour mesurer la performance des différents modèles sont les suivants:

WER** :** (Word Error Rate) ou taux d’erreur de mots en Français. Il indique le taux de mots incorrectement reconnus par rapport à un texte de référence, c’est un outil classique pour mesurer l’efficacité d’un système de reconnaissance de la parole. Taux d’erreur de mots en fonction des modèles BLEU** :** est une métrique qui compare la sortie d’un modèle à un ou plusieurs textes de référence, généralement des traductions humaines ou des résumés. Il mesure la similitude de la sortie du modèle avec les textes de référence en termes de précision de n-gramme, c’est-à-dire la proportion de n-grammes correspondants (Séquences de n mots) entre le texte de sortie et le texte de référence. Scores BLEU en fonction des modèles **RTF (Vitesse) : **Un indicateur souvent utilisé pour mesurer la rapidité d’un processus est le RTF (Real-Time Factor), dans notre cas il représente la rapidité avec laquelle un modèle peut traiter un fichier audio. Nous avons un fichier de 10 minutes pour étalonner les différents modèles. Vitesse de traitement en fonction des modèlesLes résultats sur les images ci-dessus correspondent aux métriques moyennes calculées sur l’ensemble de nos fichiers audios de test. Bien qu’Insanely Fast Whisper ne soit pas le meilleur en termes de WER, son score de 0,0617 reste compétitif, surtout face à Deepgram Nova3, un modèle propriétaire qui performe bien moins. Il affiche aussi des scores BLEU très compétitifs, rivalisant avec Gladia Whisper-Zero et se rapprochant d’AssemblyAI Universal, tout en surpassant nettement Deepgram Nova3. Ses scores élevés (par exemple, BLEU-1 à 0,92 et BLEU-4 à 0,86) témoignent de sa capacité à produire des transcriptions de haute qualité, proches des références humaines.

Cela est particulièrement impressionnant pour un modèle open-source, qui offre une flexibilité et une transparence que les modèles propriétaires comme Deepgram Nova3 ne peuvent égaler. Enfin, sa vitesse est le point le plus impressionant, en effet en supprimant l’interface inhérente aux différents modèles propriétaires, on réduit le temps de traitement.

Évaluation des modèles de language (LLM)

Nous avons déployé une dizaine de modèles open-source comme Mistral 7B et LLaMA 70B via Ollama. Il nous fallait ensuite définir des métriques claires qui nous permettent de déterminer quel modèle (propriétaire ou open source) était le plus adapté à la tâche. J’ai donc conçu un benchmark spécifique correspondant à notre cas d’usage : la génération de comptes-rendus de réunions, principalement en français.

Illustration de l’agent en charge du résuméCe benchmark évalue les modèles sur des tests de raisonnement, de synthèse et de génération de texte.** **Les évaluateurs étaient un petit modèle spécialisé dans l’analyse grammaticale et syntaxique, CamemBERT, ainsi que moi-même. Passons aux résultats de ces tests:

Capacité à comprendre et produire du Français en fonction des modèlesComme on pouvait s’y attendre, les modèles propriétaires sont très hauts dans le classement. Cependant, le modèle Phi 4 de Microsoft ainsi que les modèles LLaMA 3.3 et 3.2 offrent des résultats plus que satisfaisants. On notera tout de même que parfois **Phi 4 **hallucine des réponses en anglais, ce qui est très important et à prendre en compte pour notre décision finale.

Temps de réponse en fonction des modèlesLe second critére très important est la rapidité de réponse, on observe que certains modèles offrent des temps de réponse impressionants en dessous des 2 secondes. Quant à **LLaMA 3.3 **et ses 70 milliards de paramètres, malgré ses excellents résultats pour générer du texte on réalise ici qu’il est un peu trop gros pour notre petite L40S et que son temps de réponse est bien trop long pour notre cas d’usage.

Capacité à générer des comptes-rendus en Français en fonction des modèlesEnfin, le dernier critère pris en compte est la pertinence des résumés produits. Le schéma ci-dessus est une somme pondérée de tous les critères précédents sur les résultats des différents tests. LLaMA 3.2 et ses 3 milliards de paramètres seulement semble correspondre parfaitement à notre cas d’usage tout en ayant des performances supériences ou égales aux modèles propriétaires. Ce modèle, en plus d’avoir des performances plus que satisfaisantes, nous offre tous les avantages de l’auto-hébergement, ce qui en fait un modèle de choix pour notre cas d’usage.

Conclusion

En conclusion, Autoscribe démontre qu’il est possible de combiner la puissance de l’IA moderne avec la maîtrise totale de ses données grâce à l’auto-hébergement. Nos tests sur une instance Scaleway L40S, utilisant des modèles open-source comme Insanely Fast Whisper pour la transcription et LLaMA 3.2 pour la génération de comptes-rendus, ont révélé des performances compétitives face aux solutions propriétaires, tout en offrant une flexibilité et une souveraineté inégalées. Pour les entreprises cherchant à allier innovation et confidentialité, Autoscribe représente une solution prometteuse, adaptable et prête à évoluer avec les besoins futurs.

#IA #Autoscribe #AgentOrchestration #STT #LLM #Souveraineté #DigitalWorkplace #OpenSource #Scaleway #Steamulo #Innovation

Vos réunions Automatisées et vos données Sécurisées avec Autoscribe was originally published in STEAMULO Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

✨ Retour sur AI-Pulse : Jeudi dernier nous avons pu participer au salon IA Pulse, où nous avons eu l’opportunité de présenter notre dernière innovation : Autoscribe !

🎯 La semaine dernière, nous avons bouclé notre tournée des forums étudiants :

📍 UTT 📍 UTC 📍 ECE

Merci à tous les étudiants qui sont venus échanger avec nous ! #ForumUTT #ForumUTC #ForumECE #Rencontre #OpportunitésCarrière #Technologie #FutursTalents #Informatique

Octobre rose 🎀

La lutte contre le cancer du sein nous concerne tous !

C’est la rentrée les goodies sont arrivés chez Steamulo ! 💼✨

🚨 Cybersécurité : une urgence nationale ! 🚨

Les cyberattaques explosent : +255% en France, 43% touchent des PME, et 95% sont dues à des erreurs humaines.

💡 Rejoignez-nous le 19 novembre 2024 à Paris pour un événement exclusif sur la directive NIS2 et ses impacts sur la cybersécurité. Avec les experts de @cybervadis_, @ovhcom, @orange, OGO security et Bastion Technologies.

📅 Lieu : 14 rue Auber, Paris 9 ⏰ Heure : 17h45-19h10 🍸 Cocktail networking à la fin !

#CyberSécurité #NIS2 #PME #Evenement #TechParis