L'Essor de Kubernetes dans l'Infogérance Moderne
Introduction
L'infogérance est le coeur de métier de WizOps. Et Kubernetes est devenu l'outil central de cette activité. Chez nos clients Défense (KNDS), e-santé (Okeiro), fintech (Earny SA), mobilité (Padam Mobility) ou certification ISO (Bloomflow), K8s standardise la manière dont on gère les applications en production. En 15 ans, j'ai vu l'infogérance passer de la gestion de serveurs physiques à l'orchestration de workloads déclaratifs. Voici comment cette transformation s'est concrétisée dans mes missions.
De l'infogérance classique au Kubernetes-first
L'infogérance classique, c'était gérer des serveurs : installer des packages, configurer des services, appliquer des patches de sécurité, surveiller les disques qui se remplissent, redémarrer les services qui plantent. Chez Epiconcept, j'ai fait exactement ça pendant 4 ans avec Ansible sur 200+ serveurs pour l'INSERM et les Armées. C'était efficace, mais chaque serveur était un flocon de neige : malgré l'idempotence d'Ansible, les serveurs accumulaient de la dette technique au fil du temps.
L'infogérance moderne avec Kubernetes change le paradigme. On ne gère plus des serveurs, on gère des workloads déclaratifs. Le serveur (le noeud K8s) devient une ressource interchangeable, un commodity. Chez Bloomflow, quand un noeud avait un problème (disque qui ralentit, kernel panic, processus zombie), on le drainait (kubectl drain) et le remplaçait en 10 minutes via Terraform, sans impact utilisateur. Les pods migraient automatiquement vers d'autres noeuds. Essayez de faire ça avec des serveurs traditionnels : c'est des heures de migration manuelle avec des risques d'oubli. L'infogérance passe de la gestion réactive de serveurs à l'orchestration proactive de workloads.
Multi-provider : le dénominateur commun pour l'indépendance cloud
Chez WizOps, je propose de l'infogérance sur tous les providers cloud majeurs : AWS, GCP, Azure, Scaleway, OVH, Outscale. Kubernetes est le dénominateur commun qui rend cette polyvalence possible. Les Helm Charts sont les mêmes quel que soit le provider, seules les values changent (type de storage, classe d'ingress, configuration DNS). Un déploiement sur EKS AWS et un déploiement sur GKE GCP utilisent les mêmes manifestes Kubernetes, la même logique ArgoCD, les mêmes alertes Prometheus.
Chez Bloomflow, cette portabilité multi-cloud a été décisive lors d'un appel d'offres DGE (Direction Générale des Entreprises) qui exigeait un hébergement SecNumCloud. En 2 jours, l'application qui tournait sur AWS a été déployée sur Outscale (le seul provider SecNumCloud à l'époque avec 3DS Outscale) sans modifier une seule ligne de code applicatif. Seuls les modules Terraform pour l'infrastructure et les values Helm pour le stockage ont été adaptés. Chez Earny SA, la migration GCP vers AWS s'est faite avec le même principe : l'applicatif Kubernetes est resté identique, seule l'infrastructure Terraform sous le cluster a changé. Cette indépendance cloud est un argument commercial majeur pour les clients qui ne veulent pas de vendor lock-in.
L'infogérance automatisée : superviser plutôt qu'intervenir
L'automatisation est le levier de productivité numéro un en infogérance Kubernetes. Chez KNDS, le cluster Kubernetes OVH Cloud fonctionnait en quasi-autonomie grâce à un ensemble d'opérateurs qui géraient chaque aspect : ArgoCD pour les déploiements (toute modification dans Git était automatiquement synchronisée), Prometheus + Alertmanager pour le monitoring et les alertes (notifiées sur Discord avec le contexte complet), External Secrets Operator pour la synchronisation automatique des secrets depuis OKMS, et cert-manager pour le renouvellement automatique des certificats TLS.
Mon rôle en tant qu'infogérant n'était plus d'intervenir manuellement à chaque changement, mais de superviser, optimiser et anticiper. Je revoyais les dashboards Grafana chaque matin pour détecter les tendances (utilisation mémoire croissante, latence qui dérive), j'optimisais les requests/limits des pods trimestriellement, et je planifiais les montées de version Kubernetes en staging avant la prod. Le temps d'intervention moyen a chuté de 10 heures par semaine (infogérance classique Ansible) à 3 heures par semaine (infogérance Kubernetes automatisée).
L'observabilité comme fondation de l'infogérance
L'infogérance Kubernetes sans observabilité, c'est conduire de nuit sans phares. Chez Metronome, j'ai déployé la stack complète Grafana + Prometheus + Loki sur le cluster Kubernetes OVH via des Helm Charts Terraform. Chaque microservice avait son dashboard Grafana pré-configuré : latence des requêtes (P50, P95, P99), taux d'erreur HTTP, utilisation CPU/mémoire, et nombre de replicas. Les alertes Prometheus notifiaient l'équipe quand un service dépassait ses seuils de latence ou quand le taux d'erreur 5xx dépassait 1%.
Chez Bloomflow, OpenTelemetry ajoutait la dimension du tracing distribué : suivre une requête à travers 30 microservices pour identifier le service responsable d'une latence anormale. Sans le tracing, diagnostiquer un problème de performance dans une architecture microservices est une recherche à l'aveugle. Chez Cardiologs sur Azure, Datadog remplissait ce rôle avec ses intégrations AKS natives. L'observabilité n'est pas un bonus ou un nice-to-have : c'est le coeur de l'infogérance moderne, car on ne peut pas gérer ce qu'on ne peut pas voir.
La sécurité adaptée au contexte réglementaire
Chaque contexte réglementaire a ses exigences spécifiques en matière de sécurité Kubernetes, et l'infogérance doit s'y adapter. Chez KNDS (Défense), j'ai implémenté un dispositif complet : RBAC strict (chaque équipe n'a accès qu'à son namespace), NetworkPolicies (isolation réseau entre les services, chaque pod ne communique qu'avec les services autorisés), profils seccomp (limitation des appels système autorisés pour chaque conteneur), External Secrets Operator connecté à OKMS (pas de secret en clair nulle part), et scan Trivy de chaque image dans la CI.
Chez Bloomflow (ISO 27001), le dispositif incluait en plus le signing d'images avec Cosign et des admission controllers Kubernetes qui rejetaient les images non signées ou les images avec des CVE critiques non corrigées. Chez Coopengo (HDS -- Hébergement de Données de Santé), le cluster AWS était configuré avec les contrôles de conformité santé : chiffrement au repos des volumes EBS, logs d'audit CloudTrail activés, accès réseau restreint aux IPs autorisées. La force de Kubernetes dans ces contextes : la sécurité est déclarative et versionnable, pas un ensemble de scripts ad-hoc.
Conclusion
L'essor de Kubernetes dans l'infogérance est une évolution logique et irréversible. K8s standardise les pratiques quelle que soit l'industrie, automatise les opérations pour réduire la charge d'intervention de 70%, et offre une portabilité multi-cloud qui libère les clients du vendor lock-in. Chez WizOps, Kubernetes est au centre de notre offre d'infogérance et d'accompagnement. Les entreprises qui l'adoptent gagnent en fiabilité, en sécurité et en agilité. C'est le standard de l'industrie, validé sur le terrain dans des contextes aussi exigeants que la défense et la santé.