Préparer les mises en production et gérer les incidents

En parallèle des corrections, j'ai préparé et piloté les livraisons en production, et géré un incident de bout en bout.

Les points qui font échouer une mise en production

Le comportement des variables au déploiement

Une variable de projet ne se comporte pas de la même façon selon qu'elle est portée par le projet ou par l'instance. Un déploiement peut écraser une valeur spécifique à la production par celle de l'environnement de développement, sans que rien ne le signale.

J'ai systématiquement identifié, avant chaque livraison, quelles variables devaient rester propres à la cible et lesquelles pouvaient être transportées.

Le calage des dates et des périodes

Sur des traitements qui reconstruisent un historique, la période à traiter au premier lancement n'est presque jamais celle du fonctionnement courant. Se tromper là-dessus produit soit des trous, soit des doublons. Et les doublons se remarquent plus tard, quand ils ont déjà été consommés en aval.

Les dépendances entre projets

Livrer un projet dont un autre dépend impose de vérifier l'ordre et le moment. Une livraison isolée peut casser une chaîne aval qui, elle, n'a pas changé.

La gestion d'incident

J'ai pris en charge un incident depuis l'analyse technique jusqu'à la relance en production. La partie technique n'a pas été la plus longue.

L'essentiel du temps est passé en coordination : relancer la prise en charge quand le ticket stagnait, travailler avec les équipes DevOps sur les accès et les déploiements, et clarifier avec le métier ce qui était attendu exactement.

Sur un incident, savoir quoi corriger prend souvent moins de temps que réunir les conditions pour pouvoir le corriger.

J'ai aussi tenu informées les équipes concernées au fur et à mesure. Un incident silencieux qui se résout est vécu comme un incident non traité par ceux qui l'attendent.

Les noms de projets, de tables et de systèmes internes ont été retirés. Les détails techniques sont réels.