Comment vérifier si votre nouvelle version fonctionne réellement

Vous venez de terminer un déploiement. Le pipeline est vert. La nouvelle version est en ligne. Quelqu'un dans l'équipe ouvre un navigateur, charge la page d'accueil et dit "Ça a l'air correct." Tout le monde souffle et passe à autre chose.

Cette sensation est familière, mais elle est aussi dangereuse. Une personne qui vérifie une seule page n'est pas un processus reproductible. Cela ne vous dit pas si les autres fonctionnalités marchent. Cela ne vous dit pas si l'API répond correctement. Et cela ne vous dit certainement pas si les utilisateurs auront une bonne expérience.

Si votre vérification de déploiement repose sur l'intuition de quelqu'un, vous utilisez essentiellement vos utilisateurs comme premier système de détection. Au moment où ils signalent un problème, les dégâts sont déjà faits.

Le problème des vérifications manuelles

Les vérifications manuelles après déploiement présentent trois défauts fondamentaux.

Premièrement, elles sont incohérentes. La personne qui vérifie aujourd'hui peut regarder des choses différentes de celle qui vérifiera demain. L'une peut vérifier la page de connexion. L'autre peut vérifier la fonctionnalité de recherche. Vous ne pouvez pas comparer les résultats entre les déploiements parce que les vérifications elles-mêmes changent constamment.

Deuxièmement, les vérifications manuelles sont superficielles. Un humain ne peut vérifier qu'une poignée de pages ou de points d'accès dans un temps raisonnable. Les workflows complexes impliquant plusieurs étapes sont rarement testés manuellement après chaque déploiement. Les choses qui cassent le plus souvent sont justement ces flux multi-étapes que personne ne vérifie.

Troisièmement, les vérifications manuelles sont lentes. Au moment où quelqu'un finit de vérifier quelques pages, le déploiement peut déjà servir des milliers d'utilisateurs. Si quelque chose est cassé, ces utilisateurs sont déjà impactés.

C'est là que la vérification en tant que processus structuré entre en jeu. La vérification consiste à contrôler si une version nouvellement déployée fonctionne réellement correctement, non seulement du côté serveur mais du point de vue de l'utilisateur. Elle répond à une question : "Les gens peuvent-ils utiliser cette version sans rencontrer de problèmes évidents ?"

Commencez par des tests de fumée

La forme la plus simple de vérification est le test de fumée. Le terme vient de l'électronique : lorsque vous allumez un nouveau circuit imprimé pour la première fois, vous vérifiez si de la fumée s'en échappe. Pas de fumée signifie qu'aucun composant ne brûle et vous pouvez procéder à des tests plus approfondis.

En termes de déploiement, un test de fumée exécute des vérifications de base pour confirmer que la nouvelle version n'est pas immédiatement cassée. Ces vérifications sont simples et rapides. Elles ne vérifient pas la logique métier. Elles ne détectent que les échecs les plus évidents.

Un test de fumée typique peut inclure :

Voici un exemple concret de script de test de fumée que vous pouvez exécuter après chaque déploiement :

#!/bin/bash
# smoke-test.sh - Exécute des tests de fumée de base après le déploiement

BASE_URL="http://localhost:8080"
FAILED=0

check_endpoint() {
  local url="$1"
  local description="$2"
  local status=$(curl -s -o /dev/null -w "%{http_code}" "$url")
  if [ "$status" -eq 200 ]; then
    echo "RÉUSSI : $description"
  else
    echo "ÉCHEC : $description (HTTP $status)"
    FAILED=1
  fi
}

check_endpoint "$BASE_URL/" "La page d'accueil retourne 200"
check_endpoint "$BASE_URL/login" "La page de connexion s'affiche"
check_endpoint "$BASE_URL/api/health" "Le point d'accès santé répond"
check_endpoint "$BASE_URL/static/css/main.css" "Le fichier CSS se charge"

if [ "$FAILED" -eq 1 ]; then
  echo "Tests de fumée échoués. Retour arrière recommandé."
  exit 1
else
  echo "Tous les tests de fumée sont réussis."
fi
  • Charger la page d'accueil et confirmer qu'elle retourne HTTP 200
  • Vérifier que la page de connexion s'affiche sans erreur
  • Vérifier qu'un point d'accès API critique répond dans un délai raisonnable
  • Confirmer que les ressources statiques comme les fichiers CSS et JavaScript se chargent correctement

L'exigence clé est la cohérence. Vous devez exécuter les mêmes vérifications à chaque déploiement. Si les vérifications changent selon qui les exécute, vous perdez la capacité de comparer les résultats entre les déploiements. Un test de fumée qui réussit aujourd'hui mais a échoué la semaine dernière vous donne une information utile. Un test de fumée qui change à chaque fois ne vous apprend rien.

Les tests de fumée doivent se terminer en moins d'une minute. S'ils prennent plus de temps, ce ne sont plus des tests de fumée. Ce sont autre chose. Gardez-les rapides et superficiels.

Allez plus loin avec les transactions synthétiques

Une fois les tests de fumée réussis, vous pouvez passer à une vérification plus approfondie : les transactions synthétiques. Ce sont des simulations automatisées de ce que les utilisateurs réels font dans votre application.

Une transaction synthétique ne se contente pas de vérifier si une page se charge. Elle parcourt un flux utilisateur réel. Par exemple :

  1. Ouvrir la page d'accueil
  2. Cliquer sur le bouton de connexion
  3. Saisir un nom d'utilisateur et un mot de passe de test
  4. Soumettre le formulaire de connexion
  5. Naviguer vers une fonctionnalité spécifique
  6. Remplir un formulaire avec des données de test
  7. Soumettre le formulaire
  8. Vérifier que le résultat attendu apparaît sur la page suivante

