Christophe Delattre

déc. 2025 – Présent · Munich, Allemagne

Pilotage de l’évolution du framework d’automatisation réseau AUD (Amadeus Unified Descriptor) — que j’ai initialement conçu et développé — vers un produit open source générique : réarchitecture de son modèle pour couvrir tout cas d’usage au-delà des besoins internes, tout en maîtrisant la sécurité et la gouvernance.

• Refonte du modèle de données et de l’architecture d’AUD pour les rendre génériques et indépendants du cas d’usage, afin de couvrir tout scénario de conception réseau et non plus seulement les besoins d’Amadeus.
• Conduite de la collecte des besoins à l’échelle de l’organisation et validation du nouveau modèle au regard de ces besoins.
• Planification du projet pour aligner l’orientation open source avec les exigences internes, la sécurité et la gouvernance.
• Proposition de plusieurs options d’architecture et de conception, et mise à disposition d’un outillage graphique pour aider à concevoir des réseaux avec le nouveau modèle.
• Rédaction du high-level design et des spécifications détaillées, et démarrage de l’implémentation, avec une CI sur GitHub et GitHub Actions.
• Choix de PostgreSQL comme backend et définition de ses procédures opérationnelles, de ses SLI, SLO et de son observabilité, appuyés par des études de performance sur les différents cas d’usage.

• PostgreSQL
• GitHub
• GitHub Actions
• SLI/SLO/SLA
• Observability
• System Design
• Open Source
• Governance

janv. 2024 – déc. 2025 · Munich, Allemagne

Pilotage de l’intégration, sous l’angle de la fiabilité, d’un produit hôtelier nouvellement acquis vers les standards d’ingénierie du groupe — migration de son outillage, de ses processus et de sa plateforme afin d’assurer une transition en douceur et une continuité de service sans interruption.

• Définition de SLO volontairement plus exigeants que les SLA contractuels — 99,95 % de disponibilité et 300 ms de temps de réponse, contre 99,9 % et 500 ms — afin de conserver une marge avant que les engagements clients ne soient menacés.
• Introduction des RCA et des post-mortems, jusque-là inexistants, animation personnelle des revues pour donner l’exemple, suivi des correctifs jusqu’à leur clôture et blocage des releases tant qu’ils n’étaient pas livrés, selon la règle « un incident ne doit pas se reproduire ».
• Intégration d’une observabilité de bout en bout — métriques et supervision avec Prometheus, alerting avec Alertmanager et logs centralisés avec Splunk — ramenant la latence des logs de 15 minutes, avec pertes occasionnelles, à un quasi-temps réel afin de rendre l’atteinte des SLO réellement visible.
• Mise en place de pipelines CI/CD avec Jenkins et GitHub Actions pour produire des livraisons cohérentes et reproductibles — faisant passer les releases d’une par mois à une par semaine.
• Standardisation des déploiements en utilisant Helm umbrella charts et ArgoCD (GitOps), et évaluation d’un remplacement du processus historique de promotion logicielle.
• Migration d’une quarantaine de microservices de machines virtuelles vers Kubernetes, répartis sur quatre clusters de production — on-premise et cloud, chacun scindé PCI et non-PCI — plus deux clusters de test, et planification des évolutions majeures de la plateforme, dont la création et la migration de clusters.
• Intégration du produit au processus de gestion des changements du groupe et maintien de la conformité des environnements PCI — application régulière des correctifs de sécurité sur l’infrastructure comme sur les applications, et appui aux équipes de développement sur leurs scans Black Duck et SonarQube et leur reporting sécurité.
• Refonte des contrôles d’accès à la plateforme — plus de visibilité pour les développeurs, plus de contrôle pour les SRE — et mise à disposition d’environnements éphémères en libre-service pour les tests d’intégration des développeurs.
• Définition de la matrice RACI, jusqu’alors inexistante — répartition des responsabilités entre les équipes plateforme, SRE et applicatives — puis accompagnement des équipes issues de l’acquisition, sans pratique SRE préalable, en documentant et en diffusant les standards derrière chaque nouveau processus plutôt qu’en l’imposant.
• Travail au sein d’une équipe de 10 personnes répartie sur trois régions (Amériques, Europe, Asie) avec une astreinte en follow-the-sun par rotation hebdomadaire, et participation au recrutement de deux ingénieurs en Inde.

