Déploiement vs Mise en production : pourquoi le Progressive Delivery sépare deux choses que vous pensiez identiques

Votre équipe vient de terminer un nouveau flux de paiement. Le code est testé, la pull request est fusionnée, et le pipeline de déploiement est au vert. Vous appuyez sur "déployer". La nouvelle version part en production. Désormais, chaque utilisateur voit le bouton redessiné, les champs de formulaire réorganisés et le nouvel écran de confirmation.

Mais que faire si vous vouliez observer les performances du nouveau flux avant de le montrer à tout le monde ? Et si vous ne laissiez que 5 % des utilisateurs l'essayer d'abord, puis augmenter progressivement en fonction des données réelles ?

Dans la plupart des équipes, le déploiement et la mise en production ont lieu en même temps. Quand le nouveau code arrive sur le serveur, les fonctionnalités qu'il contient deviennent disponibles pour les utilisateurs. Pourtant, ces deux actions ne sont pas obligatoirement liées. Les séparer vous offre un niveau de contrôle qui change votre façon d'envisager la livraison de logiciels.

Le déploiement est technique. La mise en production est expérientielle.

Le déploiement est l'action de placer du code sur un serveur. C'est une opération technique. Vous construisez un artefact, vous le transférez dans un environnement, et vous démarrez la nouvelle version. Le serveur exécute désormais le nouveau code.

La mise en production est l'action de rendre une fonctionnalité accessible aux utilisateurs. C'est une décision expérientielle. Le code est déjà exécuté sur le serveur, mais la fonctionnalité est cachée derrière un interrupteur. Quand vous actionnez cet interrupteur, les utilisateurs voient le nouveau comportement.

Un même déploiement peut contenir plusieurs fonctionnalités non encore mises en production. Vous pouvez déployer une fois et mettre en production progressivement. Vous pouvez aussi mettre une fonctionnalité à disposition d'un groupe d'utilisateurs mais pas d'un autre, le tout à partir de la même version de l'application en cours d'exécution.

Le diagramme ci-dessous illustre cette séparation :

