Pourquoi les vérifications manuelles après déploiement échoueront (et que faire à la place)

Vous venez de déployer une nouvelle version. Vous ouvrez votre navigateur, cliquez sur quelques pages, vérifiez que la base de données répond, et tout semble correct. Vous fermez l'onglet et passez à autre chose.

Cela fonctionne quand vous déployez une fois par semaine. Mais quand les déploiements ont lieu quotidiennement, ou plusieurs fois par jour, cette vérification manuelle cesse d'être fiable. La même personne ne peut pas répéter exactement la même inspection à chaque fois sans rien oublier. Certaines vérifications sont sautées parce que vous êtes pressé. D'autres sont bâclées parce que la réunion suivante commence. D'autres encore sont considérées comme bonnes parce que "ça a marché la dernière fois".

Le problème n'est pas que les gens sont négligents. Le problème est que la répétition manuelle ne passe pas à l'échelle. Et quand un mauvais déploiement passe à travers parce que quelqu'un a oublié de vérifier un endpoint, c'est toute l'équipe qui en paie le prix.

Le coût réel des vérifications manuelles post-déploiement

Les vérifications manuelles après déploiement créent des risques cachés que les équipes sous-estiment souvent.

D'abord, elles dépendent de la mémoire. La personne qui effectue la vérification doit se souvenir de chaque étape : quels endpoints tester, quelles réponses attendre, quelles requêtes base de données vérifier, quels jobs background confirmer. La mémoire n'est pas fiable, surtout sous pression.

Ensuite, elles varient d'une personne à l'autre. Un ingénieur peut vérifier le flux de connexion et la fonction de recherche. Un autre peut vérifier le processus de commande et le panneau d'administration. Aucun ne vérifie tout, et chacun suppose que l'autre a couvert le reste.

Troisièmement, elles ne laissent pas de trace. Quand une vérification manuelle réussit, il n'y a aucun enregistrement de ce qui a été vérifié, de la réponse obtenue, ou du caractère approfondi de la vérification. Si quelque chose casse une heure plus tard, vous ne pouvez pas consulter les résultats des vérifications pour comprendre ce qui a changé.

Quatrièmement, elles créent un goulot d'étranglement. La personne qui sait comment effectuer les vérifications devient un gardien. Les déploiements l'attendent. Les releases sont retardées. Et si cette personne n'est pas disponible, l'équipe déploie sans vérifications ou ne déploie pas du tout.

Automatiser les vérifications post-déploiement : l'idée centrale

La solution est simple : après que votre pipeline a fini de déployer une nouvelle version, il doit immédiatement exécuter un ensemble prédéfini de vérifications. Ces vérifications s'exécutent de la même manière à chaque fois, sans que personne ait besoin de se souvenir de quoi inspecter.

Le diagramme suivant compare l'approche manuelle et l'approche automatisée décrite ici :

