Mohamed Nejib Zayèt

Contexte de mission: Intervention sur le programme Orange Federated Connectivity (OFC) à double périmètre : • Architecture Cloud Azure : conception et implémentation de l'intégration réseau entre Azure, l'on-premise Orange et les filiales du groupe • Platform Engineering Kubernetes (GKE) : sécurisation et industrialisation de la plateforme hébergeant les applications du programme OFC Volet 1 — Architecture Cloud Azure : Orange Federated Connectivity (OFC) Contexte : conception du volet Azure de l'architecture OFC, avec exigences fortes sur la gouvernance d'adressage, l'isolation des flux et l'efficacité du routage hybride. Contraintes d'architecture majeures • Adressage propriétaire OFC (RFC 1918) avec NAT systématique sur tous les flux entrants/sortants des filiales • VPN dédié par filiale en double tunnel S2S (haute disponibilité) • Routage inter-filiales optimisé : les flux Azure ↔ Azure ne doivent pas transiter par l'on-premise Réalisations • Conception et implémentation Terraform de l'architecture OFC (Virtual WAN, Hub, VNet, VPN Gateway S2S). • Optimisation du routage inter-filiales via routing intent Virtual WAN et filtrage hub-to-hub, éliminant le trombone réseau • Solution de NAT bidirectionnelle après identification des limites d'Azure Firewall : ◦ SNAT sortant via VMs Linux + iptables ◦ DNAT entrant via Private Link Service, Private Endpoints et Load Balancer interne • POC validant l'ensemble des choix d'architecture sur les contraintes critiques • Automatisation des tests de validation : Développement d’un module Terraform réutilisable de validation automatisée de connectivité filiale : déploiement de VMs de test, exécution de contrôles réseau et restitution automatisée des résultats. • Documentation d'architecture et formalisation des arbitrages techniques • Interactions avec les architects réseau Microsoft sur les arbitrages et la remontée des blocages • Cadrage avec le futur intégrateur cible : compatibilité de l'architecture blue et disponibilité des services Azure dans leurs futures régions Volet 2 — Platform Engineering Kubernetes (GKE) Contexte : plateforme GKE hébergeant les applications du programme OFC. Issue d'un prototype AWS migré sur GCP, présentait à mon arrivée des lacunes en qualité de packaging, automatisation et hardening. Initiative : proposition et défense d'une feuille de route structurée — au-delà de mon scope Azure initial — pour aligner la plateforme GKE sur les standards Kubernetes attendus pour des applications critiques. Réalisations • Migration Kustomize → Helm avec bonnes pratiques (valeurs paramétrables, templates structurés, hooks) • Rédaction de tests pour les charts Helm • Pipelines CI/CD GitLab pour la livraison des conteneurs Docker, intégration scanners de sécurité (Trivy) • Pipelines de déploiement dédiés aux charts Helm • Hardening des clusters GKE • Network Policies pour cloisonner les communications inter-applications • Intégration HashiCorp Vault + ESO pour la gestion des secrets, en remplacement des random_string Terraform — séparation IaC / gestion des secrets • Évaluation technique des candidats : conduite des entretiens (nouveaux profils et remplaçants), compte-rendu d'évaluation au client Stack technique Cloud & Networking : Azure (Virtual WAN, Hub, VNet, VPN Gateway S2S, Private Link, Load Balancer, Firewall), GCP (GKE) Kubernetes : Helm, Kustomize, Network Policies, ESO IaC & CI/CD : Terraform, GitLab CI Sécurité : Vault, Trivy, hardening Kubernetes, VMs Linux + iptables (SNAT custom)

