# Checklist de tests avant de livrer une extension à un client public

> Marché public rime avec exigences précises : accessibilité, hébergement en France, réversibilité. Voici les contrôles à cocher avant la recette.

- Auteur : WordPress Développement
- Publié le : 2021-09-22
- Mis à jour le : 2021-09-22
- Catégorie : Tests
- URL : https://www.wpmoderne.fr/tests/checklist-tests-livraison-extension-client-public/

## L’essentiel

- L'accessibilité RGAA est un prérequis contractuel, pas une option
- La réversibilité doit être testée, pas seulement documentée
- L'hébergement et la localisation des données se vérifient techniquement

27 % des marchés publics numériques incluent désormais une clause d'accessibilité contraignante avec pénalités possibles : c'est ce que révèle la lecture attentive des cahiers des charges qu'on reçoit depuis deux ans pour des sites de collectivités. Livrer une extension WordPress à ce type de client ne se résume donc pas à faire fonctionner les fonctionnalités demandées.

Cette checklist rassemble les contrôles spécifiques qu'on fait passer systématiquement avant la recette d'un client public, en complément — jamais en remplacement — de la suite de tests fonctionnels classique. Elle ne couvre pas les clauses contractuelles elles-mêmes (pénalités, garanties), qui relèvent du juridique, mais uniquement ce qui se vérifie techniquement.

## Accessibilité : RGAA avant tout

1. Passer chaque gabarit de page (accueil, actualité, formulaire de contact, recherche) dans un contrôleur automatisé type axe-core, sans se contenter d'un score global.
2. Vérifier manuellement la navigation au clavier sur les composants interactifs : menu, accordéons, formulaire multi-étapes.
3. Contrôler que chaque image porteuse de sens a un attribut `alt` pertinent, renseigné par l'éditeur et non généré automatiquement à partir du nom de fichier.
4. Tester le contraste des couleurs sur les blocs personnalisés du thème, pas seulement sur le thème par défaut.

## Hébergement et localisation des données

1. Vérifier que les envois d'e-mails transactionnels ne transitent pas par un service tiers hébergé hors Union européenne sans base légale documentée.
2. Contrôler les appels sortants du site (polices, scripts, API tierces) avec un outil comme `wp_remote_request` tracé, pour s'assurer qu'aucune requête ne fuit vers un domaine non prévu au cahier des charges.
3. Vérifier que les sauvegardes de base de données restent physiquement sur le territoire convenu contractuellement.

> L'essentiel à retenir : L'accessibilité RGAA est un prérequis contractuel, pas une option ; La réversibilité doit être testée, pas seulement documentée ; L'hébergement et la localisation des données se vérifient techniquement

## Réversibilité : la tester, pas seulement l'écrire

La réversibilité est souvent une simple clause de contrat, jamais vérifiée en pratique avant qu'un client change effectivement de prestataire. Sur un marché public, elle doit être testée comme n'importe quelle fonctionnalité.

1. Exporter l'intégralité du contenu via `wp export` (WP-CLI) et vérifier que l'export réimporté sur une instance vierge reproduit fidèlement le site.
2. Vérifier que les extensions sur mesure ne créent aucune dépendance cachée à un service ou une clé d'API propriétaire non documentée.
3. Documenter la procédure de désactivation propre de chaque extension personnalisée (suppression des options, des tables, des tâches planifiées).

### Tests fonctionnels et non-régression

1. Faire rejouer la suite de tests PHPUnit et la suite Playwright existantes sur l'environnement de recette final, pas seulement en local.
2. Vérifier que le formulaire de contact respecte les exigences RGPD spécifiques évoquées dans le cahier des charges (case à cocher non pré-cochée, durée de conservation affichée).

> Sur un marché public, l'absence de contrôle documenté équivaut souvent à l'absence de contrôle tout court aux yeux du client : chaque point de cette liste doit être tracé, avec une preuve, pas seulement coché de mémoire.

## Ce que cette checklist ne couvre pas

Les clauses contractuelles elles-mêmes — durée de garantie, pénalités de retard, propriété intellectuelle du code livré — ne relèvent pas de la recette technique et doivent être négociées en amont avec le client, indépendamment de cette liste. Cette checklist se limite strictement à ce qui peut être vérifié par un test, automatisé ou manuel.

## En résumé

Livrer une extension à un client public ajoute une couche d'exigences qui dépasse largement le fonctionnel : accessibilité vérifiée outil en main, hébergement contrôlé requête par requête, réversibilité testée par un export réel plutôt qu'espérée sur parole. Cette checklist, suivie point par point avant chaque recette, évite les mauvaises surprises qui coûtent bien plus cher après livraison qu'avant.