Dans les équipes amateurs, le déploiement est un « événement ». Le développeur principal crie : « Tout le monde, arrêtez de fusionner ! Je déploie ! » Ils se connectent en SSH à un serveur. Ils exécutent git pull. Ils prient. Si ça casse, ils paniquent.

Dans les équipes professionnelles, le déploiement est un Non-Événement. Cela arrive 20 fois par jour. C’est ennuyeux. C’est invisible. S’il tombe en panne, le système revient automatiquement en arrière avant que l’utilisateur ne le voie.

Ceci est réalisé grâce à l’Intégration continue/Déploiement continu (CI/CD). Le Pipeline est un robot qui garde votre environnement de production. Son travail est simple : Rejetez impitoyablement le mauvais code.

Pourquoi Maison Code en parle

Chez Maison Code Paris, nous agissons comme la conscience architecturale de nos clients. Nous héritons souvent de stacks “modernes” construites sans compréhension fondamentale de l’échelle.

Nous abordons ce sujet car il représente un point de pivot critique dans la maturité de l’ingénierie. Une mise en œuvre correcte différencie un MVP fragile d’une plateforme résiliente de niveau entreprise.

1. La philosophie : la branche principale est sainte

L’objectif de CI/CD est de garantir que la branche « principale » est toujours déployable. Vous ne poussez jamais directement vers « principal ». Vous adhérez au Trunk Based Development (ou Short-Lived Feature Branches).

Le développeur crée la branche feat/new-checkout.
Le développeur pousse le code.
Exploitation du pipeline CI. Les tests réussissent.
Le développeur ouvre la Pull Request (PR).
Environnement d’aperçu est déployé.
Un examen par les pairs a lieu.
Fusionner avec « principal ».
Le pipeline CD s’exécute. Déploie en production.

2. Couche 1 : Analyse statique (The Grammar Police)

Les bogues les moins chers à corriger sont ceux détectés avant l’exécution du code. Nous exécutons cela à chaque git push.

Linting (ESLint) : détecte les erreurs de syntaxe et les mauvais modèles (no-unused-vars).
Formatage (plus joli) : applique le style. Aucun argument sur les tabulations et les espaces lors de la révision du code.
Vérification de type (TypeScript) : la vérification la plus critique. “Vous avez transmis une chaîne à une fonction attendant un nombre.”

# .github/workflows/ci.yml
Nom : CI
sur : [appuyer]
emplois :
  valider :
    exécution : ubuntu-latest
    étapes :
      - utilise : actions/checkout@v3
      - utilise : actions/setup-node@v3
      - exécuter : npm ci
      - exécuter : npm run type-check # tsc --noEmit
      - exécuter : npm exécuter lint

Coût : 30 secondes. Valeur : permet d’économiser des heures de débogage « undéfini n’est pas une fonction ».

3. Couche 2 : Tests unitaires (La vérification logique)

(Voir Tests unitaires). La fonction calculateTax() renvoie-t-elle la valeur correcte pour un utilisateur allemand ? Nous utilisons Vitest. Cela doit être rapide. Si les tests unitaires prennent plus de 5 minutes, les développeurs cesseront de les exécuter localement.

4. Couche 3 : L’environnement de prévisualisation (Vercel)

Cela change la donne. Lorsqu’un PR est ouvert, Vercel déploie automatiquement ce code sur une URL unique : https://my-app-git-feat-checkout.vercel.app. Cela permet :

AQ visuelle : le concepteur peut cliquer sur la caisse pour voir si les pixels sont parfaits.
Évaluation du produit : le PM peut vérifier que la fonctionnalité répond aux exigences.
Tests E2E automatisés : le pipeline peut exécuter un navigateur sur cette vraie URL.

5. Couche 4 : Tests de bout en bout (E2E) (le simulateur utilisateur)

Les tests unitaires ne suffisent pas. “La connexion à la base de données fonctionne. Le bouton s’affiche. Mais cliquer sur le bouton n’enregistre pas dans la base de données.” Seul Playwright (ou Cypress) détecte cela.

Le pipeline CI fait tourner un navigateur sans tête et agit comme un utilisateur.

Accédez à « /product/sneaker ».
Cliquez sur « Ajouter au panier ».
Attendez-vous à ce que « Panier (1) » soit visible.

  e2e :
    besoins : aperçu
    exécution : ubuntu-latest
    étapes :
      - utilise : actions/checkout@v3
      - nom : Exécuter le dramaturge
        exécuter : test de dramaturge npx
        env :
          BASE_URL : ${{ github.event.deployment_status.target_url }}

Bloqueur : si les tests E2E échouent, le bouton « Fusionner » dans GitHub est désactivé.

6. Déploiement continu : la version

