Déploiement vs Mise en production : quand les utilisateurs reçoivent vraiment votre nouvelle version

Votre équipe vient de terminer le déploiement de la version 1.2.0 en production. L'artefact est sur le serveur, l'application tourne, tous les health checks sont au vert. Cela signifie-t-il que tous vos utilisateurs utilisent désormais les nouvelles fonctionnalités ? Probablement pas.

Peut-être que votre équipe a délibérément caché certaines fonctionnalités pour surveiller la stabilité. Peut-être que le déploiement a été fait sur un nouveau serveur pas encore connecté aux utilisateurs. L'écart entre « le code tourne » et « les utilisateurs peuvent l'utiliser » est plus grand que la plupart des équipes ne le pensent.

La différence entre déploiement et mise en production

Le déploiement est une action technique. Vous placez un artefact dans un environnement et le faites fonctionner. Le serveur accepte le nouveau binaire, la migration de base de données s'exécute, l'application commence à répondre aux requêtes. D'un point de vue infrastructure, le travail est terminé.

Le diagramme suivant illustre la divergence entre déploiement et mise en production :

flowchart TD A[Commit de code] --> B[Build & Test] B --> C[Déploiement en production] C --> D{Stratégie de release ?} D -->|Feature Flags| E[Feature Flag désactivé] D -->|Canary| F[Aiguiller 5% du trafic] D -->|Blue-Green| G[Déploiement sur env inactif] E --> H[Activer le flag pour les utilisateurs] F --> I[Surveiller & augmenter le %] G --> J[Bascule du trafic] H --> K[Les utilisateurs accèdent à la fonctionnalité] I --> K J --> K style C fill:#4a90d9,color:#fff style K fill:#27ae60,color:#fff

La mise en production (release) est une décision métier. C'est le moment où une fonctionnalité ou un correctif devient réellement accessible aux utilisateurs. Le déploiement peut avoir lieu sans mise en production, mais la mise en production ne peut pas avoir lieu sans déploiement.

Cette distinction est importante car elle change votre façon d'envisager le risque. Quand déploiement et mise en production sont la même chose, chaque déploiement porte tout le poids de l'impact utilisateur. Quand vous les séparez, vous gagnez de la marge de manœuvre.

Feature Flags : la séparation la plus simple

Les feature flags sont le moyen le plus courant de découpler déploiement et mise en production. Vous ajoutez du code qui peut activer ou désactiver des fonctionnalités sans redéployer. La nouvelle version part en production avec plusieurs fonctionnalités, mais une seule est active pour un petit groupe d'utilisateurs.

Voici un exemple simple de configuration de feature flags dans un fichier YAML :

# config/feature-flags.yaml
features:
  new-checkout:
    enabled: false
    description: "Nouveau flux de paiement en une page"
    rollout_percentage: 0
  dark-mode:
    enabled: true
    description: "Mode sombre pour tous les utilisateurs"
    rollout_percentage: 100

Quand l'équipe est prête à mettre en production le nouveau checkout, elle passe enabled: false à enabled: true et met à jour le pourcentage de déploiement progressif. Pas de changement de code, pas de redéploiement — juste une mise à jour de configuration qui prend effet immédiatement.

Si la fonctionnalité fonctionne bien, vous l'ouvrez à plus d'utilisateurs. Si quelque chose casse, vous désactivez le flag. Pas besoin de rollback, pas de déploiement d'urgence. Le reste de l'application continue de fonctionner normalement.

Ce pattern fonctionne particulièrement bien pour les équipes qui déploient fréquemment. Vous pouvez déployer du code plusieurs fois par jour sans craindre d'exposer des fonctionnalités inachevées. Le flag devient votre interrupteur de sécurité.

Canary Releases : tester avec du trafic réel

Les canary releases poussent la séparation plus loin. Vous déployez la nouvelle version en production mais n'aiguillez qu'un petit pourcentage d'utilisateurs vers elle — disons 5 %. Ce groupe reçoit le nouveau code tandis que tous les autres restent sur l'ancienne version.

Vous surveillez les taux d'erreur, les temps de réponse et le comportement utilisateur pour ce petit groupe. Si tout semble normal, vous augmentez progressivement le pourcentage. Si quelque chose cloche, vous redirigez tout le trafic vers l'ancienne version. Pas de rollback nécessaire, pas de temps d'arrêt.

