Le métier
Ingénieur de production,
c'est quoi exactement ?
C'est le poste dont personne ne parle quand tout va bien, et le premier qu'on appelle à 3 h du matin. Voici ce qu'il recouvre, sans jargon.
Une équipe de développement écrit du code et le livre. Entre cette livraison et le moment où un client s'en sert, il y a un intervalle que beaucoup d'organisations sous-estiment : il faut vérifier que le livrable est complet, le déployer sur des environnements successifs, s'assurer qu'il n'a pas dégradé ce qui tournait déjà, surveiller son comportement, et savoir revenir en arrière s'il déraille.
Mon métier, c'est cet intervalle. Je ne conçois pas l'application : je garantis qu'elle arrive en production, qu'elle y reste, et qu'on sait quoi faire quand elle tombe.
Concrètement, cela recouvre quatre responsabilités : les mises en production, avec l'analyse des livraisons et le respect du processus de gestion des changements ; les chaînes de livraison, qui rendent ces déploiements reproductibles plutôt qu'artisanaux ; l'ordonnancement, c'est-à-dire les traitements automatiques qui s'exécutent chaque nuit et dont personne ne voit l'existence jusqu'à leur échec ; et la supervision, qui détermine si l'on apprend une panne par un tableau de bord ou par un client mécontent.
Ce qui distingue ce poste des voisins
Les intitulés se ressemblent et les outils se recoupent. Ce qui change, c'est la question à laquelle chacun répond.
Administrateur système
Répond de l'infrastructure : les serveurs, le réseau, le stockage. Sa question : est-ce que la machine tient ?
Ingénieur de production
Répond du service rendu par les applications en production. Sa question : est-ce que la livraison arrive, tourne et reste réparable ?
Développeur DevOps
Répond de l'outillage et des pipelines de son équipe. Sa question : est-ce que mon code part vite et souvent ?
SRE
Répond de la fiabilité mesurée par des objectifs de service. Sa question : combien de panne puis-je encore me permettre ?
Dans les grandes organisations que j'ai connues, ces rôles coexistent et se parlent. Je fais le lien entre le développement, qui veut livrer, et l'exploitation, qui veut de la stabilité — les deux ayant raison.
À quoi ressemble une journée
Variable selon les périodes, mais la structure revient.
- MatinContrôle des traitements de nuit : chaînes terminées, fichiers reçus, alertes de la veille. Ce qui a échoué se rattrape avant que les équipes métier n'arrivent.
- JournéeAnalyse des livraisons à venir avec les équipes de développement, préparation des mises en production, rédaction ou mise à jour des procédures d'exploitation.
- Fenêtre de MEPDéploiement, contrôles post-déploiement, communication aux équipes concernées. Retour arrière si les contrôles ne passent pas — décision prise à l'avance, pas dans l'urgence.
- IncidentRétablir d'abord, comprendre ensuite. Un palliatif qui remet le service debout vaut mieux qu'un diagnostic parfait pendant que la production est à l'arrêt.
- AprèsPost-mortem : ce qui a échoué, pourquoi la détection a pris ce temps-là, ce qu'on change pour la prochaine fois. Sur les faits, pas sur les personnes.
Ce que j'exploite au quotidien
Organisé par couche, de la mise en production jusqu'à la sauvegarde. Tout ce qui suit vient d'environnements réellement exploités, pas d'une veille technologique.
Mise en production et CI/CD
- Jenkins
- XL Release, XL Deploy
- Git, GitLab
- Homologation et recette
- Gestion des changements
Ordonnancement et transferts
- Control-M, VTOM
- OPcon, $U CTR-M
- Axway CFT, Automator
- Talend, Kafka
Conteneurs et cloud
- Kubernetes, Rancher
- Docker
- Azure
- VMware, Hyper-V
Supervision et exploitation
- Elastic Search, Kibana
- Grafana, Prometheus
- Zabbix, PRTG, ServiceNAV
- Incidents N3, astreinte HNO
Systèmes et automatisation
- Red Hat, Linux, Windows Server
- Ansible, Terraform
- PowerShell, scripting
- DNS, Bind, AD, IIS, Apache, Tomcat
Sauvegarde et sécurité
- Veeam, DoubleTake
- Coffre à secrets, PAM
- Secret Server IBM
- Cadre ISO 27001