L'infrastructure Kubernetes d'un grand groupe immobilier français hébergeait l'ensemble du portefeuille d'applications digitales : le PIM Akeneo pour la gestion des données produits, le pipeline de traitement batch Export Ligneurs, l'ensemble des sites web corporate (identifiés sous le nom PWR - Pichet Web Resources), l'Intranet du groupe, l'API partenaires leads PSR, la Tyk API Gateway, et divers microservices dont une plateforme IoT de logement connecté. Le projet a couvert deux phases majeures : des clusters Kubernetes on-premise gérés par Claranet (ex-Oxalide) de 2019 a 2021, suivis d'une migration complète vers AWS EKS (Elastic Kubernetes Service) sur la région eu-west-3 de 2022 a 2024.

• Assurer la haute disponibilité de toutes les applications critiques (sites web, PIM, API) avec zero indisponibilité non planifiée en heures ouvrables
• Industrialiser les déploiements via GitLab CI + Helm, réduisant le temps de déploiement de heures a minutes
• Migrer vers AWS EKS pour une meilleure scalabilité, résilience et les bénéfices du Kubernetes géré
• Superviser proactivement les ressources (CPU, mémoire, disque, certificats SSL) pour prévenir les incidents
• Gérer les accès sécurisés via bastions SSH, tunnels VPN et gestion de certificats

L'ensemble de la présence digitale de l'organisation dépendait de cette infrastructure. Avec plus de 5 sites commerciaux servant des milliers de visiteurs quotidiens, un système PIM alimentant les données produits sur tous les canaux et des traitements batch synchronisant les données avec les partenaires externes, les enjeux étaient considérables. L'équipe infrastructure opérait en modèle d'hébergement géré avec Claranet, nécessitant une coordination étroite entre les équipes de développement internes et les ingénieurs d'exploitation externes.

La gestion de l'infrastructure nécessitait une coordination constante entre l'équipe de développement interne du Groupe Pichet et l'équipe d'hébergement géré chez Claranet (ex-Oxalide). En tant que consommateur principal de la plateforme Kubernetes (PIM, Export Ligneurs) et superviseur des déploiements, je servais de pont entre les besoins du développement et les opérations d'infrastructure, recevant toutes les alertes de monitoring et participant directement à la résolution des incidents.

• Expertise approfondie des opérations Kubernetes : gestion du cycle de vie des pods, limites de ressources, horizontal pod autoscaling, persistent volume claims et ingress controllers
• Compétences pratiques AWS : gestion de clusters EKS, configuration S3, politiques IAM, NLB load balancers et architecture de bastions
• Maturité en gestion d'incidents : développement d'approches systématiques pour le tri, l'escalade et la résolution d'incidents d'infrastructure sous pression
• Conception de pipelines CI/CD : automatisation des déploiements GitLab CI + Helm Charts, configurations spécifiques par environnement et garde-fous de déploiement
• Évolution de développeur vers superviseur d'infrastructure : ce projet a fondamentalement changé ma compréhension du cycle de vie complet de livraison logicielle

Après la stabilisation complète de la migration AWS EKS, l'infrastructure est entrée dans une phase opérationnelle mature. Le setup de monitoring avec Centreon et New Relic fournissait des alertes proactives, et le pipeline de déploiement basé sur Helm permettait aux équipes de déployer avec confiance. La gestion des accès bastions, bien qu'initialement difficile (ISS-423267 est resté ouvert pendant des mois), a finalement fourni un chemin d'accès sécurisé et auditable aux systèmes de production.

La plateforme Kubernetes a continué de fonctionner après mon départ du groupe en mars 2024. Les décisions architecturales prises lors de la mise en place initiale - Helm charts standardisés, cert-manager automatisé pour SSL/TLS, séparation claire des namespaces entre environnements - se sont révélées durables et ont permis à l'infrastructure de monter en charge avec les besoins digitaux croissants de l'organisation. La migration de l'on-premise vers AWS EKS a validé la stratégie cloud-first et posé les bases pour de futures initiatives cloud-native.

Aujourd'hui, les principes d'infrastructure établis pendant ce projet - conteneurisation, orchestration, déploiements automatisés, monitoring proactif - sont des standards de l'industrie. L'expérience de gestion d'un cycle de vie d'infrastructure sur 5 ans, de la mise en place initiale jusqu'à une migration cloud majeure, apporte une perspective unique sur les implications à long terme des décisions d'infrastructure. Les leçons apprises nourrissent directement mon approche actuelle de l'infrastructure-as-code et de l'architecture cloud.

• L'industrialisation GitLab CI + Helm a été un franc succès. Les pipelines de déploiement standardisés sur toutes les applications ont apporté consistance et fiabilité, réduisant drastiquement les incidents liés aux déploiements après la période de mise en place initiale.
• La stratégie de double cluster (preprod + prod) avec séparation claire des environnements a prévenu de nombreux problèmes potentiels en production. L'incident où la config de prod a été déployée en preprod (SRQ0389097) a en fait renforcé l'importance des garde-fous d'environnement.
• Le monitoring proactif avec Centreon + New Relic a détecté de nombreux problèmes avant qu'ils n'impactent les utilisateurs finaux, transformant la gestion d'infrastructure d'une lutte réactive contre les incendies en prévention proactive.

• La planification des ressources pendant la Phase 1 était insuffisante. La crise de Jul-Oct 2019 avec des alertes récurrentes de mémoire/charge/swap des noeuds aurait pu être évitée avec une meilleure planification de capacité et des requests/limits de ressources sur les pods.
• La gestion des accès bastions (ISS-423267) a traine trop longtemps. Un processus de gestion des accès plus structuré avec des clés SSH pré-provisionnées et une rotation automatisée aurait épargné un overhead de coordination significatif.
• La documentation des décisions d'infrastructure et des runbooks était inconsistante. Créer des runbooks exhaustifs pour les patterns d'incidents courants plus tôt aurait accéléré l'onboarding et réduit les temps de résolution.

Avec le recul, j'aurais poussé pour la migration AWS EKS plus tôt. La phase on-premise, bien qu'educative, a consommé un effort opérationnel significatif que le Kubernetes géré aurait éliminé. J'aurais aussi mis en place des pratiques GitOps (ArgoCD ou Flux) dès le départ, et établi l'infrastructure-as-code avec Terraform pour toutes les ressources cloud plutôt que de dépendre de demandes manuelles à Claranet. Enfin, j'aurais investi davantage dans les tests automatisés des Helm charts et manifestes Kubernetes avant le déploiement, détectant les erreurs de configuration en CI plutôt qu'en production.

• L'infrastructure n'est jamais "terminée" - elle nécessite une attention continue, du monitoring et de l'évolution. Le cycle de vie de 5 ans m'a appris que les décisions architecturales initiales ont des effets composés au fil du temps.
• Le modèle d'hébergement géré (Claranet) a des avantages (expertise, support 24/7) et des limites (dépendance, itération plus lente). Comprendre où tracer la ligne entre géré et autogéré est une compétence critique.
• La gestion d'incidents est une compétence qui ne se développe qu'avec la pratique réelle. La pression des incidents en production avec impact business m'a appris la composure, la pensée systématique et la communication claire sous stress.