Une mise en production progressive consiste à déployer une nouvelle version d’une application d’abord pour une petite partie des utilisateurs, à observer son comportement, puis à l’étendre par paliers jusqu’à tout le monde. Elle s’appuie sur trois outils : des livraisons petites et fréquentes, des interrupteurs de fonctionnalités (feature flags) et un retour arrière rapide et répété à l’avance. Résultat : une anomalie touche quelques personnes pendant quelques minutes, au lieu de bloquer toute l’entreprise un lundi matin.
Ce guide s’adresse aux dirigeants et responsables métier qui pilotent une application interne, un portail client ou un SaaS. Il explique les techniques, ce qu’elles coûtent en organisation et comment choisir la bonne combinaison.
Pourquoi la mise en production est-elle le moment le plus risqué ?
Une application qui tourne sans changement tombe rarement en panne. Ce sont les modifications qui introduisent les défauts. Le livre Site Reliability Engineering de Google l’énonce clairement : environ 70 % des pannes sont dues à des changements apportés à un système en fonctionnement. Les auteurs recommandent d’automatiser trois pratiques pour limiter les dégâts : les déploiements progressifs, la détection rapide des problèmes et le retour arrière sûr.
Dans une PME ou une ETI, le risque prend une forme très concrète :
- les préparateurs ne peuvent plus valider les commandes ;
- les techniciens terrain n’ont plus accès à leurs interventions du jour ;
- les clients du portail voient une page d’erreur au moment de passer commande.
La réaction instinctive consiste à livrer moins souvent, en gros lots soigneusement testés. C’est l’inverse qu’il faut faire : un gros lot contient davantage de changements, donc davantage de causes possibles de panne, et il est plus difficile à diagnostiquer et à annuler. C’est l’une des raisons pour lesquelles nous livrons à chaque sprint des incréments de taille modeste.
Déploiement et mise à disposition : deux décisions distinctes
La notion qui change tout est la séparation entre déployer et mettre à disposition.
- Déployer, c’est installer une nouvelle version du code sur les serveurs de production. C’est une opération technique.
- Mettre à disposition (on parle aussi de « release »), c’est rendre une fonctionnalité visible et utilisable par des utilisateurs. C’est une décision métier.
Tant que les deux sont confondues, chaque livraison est un pari : tout le code est actif pour tout le monde au même instant. Une fois séparées, l’équipe technique peut déployer souvent et sans enjeu, pendant que le responsable métier choisit quand ouvrir chaque fonctionnalité, et à qui.
Un feature flag est un interrupteur dans l’application qui active ou désactive une fonctionnalité sans redéployer le code. C’est l’outil qui rend cette séparation possible.
Les quatre techniques à connaître
Les feature flags (interrupteurs de fonctionnalités)
L’article de référence de Pete Hodgson publié sur martinfowler.com distingue quatre familles d’interrupteurs, qui n’ont ni la même durée de vie ni le même usage :
| Type d’interrupteur | À quoi il sert | Durée de vie typique |
|---|---|---|
| De livraison | Livrer du code inachevé ou non encore ouvert, sans le rendre visible | Courte : une à deux semaines selon l’article |
| D’expérimentation | Comparer deux versions d’un écran ou d’un parcours (test A/B) | Le temps d’obtenir un résultat fiable |
| D’exploitation | Couper ou dégrader une fonction coûteuse en cas de surcharge ou d’incident | Souvent courte, parfois permanente (« coupe-circuit ») |
| De permission | Réserver une fonction à un groupe : pilotes, offre premium, un site | Longue, parfois plusieurs années |
Le même article met en garde : les interrupteurs sont un stock qui a un coût. Chaque interrupteur ajoute une condition dans le code et un cas à tester. Les équipes sérieuses ajoutent une tâche de suppression dès qu’elles créent un interrupteur de livraison, fixent une date d’expiration et limitent leur nombre total.
Le déploiement canari
Le nom vient des mineurs qui descendaient un canari dans la mine : l’oiseau signalait le gaz avant les hommes. Un déploiement canari envoie d’abord une petite partie du trafic ou des utilisateurs vers la nouvelle version, puis élargit à mesure que la confiance grandit. En cas de problème, on redirige tout le monde vers l’ancienne version.
Le guide SRE de Google consacré aux canaris apporte deux conseils très utiles. D’abord, choisir quelques indicateurs qui reflètent directement ce que vit l’utilisateur (taux d’erreur, temps de réponse), en se limitant à une douzaine au plus. Ensuite, comparer le groupe canari au reste des utilisateurs, et non regarder la moyenne globale : un taux d’erreur de 20 % sur 5 % du trafic n’apparaît que comme environ 1 % d’erreurs sur l’ensemble.
Le déploiement bleu-vert
Le principe du déploiement bleu-vert : deux environnements de production aussi identiques que possible. L’un (bleu) sert les utilisateurs pendant que la nouvelle version est installée et vérifiée sur l’autre (vert). Une fois le vert validé, on bascule tout le trafic. En cas de problème, on rebascule vers le bleu, qui fait toujours tourner l’ancienne version.
L’ouverture par groupe pilote
C’est la variante la plus naturelle pour une application métier interne : on active la nouvelle fonctionnalité pour un site, une agence ou un service volontaire, pendant une à deux semaines, avant de l’ouvrir à tous. Techniquement, c’est un interrupteur de permission ; humainement, c’est un excellent levier d’adoption, comme nous l’expliquons dans notre article sur la conduite du changement.
Quelle technique choisir pour votre application ?
Toutes ces techniques ne se valent pas selon le contexte. Voici une grille de décision simple :
| Situation | Combinaison recommandée |
|---|---|
| Application interne, quelques dizaines d’utilisateurs, un seul site | Livraisons fréquentes + interrupteurs de livraison + retour arrière scripté |
| Application interne multi-sites ou multi-services | Ouverture par groupe pilote (site ou service) + interrupteurs de permission |
| Portail client ou extranet à fort trafic | Canari par pourcentage d’utilisateurs + supervision des erreurs et temps de réponse |
| SaaS B2B multi-clients | Interrupteurs par client + ouverture aux clients volontaires + canari technique |
| Application critique pour la production ou la logistique | Bleu-vert + fenêtre de déploiement hors pic d’activité + retour arrière répété |
Dans tous les cas, ces techniques supposent des fondations : un déploiement automatisé (une même commande installe la version en production, sans manipulation manuelle), des tests automatisés qui s’exécutent avant chaque livraison, et une supervision qui alerte avant que les utilisateurs n’appellent le support.
Le point délicat : la base de données
Revenir à l’ancienne version du code est facile. Revenir à l’ancienne structure de la base de données, avec les données saisies entre-temps, l’est beaucoup moins. C’est le principal piège des retours arrière.
La réponse s’appelle le changement en parallèle, ou « expand and contract », décrit par Danilo Sato. Il se déroule en trois temps :
- Étendre : ajouter la nouvelle structure (une colonne, une table) sans supprimer l’ancienne. Les deux versions du code fonctionnent.
- Migrer : faire passer progressivement le code et les données vers la nouvelle structure.
- Contracter : une fois que plus rien n’utilise l’ancienne structure, la supprimer.
Exemple hypothétique : une entreprise de négoce veut scinder le champ « adresse » de ses clients en adresse de facturation et adresse de livraison. Plutôt que de transformer la colonne en une seule opération, l’équipe ajoute les deux nouveaux champs, les alimente en parallèle pendant deux sprints, bascule les écrans un par un, puis retire l’ancien champ. À chaque étape, un retour arrière reste possible sans perte de données. Le sujet rejoint celui de la migration de données : on ne transforme jamais une donnée sans chemin de retour.
La checklist d’une mise en production sereine
Avant chaque livraison significative, vérifiez ces points avec votre équipe ou votre prestataire :
- La livraison est petite : on peut décrire ce qu’elle contient en quelques lignes.
- Les tests automatisés sont passés et la recette métier des fonctions concernées est faite.
- Les nouvelles fonctionnalités sont derrière un interrupteur, fermé par défaut.
- Le groupe pilote est identifié et prévenu, avec un canal pour remonter les problèmes.
- Les indicateurs à surveiller sont listés (erreurs, temps de réponse, volume de transactions métier).
- Le retour arrière est documenté, automatisé et a déjà été répété.
- Les changements de base de données sont compatibles avec la version précédente.
- Le créneau évite les pics d’activité (clôture comptable, inventaire, rush commercial).
- Une personne est disponible pour surveiller pendant l’heure qui suit.
- Les interrupteurs des livraisons précédentes devenus inutiles sont planifiés pour suppression.
Ce dernier point est souvent oublié. Un interrupteur qui reste en place après l’ouverture générale devient de la dette technique : du code mort, des conditions que plus personne ne comprend, des combinaisons non testées.
Ce que cela change pour vos équipes métier
Pour le dirigeant ou le responsable métier, la mise en production progressive a trois effets visibles.
Les livraisons deviennent des non-événements. Plus besoin de prévenir tout le monde d’une coupure, ni de mobiliser une équipe un samedi. Les nouvelles fonctions apparaissent quand le métier décide de les ouvrir.
Le métier reprend la main sur le calendrier. Une fonction peut être prête techniquement et attendre le bon moment : après la formation des équipes, après la clôture de fin de mois, au lancement d’une offre commerciale.
Le droit à l’erreur devient réel. Si une fonction déroute les utilisateurs pilotes, on la referme, on corrige et on rouvre. Personne n’a perdu de journée.
Ces pratiques font partie du socle de toute application web sur mesure bien conçue, et elles se prévoient dès la conception de l’architecture. Elles se mesurent aussi : les indicateurs DORA suivent précisément la fréquence des déploiements, le taux d’échec des changements et le temps de rétablissement.
Par où commencer si vos mises en production sont aujourd’hui stressantes ?
Si chaque livraison mobilise l’équipe tard le soir, inutile de tout transformer d’un coup. Trois étapes, dans cet ordre :
- Automatiser le déploiement : une seule commande, identique à chaque fois, sans manipulation manuelle sur le serveur.
- Rendre le retour arrière trivial, puis le répéter une fois à froid pour vérifier qu’il fonctionne.
- Introduire le premier interrupteur sur la prochaine fonctionnalité importante, avec un groupe pilote.
Vous voulez savoir si votre application actuelle permet ce type de livraison, ou concevoir une nouvelle application qui l’intègre dès le départ ? Décrivez votre contexte dans notre diagnostic de projet en ligne : il prend deux minutes et nous revenons vers vous avec une première analyse.
