# Ce qu’un test de smoke doit vérifier en trente secondes après un déploiement

> Une liste volontairement courte de vérifications à exécuter juste après une mise en production, pour une équipe qui déploie plusieurs fois par jour sans repasser toute la suite complète.

- Auteur : Clément Hadrot
- Publié le : 2026-08-28
- Mis à jour le : 2026-08-28
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/test-de-smoke-trente-secondes-apres-deploiement/

## L’essentiel

- Un test de smoke ne vérifie pas tout, il vérifie que rien de vital ne s'est cassé
- Trente secondes maximum, sinon il devient un frein au rythme de déploiement qu'il est censé sécuriser
- Un smoke test qui grossit trop finit par redevenir la suite complète qu'il devait remplacer

Cinq vérifications, exécutées en moins de trente secondes, contre une suite complète de quarante tests qui prend près de six minutes : c'est l'écart volontairement assumé entre le smoke test post-déploiement et la suite de tests fonctionnels d'une plateforme de mise en relation entre artisans et particuliers, qui déploie en production plusieurs fois par jour.

Un smoke test ne remplace jamais la suite complète, exécutée en amont dans le pipeline avant que le déploiement ne soit autorisé. Il répond à une question différente, posée après coup, une fois le code déjà en production : rien de vital ne s'est-il cassé au moment précis du déploiement lui-même, indépendamment de ce que la suite complète avait déjà validé en amont ?

## Ce que ces cinq vérifications couvrent

1. La page d'accueil répond avec un code de statut HTTP 200, confirmant que le serveur web sert bien une réponse.
2. Le point d'entrée de l'API REST WordPress, `/wp-json/`, retourne une structure JSON valide, confirmant que le cœur applicatif s'initialise correctement.
3. Une recherche d'artisan par métier retourne au moins un résultat, confirmant que la connexion à la base de données fonctionne et que l'index de recherche répond.
4. La page de connexion affiche bien le formulaire attendu, confirmant qu'aucune erreur fatale ne bloque le chargement des scripts d'authentification.
5. Un appel de test vers le fournisseur de paiement, en mode simulation, confirme que les clés d'API configurées après déploiement restent valides.

## Le script qui exécute ces cinq vérifications

> L'essentiel à retenir : Un test de smoke ne vérifie pas tout, il vérifie que rien de vital ne s'est cassé ; Trente secondes maximum, sinon il devient un frein au rythme de déploiement qu'il est censé sécuriser ; Un smoke test qui grossit trop finit par redevenir la suite complète qu'il devait remplacer

```
#!/usr/bin/env bash
set -euo pipefail

BASE_URL="https://exemple-artisans.fr"

verifier() {
  local url="$1"
  local motif="$2"
  if ! curl -fsS "$url" | grep -q "$motif"; then
    echo "ÉCHEC : $url"
    exit 1
  fi
  echo "OK : $url"
}

verifier "$BASE_URL/" "<html"
verifier "$BASE_URL/wp-json/" "\"name\""
verifier "$BASE_URL/?s=electricien" "resultats-recherche"
verifier "$BASE_URL/connexion/" "id=\"loginform\""
verifier "$BASE_URL/wp-json/paiement/v1/test-cle" "\"valide\":true"

echo "Smoke test terminé en succès."
```

### Pourquoi rester à cinq, et pas davantage

Une première version du smoke test comptait douze vérifications, incluant des scénarios de réservation complets. Cette version dépassait deux minutes d'exécution, un délai jugé incompatible avec un rythme de plusieurs déploiements quotidiens : l'équipe finissait par ignorer le smoke test faute de patience, exactement le risque que ce type de test doit éviter. Le retour à cinq vérifications essentielles a restauré une exécution systématique après chaque déploiement.

## Ce qu'un smoke test ne doit jamais essayer de couvrir

- Les scénarios métier complets, comme le parcours entier de prise de rendez-vous avec un artisan, qui relèvent de la suite fonctionnelle exécutée avant le déploiement.
- Les cas limites et les erreurs de validation de formulaire, qui appartiennent à des tests plus ciblés et moins urgents à vérifier juste après une mise en production.
- Le monitoring synthétique continu, qui surveille la disponibilité du site en permanence et répond à un besoin distinct, indépendant de tout déploiement précis.

> Un smoke test qui prend cinq minutes n'est plus un smoke test, c'est une suite complète qui s'ignore.

## Où déclencher ce script, concrètement

Le script s'exécute automatiquement à la fin de chaque déploiement, comme dernière étape du pipeline de mise en production, plutôt que d'être lancé manuellement par la personne qui déploie. Un échec de l'une des cinq vérifications déclenche une alerte immédiate sur le canal de discussion de l'équipe technique, avec le nom précis de la vérification en échec, permettant une réaction en quelques secondes plutôt qu'une découverte tardive par un client mécontent.

Cette automatisation retire également toute tentation d'ignorer la vérification par manque de temps : une fois intégrée au pipeline, elle s'exécute qu'on le veuille ou non, ce qu'une étape manuelle laissée à la discrétion de chacun ne garantit jamais aussi fiablement.

## En résumé

Un smoke test post-déploiement gagne à rester volontairement limité à quelques vérifications vitales, exécutables en une trentaine de secondes, plutôt que de tenter de couvrir l'ensemble des scénarios métier déjà validés en amont par la suite complète. Sur cette plateforme d'artisans, réduire le smoke test de douze à cinq vérifications, puis l'intégrer directement au pipeline de déploiement, a restauré une exécution systématique après chaque mise en production, condition indispensable pour qu'il serve réellement à quelque chose.