Tests de Fumée et Transactions Synthétiques : Vérifier que votre Déploiement Fonctionne Réellement
Vous venez de voir votre pipeline passer au vert. Les tests unitaires sont OK, les tests d'intégration sont OK, même les tests de bout en bout sont propres. Vous lancez le déploiement, la barre de progression se remplit, et le pipeline annonce un succès. Mais voici la vérité qui dérange : aucun de ces tests n'a été exécuté dans l'environnement de production réel. Ils ont tous tourné ailleurs — sur un runner CI, un serveur de staging, une machine locale. Au moment où votre application atterrit sur l'infrastructure réelle, tout peut encore casser.
C'est pourquoi les tests de fumée et les transactions synthétiques existent. Ils ne remplacent pas votre suite de tests existante. Ils constituent une couche distincte qui répond à une question différente : non pas « le code est-il correct ? » mais « le déploiement a-t-il réellement fonctionné ? »
Le Contrôle le Plus Simple : les Tests de Fumée
Un test de fumée est la chose la plus basique que vous puissiez faire après un déploiement. Il répond à une question : l'application est-elle vivante et répond-elle ?
Considérez-le comme l'allumage d'un nouveau rack de serveurs dans un datacenter. Avant d'exécuter une charge de travail sérieuse, vous vérifiez que le voyant d'alimentation est allumé, que les ventilateurs tournent, et que vous pouvez pinguer l'interface de gestion. Vous ne lancez pas un benchmark complet. Vous confirmez simplement que l'équipement est sous tension.
Pour une application web, un test de fumée pourrait être une simple requête HTTP vers le point de terminaison de health check. Pour un service backend, cela pourrait être la vérification que le processus tourne et écoute sur le port attendu. Pour une application mobile, cela pourrait signifier vérifier que l'application se lance sans planter sur un appareil réel.
Les caractéristiques clés d'un bon test de fumée sont la rapidité et la simplicité. Il doit s'exécuter en secondes, pas en minutes. Il ne doit pas dépendre de logique métier complexe ou de systèmes externes qui pourraient être temporairement indisponibles. Si votre test de fumée a besoin d'une connexion à une base de données, d'un serveur de cache et de trois API tierces, ce n'est plus un test de fumée — c'est tout autre chose.
Voici à quoi ressemblent un test de fumée pratique et une transaction synthétique en bash :
# Smoke test: quick health check
curl -f -s -o /dev/null http://myapp.com/health || exit 1
echo "Smoke test passed"
# Synthetic transaction: simulate a user login and search
#!/bin/bash
set -e
BASE="http://myapp.com"
# Step 1: Load login page
curl -s -o /dev/null -w "%{http_code}" "$BASE/login" | grep -q 200 || exit 1
# Step 2: Submit login form (simulated)
curl -s -c /tmp/cookies.txt -b /tmp/cookies.txt \
-d "username=testuser&password=testpass" \
-o /dev/null -w "%{http_code}" "$BASE/login" | grep -q 302 || exit 1
# Step 3: Search for a product
curl -s -b /tmp/cookies.txt "$BASE/search?q=laptop" | grep -q "results" || exit 1
echo "Synthetic transaction passed"
Placez votre test de fumée comme première étape après le déploiement, avant que tout trafic ne soit dirigé vers la nouvelle version. Si le test de fumée échoue, le pipeline doit s'arrêter immédiatement. Ne passez pas à des vérifications plus approfondies. Ne dirigez pas le trafic utilisateur. Le déploiement a échoué au niveau le plus basique, et rien d'autre n'a d'importance tant que cela n'est pas résolu.
Aller Plus Loin : les Transactions Synthétiques
Une transaction synthétique va encore plus loin dans la vérification. Au lieu de simplement vérifier que l'application est vivante, elle simule un comportement utilisateur réel. Elle parcourt les chemins critiques de votre application comme le ferait un utilisateur réel, mais elle s'exécute automatiquement, déclenchée par le pipeline.
Imaginez une application e-commerce. Une transaction synthétique pourrait :
- Ouvrir la page d'accueil
- Rechercher un produit
- Ajouter le produit au panier
- Procéder au paiement
- Finaliser le flux d'achat
Chaque étape vérifie que la réponse est correcte, que les pages se chargent correctement, que le panier contient bien le bon article, et que la confirmation de commande apparaît. Si une étape échoue, la transaction synthétique échoue.
Les transactions synthétiques sont plus coûteuses que les tests de fumée. Elles prennent plus de temps à s'exécuter — souvent plusieurs minutes au lieu de secondes. Elles dépendent du bon fonctionnement d'un plus grand nombre de parties du système. Mais elles détectent des problèmes que les tests de fumée ne peuvent pas détecter.
Un scénario courant : le test de fumée réussit car le point de terminaison de health check renvoie un 200 OK. Mais la page de connexion renvoie une erreur 500 car un fichier de configuration n'a pas été copié correctement lors du déploiement. Le test de fumée n'a jamais vérifié la page de connexion. La transaction synthétique l'aurait immédiatement détecté.
Où les Placer dans Votre Pipeline
Les tests de fumée et les transactions synthétiques servent des objectifs différents et doivent apparaître à différentes étapes de votre pipeline de déploiement.
Le test de fumée passe en premier, immédiatement après la fin du déploiement. C'est votre gardien. Si l'application ne tourne même pas, il est inutile d'exécuter quoi que ce soit d'autre. Le pipeline doit échouer rapidement et s'arrêter.
La transaction synthétique s'exécute après la réussite du test de fumée. C'est votre vérification plus approfondie avant l'arrivée du trafic utilisateur. Si la transaction synthétique échoue, vous avez encore le temps d'arrêter le déploiement avant que les utilisateurs ne rencontrent le problème.
En pratique, vous n'avez pas besoin de nombreuses transactions synthétiques. Deux à cinq scénarios couvrant vos parcours utilisateur les plus critiques suffisent généralement. L'objectif n'est pas un test exhaustif — vous l'avez déjà fait avant le déploiement. L'objectif est de confirmer que le déploiement lui-même n'a rien cassé.
Ce que Ces Tests Détectent et que les Autres Ratent
Les tests pré-déploiement s'exécutent dans des environnements contrôlés. Ils utilisent des bases de données de test, des services mockés et des fichiers de configuration qui peuvent différer de la production. Même avec des environnements de staging qui reflètent étroitement la production, des différences existent.
Les tests de fumée et les transactions synthétiques s'exécutent dans l'environnement de production réel. Ils détectent des problèmes qui n'apparaissent que là :
- Différences de configuration d'environnement entre le staging et la production
- Dépendances manquantes ou versions incorrectes en production
- Problèmes de permissions qui n'existent que dans le compte ou le cluster de production
- Politiques réseau qui bloquent le trafic légitime
- Problèmes de certificats SSL
- Mauvaise configuration du répartiteur de charge
- Épuisement du pool de connexions à la base de données dans des conditions réelles
Ce ne sont pas des problèmes théoriques. Ils surviennent régulièrement dans des équipes de toutes tailles. Une valeur de configuration qui fonctionne parfaitement en staging mais qui a une faute de frappe en production. Un secret qui a été renouvelé en staging mais pas en production. Une règle de pare-feu qui bloque le port du nouveau service. Ces problèmes ne seront jamais détectés par les tests pré-déploiement car ces tests ne s'exécutent pas contre l'environnement réel.
Une Liste de Vérification Pratique
Lors de la mise en œuvre de tests de fumée et de transactions synthétiques pour votre pipeline, gardez ces points à l'esprit :
- Gardez les tests de fumée sous les 10 secondes. S'ils prennent plus de temps, simplifiez-les.
- Placez les tests de fumée immédiatement après le déploiement, avant le routage du trafic.
- Faites échouer le pipeline en cas d'échec du test de fumée. Ne continuez pas.
- Exécutez les transactions synthétiques après la réussite des tests de fumée, avant le basculement complet du trafic.
- Limitez les transactions synthétiques à 2 à 5 parcours utilisateur critiques.
- N'utilisez pas les transactions synthétiques pour des tests exhaustifs. C'est le rôle de vos tests pré-déploiement.
- Surveillez les résultats des transactions synthétiques dans le temps. Un schéma d'échecs intermittents peut indiquer un problème sous-jacent.
- Assurez-vous que les transactions synthétiques s'exécutent contre l'environnement de production réel, pas une réplique de staging.
L'Essentiel à Retenir
Vos tests pré-déploiement vérifient que votre code est correct. Vos tests de fumée et transactions synthétiques vérifient que votre déploiement a réussi. Ce n'est pas la même chose, et l'un ne peut pas remplacer l'autre. Un pipeline vert signifie que votre code a passé tous les contrôles dans un environnement contrôlé. Un test de fumée réussi signifie que votre application tourne réellement en production. Une transaction synthétique réussie signifie que vos utilisateurs peuvent accomplir leurs tâches les plus importantes. Ajoutez les deux à votre pipeline de déploiement, et vous détecterez les problèmes qui n'apparaissent que lorsque le code rencontre la réalité.