Les transactions synthétiques diffèrent des tests de fumée de deux manières importantes.

Premièrement, elles sont plus longues et plus réalistes. Un test de fumée vérifie si la porte s'ouvre. Une transaction synthétique vérifie si vous pouvez entrer, vous asseoir, commander, payer et repartir avec un reçu.

Deuxièmement, les transactions synthétiques vérifient l'exactitude des données, pas seulement la disponibilité de la page. Un test de fumée confirme que la page de connexion se charge. Une transaction synthétique confirme qu'après la connexion, l'utilisateur voit son tableau de bord avec les bonnes données. C'est un signal beaucoup plus fort.

Les transactions synthétiques doivent s'exécuter immédiatement après la fin du déploiement. Elles ne sont pas destinées à remplacer la surveillance à long terme. Elles sont conçues pour vous donner une réponse rapide : "Cette version est-elle suffisamment saine pour continuer à servir les utilisateurs, ou devons-nous revenir en arrière ?"

Exécutez les deux immédiatement après le déploiement

Les tests de fumée et les transactions synthétiques fonctionnent mieux comme un pipeline de vérification en deux étapes.

Première étape : exécutez les tests de fumée. S'ils échouent, arrêtez-vous. Quelque chose est fondamentalement cassé. Revenez en arrière ou corrigez immédiatement. Ne passez pas à des vérifications plus approfondies tant que les bases ne fonctionnent pas.

Le diagramme ci-dessous montre le flux de décision automatisé :

flowchart TD A[Déploiement terminé] --> B[Exécuter tests de fumée] B -- Échec --> C[Retour arrière] B -- Réussi --> D[Exécuter transactions synthétiques] D -- Échec --> C D -- Réussi --> E[Déploiement sain] style A fill:#e6f3ff,stroke:#333,stroke-width:2px style B fill:#fff3cd,stroke:#333,stroke-width:2px style D fill:#fff3cd,stroke:#333,stroke-width:2px style C fill:#f8d7da,stroke:#333,stroke-width:2px style E fill:#d4edda,stroke:#333,stroke-width:2px

Deuxième étape : exécutez les transactions synthétiques. Si elles échouent, vous avez un problème plus nuancé. L'application fonctionne, mais des flux utilisateur spécifiques sont cassés. Vous devez décider s'il faut revenir en arrière ou appliquer un correctif rapide, selon la gravité.

Les deux vérifications doivent se terminer en quelques minutes après le déploiement. L'objectif est de savoir si la nouvelle version est sûre avant que la plupart des utilisateurs ne la rencontrent.

Une liste de vérification pratique

Voici une liste de vérification simple que vous pouvez adapter pour vos propres déploiements :

  • Test de fumée : la page d'accueil retourne 200
  • Test de fumée : la page de connexion s'affiche sans erreur
  • Test de fumée : un point d'accès API critique répond en moins de 2 secondes
  • Test de fumée : les ressources statiques se chargent correctement
  • Transaction synthétique : l'utilisateur peut se connecter avec des identifiants de test
  • Transaction synthétique : l'utilisateur peut effectuer un workflow principal (par exemple, créer une commande, soumettre un formulaire, consulter un rapport)
  • Transaction synthétique : les données créées pendant le test sont visibles à l'emplacement attendu

Cette liste n'est pas exhaustive. Vous devrez l'ajuster en fonction des flux spécifiques de votre application. Mais la structure est universelle : commencez rapidement et superficiellement, puis allez plus loin.

À quoi cela ressemble en pratique

Imaginez que vous déployez une nouvelle version d'une application e-commerce. Le test de fumée s'exécute et confirme que la page d'accueil se charge, que l'API de recherche répond et que les images des produits apparaissent. Bien.

Ensuite, la transaction synthétique s'exécute. Elle simule un utilisateur recherchant un produit, l'ajoutant au panier, passant à la caisse et effectuant le paiement. La transaction échoue à l'étape du paiement. Le test révèle que la nouvelle version a cassé l'intégration du paiement.

Sans la transaction synthétique, vous pourriez ne découvrir cela que lorsque les utilisateurs commencent à se plaindre. Avec elle, vous le savez dans les deux minutes suivant le déploiement. Vous pouvez revenir en arrière avant que plus d'une poignée d'utilisateurs ne rencontrent le flux cassé.

C'est la différence entre une vérification structurée et le fait d'espérer le meilleur.

Tout ne peut pas être vérifié de la même manière

Les tests de fumée et les transactions synthétiques fonctionnent bien pour les applications. Mais ils ne fonctionnent pas de la même manière pour les bases de données ou l'infrastructure. Une migration de base de données ne peut pas être vérifiée en chargeant une page. Un changement d'infrastructure ne peut pas être vérifié en simulant une connexion utilisateur.

Différents types de déploiements nécessitent différents signaux de vérification. Le principe reste le même : vérifiez tôt, vérifiez de manière cohérente et vérifiez du point de vue de l'utilisateur. Mais les vérifications spécifiques seront différentes selon ce que vous déployez.

L'essentiel à retenir

Arrêtez de compter sur une seule personne qui ouvre un navigateur après le déploiement. Construisez un pipeline de vérification en deux étapes : des tests de fumée pour la santé de base, puis des transactions synthétiques pour les flux utilisateur réalistes. Exécutez les deux immédiatement après chaque déploiement. Si l'une ou l'autre étape échoue, vous le savez avant vos utilisateurs.

Vos utilisateurs ne devraient jamais être les premiers à découvrir que votre déploiement a cassé quelque chose. La vérification structurée est la façon de garantir cela.