Quand un déploiement est-il vraiment terminé ?

Vous venez d'exécuter votre commande de déploiement. Le terminal affiche un résultat vert et propre. Pas d'erreurs. Pas d'avertissements. Le nouveau conteneur tourne. Les fichiers sont en place. Votre équipe commence à ranger pour rentrer chez elle.

Mais le déploiement est-il vraiment terminé ?

La plupart des équipes considèrent le moment où la commande de déploiement se termine comme la ligne d'arrivée. C'est une hypothèse dangereuse. Ce que vous savez à ce stade, c'est seulement que le processus de déplacement des fichiers ou de redémarrage des services s'est déroulé avec succès. Vous ne savez pas encore si l'application fonctionne réellement.

La différence entre déployer et être en bonne santé

Un déploiement comporte deux phases distinctes. La première est l'acte technique de mettre la nouvelle version en place. La seconde consiste à vérifier que la nouvelle version se comporte correctement. De nombreuses équipes s'arrêtent après la première phase et considèrent le travail comme terminé.

Le diagramme suivant illustre le processus en deux phases décrit ci-dessus :

flowchart TD A[Phase de déploiement] --> B[Déplacer fichiers / redémarrer services] B --> C[Déploiement réussi] C --> D[Phase de vérification] D --> E[Tests de fumée] E --> F[Transactions synthétiques] F --> G[Signaux de monitoring] G --> H[Taux d'erreur, latence, ressources] H --> I[Preuves collectées] I --> J[Déploiement terminé] C -.->|Pas terminé| K[Déploiement NON terminé] style J fill:#a3d9a5 style K fill:#f4a3a3

Pensez à ce qui peut mal tourner après un déploiement réussi :

  • Le nouveau code a une erreur de configuration qui n'apparaît que sous un trafic réel
  • Une migration de base de données a réussi, mais le code applicatif attend un nom de colonne différent
  • Une dépendance a été mise à jour et a cassé une intégration que les tests unitaires n'ont pas détectée
  • La nouvelle version utilise plus de mémoire et déclenche un OOM killer après quelques minutes

Aucun de ces problèmes n'apparaîtrait dans vos logs de déploiement. Le terminal dirait toujours "déploiement réussi". Mais l'application serait cassée.

Ce qui compte comme preuve

Un déploiement n'est terminé que lorsque vous avez la preuve que la nouvelle version est saine et prête à servir les utilisateurs. Cette preuve doit être mesurable et vérifiable. Les intuitions et "ça m'a l'air bien" ne comptent pas.

Les preuves proviennent de multiples sources. Les tests de fumée constituent la couche la plus basique. Ils vérifient que l'application démarre, que la page principale se charge et que les fonctionnalités principales répondent. Un test de fumée qui échoue signifie que quelque chose de fondamental ne va pas.

Voici un script minimal qui automatise la première couche de collecte de preuves après un déploiement :

#!/bin/bash
# post-deploy-verify.sh - À exécuter après la commande de déploiement

set -euo pipefail

URL="https://your-app.example.com"
DB_CONN_STRING="postgresql://user:pass@db-host:5432/app"

# 1. Health check
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$URL/health")
if [ "$HTTP_CODE" -ne 200 ]; then
  echo "ÉCHEC: Health check a retourné $HTTP_CODE"
  exit 1
fi
echo "RÉUSSI: Health check a retourné 200"

# 2. Test de fumée - la page principale se charge
if ! curl -s "$URL" | grep -q "<title>App</title>"; then
  echo "ÉCHEC: La page principale ne contient pas le titre attendu"
  exit 1
fi
echo "RÉUSSI: La page principale se charge correctement"

# 3. Test de connectivité à la base de données
if ! psql "$DB_CONN_STRING" -c "SELECT 1" > /dev/null 2>&1; then
  echo "ÉCHEC: Connexion à la base de données impossible"
  exit 1
fi
echo "RÉUSSI: Connexion à la base de données réussie"

echo "Tous les tests passés - preuves de déploiement collectées"

Les transactions synthétiques vont plus loin. Elles simulent des parcours utilisateur réels : connexion, recherche de données, soumission d'un formulaire, validation d'une commande. Si une transaction synthétique réussit, vous savez qu'un parcours utilisateur complet fonctionne de bout en bout.

Ensuite, il y a les signaux système dont nous avons parlé plus tôt dans cette série. Après le déploiement, vous devez vérifier si la disponibilité reste stable, si les taux d'erreur n'augmentent pas et si la latence ne se dégrade pas. Si tous ces signaux semblent normaux, vous avez de bonnes raisons de penser que la nouvelle version ne cause pas de problèmes.

Le piège de la vérification informelle

Le vrai danger n'est pas que les équipes sautent complètement la vérification. C'est qu'elles le font de manière informelle. Un développeur jette un coup d'œil à un tableau de bord, voit des barres vertes et suppose que tout va bien. Mais ce coup d'œil pourrait manquer une augmentation subtile des erreurs 500. Il pourrait manquer le fait que le flux de paiement expire pour un sous-ensemble d'utilisateurs.

La vérification informelle échoue parce qu'elle repose sur l'attention et la mémoire humaines. Le développeur qui a déployé pourrait être fatigué après une longue journée. Il pourrait être pressé de rejoindre une autre réunion. Il pourrait ne pas savoir exactement quels signaux vérifier pour ce changement particulier.

La solution est de définir vos critères de preuve avant de déployer. Décidez à l'avance quels signaux prouveront que le déploiement est terminé. Notez-les. Rendez-les explicites.

Un ensemble raisonnable de critères pourrait ressembler à ceci :

  • Le test de fumée pour la page principale et le flux de connexion réussit
  • Les transactions synthétiques pour les trois parcours utilisateur les plus critiques réussissent
  • Le taux d'erreur reste inférieur à 0,1 pour cent
  • La latence P95 n'augmente pas de plus de 5 pour cent par rapport à la ligne de base avant déploiement
  • L'utilisation du pool de connexions à la base de données reste inférieure à 70 pour cent

Lorsque toutes ces conditions sont remplies, le déploiement est terminé. Si une condition échoue, le déploiement n'est pas terminé, même si la commande de déploiement a réussi.

Qui décide que le déploiement est terminé

Dans une petite équipe, c'est souvent le développeur qui a déployé qui prend la décision. Il vérifie les critères, examine les signaux et décide si le travail est terminé. Cela fonctionne quand l'équipe est petite et que tout le monde connaît bien le système.

Au fur et à mesure que l'équipe grandit, la décision devrait être confiée à l'automatisation. Le pipeline lui-même ne devrait pas marquer le déploiement comme terminé tant que toutes les vérifications automatisées ne sont pas passées. Cela supprime le jugement humain de la boucle et assure la cohérence. Chaque déploiement reçoit la même vérification, à chaque fois.

Pour les changements à haut risque, vous pourriez toujours vouloir un humain dans la boucle. Un ingénieur senior ou une personne d'astreinte peut examiner les preuves et prendre la décision finale. Mais même dans ce cas, les critères doivent être clairs. L'humain ne devine pas si les choses semblent correctes. Il vérifie une liste prédéfinie de conditions.

Il n'y a pas de règle universelle sur la quantité de preuves nécessaire. Un correctif de bug mineur pour un outil interne nécessite moins de vérification qu'un changement de fonctionnalité majeur pour un système de paiement destiné aux clients. L'important est que votre équipe se mette d'accord sur les critères pour chaque type de changement.

Une liste de contrôle pratique pour l'achèvement du déploiement

Voici une liste de contrôle simple que vous pouvez adapter pour votre équipe :

  • La commande de déploiement s'est terminée sans erreur
  • Les tests de fumée ont réussi (page principale, connexion, fonctionnalités principales)
  • Les transactions synthétiques ont réussi (parcours utilisateur critiques)
  • Le taux d'erreur est dans la plage acceptable
  • La latence est dans la plage acceptable
  • L'utilisation des ressources (CPU, mémoire, connexions) est stable
  • Aucune alerte déclenchée par les systèmes de monitoring
  • Les migrations de base de données appliquées et vérifiées

Si un élément échoue, le déploiement n'est pas terminé. Enquêtez avant de déclarer le succès.

Ce qui change quand vous faites les choses correctement

Lorsque votre équipe convient que le déploiement n'est pas terminé tant qu'il n'y a pas de preuve de bon fonctionnement, l'ensemble du processus de déploiement change. Le déploiement cesse d'être une tâche technique qui se termine au terminal. Il devient une transition qui se termine lorsque les utilisateurs peuvent utiliser la nouvelle version en toute sécurité.

Ce changement modifie les comportements. Les équipes commencent à écrire de meilleurs tests de fumée parce qu'elles savent que ces tests déterminent si elles peuvent rentrer chez elles. Elles commencent à définir des critères clairs avant de déployer, pas après. Elles arrêtent de se précipiter pour clore le déploiement et commencent à prêter attention à ce qui se passe après la mise en ligne de la nouvelle version.

La prochaine fois que votre équipe effectuera un déploiement, observez ce qui se passe après la fin de la commande. Est-ce que tout le monde se détend et passe à autre chose ? Ou vérifient-ils d'abord les preuves ? Ce moment vous indique si votre équipe comprend vraiment quand un déploiement est terminé.