Quand vous voulez contrôler exactement qui reçoit la nouvelle version en premier

Imaginez une application déployée dans trois régions : Asie, Europe et Amérique. Vous venez de terminer une mise à jour majeure, mais vous n'êtes pas certain de son comportement face à des conditions d'infrastructure ou des schémas d'utilisation différents. Vous pourriez tout pousser d'un coup et espérer que tout se passe bien. Ou alors, faire un déploiement canary en envoyant 5 % du trafic aléatoire vers la nouvelle version.

Mais que faire si le problème n'est pas aléatoire ? Et si les utilisateurs en Asie ont une configuration réseau différente, ou si les utilisateurs premium empruntent des flux de paiement que les utilisateurs gratuits ne touchent jamais ? Un échantillon aléatoire de 5 % pourrait passer à côté du groupe exact où l'échec se produira.

C'est là que vous avez besoin de plus de contrôle que ce qu'offrent les déploiements canary. Vous devez décider non seulement combien de trafic reçoit la nouvelle version, mais qui la reçoit.

Ce que signifie réellement le déploiement par étapes

Le déploiement par étapes (staged rollout) est une stratégie de déploiement où vous publiez une nouvelle version à des groupes d'utilisateurs spécifiques selon une séquence planifiée. Chaque groupe est défini par des critères qui comptent pour votre application : région géographique, type de compte, plateforme de l'appareil, plages d'ID utilisateur, ou tout autre attribut sur lequel vous pouvez router.

L'idée centrale est simple : limiter les risques en contrôlant quels utilisateurs sont exposés à la nouvelle version à chaque étape. Vous observez chaque groupe avant de passer au suivant. Si quelque chose tourne mal, l'impact est contenu à un ensemble d'utilisateurs connu et gérable.

Cela diffère d'un déploiement canary. Le canary utilise des pourcentages de trafic aléatoires. Il ne se soucie pas de l'identité de l'utilisateur. Le déploiement par étapes se soucie profondément de qui reçoit quoi, car le regroupement est délibéré et basé sur une logique métier ou opérationnelle.

Un exemple concret : déploiement par région

Reprenons le scénario des trois régions. Votre application tourne en Asie, Europe et Amérique. Vous soupçonnez que la latence réseau, les configurations des centres de données ou les règles de conformité locales pourraient causer des problèmes dans une région mais pas dans les autres.

Le diagramme suivant illustre le processus de déploiement par étapes pour l'exemple des trois régions :

