Du commit à la production : les étapes, les outils et les garde-fous que nous mettons en place.
Chaque projet client chez IT Engineering Factory dispose d'un pipeline CI/CD dès la première semaine. Ce n'est pas un luxe — c'est une condition de qualité et de vitesse. Voici la structure typique que nous mettons en place, et pourquoi chaque étape est là.
Lint + type check (< 30s) : premier garde-fou contre les erreurs triviales. Tests unitaires et d'intégration (< 2min) : validation du comportement métier. Build Docker (< 3min) : on construit l'image qui va partir en production. Push sur ECR + scan de sécurité Trivy : on ne déploie rien avec des vulnérabilités critiques connues. Déploiement staging automatique : l'équipe a toujours un environnement de test à jour. Déploiement production : déclenché manuellement ou automatiquement selon le projet, avec rollback automatisé si les health checks échouent.
Trois choix ont changé notre rapport aux incidents de production. Premier : les health checks avant et après chaque déploiement — si le service ne répond pas sous 90 secondes, rollback automatique ECS. Deuxième : les feature flags pour les fonctionnalités risquées — on déploie en production mais on active progressivement. Troisième : les alertes sur les métriques métier en plus des métriques infra — un bug silencieux dans la logique métier ne fait pas monter le CPU.
“Un pipeline qui ne déploie pas automatiquement en production est un pipeline à moitié fait. La valeur est dans la livraison, pas dans le build.”
Notre stack complète : GitHub Actions pour l'orchestration, Docker + ECR pour les images, ECS Fargate pour l'exécution, Terraform pour l'infrastructure, Datadog pour l'observabilité. Ce n'est pas la seule façon de faire — mais c'est celle qui nous a donné le meilleur rapport complexité/fiabilité sur les projets africains que nous gérons.