flowchart TD A[Code fusionné] --> B[Déploiement sur le serveur] B --> C[Tout le code s'exécute sur le serveur] C --> D{Vérification du feature flag} D -- Flag activé --> E[Mise en production pour les utilisateurs] D -- Flag désactivé --> F[Fonctionnalité cachée] E --> G[Surveillance des métriques] G --> H{Données positives ?} H -- Oui --> I[Augmenter le % de rollout] H -- Non --> J[Désactiver le flag] I --> K[Mise en production complète] K --> L[Supprimer le flag du code] J --> F

Cette séparation est le fondement du Progressive Delivery.

Un exemple concret

Imaginez que votre équipe a développé un nouveau bouton "Acheter maintenant". Il est plus grand, plus coloré et mieux placé. L'équipe a confiance dans le code, mais n'est pas sûre de la réaction des utilisateurs existants. Un changement soudain de mise en page pourrait dérouter ceux qui utilisent l'ancienne interface depuis des mois.

Avec le Progressive Delivery, voici comment procéder :

  1. Vous déployez la nouvelle version en production. Le code du nouveau bouton s'exécute sur le serveur, mais il est caché. Les utilisateurs voient l'ancien bouton.
  2. Vous configurez votre système de feature flags pour afficher le nouveau bouton à 5 % des utilisateurs, sélectionnés aléatoirement.
  3. Après une semaine, vous analysez les données. Les utilisateurs qui ont vu le nouveau bouton ont finalisé leurs achats à un taux plus élevé. Aucune confusion signalée.
  4. Vous augmentez le rollout à 50 % des utilisateurs. Une autre semaine passe. Les données sont toujours bonnes.
  5. Vous mettez la fonctionnalité à disposition de 100 % des utilisateurs. Elle est désormais totalement en production.

Remarquez ce qui s'est passé : un seul déploiement, plusieurs mises en production. Le code est allé en production une fois. La fonctionnalité est devenue visible par étapes, guidée par le comportement réel des utilisateurs.

Les feature flags sont le mécanisme

Pour séparer le déploiement de la mise en production, vous avez besoin de feature flags. Un feature flag est une branche conditionnelle dans votre code qui vérifie si une fonctionnalité doit être active pour l'utilisateur courant. Le flag est contrôlé de l'extérieur, généralement via un service de configuration ou une plateforme dédiée de feature flags.

Un feature flag simple ressemble à ceci dans le code :

if feature_flags.is_active("new_checkout_button", user_id):
    render_new_button()
else:
    render_old_button()

Le flag peut être activé ou désactivé sans nouveau déploiement. Vous modifiez la configuration, et la prochaine requête de cet utilisateur verra le nouveau comportement. Pas de changement de code, pas de build, pas de déploiement.

Les feature flags permettent aussi l'expérimentation. Vous pouvez réaliser des tests A/B en dirigeant différents segments d'utilisateurs vers différentes variantes de fonctionnalités. Un groupe voit un bouton rouge, un autre voit un bouton bleu. Les données vous indiquent lequel fonctionne le mieux.

En quoi cela diffère du canary et du staged rollout

Le déploiement canary et le staged rollout consistent à diriger les utilisateurs vers différentes versions de l'application. Vous exécutez deux versions côte à côte, et un load balancer envoie un pourcentage du trafic vers la nouvelle version. En cas de problème, vous redirigez le trafic vers l'ancienne version.

Le Progressive Delivery fonctionne différemment. Vous exécutez une seule version de l'application. Tous les utilisateurs accèdent aux mêmes serveurs. Mais au sein de cette version, différents utilisateurs voient différentes fonctionnalités. La séparation se fait au niveau des fonctionnalités, pas au niveau de l'application.

Cette distinction est importante quand vous voulez mettre en production une fonctionnalité indépendamment des autres changements du même déploiement. Avec le canary, vous ne pouvez pas afficher le nouveau bouton à 5 % des utilisateurs tout en gardant le reste de la nouvelle version cachée. Vous envoyez soit les utilisateurs vers la nouvelle version, soit vers l'ancienne. Avec le Progressive Delivery, vous contrôlez chaque fonctionnalité individuellement.

Le coût des feature flags

Les feature flags ne sont pas gratuits. Chaque flag ajoute une branche conditionnelle à votre code. Avec le temps, les flags s'accumulent. Si vous ne les nettoyez pas, votre codebase se remplit de conditions mortes qui rendent la logique plus difficile à lire et à tester.

Une pratique courante consiste à utiliser un flag pour une fonctionnalité, la valider, la déployer complètement, puis supprimer le flag dans le sprint suivant. Mais les équipes oublient souvent cette étape. Le flag reste dans le code, et personne ne se souvient de ce qu'il contrôle ni s'il est encore actif.

La discipline est essentielle. Considérez les feature flags comme temporaires par défaut. Quand une fonctionnalité est entièrement déployée pour tous les utilisateurs, planifiez son nettoyage. Si vous utilisez une plateforme de feature flags, la plupart des outils fournissent des tableaux de bord qui montrent quels flags sont complètement déployés et prêts à être supprimés.

Quand le Progressive Delivery a du sens

Toutes les équipes n'ont pas besoin du Progressive Delivery. Si votre application est petite, votre base d'utilisateurs homogène et vos fonctionnalités simples, la surcharge liée aux feature flags peut ne pas en valoir la peine.

Mais le Progressive Delivery devient précieux quand :

  • Vous livrez des fonctionnalités qui modifient significativement le comportement des utilisateurs.
  • Vous avez une base d'utilisateurs large ou diversifiée avec des réactions variables.
  • Vous souhaitez valider les fonctionnalités avec des données réelles avant le déploiement complet.
  • Votre équipe livre fréquemment et veut dissocier la cadence de déploiement du moment de la mise en production.

L'idée clé est que le Progressive Delivery offre un juste milieu entre "livrer à tout le monde" et "ne rien livrer du tout". Vous pouvez livrer le code, observer l'impact, et étendre la mise en production en fonction des preuves.

Une checklist pratique pour adopter le Progressive Delivery

Si vous décidez de séparer le déploiement de la mise en production, voici les étapes pour commencer :

  • Choisissez une fonctionnalité qui bénéficierait d'une exposition progressive. Ne commencez pas avec toutes les fonctionnalités.
  • Ajoutez un feature flag pour cette fonctionnalité. Utilisez un simple fichier de configuration ou un service dédié.
  • Déployez le code avec le flag désactivé. Vérifiez que la fonctionnalité est cachée.
  • Activez le flag pour un petit pourcentage d'utilisateurs. Surveillez les métriques et les logs.
  • Augmentez le pourcentage en fonction des données. En cas de problème, désactivez immédiatement le flag.
  • Quand la fonctionnalité est entièrement déployée, supprimez le flag du code.

Ce qu'il faut retenir

Le déploiement et la mise en production ne sont pas la même chose. Le déploiement consiste à placer du code sur des serveurs. La mise en production consiste à rendre les fonctionnalités visibles aux utilisateurs. Le Progressive Delivery sépare ces deux actions pour que vous puissiez livrer du code selon votre calendrier et mettre en production les fonctionnalités selon le calendrier des données.

La prochaine fois que votre équipe termine une fonctionnalité, demandez-vous : devons-nous la déployer pour tout le monde immédiatement, ou pouvons-nous laisser les données décider ?