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
- 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.
- Vérifier manuellement la navigation au clavier sur les composants interactifs : menu, accordéons, formulaire multi-étapes.
- Contrôler que chaque image porteuse de sens a un attribut
altpertinent, renseigné par l’éditeur et non généré automatiquement à partir du nom de fichier. - 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
- 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.
- Contrôler les appels sortants du site (polices, scripts, API tierces) avec un outil comme
wp_remote_requesttracé, pour s’assurer qu’aucune requête ne fuit vers un domaine non prévu au cahier des charges. - Vérifier que les sauvegardes de base de données restent physiquement sur le territoire convenu contractuellement.
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é.
- 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. - 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.
- 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
- Faire rejouer la suite de tests PHPUnit et la suite Playwright existantes sur l’environnement de recette final, pas seulement en local.
- 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.