• SLI/SLO/SLA
• Kubernetes
• Helm
• ArgoCD
• GitOps
• Jenkins
• GitHub Actions
• Prometheus
• Alertmanager
• Zabbix
• Datadog
• Splunk
• CI/CD
• PCI
• SonarQube
• Black Duck

déc. 2019 – déc. 2023 · Munich, Allemagne

Lead technique au sein de l’équipe Network Automation, qui fournit et exploite l’infrastructure réseau de l’ensemble des produits du groupe. J’ai contribué à faire passer l’équipe d’opérations réseau manuelles et lourdes en changements vers un modèle de software-defined networking (SDN) en libre-service, en construisant les frameworks qui permettent aux utilisateurs de déclarer leurs besoins réseau et de faire configurer automatiquement les équipements.

• Lead technique de l’équipe : définition de la direction technique et contribution à sa croissance de 2 à 14 ingénieurs par la participation au recrutement et à la montée en compétence.
• Conception et développement d’AUD à partir d’une page blanche — une structure de données modélisée en OpenAPI et une couche d’orchestration (Azure Functions, cache multi-niveaux) devenue le socle de l’automatisation des firewalls, NSG, OVN et du tableau de bord de sécurité, aujourd’hui utilisée par toutes les équipes d’ingénierie du groupe.
• Passage des changements de firewall d’une configuration manuelle, équipement par équipement, à un processus entièrement automatisé couvrant les différentes couches de sécurité dans le cloud, piloté par l’intention déclarée plutôt que par des règles écrites à la main.
• Réduction du risque lié aux changements en automatisant le processus de gestion des changements des applications AUD (Viewer, API, Orchestrator) via ServiceNow, remplaçant les validations manuelles par des workflows auditables.
• Mise en place de garde-fous de fiabilité sur l’ensemble des services Python du framework : standards de qualité de code, stratégies de test, KPI, supervision et alerting, et gestion des correctifs.
• Rédaction des runbooks opérationnels et des procédures de gestion des incidents et des problèmes, permettant aux équipes d’exploitation d’opérer le framework AUD et de traiter les incidents en autonomie.
• Livraison de l’automatisation DNS (création d’enregistrements) on-premise via Ansible/AWX selon un standard commun, puis transfert à l’équipe DNS sous forme de capacité en libre-service.
• Obtention de la conformité PCI pour le framework et livraison du CCB Approval Viewer, offrant aux comités de revue des changements une visibilité en temps réel sur l’avancement des demandes techniques.

• Terraform
• Ansible
• AWX
• Azure
• Azure Functions
• Jenkins
• Bitbucket
• ServiceNow
• OpenAPI
• Python
• SDN
• PCI

sept. 2017 – déc. 2019 · Munich, Allemagne

Responsable des plateformes et des processus de livraison derrière les produits d’analytique et de machine learning de l’unité Airline Data — en charge du volet infrastructure et fiabilité de la data science, plutôt que de la modélisation.

• Stream owner du cluster DSC (Data Science & Consulting) : architecture, planification de capacité et exploitation, pour une équipe virtuelle de 5 personnes réparties sur 3 équipes.
• Mise en place d’une chaîne CI/CD complète pour le déploiement et la gestion du cycle de vie des clusters (Jenkins, Azure DevOps), avec intégration de la supervision Prometheus et gestion des releases.
• Stream owner de la Data Science Platform (DSP) v1 : définition et automatisation sur OpenStack, orchestration des flux de données incluse.
• Pilotage de l’évaluation et du déploiement des plateformes de notebooks (JupyterHub, Zeppelin), validées sur Kubernetes/OpenShift.
• Industrialisation de la livraison : standardisation des pipelines de livraison et des workflows de développement ; exploitation de clusters Hadoop/AWS EMR pour comparer les performances avec l’on-premise, et réalisation d’un PoC GPU pour la détection d’anomalies de sécurité.