L'avantage clé est que vous testez avec du trafic réel, pas des tests synthétiques. Les vrais utilisateurs ont de vrais navigateurs, de vraies conditions réseau et de vrais schémas d'utilisation. Un canary détecte des problèmes que les environnements de staging ne verront jamais.

Blue-Green Deployment : séparation au niveau infrastructure

Le déploiement blue-green sépare la mise en production du déploiement au niveau infrastructure. Vous maintenez deux environnements de production identiques : blue et green. L'ancienne version tourne sur blue. Vous déployez la nouvelle version sur green pendant que blue continue de servir tous les utilisateurs.

Quand vous êtes confiant que green est stable, vous basculez le trafic de blue vers green. La mise en production a lieu au moment du basculement de trafic, pas quand le déploiement s'est terminé. Si quelque chose se passe mal après le basculement, vous rebasculez le trafic vers blue.

Ce pattern est utile pour les applications où vous ne pouvez pas utiliser facilement les feature flags, ou quand les changements sont trop fondamentaux pour être activés avec un flag. Les changements de schéma de base de données, les mises à niveau majeures de framework ou les modifications d'infrastructure bénéficient souvent du déploiement blue-green.

Pourquoi séparer déploiement et mise en production est important

La séparation vous donne le contrôle sur le timing. Vous pouvez déployer à 2 heures du matin quand le trafic est faible, mais retarder la mise en production jusqu'au matin quand votre équipe est prête à surveiller. Vous pouvez déployer plusieurs fois dans la journée sans craindre de perturber les utilisateurs, car la mise en production est une décision séparée.

Cela change aussi votre façon de gérer les problèmes. Quand déploiement et mise en production sont couplés, un mauvais déploiement signifie que les utilisateurs voient immédiatement des erreurs. Quand ils sont séparés, vous avez le temps de détecter les problèmes avant que les utilisateurs ne soient affectés. Les signaux de santé du déploiement vous disent que le serveur tourne. Les signaux après la mise en production vous disent que les utilisateurs sont satisfaits.

Que surveiller après la mise en production

La mise en production est le moment où les utilisateurs commencent à expérimenter vos changements. Avant la mise en production, tout est sous votre contrôle. Après, les utilisateurs sont impliqués. S'il y a un problème, ils le ressentent en premier.

Les health checks qui semblaient verts pendant le déploiement ne racontent peut-être pas toute l'histoire. L'application tourne, mais les utilisateurs accomplissent-ils leurs tâches ? Les taux d'erreur sont-ils réellement bas, ou les erreurs se produisent-elles dans des parties de l'application que votre monitoring ne couvre pas ? Les performances sont-elles stables sous charge réelle ?

Vous devez surveiller différemment après la mise en production. Surveillez les métriques orientées utilisateur : temps de chargement des pages, taux de complétion des transactions, taux d'erreur par fonctionnalité. Comparez-les à la référence d'avant la mise en production. Un déploiement vert avec une mauvaise mise en production reste un mauvais résultat.

Checklist pratique pour votre prochaine mise en production

Avant de déclarer une mise en production terminée, passez en revue ces points :

  • Pouvez-vous revenir en arrière sans redéployer ? Sinon, quel est votre plan de rollback ?
  • Savez-vous quels utilisateurs voient la nouvelle version ? Si vous faites un canary, confirmez que la répartition du trafic fonctionne.
  • Surveillez-vous les métriques orientées utilisateur, pas seulement la santé du serveur ? La santé du serveur vous dit que l'app tourne. Les métriques utilisateur vous disent que l'app fonctionne.
  • Avez-vous un moyen de désactiver la fonctionnalité sans redéployer ? Si vous n'utilisez pas de feature flags, envisagez d'en ajouter avant la prochaine mise en production.
  • Qui doit être informé que la mise en production a eu lieu ? Les équipes support, les rédacteurs de documentation et les autres parties prenantes doivent être prévenus.

Ce qu'il faut retenir

Le déploiement met le code sur les serveurs. La mise en production met les fonctionnalités entre les mains des utilisateurs. Traitez-les comme des décisions séparées, et vous gagnez la capacité de déployer en toute confiance, de mettre en production avec précaution, et de récupérer rapidement quand quelque chose tourne mal. Les meilleures équipes ne se contentent pas de bien déployer — elles font de bonnes mises en production, car elles savent que les deux ne sont pas la même chose.