Le client est un service logistique qui traite des dizaines de milliers de commandes par jour, avec des pics en soirée et pendant les promotions et des SLA stricts envers ses partenaires commerçants. Son infrastructure s’était développée sans plan : VPS dispersés, configurations directement sur les serveurs et déploiements manuels selon une procédure dans le wiki. Chaque mise en production impliquait un déploiement de nuit avec interruption de service ; chaque pic faisait courir un risque de perte de commandes. L’incident qui a motivé le projet s’est produit pendant les promotions de fin d’année : la plateforme est restée indisponible quatre heures et le service a dû indemniser ses partenaires.
Passer à une infrastructure maîtrisée sans interrompre l’activité :
infrastructure as code, livraison automatisée, conteneurisation et orchestration, observabilité et reprise prévisible après incident. Le fondateur a formulé le critère de réussite ainsi : « déployer pendant les heures de travail, sans interruption et sans personne connectée en SSH ».
Nous avons suivi une séquence éprouvée : d’abord les conteneurs et des environnements reproductibles, ensuite l’automatisation de la livraison, et seulement après l’orchestration avec autoscaling.
- Nous avons audité l’infrastructure : cartographie des services et dépendances, mesure du profil de charge aux heures de pointe et inventaire des opérations manuelles qui provoquaient le plus souvent des incidents.
- Nous avons conteneurisé les services : uniformisation des builds, déplacement de la configuration hors du code vers des variables d’environnement et création d’environnements dev/stage/prod identiques.
- Nous avons décrit l’infrastructure en code avec Terraform : les environnements sont déployés depuis le dépôt et les modifications manuelles dans la console du fournisseur cloud sont interdites.
- Nous avons créé une pipeline GitLab CI : tests et builds d’images automatiques, déploiement immédiat en stage et déploiement en production sur déclenchement après revue ; le rollback se fait en une action.
- Nous avons migré la plateforme vers Kubernetes avec autoscaling : aux pics du soir et des promotions, des instances supplémentaires sont disponibles au lieu de travaux manuels en urgence.
- Nous avons déployé le monitoring et les alertes : métriques des quatre signaux d’or — latence, erreurs, trafic et saturation — avec astreinte et escalade planifiée.
- Nous avons configuré les sauvegardes et le disaster recovery : procédure de restauration et exercice d’incident en stage avec mesure du MTTR réel.
La valeur principale du projet n’est pas technologique, mais tient au transfert de responsabilité : l’infrastructure ne dépend plus d’une personne disposant d’un accès SSH. Chaque déploiement est reproductible, chaque environnement peut être restauré à partir du code et les incidents apparaissent sur les tableaux de bord avant le premier message d’un client. Les interruptions passent ainsi de catastrophes à des incidents courants, avec un plan d’action clair et un temps de restauration mesurable.
Les bénéfices économiques se composent de trois éléments : une économie directe de 32 % sur l’infrastructure grâce à l’autoscaling et à l’abandon des capacités de pointe maintenues en permanence ; des heures d’équipe économisées sur les déploiements nocturnes ; et surtout le chiffre d’affaires préservé pendant des pics qui se déroulent désormais sans incident. Un grand client, une chaîne de magasins, a renouvelé son contrat après la première promotion menée sur la nouvelle infrastructure.
| Indicateur | Résultat |
|---|---|
| Déploiement d’une mise en production | 3–4 heures manuellement → 15 minutes automatiquement |
| Fréquence des mises en production | 2–3 par mois → Presque tous les jours |
| Disponibilité de la plateforme | 97,8% → 99,95% |
| Pics de charge | Risque d’interruption → Autoscaling sans intervention humaine |
Les indicateurs ont été repris des documents sources de l’étude de cas. La période est indiquée lorsqu’elle est précisée dans la source.
- déploiement d’une mise en production (auparavant 3–4 heures manuellement)
- 15 min
- disponibilité de la plateforme (auparavant 97,8 %)
- 99,95%
- rétablissement après une panne (auparavant 2–4 heures)
- 20–30 min
- coût de l’infrastructure
- −32%
Les bornes supérieures des plages sont représentées (4 heures, 30 minutes). Indisponibilité = 100 % − disponibilité.
- 01Commit
- 02Tests
- 03Build de l’image
- 04Stageimmédiatement
- 05Prodsur déclenchement après revue
Pistes de développement de l’infrastructure pour le prochain cycle :
- Une pratique FinOps, avec des alertes sur les anomalies de coûts et une visibilité des dépenses par équipe.
- Une approche GitOps : l’état de la production est décrit dans le dépôt et les changements passent uniquement par des pull requests.
- Le multi-région : répliquer les services critiques pour résister aux pannes du fournisseur.
Avant, une mise en production, c’était une nuit, du café et une prière. Maintenant, c’est un bouton et quinze minutes. Nous avons fêté en équipe la première promotion sans incident.
— Directeur technique du service logistique