Une fois le code fusionné avec « main », le pipeline CD démarre. Pour Vercel/Netlify, c’est automatique. Pour AWS (Docker/ECS), nous utilisons GitHub Actions pour créer le conteneur, le pousser vers ECR et mettre à jour la définition de tâche.

Zéro temps d’arrêt (bleu/vert)

Nous ne redémarrons jamais un serveur live.

Faites tourner Green (nouvelle version).
Attendez le bilan de santé (« 200 OK »).
Basculez l’équilibreur de charge sur Vert.
Tuez Blue (ancienne version). Cela garantit que si la nouvelle version plante au démarrage, aucun utilisateur ne la voit.

7. La règle du « déploiement du vendredi »

Il y a un mème : « Ne déployez pas vendredi. » Chez Maison Code, nous déployons le vendredi. Si vous avez peur de déployer vendredi, cela signifie que vous ne faites pas confiance à votre pipeline. Cela signifie que vous comptez sur le contrôle qualité manuel ou sur l’espoir. Un pipeline robuste vous donne la confiance nécessaire pour expédier à tout moment.

8. Analyse de sécurité (Maj gauche)

La sécurité se fait souvent « à la fin » via un Pentest. Nous le déplaçons vers la Pull Request.

Snyk / Dependabot : analyse package.json à la recherche de dépendances vulnérables.
Trivy : analyse les conteneurs Docker pour détecter les vulnérabilités du système d’exploitation.
SonarQube : analyse le code pour détecter les points d’accès (par exemple, les mots de passe codés en dur). Si vous validez une clé AWS, le pipeline explose. Cela empêche le secret d’atteindre l’historique de la branche « principale ».

9. Gestion des coûts (Infracost)

Les développeurs adorent créer de grandes instances. “J’ai besoin d’une base de données X1.Large pour les tests.” Nous utilisons Infracost. Il s’exécute dans le PR et commente :

“Ce PR augmente la facture mensuelle de 150 € (mise à niveau vers X1.Large).” Cela rend les coûts transparents. Le CTO peut approuver ou rejeter le « changement financier » tout comme un « changement de code ». Il introduit FinOps dans DevOps.

10. Gestion des secrets (Env Vars)

Ne validez jamais les fichiers .env. Nous utilisons Vercel Env Management ou AWS Secrets Manager. Le pipeline CI les injecte au moment de la construction. Pour les vérifications Open Source (comme « npm audit »), nous garantissons que les secrets ne sont pas enregistrés dans la console.

9. GitOps (ArgoCD) : Le Saint Graal

Pour nos clusters Kubernetes, nous utilisons GitOps. L’état du cluster est défini dans Git. Si vous souhaitez passer de 3 pods à 5 pods, vous n’exécutez pas kubectl scale. Vous modifiez « deployment.yaml » dans Git. ArgoCD voit le changement et synchronise le cluster. Détection de dérive : si un ingénieur cowboy modifie le cluster manuellement (SSH), ArgoCD détecte la dérive et la écrase à l’état Git. Cela applique religieusement « l’infrastructure en tant que code ».

10. Amorçage de base de données pour les aperçus

Un environnement de prévisualisation est inutile s’il possède une base de données vide. Vous vous connectez et il n’y a aucun produit. Nous implémentons le Amorçage automatisé.

Déployez la base de données (branche Neon / Supabase).
Exécutez npm run seed.
Injecte : 10 produits, 2 utilisateurs (administrateur/client), 5 commandes. Le PM peut désormais tester immédiatement la page « Historique des commandes ». C’est la différence entre un « déploiement technique » et un « produit utilisable ».

11. Rollback avancé : déploiements Canary

Pour les applications à haut risque, Bleu/Vert est trop binaire. Nous utilisons Déploiements Canary.

Déployez la v2 sur 5 % du trafic.
Pipeline surveille le taux d’erreur.
Si le taux d’erreur est < 0,1 %, augmentez-le à 20 %.
Si le taux d’erreur augmente, Retour automatique à 0 %. Cela limite le “Blast Radius” d’un mauvais bug. Seuls 5 % des utilisateurs ont vu l’erreur. Cela nécessite des Load Balancers sophistiqués (AWS ALB / Cloudflare), mais c’est le filet de sécurité ultime.

12. Conclusion

Les opérations manuelles sont l’ennemie de l’échelle. Chaque fois qu’un humain touche un serveur, le risque d’erreur est de 10 %. Chaque fois qu’un script touche un serveur, le risque est de 0 % (après la première exécution réussie). Automatisez tout. Faites de « Faire la bonne chose » la « chose facile ».

Découvrez les [Tests automatisés](/fr/blog/tech-automated-testing-fr) et [Infrastructure as Code](/fr/blog/tech-infrastructure-code-fr).