Déploiement vs Mise en Production : Pourquoi Votre Nouveau Code N'atteint Pas Encore les Utilisateurs

Vous venez de terminer un déploiement. Le pipeline est vert, l'artefact est sur le serveur de production, et votre équipe s'apprête à annoncer la fin des travaux. Mais quand vous vérifiez l'application, les utilisateurs voient toujours l'ancienne version. Rien n'a changé de leur côté.

Ce moment déroute beaucoup d'équipes. Vous avez tout fait correctement. Le code est là. Le serveur exécute le nouveau binaire. Alors pourquoi les utilisateurs ne reçoivent-ils pas la mise à jour ?

La réponse est simple : le déploiement et la mise en production sont deux choses différentes. Et comprendre cette différence change votre façon de concevoir la livraison de logiciels.

Le Déploiement Signifie que le Code est sur le Serveur

Le déploiement est l'action de placer une nouvelle version de votre application sur un serveur. L'artefact sort de votre registre, est copié dans l'environnement cible, et le serveur commence à l'exécuter. Si vous avez déployé en production, la nouvelle version est physiquement présente sur les serveurs de production.

C'est tout. Le déploiement est une action technique. Il ne dit rien sur la capacité des utilisateurs à utiliser réellement la nouvelle version.

Imaginez ceci : vous avez chargé un nouveau film dans le projecteur d'un cinéma. La pellicule est en place, les bobines sont prêtes, et le projecteur est allumé. Mais le film n'a pas encore commencé. Le public regarde toujours le film précédent.

Le diagramme suivant montre la chronologie et le flux de trafic entre les anciennes et nouvelles versions pendant le déploiement, la mise en production et le déploiement canari :

sequenceDiagram participant Dev as Équipe Dev participant LB as Équilibreur participant Old as Ancienne Version participant New as Nouvelle Version participant User as Utilisateurs Dev->>LB: Déployer nouvelle version LB->>New: Démarrer nouvelle version Note over New: En cours d'exécution mais inactive User->>LB: Requête LB->>Old: Router vers ancienne version Note over LB: Moment de mise en production Dev->>LB: Basculer le trafic vers la nouvelle LB->>New: Router tous les utilisateurs Note over LB: Déploiement canari Dev->>LB: Router 5% vers la nouvelle User->>LB: Requête LB->>New: Router certains utilisateurs LB->>Old: Router la plupart des utilisateurs Dev->>LB: Augmenter à 50% Dev->>LB: Router 100%

La Mise en Production Signifie que les Utilisateurs Reçoivent la Nouvelle Version

La mise en production est le moment où la nouvelle version commence à servir du trafic utilisateur réel. Le trafic désigne les requêtes provenant des utilisateurs vers votre application. Tant que le trafic est toujours dirigé vers l'ancienne version, les utilisateurs ne ressentiront aucun effet du nouveau code présent sur le serveur.

La nouvelle version est là. Elle s'exécute. Mais elle est inactive. Personne ne l'atteint.

La mise en production, c'est quand vous passez le panneau de "bientôt disponible" à "en cours de diffusion". Le projecteur se met en marche, et le public voit le nouveau film.

Pourquoi les Séparer ?

Si vous pouvez déployer et mettre en production en même temps, pourquoi voudriez-vous les séparer ? Parce que la séparation vous donne du contrôle.

Quand le déploiement et la mise en production sont la même action, chaque déploiement devient un pari. Vous poussez du code, les utilisateurs le voient immédiatement, et si quelque chose casse, tout le monde en subit les conséquences. Il n'y a pas de tampon entre "nous l'avons mis là" et "les utilisateurs le voient".

Quand vous les séparez, vous obtenez une fenêtre. Vous pouvez :

  • Déployer la nouvelle version et la laisser en attente.
  • Surveiller son comportement sans impact utilisateur.
  • Vérifier qu'elle démarre correctement, se connecte aux bases de données et gère les requêtes internes.
  • Corriger les problèmes avant qu'un utilisateur ne les remarque.

Cette fenêtre est votre filet de sécurité. Elle transforme le déploiement d'un événement à haut risque en une opération de routine.

Comment Séparer le Déploiement de la Mise en Production

La méthode la plus simple utilise un équilibreur de charge ou un proxy inverse. Voici comment cela fonctionne :

  1. Déployez la nouvelle version sur le serveur en parallèle de l'ancienne version.
  2. Configurez l'équilibreur de charge pour envoyer tout le trafic utilisateur vers l'ancienne version.
  3. La nouvelle version s'exécute mais ne reçoit aucune requête externe.
  4. Quand vous êtes prêt, mettez à jour la configuration de l'équilibreur de charge pour router le trafic vers la nouvelle version.

Ce changement de configuration est votre mise en production. Il peut avoir lieu quelques secondes après le déploiement, ou des heures plus tard. Le timing vous appartient.

