Le déploiement du vendredi : ce qu'il faut avoir avant de pouvoir se le permettre

La règle est presque universelle et elle est rarement discutée : on ne met pas en production le vendredi. Elle a l’apparence du bon sens, elle a évité des week-ends gâchés à beaucoup de monde, et personne n’a envie de passer pour l’imprudent qui la conteste. Je voudrais pourtant la prendre au sérieux, parce qu’elle dit quelque chose de précis sur l’état d’une organisation — et ce qu’elle dit n’est pas ce qu’on croit. Une équipe qui s’interdit de déployer le vendredi n’a pas décidé d’être prudente. Elle a constaté qu’elle ne sait pas revenir en arrière, et elle a choisi d’organiser sa semaine autour de cette incapacité plutôt que de la corriger.

Le raisonnement tient en une observation : si déployer le vendredi est dangereux, alors déployer est dangereux. Le lundi ne rend pas l’opération plus sûre ; il rend seulement ses conséquences plus faciles à absorber, parce qu’il reste 4 jours ouvrés pour réparer. La règle n’achète donc pas de la sécurité, elle achète du temps de réparation. C’est un arbitrage défendable à court terme, et coûteux à long terme : il gèle la capacité de livrer 1 jour sur 5 et il dissimule le problème réel.

Les quatre capacités, et ce qui les invalide

Capacité	Le test	Ce qui l’invalide
Retour arrière	Combien de minutes, et exécuté quand pour la dernière fois ?	Procédure documentée mais jamais exercée depuis 6 mois
Déploiement ≠ activation	Peut-on activer une fonctionnalité sans déployer ?	Livrer du code équivaut à activer une fonctionnalité
Observabilité métier	En combien de temps une chute des commandes alerte-t-elle ?	Alertes sur l’infrastructure seulement, pas sur le métier
Migrations réversibles	La dernière migration était-elle annulable ?	Colonne supprimée, transformation appliquée en place

Une équipe qui répond correctement aux quatre déploie le vendredi sans y penser. Une équipe qui échoue sur une seule a un chantier — et la règle du vendredi ne fait que le masquer.

Première capacité : un retour arrière mesuré

Tout commence ici, et rien de ce qui suit n’a de valeur sans cette base.

La question à poser à une équipe n’est pas « avez-vous un retour arrière », à laquelle tout le monde répond oui. Elle est : combien de minutes, et quand l’avez-vous exécuté pour la dernière fois. Ces deux questions produisent des silences instructifs.

Un retour arrière qui existe dans la documentation mais qui n’a pas été exercé depuis 6 mois n’existe pas. Il dépend d’un script qui a peut-être dérivé, d’une variable d’environnement qui a changé, d’une personne qui connaît la manipulation et qui est en vacances. Le jour où on en a besoin, on est en situation d’incident, sous stress, et l’on découvre la procédure en même temps qu’on l’exécute.

Un retour arrière opérationnel a trois propriétés : son délai est connu et se compte en minutes, il a été exécuté récemment en conditions normales, et n’importe quel membre de l’équipe peut le déclencher. Une équipe qui possède cela a transformé un incident potentiel en désagrément borné — et le jour de la semaine cesse mécaniquement d’être un facteur.

Deuxième capacité : découpler le déploiement de l’activation

C’est le changement qui produit le plus grand effet sur le risque, et il est souvent plus simple à mettre en place qu’on ne l’imagine.

Tant que mettre du code en production signifie activer une fonctionnalité, chaque déploiement est un événement à double enjeu : le code fonctionne-t-il, et la fonctionnalité est-elle bonne. Ces deux questions se mélangent, alors qu’elles ne se répondent ni au même moment ni par les mêmes personnes.

Les séparer consiste à livrer le code inactif, derrière un interrupteur. Le déploiement devient alors une opération technique, vérifiable immédiatement et sans conséquence visible. L’activation devient une décision produit, prise quand on veut, réversible en secondes, sans nouvelle mise en production. On peut activer pour l’équipe interne, puis pour 1 % du trafic, puis pour tout le monde — et désactiver aussi vite si les indicateurs se dégradent.

Cette séparation a un effet secondaire précieux : elle rend le déploiement ennuyeux. Or l’ennui est exactement l’objectif recherché en matière de mise en production.

La question n’est pas « à quelle fréquence cassez-vous la production », mais « combien de temps vous faut-il pour vous en apercevoir, et combien pour revenir ». Une équipe qui répond en minutes peut déployer n’importe quel jour.

Troisième capacité : savoir en combien de temps on le remarque