Contexte de mission: Plateforme nationale française de valorisation des données de santé, mettant à disposition des chercheurs un environnement sécurisé pour l'analyse de données médicales anonymisées. Caractéristiques: • Plateforme manipulant des données de santé sensibles, contraintes de sécurité élevées. • Environnement totalement air-gap. • Plusieurs centaines d'environnements de production gérés via une architecture Terragrunt multi-niveaux. Positionnement : équipe build de 4-5 personnes, conception et industrialisation des solutions livrées à l'équipe d'exploitation de production. Industrialisation et factorisation des configurations Terragrunt: • Contexte : la configuration reposait sur 2 niveaux d'héritage (global + par environnement). Les environnements étaient répartis en 4 typologies sans niveau intermédiaire dédié,toute modification commune à une typologie nécessitait l'édition manuelle de plusieurs dizaines d'environnements. • Réalisation : conception et implémentation d'un niveau d'héritage intermédiaire par typologie, refonte de l'ordre de précédence Terragrunt, adaptation des configurations existantes. • Impact : élimination des modifications manuelles répétitives, réduction des risques d'incohérence inter-environnements, accélération des évolutions de configuration. • Sécurisation des upgrades AKS via détection des APIs dépréciées. Contexte : les upgrades AKS révélaient régulièrement des incompatibilités liées à des APIs dépréciées dans les Helm charts internes, détectées tardivement. Réalisation : intégration de Pluto en CI/CD pour détecter les ressources utilisant des APIs dépréciées, configuration de la cible Kubernetes en amont des versions AKS futures, accompagnement des équipes pour corriger les charts. • Impact : détection des incompatibilités au build, upgrades AKS dérisqués, capitalisation pour les futures montées de version. Migration Terraform 1.0 → 1.8 : • Contexte : la plateforme utilisait Terraform 1.0, accumulant de la dette technique. Le bloc moved (refactoring sans destruction) manquait notamment. • Réalisation : montée de version progressive vers Terraform 1.8.3, traitement des incompatibilités, exploitation du bloc moved dans les refactorings (notamment factorisation Terragrunt). • Impact : résorption de la dette technique IaC, déblocage des refactorings d'infrastructure sans interruption. Migration de l'authentification GitLab → Keycloak: • Contexte : l'authentification des chercheurs (Jupyter, RStudio) reposait sur GitLab utilisé uniquement comme IDP. Deux limites majeures : UX : double authentification (VDI puis GitLab) avant accès aux outils FinOps : GitLab requiert une base managée, facturée sur chaque environnement et coût multiplié à l'échelle de la plateforme. • Réalisation: • Conception de l'architecture Keycloak comme ID Provider unique de la plateforme • Création des identités, rôles et politiques d'accès Keycloak • Import Helm Chart et images Keycloak dans la registry interne (contrainte air-gap) • Automatisation de bout en bout de l'authentification Jupyter et RStudio • Flux de transition sécurisé pour migration des secrets sans interruption • Adaptation de la Helm Chart ESO pour création automatique des secrets dans un namespace dédié, synchronisation vers KeyVault • Déploiement GitLab conditionnel (paramètre Terragrunt) pour suppression progressive et réversible par environnement • Impact: • Suppression complète de GitLab et des bases PostgreSQL managées sur les environnements concernés → réduction de coûts récurrents significative • Authentification unifiée (SSO réel) pour les utilisateurs • Architecture d'authentification découplée du gestionnaire de code Modernisation et conteneurisation du Catalogue de métadonnées (open source européen): • Contexte : projet européen permettant aux établissements de santé de remonter leurs métadonnées vers un référentiel commun. L’équipe build de la plateforme HDH a été sollicitée pour accompagner l’industrialisation Kubernetes d’un projet distinct porté par la même structure. • État initial : application sur VM en Docker Compose, build manuel, bind mounts hérités du développement local (volumes pour code et configuration d'une API stateless), aucune chaîne CI/CD. • Réalisation: • Audit et nettoyage Docker Compose : suppression des bind mounts inutiles pour services stateless, élimination des volumes de configuration (incompatibles avec une approche Kubernetes native via ConfigMaps), rationalisation des commandes de démarrage • Chaîne CI/CD GitLab : build, versioning et push automatisés des images vers la registry • Helm Chart cloud-agnostique destinée à la publication open source (templates paramétrables, valeurs documentées, environnement local développeur) • Documentation d'installation dev et production • Déploiement V1 sur Scaleway : validation réelle du caractère cloud-agnostique Impact • Projet publiable en open source selon les standards européens • Cycle de livraison automatisé et reproductible • Portabilité démontrée par déploiement sur un cloud différent Autres réalisations transverses • Déploiement de Gitea via Terraform/Terragrunt pour les besoins internes • Reconception d'un chantier structurant : analyse critique d'une demande de fonctionnalité dont l'implémentation initiale présentait un coût de validation et de test élevé. Proposition et défense d'une approche alternative validée par l'équipe et l'instance de pilotage, gain estimé d'environ un mois de charge • Rôles RBAC restreints pour permettre à Jupyter d'exécuter des scripts maison de vérification sur les Storage Accounts, dans le principe du moindre privilège • Participation aux réflexions stratégiques GitOps pour la plateforme Contribution à la qualité de la plateforme et à la dynamique d'équipe • Accompagnement des nouveaux arrivants sur leurs premières contributions, dans un contexte de plateforme à forte complexité (multi-environnements, air-gap, stack étendue) • Gestion de la dette technique : identification, formalisation et création de tickets structurés dans le backlog • Proposition FinOps sur les environnements éphémères : conception d'un mécanisme liant le cycle de vie des environnements de test au cycle de vie des tickets et merge requests pour identifier et nettoyer les ressources orphelines • Debug d'incidents transverses : résolution d'un blocage critique sur les agents CI/CD ayant impacté l'ensemble de l'équipe Stack technique: Azure (AKS, KeyVault, Storage), Kubernetes, Helm, Terraform, Terragrunt, GitLab CI, Keycloak, External Secrets Operator (ESO), Pluto, Trivy, Docker, Docker Compose, Gitea, Scaleway