Voici un exemple pratique utilisant une CLI d'équilibreur de charge hypothétique pour basculer le trafic :

# Déployer la nouvelle version en parallèle de l'ancienne
# (suppose que les deux sont déjà en cours d'exécution sur le serveur)

# Vérifier la distribution actuelle du trafic
trafficctl get-weight myapp
# Sortie : myapp-v1: 100%, myapp-v2: 0%

# Basculer 10% du trafic vers la nouvelle version (canari)
trafficctl set-weight myapp-v2 10%

# Après surveillance, basculer tout le trafic vers la nouvelle version
trafficctl set-weight myapp-v2 100%

# Revenir en arrière si nécessaire : rediriger instantanément tout le trafic vers l'ancienne version
trafficctl set-weight myapp-v1 100%

Les Déploiements Canari : Un Déploiement Progressif

Une approche plus raffinée est le déploiement canari. Au lieu de basculer tout le trafic d'un coup, vous envoyez d'abord un petit pourcentage d'utilisateurs vers la nouvelle version.

Disons que vous avez mille utilisateurs. Vous commencez par en router cinquante vers la nouvelle version. Si tout semble bon après cinq minutes, vous passez à deux cents. Puis cinq cents. Puis la totalité.

Cette approche limite le rayon d'impact. Si la nouvelle version a un bug, seules cinquante personnes le subissent au lieu de mille. Vous détectez les problèmes tôt, avec des dégâts minimes.

Les déploiements canari fonctionnent bien aussi avec les feature flags. Vous pouvez déployer du code caché derrière un flag, l'activer pour un petit groupe, observer les résultats, et élargir progressivement l'audience.

Revenir en Arrière Sans Redéploiement

La séparation facilite aussi le retour en arrière. Si vous mettez en production une version défectueuse, vous n'avez pas besoin de redéployer l'ancienne. L'ancienne version est toujours sur le serveur, toujours en cours d'exécution, et toujours capable de gérer le trafic.

Vous changez simplement la configuration de l'équilibreur de charge. Le trafic bascule vers l'ancienne version. Les utilisateurs retrouvent un environnement stable en quelques secondes.

Comparez cela à une approche combinée déploiement-et-mise-en-production. Là, un retour en arrière signifie :

  • Trouver l'ancien artefact.
  • Le redéployer.
  • Attendre le redémarrage du serveur.
  • Espérer que le retour en arrière lui-même n'introduise pas de problèmes.

Ce processus prend des minutes au mieux, et souvent plus longtemps. Pendant ce temps, les utilisateurs subissent une application défaillante.

Qui Décide du Moment de la Mise en Production ?

Le déploiement est une décision technique. Votre pipeline CI/CD peut le gérer automatiquement. Mais la mise en production implique souvent les parties prenantes produit ou métier.

L'équipe produit sait si la fonctionnalité est prête pour les utilisateurs. Elle peut vouloir la tester en interne d'abord, réaliser un test A/B, ou retarder la mise en production pour des raisons marketing. Elle comprend l'impact utilisateur d'une manière que le pipeline de déploiement ne peut pas.

Cela ne signifie pas que chaque mise en production nécessite une réunion. Pour les mises à jour de routine, vous pouvez automatiser la mise en production après une brève période d'observation. Mais pour les changements significatifs, la décision de mise en production devrait impliquer des personnes qui comprennent le contexte métier.

Une Liste de Vérification Pratique pour Votre Prochaine Mise en Production

Avant de mettre en production une nouvelle version pour les utilisateurs, passez en revue ces points :

  • La nouvelle version a-t-elle fonctionné en production pendant au moins quelques minutes sans erreur ?
  • Les logs montrent-ils un comportement normal ?
  • Avez-vous un moyen de rediriger le trafic vers l'ancienne version si nécessaire ?
  • Quelqu'un a-t-il confirmé que la fonctionnalité est prête d'un point de vue produit ?
  • La fenêtre de mise en production est-elle choisie pour minimiser l'impact utilisateur ?
  • Savez-vous qui contacter si quelque chose tourne mal après la mise en production ?

Cette liste est volontairement courte. Trop complexifier le processus de mise en production conduit à des étapes sautées. Restez simple, et appliquez-la systématiquement à chaque fois.

Le Vrai Enseignement

Le déploiement et la mise en production ne sont pas la même chose. Le déploiement consiste à placer du code sur un serveur. La mise en production consiste à laisser les utilisateurs y accéder. Les traiter comme des actions séparées vous donne le contrôle sur le risque, la vitesse de retour en arrière et l'expérience utilisateur.

La prochaine fois que votre pipeline passe au vert, demandez-vous : venez-vous de déployer, ou avez-vous réellement mis en production ? La réponse détermine si vos utilisateurs reçoivent la mise à jour ou attendent encore que le film commence.