• Kubernetes
• OpenShift
• OpenStack
• Azure DevOps
• AWS EMR
• Hadoop
• CI/CD
• JupyterHub
• Python

mai 2015 – sept. 2017 · Boston, États-Unis & Munich, Allemagne

Responsable de la continuité de service de la plateforme InterContinental Hotels Group — une pile technologique entièrement nouvelle, hébergée dans de nouveaux datacenters, conçue pour respecter des SLA exigeants tout en maîtrisant les coûts de maintenance.

• Garant de la continuité du premier service d’Amadeus vendu avec un SLA de 99,999 % de disponibilité et de 50 ms de temps de réponse — les SLO de l’entreprise ne couvraient pas ce niveau d’exigence : nous en avons donc défini de nouveaux, appuyés par une alerte en quasi-temps réel sur dépassement de SLA.
• Exploitation du parc de production sous-jacent : plus de 20 clusters OpenShift (dont 10 en production, sur 2 régions × 5 zones de disponibilité), 4 clusters Couchbase répliqués via XDCR et 2 clusters Oracle en Data Guard — l’ensemble dimensionné à partir des SLA contractuels, des prévisions de trafic et de l’empreinte des applications.
• Application d’une politique d’error budget dans les premiers temps — deux incidents de production consécutifs bloquaient la release suivante jusqu’à la démonstration d’un cycle sain — puis taux d’échec des changements ramené proche de 0 % grâce à une chaîne de promotion entièrement automatisée sur Jenkins CI, détectant les défaillances en amont.
• Construction d’une infrastructure-as-code de A à Z — Infrastructure-as-a-Service sur OpenStack/VMware, initialisée avec Heat, Terraform, cloud-init, Puppet et Ansible, applications déployées sur Red Hat OpenShift.
• Conception et validation de la supervision et de l’alerting fonctionnels et non fonctionnels : supervision OpenShift et Oracle, supervision functionnelle basée sur SoapUI/Jenkins et installation Nagios entièrement automatisée.
• Mise en place d’une astreinte en follow-the-sun entre Boston, Munich et Sydney (12 ingénieurs, rotation hebdomadaire, toute l’équipe dans la boucle) : un seul incident majeur avec impact client sur la période, tous les autres détectés automatiquement et résolus en moins d’une minute (MTTR), chacun avec RCA, post-mortem et auto-remédiation en attendant le correctif définitif.

• SLI/SLO/SLA
• OpenShift
• OpenStack
• VMware
• Terraform
• Heat
• Puppet
• Ansible
• Jenkins
• Nagios
• Couchbase XDCR
• Oracle Data Guard

avr. 2013 – mai 2015 · Munich, Allemagne

Développeur principal d’une suite d’outils opérationnels aidant les équipes de première ligne à gérer efficacement les incidents et à réduire le temps de restauration des services.

• Réduction du temps de restauration des incidents par des actions automatisées rapides, globales et sécurisées, et refonte de l’architecture pour respecter les SLA — conception Couchbase multi-datacenter avec un front-end léger pour réduire la latence des sites distants (Sydney, Miami).
• Introduction de pratiques de qualité logicielle et de gestion des releases : processus de release reliant versioning et intégration continue, couverture de code, contrôles d’analyse statique, et premiers environnements de test Vagrant/Docker.

• Java (J2EE)
• Couchbase
• Jenkins
• Git
• Docker
• Vagrant

janv. 2011 – avr. 2013 · Sophia-Antipolis, France

Responsable des produits middleware pour le backend du moteur de recherche du portail Orange. Coordination d’une équipe de 3 personnes développant un framework de communication inter-processus multithreadé et une couche de cache multi-datacenter — améliorant la performance, la robustesse et le respect des SLA de temps de réponse.

• ElasticSearch
• Middleware
• Caching
• RDF/XML

janv. 2008 – janv. 2011 · Carros, France

Logiciels embarqués et clients pour des systèmes de supervision et de commande d’éclairage aéroportuaire et public : commande du balisage lumineux d’aérodrome, client de supervision pour la tour de contrôle, et pilotage de bout en bout d’un projet de supervision d’éclairage public pour le client EDF.

• Embedded C/C++
• Rich client
• Monitoring