Contexte de mission: ChamberSign : autorité de certification française et tiers de confiance délivrant des identités numériques et certificats électroniques (signature, scellement, authentification) pour les entreprises, collectivités et organisations publiques. Mission : référent Cloud Azure & DevOps sur deux projets en parallèle : • Viseo 3 — plateforme de gestion et délivrance des certificats électroniques ChamberSign : projet à maturité technique établie, industrialisation des nouveaux chantiers et évolution des standards d'automatisation • Identité Numérique — solution d'identité numérique professionnelle (OpenID Connect, niveau substantiel) : projet greenfield démarré en cours de mission, intervention dès la phase de conception Positionnement : référent transverse Cloud / DevOps sur les deux projets dès le démarrage de la mission. Administrateur Global du tenant Azure, en charge de l'industrialisation des infrastructures, de la gouvernance IAM, de l'automatisation des déploiements (build et production on-premise) et du support aux équipes Dev et Hébergeurs. Industrialisation de l'infrastructure Azure (Infrastructure as Code): • Transformation vers IaC Terraform en remplacement d'une gestion partiellement manuelle • Provisionnement Terraform des 3 environnements Azure : développement, recette, qualification • Couverture Terraform complète : VM, Réseau, Storage Accounts, Azure AD, DNS, ACR, Monitoring, Named Locations • Backend state remote sur Storage Account Azure (cohérence inter-environnements et collaboration multi-utilisateurs) • Automatisation des déploiements applicatifs (deux chaînes complémentaires) Chaîne CI/CD Azure DevOps sur les environnements de build Azure (dev, recette) • Pipelines Azure DevOps pour intégration et déploiement continu sur les environnements de développement et de recette Chaîne de packaging et livraison vers la production on-premise (préprod, prod) • Les environnements de préprod/prod sont hébergés on-premise et opérés par les sysadmins internes. Conception, packaging et livraison de l’outillage de déploiement destiné à ces équipes • Playbooks Ansible d'installation et de déploiement applicatif • Scripts Bash en interface shell interactive : sélection guidée des cibles, paramétrage et contrôles avant exécution en environnement régulé • Documentation détaillée livrée avec les playbooks et scripts • Environnement Qualification Azure utilisée comme plateforme de packaging et validation avant livraison aux sysadmins Migration majeure Keycloak 15 (JBoss) → 17 (Quarkus): • Contexte : rupture technique majeure avec le passage à Quarkus comme runtime, modifiant en profondeur le modèle de déploiement, la configuration et le packaging. • Réalisation : analyse des impacts (configuration, démarrage, persistance, intégration), adaptation des playbooks Ansible et de la CI/CD au nouveau modèle, migration progressive sur les environnements de build puis production. Impact : montée de version structurelle sans rupture de service, capitalisation sur un modèle de déploiement plus moderne. Support transverse et résolution d'incidents: • Administration Global du tenant Azure : gestion des utilisateurs, groupes, rôles et accès — moindre privilège, Named Locations, politiques d'accès conditionnel • Support technique aux équipes développement et hébergeurs sur infrastructure, déploiement et configuration • Diagnostic et résolution d'incidents : support aux sysadmins lors des installations et déploiements préprod/prod, instrumentation et amélioration des playbooks pour faciliter le diagnostic • Cas significatif : sur le projet Identité Numérique, échecs récurrents des playbooks d'installation en préprod/prod. Instrumentation des playbooks Ansible permettant d'identifier des écarts entre la matrice de flux validée en amont et la configuration réelle de l'hébergement, coordination avec l'équipe hébergeur pour alignement et déblocage. Optimisation FinOps • Audit des licences Azure DevOps : identification d'un sur-licensing significatif (utilisateurs sur plan « Basic + Test Plans » sans usage effectif des Test Plans). Reclassification vers Basic → économies récurrentes sur l'ensemble du parc utilisateur. • Analyse FinOps des coûts Azure : leviers d'optimisation identifiés (dimensionnement, ressources sous-utilisées, environnements non éphémères), mise en œuvre des optimisations validées Autres réalisations • Gestion des certificats SSL : renouvellement et diffusion sur l'ensemble des environnements, en cohérence avec les exigences ChamberSign sur le cycle de vie des certificats • Documentation et capitalisation : Wiki Azure DevOps (guides d'installation, procédures de déploiement, documentation d'architecture) Stack technique: Cloud : Microsoft Azure (VM, Réseau, Storage Accounts, Azure AD, DNS, ACR, Monitoring, Named Locations, Azure DevOps) IaC & automatisation : Terraform (backend state remote sur Storage Account), Ansible, Bash, scripts Shell CI/CD : Azure DevOps Pipelines Conteneurisation & runtime : Docker, Docker Compose, Apache, Nginx Authentification : Keycloak (15 → 17, JBoss → Quarkus) Gestion de code & doc : Git, Wiki Azure DevOps