flowchart TD subgraph Manual[Vérifications manuelles post-déploiement] A[Déployer nouvelle version] --> B[Ouvrir navigateur] B --> C[Cliquer sur des pages] C --> D[Vérifier base de données] D --> E[Supposer que tout va bien] E --> F[Fermer l'onglet, passer à autre chose] F --> G[Problèmes manqués découverts plus tard] end subgraph Automated[Vérifications automatisées post-déploiement] H[Déployer nouvelle version] --> I[Pipeline déclenche smoke tests] I --> J[Pipeline exécute transactions synthétiques] J --> K{Tous les tests passent ?} K -->|Oui| L[Release confirmée saine] K -->|Non| M[Alerter immédiatement l'équipe] M --> N[Enquêter sur l'échec spécifique] end Manual -.->|Non fiable| O[L'équipe paie le prix] Automated -.->|Fiable| P[L'équipe a des preuves]

Il ne s'agit pas de tester toutes les fonctionnalités. Il s'agit de vérifier que les fonctions les plus critiques fonctionnent encore après le déploiement. Les vérifications confirment que l'application est vivante, joignable et se comporte correctement au niveau qui compte le plus pour les utilisateurs.

Le pipeline exécute ces vérifications automatiquement. Si elles réussissent toutes, l'équipe a la preuve que la nouvelle version est saine. Si une vérification échoue, le pipeline alerte immédiatement l'équipe, qui sait exactement quelle partie nécessite une attention.

Voici un exemple minimal de ce à quoi pourrait ressembler un tel script de vérification automatisée :

#!/bin/bash
# post-deploy-check.sh
# Exécuté après le déploiement pour vérifier que l'application est saine.

BASE_URL="https://your-app.example.com"
PASS=0
FAIL=1

# Smoke test : vérifier le point d'entrée principal
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$BASE_URL")
if [ "$HTTP_CODE" -ne 200 ]; then
  echo "ÉCHEC : Le point d'entrée principal a retourné $HTTP_CODE"
  exit $FAIL
fi
echo "RÉUSSI : Le point d'entrée principal est joignable"

# Transaction synthétique : simuler un flux de connexion utilisateur
LOGIN_RESPONSE=$(curl -s -X POST "$BASE_URL/api/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"test_user","password":"test_pass"}')

if echo "$LOGIN_RESPONSE" | grep -q '"token"'; then
  echo "RÉUSSI : Le flux de connexion fonctionne"
else
  echo "ÉCHEC : Le flux de connexion a échoué"
  exit $FAIL
fi

echo "Toutes les vérifications ont réussi. Le déploiement est sain."
exit $PASS

Deux types de vérifications automatisées pour commencer

Smoke Tests

Les smoke tests sont la forme la plus simple de vérifications automatisées post-déploiement. Ils vérifient que l'application est en cours d'exécution et répond aux requêtes de base.

Un smoke test peut vérifier :

  • L'application peut-elle accepter des connexions réseau ?
  • Le point d'entrée principal retourne-t-il un code 200 ?
  • La nouvelle version peut-elle atteindre la base de données ?
  • Les routes API critiques répondent-elles ?

Ces vérifications sont faciles à écrire. Ce sont simplement des scripts que votre pipeline appelle après l'étape de déploiement. Si une vérification échoue, le pipeline s'arrête et notifie l'équipe.

Les smoke tests n'ont pas besoin d'être exhaustifs. Ils doivent juste détecter les échecs évidents : un service qui n'a pas démarré, une connexion base de données qui a cassé, une configuration qui a disparu.

Transactions Synthétiques

Les transactions synthétiques vont un cran plus loin. Elles simulent ce qu'un utilisateur réel fait, étape par étape.

Pour une application e-commerce, une transaction synthétique pourrait :

  1. Ouvrir la page de liste des produits
  2. Cliquer sur un produit spécifique
  3. L'ajouter au panier
  4. Procéder au paiement
  5. Remplir les détails de livraison
  6. Confirmer la commande

Chaque étape vérifie que la réponse est correcte. Si la page du panier retourne une erreur, ou si le paiement ne se charge pas, la transaction synthétique échoue et le pipeline sait que quelque chose ne va pas.

Les transactions synthétiques nécessitent plus de configuration que les smoke tests. Vous devez écrire des scripts qui imitent le comportement utilisateur. Mais elles détectent des problèmes que les smoke tests manquent, comme des workflows cassés ou des données manquantes dans un processus en plusieurs étapes.

Par quoi automatiser en premier

N'essayez pas de tout automatiser d'un coup. Commencez par les fonctions qui causeraient le plus de dégâts si elles cassaient.

Demandez à votre équipe : "Si nous déployons et que cette fonctionnalité cesse de fonctionner, à quelle vitesse les utilisateurs le remarqueraient-ils ? Quels dégâts cela causerait-il ?"

Les réponses vous disent quoi automatiser en premier. Pour la plupart des applications, cela signifie :

  • Authentification et connexion
  • Fonctionnalité de recherche
  • Flux de transactions critiques (paiement, réservation)
  • Formulaires de soumission de données
  • Points d'entrée API dont dépendent d'autres services

Commencez avec un ou deux scénarios. Exécutez-les systématiquement après chaque déploiement. Ajoutez-en plus au fil du temps, en voyant ce qui casse et ce qui compte.

Un petit ensemble de vérifications qui s'exécutent à chaque fois est bien plus précieux qu'une grande suite qui échoue constamment à cause de tests instables ou de scénarios non pertinents.

Rendre les résultats visibles

Les vérifications automatisées ne sont utiles que si leurs résultats sont visibles et exploitables.

Votre pipeline doit enregistrer le résultat de chaque vérification. Stockez les résultats avec les logs de déploiement. Affichez-les sur un tableau de bord que l'équipe peut voir.

Quand toutes les vérifications réussissent, l'équipe a la preuve claire que le déploiement est sain. Quand une vérification échoue, l'équipe sait immédiatement quelle partie du système nécessite une investigation.

Cette visibilité change la façon dont l'équipe opère. Au lieu de se demander si un déploiement s'est bien passé, ils ont des données. Au lieu de se fier à la mémoire de quelqu'un, ils ont des enregistrements. Au lieu de découvrir les problèmes par les plaintes des utilisateurs, ils les attrapent quelques minutes après le déploiement.

L'étape suivante : de la vérification à la décision

Une fois que les vérifications automatisées post-déploiement deviennent routinières, l'étape logique suivante est de les utiliser comme une porte. Si les vérifications échouent, le pipeline peut automatiquement arrêter la release avant qu'elle n'atteigne les utilisateurs. Si elles réussissent, la release continue.

Il ne s'agit pas de supprimer le jugement humain. Il s'agit de supprimer le besoin pour les humains de répéter la même vérification manuelle à chaque fois. L'équipe décide quoi vérifier. Le pipeline exécute ces vérifications de manière cohérente. Et l'équipe se concentre sur les exceptions, pas sur la routine.

Checklist pratique pour démarrer

Avant de construire un système d'automatisation complet, commencez petit :

  • Identifiez les trois fonctions les plus critiques pour les utilisateurs dans votre application
  • Écrivez un script de smoke test qui vérifie que vos points d'entrée principaux répondent correctement
  • Écrivez un script de transaction synthétique qui simule un flux utilisateur central
  • Ajoutez ces vérifications à votre pipeline de déploiement, juste après l'étape de déploiement
  • Configurez le pipeline pour notifier l'équipe si une vérification échoue
  • Exécutez les vérifications pendant une semaine et notez les faux positifs ou les lacunes
  • Ajustez les vérifications en fonction de ce que vous apprenez
  • Ajoutez un scénario supplémentaire la semaine suivante

L'essentiel à retenir

Les vérifications manuelles post-déploiement fonctionnent jusqu'au jour où elles ne fonctionnent plus. Dès que votre équipe déploie plus d'une fois par jour, ou dès qu'un mauvais déploiement passe à travers parce que quelqu'un a oublié de vérifier une chose, vous avez besoin d'automatisation.

Commencez par des smoke tests pour la disponibilité de base. Ajoutez des transactions synthétiques pour les flux utilisateur critiques. Rendez les résultats visibles. Et laissez le pipeline gérer la répétition pour que votre équipe puisse se concentrer sur ce qui nécessite réellement une attention humaine.

L'objectif n'est pas d'éliminer la supervision humaine. L'objectif est d'éliminer le type de supervision qui se produit parce que quelqu'un a dû se souvenir de vérifier la même chose pour la centième fois.