Environnements et déploiements : le minimum qui change tout

Le déploiement est la partie du travail qui n’intéresse personne jusqu’au jour où elle empêche tout. J’ai vu des équipes excellentes bloquées non par la difficulté du code, mais par l’impossibilité de le mettre en ligne sans une opération manuelle risquée.

Voici le minimum que nous mettons en place, et ce qui se dégrade quand il manque.

Trois environnements, pas plus

Le local. Chaque développeur fait tourner l’application entière sur sa machine, avec des données de test. C’est la base de tout : si l’application ne tourne pas en local, chaque vérification passe par un environnement partagé, et le cycle s’allonge d’un facteur dix.

La préproduction. Aussi proche de la production que possible : même version des composants, même configuration, données représentatives. C’est là que se fait la recette. Une préproduction qui diverge de la production ne prouve rien — et donne une fausse confiance, ce qui est pire que pas de préproduction du tout.

La production. Personne n’y intervient à la main. Toute modification passe par la chaîne automatisée. C’est la règle la plus difficile à tenir et la plus importante : une correction appliquée directement en production existe désormais nulle part ailleurs, et disparaîtra au prochain déploiement.

Au-delà de trois, chaque environnement supplémentaire coûte en maintenance et en synchronisation sans apporter grand-chose. Nous en ajoutons parfois un quatrième, temporaire, pour une migration — et nous le supprimons ensuite.

Ce que la chaîne doit faire

À chaque modification proposée : construire l’application depuis zéro, exécuter les tests, vérifier les dépendances vulnérables. Si l’un échoue, la modification ne part pas.

Au déploiement : construire une fois, déployer le même artefact en préproduction puis en production. Ce point est essentiel — reconstruire entre les deux environnements signifie que ce qui a été recetté n’est pas exactement ce qui est mis en ligne.

Et surtout : pouvoir revenir en arrière. Redéployer la version précédente doit prendre quelques minutes et ne demander aucune réflexion. C’est ce qui permet de livrer sereinement, donc de livrer souvent.

Le retour arrière et les données

Le point qui rend le retour arrière compliqué n’est jamais le code : c’est la base de données.

Une modification de schéma appliquée puis annulée peut détruire des données. Notre règle : les changements de schéma sont compatibles avec l’ancienne version du code. On ajoute une colonne, on déploie le code qui l’utilise, et on ne supprime l’ancienne qu’au déploiement suivant, une fois la nouvelle version stabilisée.

Cela demande de découper une modification en deux ou trois livraisons au lieu d’une. C’est le prix d’un retour arrière réellement possible, et il est très inférieur au coût d’un incident qu’on ne peut pas annuler.

Le seul indicateur qui résume tout

Combien de temps faut-il pour mettre en production une correction d’une ligne ?

C’est la question que je pose en premier lors d’un audit, et elle agrège tout : qualité des tests, automatisation, lourdeur des validations, connaissance de la procédure.

Moins d’une heure : la chaîne est saine, on peut s’engager sur des délais courts. Une journée : acceptable, avec des marges. Plusieurs jours : aucun engagement de rétablissement n’est tenable, quelle que soit la qualité du code. « On ne sait pas » : c’est le vrai chantier, avant toute évolution fonctionnelle.

Photo : domaine public (CC0).

Les secrets et la configuration

Un point qui cause des incidents évitables.

Aucun mot de passe, clé ou certificat dans le dépôt, même privé. La configuration qui diffère entre environnements est injectée à l’exécution. Et l’inventaire de ces valeurs est documenté : la question « quelles variables faut-il pour démarrer cette application ? » doit avoir une réponse écrite.

C’est exactement ce qui manque le plus souvent lors des reprises de projet, et ce qui transforme une remise en route de deux heures en une journée d’enquête.

Photo : domaine public (CC0).

Les données des environnements de test

C’est le sujet le plus souvent traité à la légère, et celui qui expose le plus.

Copier la base de production dans un environnement de test est la pratique la plus répandue et la plus risquée. Cet environnement a des accès plus larges, moins de surveillance, et parfois des comptes partagés — pour des données strictement identiques à celles de production.

Trois approches, par ordre de préférence.

Des données inventées, générées. C’est le plus propre et le plus long à mettre en place. Le principal défaut est qu’elles ne reproduisent pas les cas tordus que dix ans d’exploitation ont accumulés.

Un extrait anonymisé de la production. Le meilleur compromis en pratique : la structure et les volumes sont réalistes, les identités ne le sont pas. L’anonymisation doit être cohérente — le même client doit porter le même faux nom partout — sinon les tests métier deviennent ininterprétables.

La production copiée telle quelle. À réserver à un incident précis, sur un environnement restreint, et à détruire ensuite. Jamais comme fonctionnement permanent.

Un détail qui a des conséquences réelles : couper les envois sortants dans tout environnement qui n’est pas la production. Les courriels partis d’un environnement de test vers de vrais clients sont un incident classique, et il se produit toujours au moment d’une reprise de données.

Revenir en arrière, et le prouver

Un déploiement n’est fiable que si le retour arrière l’est. Or il est presque toujours moins testé que l’aller.

Le point qui coince n’est jamais le code : c’est la base de données. Revenir à la version précédente d’une application dont le schéma a déjà changé ne fonctionne pas, sauf si les migrations ont été pensées pour cela.

La règle qui rend le retour arrière possible : séparer les changements de schéma des changements de code, et les déployer d’abord. On ajoute une colonne, on déploie ; le code suivant sait l’utiliser mais l’ancien sait encore fonctionner sans elle. La suppression de l’ancienne colonne intervient plusieurs déploiements plus tard, une fois qu’on est certain de ne plus revenir en arrière.

Cela demande un peu de discipline et rend chaque mise en production nettement moins tendue.

Combien d’environnements, vraiment

La réponse courante — développement, recette, préproduction, production — est souvent une de trop.

Un environnement n’est pas gratuit : il faut le maintenir, l’alimenter en données, le mettre à jour et le surveiller. Un environnement mal tenu est pire que pas d’environnement du tout, parce qu’on y teste sur une configuration qui ne ressemble plus à rien.

Ce que je recommande sur une équipe de taille modeste : la production, un environnement de recette identique à la production, et des environnements éphémères créés automatiquement pour chaque modification en cours. Ces derniers vivent quelques jours et disparaissent — ils n’accumulent donc jamais de dérive.

La préproduction permanente ne se justifie que dans un cas : quand une répétition générale est nécessaire avant chaque mise en production, typiquement à cause d’une reprise de données lourde ou d’un enchaînement complexe avec des systèmes tiers.

Ce que ça coûte à mettre en place

Sur un projet neuf : une à deux journées. C’est la meilleure dépense du projet, et elle se rentabilise avant la fin du premier mois.

Sur un projet existant sans rien : compter une à deux semaines, et l’annoncer comme un chantier à part entière plutôt que de le glisser entre deux fonctionnalités. C’est un investissement dont le rendement se mesure sur chaque livraison ultérieure — et il est difficile de le justifier autrement que par le délai de mise en production, qui a l’avantage d’être un chiffre.