Contexte : audit de l'environnement de déploiement AWS d'Inovshop (retail tech, solutions in-store digitales) au sein d'une équipe de 3 experts DevOps & Cloud, suivi de la conduite des transformations identifiées. Problématiques majeures à l'arrivée : sur-facturation due au sous-dimensionnement, absence d'automatisation des livraisons, pas de monitoring, fort couplage à l'écosystème AWS. Réalisations clés: • Migration de l'écosystème vers Kubernetes (EKS) : conteneurisation des applications, conception d'une infrastructure Kubernetes prête pour le développement. • Mise en place des chaînes CI/CD GitLab CI : build, versioning, déploiement des conteneurs avec contrôle de sécurité (Trivy). • Solution de centralisation logs & monitoring (EFK : Elasticsearch, Fluentd, Kibana). • Découplage de l'infrastructure : migration future vers d'autres clouds rendue possible. Impact: • Réduction de ~33 % de la facture AWS • Infrastructure portable, découplée de l'écosystème cloud d'origine Stack technique: AWS, Kubernetes (EKS), Docker, GitLab CI, Trivy, EFK (Elasticsearch, Fluentd, Kibana), Linux, Nginx, Bash

Contexte : conteneurisation et industrialisation des chaînes de déploiement de plusieurs microservices Angular / Spring Boot. Réalisations clés: • Conteneurisation des applications et conception de Dockerfiles optimisés (logs externalisés, réduction du temps de démarrage) • Mise en place des pipelines CI/CD GitLab CI pour l'ensemble des microservices • Externalisation des configurations pour rendre les conteneurs agnostiques de l'environnement, en collaboration avec l'équipe développement Stack technique Linux (Ubuntu), Docker, Docker Compose, GitLab CI, Python, Java, JavaScript