Qu'est-ce que le déploiement canary ? Guide pratique
Résumé
Un déploiement canary envoie une nouvelle version à une petite part du trafic réel, souvent 1 % à 5 %, avant de la généraliser. Vous comparez le taux d'erreur et la latence avec la version stable, vous élargissez la tranche si tout tient, et vous remettez le poids du canari à zéro si ça ne tient pas. Cela limite les dégâts d'une mauvaise livraison, mais demande des métriques par version et assez de trafic pour que le résultat ait du sens.
Qu'est-ce que le déploiement canary ? C'est une mise en production où la nouvelle version de votre application reçoit d'abord une petite part du trafic réel, disons 1 % à 5 %, pendant que le reste des utilisateurs reste sur l'ancienne version. Vous surveillez les taux d'erreur et la latence sur cette tranche. Si elle se comporte bien, vous l'élargissez. Si elle se dégrade, vous renvoyez le trafic vers la version stable, et presque personne ne s'en aperçoit. L'idée tient en une phrase. Le reste de cet article explique comment la faire tenir en pratique.
Pourquoi parle-t-on de canari ?
Les mineurs emportaient autrefois des canaris sous terre, parce que l'oiseau réagissait au gaz toxique avant eux. Un canari qui cessait de chanter signalait qu'il fallait sortir. Dans un déploiement canary, un petit groupe d'utilisateurs touche le nouveau code en premier et joue le même rôle d'alerte précoce. Le glossaire CNCF le décrit comme deux environnements : l'un sert le trafic en direct, l'autre fait tourner le code mis à jour, et le trafic bascule progressivement, en commençant par une petite part comme 1 %.
Ce qui complique les choses en pratique : les utilisateurs du canari sont de vrais utilisateurs, et la préproduction ne peut pas les remplacer. La production a les navigateurs bizarres, les caches périmés et le client qui importe un fichier de 40 Mo. Le canari sert à rencontrer tout cela avant que tout le monde tombe sur votre bug.
Comment fonctionne concrètement un déploiement canary ?
Quatre pièces, rien d'exotique.
Deux versions qui tournent en parallèle : l'ancienne (stable) et la nouvelle (canari). Les deux doivent pouvoir répondre aux requêtes en même temps.
Un répartiteur de trafic : un load balancer, un contrôleur d'entrée, un service mesh ou une règle CDN qui envoie un pourcentage configurable vers le canari.
Des métriques en lesquelles vous avez confiance : taux d'erreur, latence, et au moins un signal métier comme le taux de paiements réussis ou les inscriptions.
Une règle d'avancement ou d'arrêt, écrite avant le déploiement et pas inventée à 23 h devant les graphiques.
Une montée typique suit les paliers 1 %, 5 %, 25 %, 50 %, 100 %, avec une pause à chaque étape. Google Cloud Deploy décrit la même logique : vous définissez une suite de pourcentages, et l'outil répartit le trafic en conséquence. Sa documentation sur les déploiements canary montre aussi qu'à chaque phase, un job de vérification et une étape d'analyse peuvent décider s'il faut avancer.
Ce n'est pas une méthode parfaite, c'est une méthode faisable. Il n'est pas nécessaire d'avoir Kubernetes : une route pondérée dans nginx, une règle Cloudflare ou deux machines Fly.io derrière un même proxy suffisent.
À quoi ressemble la répartition du trafic dans une configuration ?
Voici l'exemple le plus simple et le plus utile : un upstream nginx avec des poids. Neuf requêtes sur dix vont vers la version stable, une sur dix vers le canari.
upstream app {
server 10.0.0.10:3000 weight=9; # stable
server 10.0.0.11:3000 weight=1; # canari
}Cette configuration a un défaut à connaître : la répartition se fait par requête. Un même utilisateur peut donc passer d'une version à l'autre d'un clic à l'autre. Si la nouvelle version change la forme d'une réponse d'API ou d'une colonne de base de données, cet utilisateur va passer un mauvais moment. Un routage collant, par cookie ou par identifiant utilisateur, règle le problème. C'est la première chose à ajouter une fois la répartition de base en place.
Que surveiller pendant que le canari tourne ?
Comparez le canari à la version stable au même moment, pas à la semaine dernière : la semaine dernière n'avait pas le même trafic. La question reste toujours la même : le canari fait-il moins bien que la version qui sert les 95 % restants, à cet instant précis ?
Le taux d'erreur : les 5xx HTTP et les exceptions non gérées, découpés par version.
La latence : les p95 et p99, pas la moyenne. La moyenne masque la queue lente, là où se cachent les régressions.
La saturation : CPU, mémoire, connexions à la base. Une fuite se voit comme une pente, il faut donc laisser le temps passer.
Une métrique métier : si le taux de paiements réussis baisse sur le canari alors que les erreurs restent stables, vous avez livré un bug silencieux.
L'erreur la plus fréquente chez les petites équipes consiste à monter sur un minuteur : cinq minutes à 1 %, puis 25 %, quoi que disent les graphiques. Avec un faible trafic, cinq minutes à 1 % peuvent représenter six requêtes, ce qui ne vous apprend rien. Attendez un nombre minimal de requêtes, pas un nombre minimal de minutes.
Une fois le trafic réel présent, des outils peuvent rendre cette surveillance moins manuelle.
Canari ou blue-green : lequel choisir ?
Le blue-green garde deux environnements complets et bascule tout le trafic d'un coup. Le retour arrière consiste à rebasculer, ce qui est rapide et propre. Le coût : pendant un instant, 100 % des utilisateurs sont sur la nouvelle version, et vous payez une infrastructure double pendant la bascule.
Le canari n'expose qu'une tranche, donc le rayon d'impact est plus petit. Le prix, c'est la complexité : il faut une répartition pondérée du trafic, des métriques par version et une règle de décision. Le retour arrière consiste à remettre le poids du canari à zéro. C'est rapide, sans être littéralement instantané si des connexions doivent se vider.
Trois raisons de choisir le canari, une raison de ne pas le faire. Optez pour le canari quand un bug en production coûte cher, quand vous avez assez de trafic pour qu'une petite tranche ait du sens, et quand vous pouvez comparer les métriques par version. Évitez-le quand vous recevez quelques dizaines d'utilisateurs par jour : la tranche canari sera statistiquement vide et vous ferez des suppositions. À cette échelle, le blue-green, ou même un déploiement simple avec un script de retour arrière rapide, est la réponse honnête.
Les mises à jour progressives (rolling updates) se situent entre les deux. Elles remplacent les instances une par une, ce qui est doux, mais ce n'est pas une expérience contrôlée : vous ne choisissez pas qui voit la nouvelle version et vous ne comparez pas de cohortes.
Où placer les feature flags ?
Un déploiement canary répartit le trafic entre des versions du code. Un feature flag répartit le comportement à l'intérieur d'une même version. On confond souvent les deux, et la confusion coûte cher.
Vous déployez le nouveau code à tout le monde, caché derrière un flag désactivé. Vous activez ensuite le flag pour 1 % des utilisateurs, puis 10 %, puis tout le monde. On parle parfois de release canari au niveau de la fonctionnalité. L'avantage : le retour arrière consiste à couper un flag, sans redéploiement. L'inconvénient : le chemin de code inactif reste en production pour tous, et les flags oubliés deviennent de la dette technique.
Pour un développeur solo, les flags sont généralement la première étape la moins coûteuse. Un booléen dans une table de configuration et un hash de l'identifiant utilisateur donnent environ 80 % de la valeur. Si vous dépassez ce stade, un service managé gère le ciblage, les journaux d'audit et les déploiements progressifs par pourcentage.
Quels problèmes apparaissent dans les vrais projets ?
Testé. Pas optimal. Voici pourquoi on le fait quand même. Ce sont les défaillances qui mordent vraiment.
Migrations de base de données. Les deux versions interrogent la même base en même temps. Si le canari supprime ou renomme une colonne, la version stable casse. La solution est le motif expand and contract : ajoutez d'abord la nouvelle colonne, livrez du code qui gère les deux formes, et ne supprimez l'ancienne que dans une version ultérieure. Sans cela, votre canari fait tomber la version stable.
Sessions avec état. Si les sessions vivent en mémoire sur une instance, un utilisateur qui passe d'une version à l'autre se retrouve déconnecté. Déplacez l'état de session vers un stockage partagé avant de tenter un canari.
Cache corrompu. Une nouvelle version qui écrit un format de cache différent peut corrompre ce que lit l'ancienne. Versionnez vos clés de cache.
Tâches de fond. Le canari consomme aussi les messages de file. Un worker bogué peut dévorer des tâches à pleine vitesse, car le pourcentage de trafic ne limite pas la consommation de la file. Donnez au canari sa propre file ou un poids de consommateur.
Des alertes que personne n'a branchées. Le canari peut échouer bruyamment dans un tableau de bord que personne n'ouvre. Un arrêt automatique sur seuil vaut mieux qu'un humain qui regarde, surtout à 2 h du matin, quand la seule personne réveillée est celle qui a déployé.
Comment démarrer sur un projet perso, et que ne pas canariser ?
Commencez plus petit que vous ne le pensez. Vous êtes un développeur, pas une équipe plateforme.
Étiquetez chaque métrique avec une version. Mettez le SHA git dans un en-tête et dans les journaux. Sans cela, impossible de comparer le canari et la stable.
Choisissez une seule règle d'arrêt. Par exemple : si le taux d'erreur du canari dépasse deux fois celui de la stable pendant cinq minutes, on revient en arrière. Une règle, écrite noir sur blanc.
Ajoutez une route pondérée. Poids nginx, règle Cloudflare ou fonctionnalité de répartition de votre hébergeur. La plupart des plateformes managées proposent désormais un routage en pourcentage sans outillage supplémentaire.
Livrez d'abord quelque chose de banal, une modification de texte plutôt que la refonte de la page tarifs. Entraînez-vous à la montée et au retour arrière quand rien n'est en jeu.
Chronométrez le retour arrière. Exécutez-le réellement une fois. S'il vous prend dix minutes de tâtonnements, c'est ce qu'il faut corriger, pas la montée.
Si votre projet en est encore à découvrir qui paiera pour lui, c'est probablement prématuré. Livrez simplement, gardez un script de retour arrière, et revenez aux canaris le jour où une panne vous coûterait de vrais clients. Si vous y êtes déjà, la route pondérée et une seule règle d'arrêt représentent un week-end de travail, et elles se rentabilisent dès la première fois qu'une mauvaise version meurt à 1 % au lieu de 100 %.
Non, il ne faut pas tout passer en canari. Les changements de configuration, les retouches de texte et la correction d'une faute dans un pied de page n'ont pas besoin de montée progressive. Réservez le canari aux modifications où se tromper coûte de l'argent ou la confiance : paiements, authentification, modèles de données, tout ce qui touche au chemin critique. Un pipeline qui monte chaque commit pendant une heure finira par être contourné dès que quelqu'un est pressé, et un processus contourné est pire qu'aucun processus.
Quelle est la modification la plus risquée de votre prochaine livraison, et que faudrait-il pour l'envoyer d'abord à 1 % des utilisateurs ?