# Une recette adaptée à un site qui n’a jamais eu le moindre test avant

> Reprendre un site sans aucun historique de tests automatisés impose une checklist de recette différente de celle d'un projet déjà couvert. Voici laquelle.

- Auteur : Clément Hadrot
- Publié le : 2026-04-22
- Mis à jour le : 2026-04-22
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/recette-site-jamais-eu-test-avant/

## L’essentiel

- Cartographier les fonctionnalités critiques avant de rédiger le moindre scénario
- Prioriser les zones à fort trafic et fort impact financier avant les zones secondaires
- Documenter chaque anomalie trouvée comme base d'une future suite de tests

Aucune ligne de code couverte par un test automatisé : c'est l'état constaté lors de la reprise de maintenance d'un site de vente de matériel professionnel, développé sur plusieurs années par différents prestataires successifs, sans qu'aucun d'entre eux n'ait laissé de suite de tests derrière lui. Recetter un tel site sans y passer des semaines, et sans valider à l'aveugle des fonctionnalités jamais vérifiées, impose une méthode particulière.

Une recette classique, pensée pour un projet déjà couvert par des tests automatisés, se concentre généralement sur les zones récemment modifiées, en s'appuyant sur la suite existante pour couvrir le reste. Sans cette suite, aucune zone du site ne bénéficie d'un filet de sécurité préexistant, ce qui impose une méthode de recette entièrement différente.

## Cartographier avant de rédiger le moindre scénario

La première étape ne consiste pas à écrire des scénarios de test, mais à établir un inventaire complet des fonctionnalités du site, à partir de son utilisation réelle plutôt que d'une documentation souvent absente ou obsolète. Cet inventaire s'appuie sur trois sources croisées : les statistiques de fréquentation des pages sur les douze derniers mois, un parcours manuel exhaustif du site par un testeur, et un entretien avec le client sur les fonctionnalités qu'il considère comme critiques pour son activité.

1. Extraire les vingt pages les plus visitées depuis l'outil d'analyse d'audience du site.
2. Lister chaque formulaire, chaque tunnel de commande et chaque intégration tierce identifiable en parcourant le site.
3. Confronter cette liste à l'entretien client pour repérer les fonctionnalités peu visitées mais critiques, comme un espace revendeur peu fréquenté mais indispensable à un partenaire clé.

## Prioriser par impact avant de prioriser par complexité

Face à un volume de fonctionnalités à recetter souvent trop important pour un temps limité, la priorisation ne se fait pas par facilité de test mais par impact réel sur l'activité. Un tableau simple, construit avec le client, croise fréquentation et criticité financière :

| Fonctionnalité | Fréquentation | Impact financier direct | Priorité |
| --- | --- | --- | --- |
| Tunnel de commande professionnel | Élevée | Direct | 1 |
| Devis en ligne pour grands comptes | Faible | Direct, montants élevés | 1 |
| Page de présentation de l'entreprise | Élevée | Indirect | 3 |

### Documenter chaque anomalie comme matière première d'une future suite

Chaque anomalie détectée pendant cette recette manuelle est consignée non seulement pour être corrigée, mais aussi comme candidat naturel à un futur test automatisé, une fois la correction apportée. Le format de consignation inclut systématiquement les étapes précises de reproduction, ce qui transforme directement le rapport d'anomalie en base d'un scénario Playwright ou PHPUnit ultérieur :

```
Anomalie : le calcul de remise par volume ne s'applique pas
  au-dessus de cinquante unités pour les comptes revendeurs.
Etapes de reproduction :
  1. Se connecter avec un compte revendeur
  2. Ajouter cinquante-cinq unités du produit REF-2201
  3. Constater : remise attendue de 12%, remise appliquee de 0%
Candidat a un test automatise : oui, priorite haute
```

> L'essentiel à retenir : Cartographier les fonctionnalités critiques avant de rédiger le moindre scénario ; Prioriser les zones à fort trafic et fort impact financier avant les zones secondaires ; Documenter chaque anomalie trouvée comme base d'une future suite de tests

## Accepter une recette incomplète plutôt qu'un report indéfini

Un projet sans historique de tests contient presque toujours plus de zones à risque que le temps disponible ne permet d'en vérifier intégralement. Plutôt que de retarder indéfiniment la livraison en cherchant une exhaustivité inatteignable, la recette se conclut par un document explicite listant les zones couvertes et celles volontairement non couvertes, validé et signé par le client en toute connaissance de cause.

> Une recette sur un site sans historique de tests ne vise pas à tout vérifier une fois pour toutes : elle vise à identifier honnêtement ce qui a été vérifié, ce qui ne l'a pas été, et à poser la première pierre d'une couverture automatisée qui n'existait pas encore.

## Transformer la recette manuelle en point de départ automatisé

Les scénarios les mieux documentés lors de cette recette manuelle deviennent, dans les semaines qui suivent, les premiers cas d'une suite Playwright naissante, en commençant exclusivement par les fonctionnalités classées en priorité un dans le tableau d'impact. Cette approche évite l'écueil classique consistant à vouloir tout automatiser d'un coup sur un projet dépourvu de toute base : mieux vaut cinq scénarios critiques solidement couverts que cinquante scénarios superficiels abandonnés à mi-parcours.

## En résumé

Recetter un site sans historique de tests exige une cartographie préalable rigoureuse, une priorisation fondée sur l'impact réel plutôt que sur la facilité, et l'acceptation explicite d'une couverture partielle plutôt qu'un report sans fin. Chaque anomalie documentée pendant cette recette devient la première brique d'une suite de tests qui, elle, protégera enfin les prochaines évolutions du site.