Ingénieur Cloud DevOps Google Cloud au Club Med

Conçu une « project factory » Terraform qui provisionne et câble les dépôts GitLab des équipes — chacun auto-généré avec un socle IaC standard et des accès CI à rotation — pour qu'un non-spécialiste n'ait qu'une configuration minimale à éditer.

socle self-service repris par les équipes data du programme

Initiateur et contributeur principal du dépôt d'infrastructure IAM / landing zone GCP (hiérarchie d'organisation, VPC partagé, gouvernance des accès) : le socle sécurisé sur lequel les équipes data ont construit.

socle cloud commun à l'ensemble des équipes du programme

Conçu et piloté la bascule « double run » zéro-interruption de la BI historique : SAS et SQL tournent en parallèle, comparent volumes et précision et signalent tout écart avant de basculer la vue exposée du legacy vers BigQuery.

bascule des flux BI sans interruption de service

Outillé le double run comme un contrôle de fiabilité de la donnée : assertions Dataform, jeux de test dédiés et comparaison des fichiers de sortie, avec des filtres isolant les corrections de règles métier volontaires des écarts subis — d'abord une passe rapide sur un sous-ensemble partitionné par jour, puis une recette élargie à l'ensemble.

écarts détectés et qualifiés avant bascule, pas après

Intégré la chaîne de données Google Cloud à l'infrastructure on-premise, avec les outils de la maison : GitLab CI teste et déclenche, OpCon ordonnance, Ansible exécute Dataform en ligne de commande sur une machine maîtrisée, OS Login et Wallix tiennent les accès. L'exploitation pilote les chaînes historiques et les nouvelles au même endroit, avec les mêmes procédures, et le code comme le déploiement restent indépendants de la console du fournisseur.

déploiement des transformations indépendant de la console du fournisseur

Porté le projet pilote de standardisation de Dataform pour les équipes data analysts et data engineering : structure et nommage, exemples de tests, patrons de modèles réutilisables, et provisioning du dépôt GitLab, du projet et du jeu de données Google Cloud en plus des droits.

standard Dataform repris par les équipes data après mon départ

Fait des tests Dataform la documentation exécutable des cas limites d'un chantier de migration — valeur absente, montant entre deux arrondis (arrondi au pair le plus proche), date sur la borne de période — en outillant la fixture pour qu'elle se lise comme le cas qu'elle décrit : génération des UNION ALL, valeurs par défaut, alignement des colonnes, et un tri ajouté en sortie de dataset uniquement en contexte de test, faute de quoi la comparaison est un pile ou face.

les règles implicites retrouvées en migration figées en tests qui échouent si elles changent

Séparé dans le modèle ce qui ne bouge plus de ce qui bouge encore : des vues imbriquées réunissent un historique figé et les données récentes, encore corrigeables et bien plus souvent requêtées — une décision de justesse autant que de coût, avec le partitionnement et le clustering qui vont avec.

relectures fréquentes bornées aux données récentes plutôt qu'à tout l'historique

Écrit un parseur Python qui génère la documentation des règles métier depuis le graphe compilé du projet : la règle est décrite au plus près de la requête qui l'applique, dans un commentaire à balisage maison (@clé valeur) renvoyant à la documentation métier de référence, et le Markdown produit est versionné puis publié. La règle cesse d'être enfouie dans le code au moment précis où on la réécrit.

documentation des règles métier générée depuis le code, pas maintenue à côté

Rendu le coût d'une requête visible au moment où elle tourne, et non sur la facture du mois : la CLI Dataform enrichie d'un affichage qui lit le volume lu par action et le multiplie par le tarif à la demande de la région — chaque développeur dispose ainsi d'un indicateur immédiat de partitionnement, de clustering et de jointures, par l'écart entre données lues et données retenues.

le coût de chaque action lisible dans le terminal, avant la facture

Donné à chaque développeur son espace isolé dans un projet BigQuery partagé : un utilitaire dérive un préfixe de son nom d'utilisateur git et génère les trois fichiers de son poste — alias de commande, identifiants, configuration — si bien que deux exécutions simultanées cessent d'écrire dans les mêmes tables, sans un seul paramètre à saisir à la main. Versions de Node et de la CLI épinglées, pour qu'un écart entre postes ne vienne jamais de l'outil.

des exécutions concurrentes sans collision, sans configuration manuelle

Réconcilié deux chaînes de calcul par le hachage de la ligne entière : les deux sources réunies dans une même table avec un discriminant, comptage par hachage, retrait des lignes reproduites à l'identique, et une assertion qui échoue tant qu'il reste un écart — ne survit à ce filtre que ce qu'il faut expliquer à la main, qu'il s'agisse d'une différence de précision, d'arrondi ou de format de date.

l'écart ramené aux seules lignes qui demandent une explication

Contribué au programme data « Road 45 » de Club Med, né de la crise Covid, en bâtissant le socle cloud des 12 domaines data et en migrant la BI historique vers BigQuery.

12 domaines data industrialisés sur Google Cloud

Mis en place une gouvernance des accès entièrement par le code : chaque demande de droit passe par une merge request validée automatiquement en CI avant application — revue, traçabilité et principe de moindre privilège intégrés au flux.

chaque accès tracé et revu via une merge request validée en CI

Au-delà du socle d'accès, mise en place de briques transverses de l'organisation : suivi des coûts (FinOps), sécurité (SecOps) et un catalogue de données à l'échelle de l'entreprise.

briques FinOps, SecOps et data catalog déployées à l'échelle de l'org

Formé la recrue DevOps interne et ma propre relève côté data, avec une passation soignée à mon remplaçant : l'équipe a gagné en autonomie et a continué sans point de rupture après mon départ.

continuité assurée — montée en autonomie de l'équipe puis reprise sans moi

Point de convergence entre les équipes internes de Club Med, deux ESN partenaires (OCTO, Avisia) et des freelances : j'ai fait le lien entre des métiers très différents — data scientists, DBA, réseau, systèmes — autour d'un cadre technique commun.

cadre commun adopté par des équipes de plusieurs organisations

D'un rôle aux contours flous, j'ai bâti une équipe cloud DevOps interne autonome : prendre l'initiative de structurer là où le cadre manquait, plutôt que d'attendre qu'on me le donne.

un périmètre flou transformé en une équipe autonome et durable

Pour rester fiable sans me laisser déborder, j'ai cadencé le temps de l'équipe en créneaux dédiés — un fil rouge, un temps d'écoute des demandes, un créneau quotidien pour les urgences : de la sérénité par l'organisation.

priorités tenues et urgences absorbées sans désorganiser le fond

Accompagner des profils très variés — data scientists, DBA, administrateurs systèmes, jusqu'à une personne proche de la retraite — vers Git, Terraform et le cloud : expliciter les prérequis insoupçonnés et avancer au rythme de chacun.

montée en compétence d'équipes non-dev vers l'infrastructure-as-code

Exposé la donnée avant de migrer le calcul : la vue BigQuery consommée par la BI a d'abord pointé vers un export Cloud Storage des fichiers produits par la chaîne historique, si bien que la bascule s'est réduite à changer la définition de cette vue vers les tables Dataform — le consommateur n'avait rien à refaire.

un seul point de bascule, côté entrepôt, invisible du lecteur

Parti des blueprints Google pour les simplifier en modules maîtrisés et lisibles plutôt que d'empiler des abstractions — priorité constante à ce que les équipes peuvent comprendre et faire évoluer seules.

modules internes repris et maintenus par les équipes