Rémi Le — ingénieur de production

Mes missions

Quatre interventions,
quatre contextes de production.

Décrites comme des post-mortems : le contexte de départ, ce que j'ai fait, ce que ça a changé. Le détail technique est dépliable sous chaque intervention.

Chaîne de livraison continue — BPCE

2025 — aujourd'hui · Banque
Contexte
Environnement bancaire : exigences de traçabilité fortes et parcours de validation stricts entre développement, homologation et production.
Action
Chaîne CI/CD de bout en bout sous Jenkins, orchestration des livraisons avec XL Release et XL Deploy, versionnement sous Git, passage systématique par l'homologation avant toute mise en production.
Résultat
Chaque mise en production est rattachée à une version identifiée et rejouable à l'identique. L'homologation devient un filtre systématique plutôt qu'une étape négociée au cas par cas, et le retour arrière est préparé avant le déploiement, pas improvisé pendant l'incident.
Détail technique

Le découpage sépare ce qui construit de ce qui déploie. Jenkins produit un livrable versionné et l'archive. XL Deploy décrit la cible et sait poser ce livrable sur chaque environnement à partir du même modèle, avec un paramétrage propre à l'environnement et non au livrable. XL Release orchestre l'enchaînement — déploiement en homologation, validation métier, fenêtre de production, contrôles post-déploiement — et conserve la trace de qui a validé quoi et quand, exigence structurante en contexte bancaire.

Le point qui demande le plus d'attention reste la parité entre l'homologation et la production. Un écart de configuration entre les deux suffit à rendre la validation illusoire : le livrable testé n'est plus celui qui tourne. C'est le premier endroit où je regarde quand une mise en production se passe mal alors que la recette était verte.

  • Jenkins
  • XL Release
  • XL Deploy
  • Git
  • Homologation

Mises en production sur Kubernetes — Galian-SMABTP

2024 — 2025 · Assurance
Contexte
Applications déployées sur Kubernetes et Rancher, livraisons applicatives fréquentes à analyser avant chaque passage en production.
Action
Analyse des livraisons avec les équipes de développement dans le cadre du processus de gestion des changements, exécution des interventions techniques, communication sur incident, tenue de la documentation d'exploitation.
Résultat
Les défauts de livraison sont détectés à l'analyse plutôt qu'en production, et la documentation reste à jour au fil des mises en production — ce qui rend une intervention d'astreinte possible sans dépendre de la personne qui a déployé.
Détail technique

Avant de valider une livraison, quatre contrôles reviennent systématiquement : le livrable correspond-il à la version annoncée dans la demande de changement ; les dépendances introduites sont-elles disponibles sur la cible ; le paramétrage est-il externalisé plutôt que figé dans l'image ; existe-t-il un chemin de retour arrière testé. Une livraison qui échoue sur l'un des quatre repart chez le développement plutôt qu'en production.

Côté traitements, OPcon déclenche et séquence les chaînes, Talend porte les flux de données, les journaux remontent dans Elastic Search avec restitution Kibana. Sur Kubernetes et Rancher, l'essentiel se joue sur les sondes de vivacité et de disponibilité : mal réglées, elles font croire à un déploiement réussi alors que l'application n'est pas prête à servir le trafic.

  • Kubernetes
  • Rancher
  • OPcon
  • Talend
  • Elastic Search
  • Jenkins
  • Azure

Fiabilisation du SI et automatisation — Bouygues Telecom

2022 — 2024 · Télécoms
Contexte
Déploiement en production de plusieurs applicatifs, contrôles récurrents assurés manuellement, transferts de fichiers entre équipes métier à sécuriser.
Action
Responsable du déploiement en production, automatisation des contrôles récurrents, mise en place de palliatifs sur incident, suivi et exécution des tests et recettes de transfert de fichiers entre équipes.
Résultat
Les vérifications quotidiennes passées en scripts ne mobilisent plus l'équipe chaque matin, et les transferts inter-métiers sont éprouvés en recette avant d'atteindre la production plutôt que découverts en incident.
Détail technique

J'ai automatisé en priorité les contrôles à la fois quotidiens, sans ambiguïté d'interprétation et coûteux en attention : présence et fraîcheur des fichiers attendus, terminaison des chaînes d'ordonnancement, espace disque et rétention des journaux. Leur résultat est binaire — un humain n'y apporte aucune valeur, mais leur oubli se paie en production.

Le vrai sujet des transferts de fichiers n'est pas le transfert lui-même mais ce qui se passe quand il échoue à moitié : fichier partiel côté destinataire, traitement déclenché sur des données incomplètes. Les recettes portaient donc autant sur les cas d'échec — coupure en cours de transfert, rejeu, doublon — que sur le cas nominal.

  • Red Hat
  • VTOM
  • Control-M
  • Prometheus
  • Kibana
  • Kafka
  • MongoDB
  • Axway CFT

Plateforme DNS abonnés et coffre à secrets — Orange

2021 — 2022 · Télécoms
Contexte
Plateforme DNS des abonnés à maintenir en condition opérationnelle, accès à privilèges à encadrer, CDN à faire évoluer vers IPv6.
Action
Maintien de la plateforme DNS, mise en production et configuration des politiques de sécurité d'un PAM, optimisation des scripts d'automatisation, participation au projet de migration IPv6 du CDN.
Résultat
Plateforme maintenue sur un service grand public où une erreur de configuration se voit immédiatement, accès à privilèges repris derrière un coffre plutôt que dispersés, et CDN engagé dans la migration IPv6.
Détail technique

Sur une plateforme DNS grand public, tout l'enjeu est de modifier sans interrompre. Les changements se propagent serveur par serveur : on sort un résolveur de la rotation, on applique, on vérifie les réponses sur un jeu de requêtes de référence, puis on le remet en service avant de passer au suivant. Les zones sont décrites en fichiers versionnés et poussées par Ansible, ce qui rend le retour arrière aussi simple que le déploiement — et évite la modification manuelle sur un seul serveur, qui crée des divergences invisibles jusqu'au jour où c'est lui qui répond.

Sur le PAM, la difficulté est moins technique qu'organisationnelle : identifier les comptes à privilèges réellement utilisés, leurs usages légitimes, et basculer sans bloquer des exploitations qui reposaient sur des accès directs depuis des années.

  • Bind
  • Red Hat
  • Ansible
  • Terraform
  • GitLab
  • Grafana
  • Control-M