Migration cloud, platform engineering, sauvetage d'infra.
En mission, courte ou longue.

Contexte

Lancement de l'app à préparer, infra sur AWS EKS.

Problème

Un cluster EKS qui crashait régulièrement (redémarrages intempestifs), à stabiliser avant le lancement. Et aucune visibilité sur ce qui se passait dedans.

Ce qui a été fait

• · Résolution des problèmes de stabilité du cluster
• · Monitoring et alerting : stack VictoriaMetrics + Grafana
• · Charts Helm prod-ready : PDB, HPA, VPA, Anti-Affinity
• · ACM + ALB pour certificats wildcard automatiques

Contexte

Plateforme de gestion d'un tracteur enjambeur de vigne autonome, héritée d'un ancien prestataire.

Problème

Une infra non maîtrisée, dont il ne restait qu'un compte AWS. Impossible de commercialiser le produit dans cet état.

Ce qui a été fait

• · Audit complet DevOps
• · Reverse engineering, documentation, IaC modulaire OpenTofu pour redéployer la plateforme rapidement
• · Cluster de type Scale pour le jumeau numérique, avec environnements de preview

Contexte

60+ services en Docker Compose legacy, infrastructure on-premise.

Problème

La bascule vers Kubernetes on-premise partait en vrille, techniquement et humainement. La stack était surchargée de technos qui font bien sur le papier, mais qui ne correspondaient en rien au niveau de maturité des équipes (des sysadmins habitués à administrer serveur par serveur, avec une maîtrise de Git relative) et n'avaient pas forcément de sens ensemble. L'équipe avait perdu l'envie, blâmait la techno et commençait à se rebeller contre un changement très mal engagé. Il fallait remettre la migration sur les rails, et surtout redonner à l'équipe sysadmin l'envie et les moyens de la porter elle-même.

Ce qui a été fait

• · Énorme ménage dans la stack : tout ce qui n'était pas 100 % utile et facilement apprenable par l'équipe a dégagé
• · Identification de ceux qui pouvaient porter le sujet, et une session de pair avec eux à chaque fois que je touchais quelque chose : Kubernetes et le GitOps se transmettent en faisant, pas en slides
• · Beaucoup de démos, pour challenger les choix et évangéliser en montrant plutôt qu'en affirmant
• · Refonte de quasiment tout, proprement, en pair programming avec leur nouvelle recrue : la confiance se construit en livrant ensemble
• · Tampon avec le responsable infra pour tempérer les objectifs de la direction et retrouver un rythme tenable
• · À chaque dysfonctionnement remonté par les devs : "je m'en occupe personnellement", puis la preuve que c'est fait
• · Cluster k0s multi-master HA + Calico CNI
• · CI/CD Jenkins + Helm charts génériques + SOPS
• · Migration progressive HAProxy/keepalived zero-downtime
• · Formation Kubernetes de 5 sysadmins

Contexte

Une offre Kubernetes mutualisée à destination des projets métiers internes. Mission d'expertise pour fiabiliser la production, accompagner les équipes applicatives et contribuer à la prochaine génération de l'offre.

Problème

Trop de bruit d'alerting, des incidents récurrents traités à la main, et un contrôle d'allocation des ressources qui poussait les applications au throttling.

Ce qui a été fait

• · Refonte de l'alerting et de la réponse à incident (règles, routage, sévérités) : moins de bruit, résolution plus rapide
• · Autoremédiation déclenchée sur alertes Prometheus : les incidents récurrents se résolvent sans intervention humaine
• · Retrait de la "cloche" d'allocation : un script custom bloquait les rolling updates tant que les requests des pods n'étaient pas à 95 % de la consommation réelle. Les projets déclaraient des requests absurdement basses pour passer le contrôle, et tout throttlait. Son retrait a rétabli un dimensionnement sain et débloqué les déploiements
• · Coaching des équipes applicatives : onboarding Kubernetes, bonnes pratiques de déploiement, ateliers Performance et Résilience
• · Dashboards Grafana de qualité production pour la plateforme et les workloads métiers
• · Contribution à la V2 de l'offre : architecture, modèle de service, parcours utilisateur

Contexte

Plateforme de salons B2B avec chat, visioconférence et scan de billets en temps réel.

Problème

Tenir la charge sur plusieurs salons simultanés, y compris pendant les pics.

Ce qui a été fait

• · Load testing intensif micro-services avec right-sizing
• · Chart Helm générique : Anti-Affinity, PDB, HPA, VPA
• · Staging isolé pour répétitions événement
• · Stack monitoring VictoriaMetrics + VMScrape/VMProbe

Contexte

Un LMS musique avec des contenus xAPI lourds : vidéo, audio, fichiers immersifs.

Problème

L'hébergement initial, une serverless function et un VPS, ne tenait pas la charge face à ces contenus lourds. Il fallait une infra souveraine française qui suive, à coûts maîtrisés.

Ce qui a été fait

• · IaC Terraform sur Scaleway Kapsule
• · GitOps ArgoCD + Image Updater
• · Stack monitoring Grafana + VictoriaMetrics
• · HA via PDB, HPA, VPA
• · Secrets et reloads automatisés : External Secrets Operator + Stakater Reloader

Contexte

Initier des élèves de 3ᵉ année à dominante développement à Docker et Kubernetes, en vue d'une utilisation professionnelle. 3 mois, sur site.

Problème

Un public qui vise le développement applicatif, pas l'administration d'infrastructure : il fallait une autonomie d'usage (conteneuriser, comprendre les manifestes, déployer, déboguer) sans la gestion bas-niveau d'une plateforme qu'ils n'opéreront pas.

Ce qui a été fait

• · Module Docker : conteneurs, build d'images, volumes et réseau, Dockerfile, compose multi-services
• · Module Kubernetes : objets fondamentaux (Pods, Deployments, Services, ConfigMaps, Secrets, Ingress), manifestes YAML, déploiement et debug
• · Pédagogie par la pratique : chaque concept immédiatement mis en œuvre sur des exercices concrets
• · Posture orientée développeur : déployer son application, lire un manifeste fourni par l'équipe ops, déboguer un pod qui ne démarre pas