Le retour arrière ne sert à rien si la dégradation n’est pas détectée. Et c’est là que beaucoup d’équipes se croient outillées alors qu’elles ne le sont pas.

Un tableau de bord n’est pas de l’observabilité. Un tableau de bord suppose que quelqu’un le regarde, ce qui est vrai pendant l’heure qui suit un déploiement et faux ensuite. Ce qu’il faut, ce sont des alertes qui se déclenchent seules, sur des indicateurs qui reflètent l’expérience réelle du client plutôt que la santé de l’infrastructure.

La distinction est importante. Une alerte sur le taux d’erreur du serveur détecte une panne franche. Elle ne détecte pas le cas beaucoup plus fréquent où tout répond correctement mais où le bouton d’ajout au panier ne fonctionne plus sur un navigateur, où le tunnel de paiement a perdu une option de livraison, où la recherche retourne des résultats vides. Ces dégradations sont invisibles pour l’infrastructure et coûteuses pour le chiffre d’affaires.

Les indicateurs qui méritent une alerte sont donc métier : commandes par heure comparées à la même heure la semaine précédente, taux de passage entre les étapes du tunnel, volume de recherches sans résultat. Ce sont eux qui répondent à la question « quelqu’un s’en apercevrait-il ».

Quatrième capacité : des migrations de données réversibles

C’est la capacité la plus technique et celle qui est le plus souvent négligée, parce qu’elle ne se voit pas tant qu’elle n’a pas manqué.

Le retour arrière du code est simple : on redéploie la version précédente. Le retour arrière d’une migration de base de données ne l’est pas. Une colonne supprimée a emporté ses données. Une transformation appliquée en place n’a pas conservé l’état antérieur. Dans ces situations, revenir au code précédent ne suffit plus, et l’incident change de nature — on ne parle plus de minutes mais d’heures, avec une restauration de sauvegarde et une perte de données récentes.

La discipline qui évite cela est connue et exige surtout de la rigueur : on n’applique jamais une modification destructrice dans le même déploiement que le code qui en dépend. On ajoute d’abord, on écrit dans les deux formats, on bascule la lecture, on vérifie sur plusieurs jours, et on ne supprime l’ancien qu’ensuite. Chaque étape est individuellement réversible.

C’est plus lent qu’une migration en une passe. C’est aussi ce qui distingue un système où l’on peut revenir en arrière d’un système où l’on ne peut qu’avancer en espérant.

Le paradoxe : déployer plus souvent réduit le risque

Ces quatre capacités produisent un effet contre-intuitif qu’il vaut la peine d’énoncer, parce qu’il inverse l’intuition habituelle sur le risque.

Une équipe qui déploie rarement accumule beaucoup de changements par livraison. Quand quelque chose casse, la surface de recherche est large et le diagnostic est long. La rareté des déploiements rend chacun plus risqué, ce qui justifie de les espacer davantage — la boucle se referme sur elle-même.

Une équipe qui déploie plusieurs fois par jour livre de petits changements. Quand quelque chose casse, le coupable est évident : c’est ce qui vient d’être livré. Le diagnostic prend des minutes, le retour arrière aussi. La fréquence réduit le risque unitaire au lieu de l’augmenter.

C’est pourquoi la règle du vendredi est autolimitante. En gelant 1 jour sur 5, elle réduit la fréquence, donc augmente la taille des lots, donc augmente le risque de chaque déploiement, donc renforce la justification de la règle.

Les quatre questions que je pose en audit

Je ne demande jamais à une équipe si elle déploie le vendredi. Je pose quatre questions dont les réponses se vérifient dans les journaux : combien de minutes pour un retour arrière, et quand a-t-il été exécuté pour la dernière fois ; peut-on activer une fonctionnalité sans déployer ; en combien de temps une dégradation du tunnel de commande déclenche-t-elle une alerte ; la dernière migration de données était-elle réversible.

Une équipe qui répond correctement aux quatre peut déployer le vendredi à 16 h, et elle le fait sans y penser. Une équipe qui échoue sur l’une d’elles a un chantier à mener — et ce chantier vaut infiniment mieux que la règle qui masque le problème. C’est d’ailleurs le même raisonnement que celui qui gouverne les contraintes de performance en intégration continue : une garantie qui n’est pas exercée automatiquement n’existe pas¹.

---

Footnotes

1. Sur l’application automatique des garanties en intégration continue, et la différence entre une contrainte opposable et une intention documentée, voir Un budget de performance sert à refuser des fonctionnalités. ↩