flowchart TD Start([Début]) --> DeployAsia[Déployer en Asie] DeployAsia --> MonitorAsia[Surveiller l'Asie] MonitorAsia --> AsiaOK{Stable ?} AsiaOK -- Oui --> DeployEurope[Déployer en Europe] AsiaOK -- Non --> RollbackAsia[Annuler en Asie] RollbackAsia --> Fix[Corriger le problème] Fix --> DeployAsia DeployEurope --> MonitorEurope[Surveiller l'Europe] MonitorEurope --> EuropeOK{Stable ?} EuropeOK -- Oui --> DeployAmerica[Déployer en Amérique] EuropeOK -- Non --> RollbackEurope[Annuler en Europe] RollbackEurope --> Fix DeployAmerica --> MonitorAmerica[Surveiller l'Amérique] MonitorAmerica --> AmericaOK{Stable ?} AmericaOK -- Oui --> Done([Terminé]) AmericaOK -- Non --> RollbackAmerica[Annuler en Amérique] RollbackAmerica --> Fix

Avec le déploiement par étapes, vous publiez d'abord en Asie. Votre équipe surveille les taux d'erreur, les temps de réponse et les signalements utilisateurs pendant quelques heures ou un jour. Si tout semble stable, vous publiez en Europe. Après une autre période d'observation, vous publiez en Amérique.

Chaque étape vous offre un point de contrôle. Si l'Asie montre un pic d'erreurs de connexion à la base de données, vous arrêtez le déploiement, corrigez le problème et recommencez depuis le début. Les deux autres régions n'ont jamais vu la version défectueuse.

Ce schéma est courant dans les entreprises qui servent un public mondial. Il est également utilisé en interne avant une publication publique : les utilisateurs internes reçoivent la nouvelle version en premier, puis un petit groupe d'adopteurs précoces externes, puis une région spécifique, puis tout le monde.

Un autre exemple : segmentation par type de compte

Considérez une application fintech avec des utilisateurs gratuits et premium. La nouvelle version inclut un changement majeur dans le module de traitement des paiements. Si quelque chose tourne mal, les utilisateurs premium pourraient ne pas finaliser leurs transactions, ce qui signifie une perte de revenus et des clients mécontents.

Les utilisateurs gratuits n'utilisent pas la fonctionnalité de paiement. Ils constituent un premier groupe plus sûr. Vous publiez d'abord pour les utilisateurs gratuits, surveillez les éventuels effets secondaires dans d'autres parties de l'application, et seulement ensuite publiez pour les utilisateurs premium.

Cette approche fonctionne car le regroupement est basé sur l'utilisation des fonctionnalités, pas seulement sur la géographie. Vous choisissez délibérément un groupe à moindre risque pour absorber l'exposition initiale.

Déploiement en anneaux : un schéma courant

Le déploiement par étapes est souvent implémenté sous forme de déploiement en anneaux (ring deployment). Imaginez des anneaux concentriques qui s'étendent vers l'extérieur :

  • Anneau 0 : Équipe interne et QA
  • Anneau 1 : Adopteurs précoces ou utilisateurs bêta
  • Anneau 2 : Utilisateurs dans une région spécifique ou avec un type de compte particulier
  • Anneau 3 : Tous les utilisateurs

Chaque anneau a ses propres critères, fenêtre d'observation et plan de rollback. Les anneaux intérieurs sont plus petits et plus sûrs. Les anneaux extérieurs sont plus grands et comportent plus de risques. Vous ne vous déplacez vers l'extérieur que lorsque les anneaux intérieurs ne montrent aucun problème critique.

Ce schéma vous offre un processus clair et reproductible pour chaque publication. Vous savez exactement quel groupe reçoit la nouvelle version en premier, combien de temps observer, et quelles métriques déclenchent un arrêt ou un rollback.

Ce qui distingue le déploiement par étapes du canary

La différence clé est l'intentionnalité. Le déploiement canary dit : « Envoyez 5 % du trafic vers la nouvelle version, aléatoirement. » Le déploiement par étapes dit : « Envoyez tout le trafic d'Asie vers la nouvelle version d'abord, puis l'Europe, puis l'Amérique. »

Le canary est statistique. Il suppose qu'un échantillon aléatoire représente l'ensemble de la base d'utilisateurs. Le déploiement par étapes est catégoriel. Il suppose que différents groupes d'utilisateurs ont des profils de risque différents, et que vous voulez contrôler l'ordre d'exposition.

Les deux réduisent les risques, mais ils résolvent des problèmes différents. Le canary est bon pour détecter les problèmes généraux tôt. Le déploiement par étapes est bon pour détecter les problèmes spécifiques à un groupe avant qu'ils ne se propagent.

Les prérequis d'infrastructure

Le déploiement par étapes n'est pas gratuit. Vous avez besoin d'une infrastructure capable de router les utilisateurs en fonction d'attributs, pas seulement de pourcentages de trafic. Cela implique généralement :

  • Un équilibreur de charge ou un service mesh qui prend en charge le routage basé sur les en-têtes ou les cookies
  • Une logique applicative capable de lire le contexte utilisateur et de diriger les requêtes vers la version correcte
  • Des feature flags ou des emplacements de déploiement qui correspondent à des groupes d'utilisateurs spécifiques
  • Des outils d'observabilité capables de découper les métriques par groupe, pas seulement globalement

Sans observabilité par groupe, le déploiement par étapes est aveugle. Vous devez comparer les taux d'erreur, la latence et les métriques métier entre le groupe qui a reçu la nouvelle version et celui qui ne l'a pas reçue. Un graphique d'erreur global ne vous dira pas si l'Asie échoue alors que l'Europe va bien.

Quand ne pas utiliser le déploiement par étapes

Le déploiement par étapes ajoute de la complexité. Si votre changement est mineur, votre risque est faible et votre base d'utilisateurs est homogène, une mise à jour progressive (rolling update) ou un simple canary suffit. Ne sur-ingéniez pas la stratégie de déploiement pour une correction de typo ou une modification UI mineure.

De plus, le déploiement par étapes ne fonctionne pas bien lorsque vous ne pouvez pas identifier de manière fiable les groupes d'utilisateurs au niveau du routage. Si votre application n'a pas de comptes utilisateurs, ou si tout le trafic passe par un point d'entrée unique sans contexte, vous n'aurez peut-être pas les données nécessaires pour définir des groupes pertinents.

Une checklist pratique rapide

Si vous décidez d'implémenter un déploiement par étapes, voici les points à maîtriser :

  • Définissez vos groupes en fonction du risque, pas de la commodité. Le premier groupe doit être le plus sûr, pas le plus facile à router.
  • Fixez des fenêtres d'observation avec des critères de succès clairs. Ne passez à l'étape suivante que lorsque vous avez suffisamment de données.
  • Ayez un plan de rollback pour chaque étape. Si l'Asie échoue, pouvez-vous annuler uniquement l'Asie sans affecter les autres ?
  • Assurez une observabilité par groupe. Vos tableaux de bord doivent afficher les métriques ventilées par groupe.
  • Communiquez le plan de déploiement à l'équipe. Tout le monde doit savoir quel groupe est en production et quand l'étape suivante commence.

L'essentiel à retenir

Le déploiement par étapes vous donne le contrôle sur qui reçoit une nouvelle version en premier. Ce n'est pas un remplacement des déploiements canary. C'est un outil différent pour une situation différente : lorsque vous savez que vos utilisateurs ne sont pas tous identiques, et que vous voulez protéger les groupes les plus précieux ou les plus vulnérables en les exposant en dernier.

La prochaine fois que vous planifiez une publication risquée, demandez-vous : « Si cela échoue, quel groupe d'utilisateurs serait le moins douloureux à casser en premier ? » Ce groupe est votre première étape.