# Contrat de maintenance d’une boutique WooCommerce : ce qu’il doit couvrir au-delà du cœur WordPress

> Un contrat de maintenance calqué sur celui d'un site vitrine oublie presque toujours les clauses spécifiques aux extensions de paiement et d'expédition d'une boutique WooCommerce. Voici ce qu'il faut ajouter.

- Auteur : WordPress Développement
- Publié le : 2021-02-06
- Mis à jour le : 2021-02-06
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/contrat-maintenance-boutique-woocommerce-au-dela-coeur-wordpress/

## L’essentiel

- Un contrat de maintenance générique ne couvre pas les extensions de paiement et d'expédition
- Les webhooks de paiement méritent une clause de surveillance dédiée
- Les délais d'intervention doivent distinguer panne de tunnel de commande et bug d'affichage mineur

Que couvre exactement un contrat de maintenance rédigé à l'origine pour un site vitrine, une fois appliqué tel quel à une boutique WooCommerce ? Dans la plupart des cas observés en reprise de projet : la mise à jour du cœur WordPress, du thème, et des extensions génériques, mais rien de spécifique aux mécanismes propres à une activité commerciale en ligne, où une panne de dix minutes sur le tunnel de commande a un coût direct et mesurable, contrairement à une page vitrine simplement statique.

Ce billet détaille les clauses qu'un contrat de maintenance dédié à une boutique WooCommerce doit couvrir en plus du socle WordPress générique, sans entrer dans la question des tarifs pratiqués.

## La surveillance des passerelles de paiement

Une passerelle de paiement dépend d'un service tiers dont la disponibilité échappe totalement au contrôle de l'agence. Le contrat doit préciser explicitement comment est surveillée la bonne réception des notifications de paiement asynchrones, et quel délai d'intervention s'applique si ces notifications cessent d'arriver silencieusement, un incident bien plus insidieux qu'une passerelle totalement indisponible et donc immédiatement visible.

## La clause spécifique aux méthodes d'expédition

> L'essentiel à retenir : Un contrat de maintenance générique ne couvre pas les extensions de paiement et d'expédition ; Les webhooks de paiement méritent une clause de surveillance dédiée ; Les délais d'intervention doivent distinguer panne de tunnel de commande et bug d'affichage mineur

Une méthode d'expédition personnalisée qui dépend d'une API de transporteur externe introduit un point de défaillance supplémentaire, distinct du cœur WooCommerce. Le contrat doit couvrir explicitement :

- La conduite à tenir si l'API du transporteur change sa structure de réponse sans préavis
- Le comportement de repli attendu en cas d'indisponibilité temporaire de cette API
- La responsabilité de mise à jour si le transporteur modifie ses conditions d'accès à son API

## La distinction entre panne de tunnel et bug d'affichage

Un contrat de maintenance générique fixe souvent un délai d'intervention unique, par exemple sous 48 heures ouvrées, quelle que soit la nature de l'incident signalé. Pour une boutique WooCommerce, cette approche est inadaptée : un tunnel de commande bloqué qui empêche tout achat n'a pas la même urgence qu'un décalage visuel mineur sur une fiche produit. Le contrat doit distinguer explicitement au moins deux niveaux de sévérité, avec des délais d'intervention différenciés pour chacun.

### Exemple de grille de sévérité

| Sévérité | Exemple | Délai d'intervention |
| --- | --- | --- |
| Critique | Impossible de valider une commande | Sous quelques heures |
| Majeure | Une méthode de paiement précise échoue | Sous 24 heures ouvrées |
| Mineure | Décalage d'affichage sur une fiche produit | Prochaine intervention planifiée |

## Les mises à jour d'extensions premium

Une extension de paiement ou d'expédition premium évolue souvent plus fréquemment qu'une extension générique, et son incompatibilité avec une version récente de WooCommerce peut interrompre le tunnel de commande du jour au lendemain. Le contrat doit préciser si ces mises à jour sont testées sur un environnement de recette avant application en production, et qui supporte le coût d'un correctif si une mise à jour casse une fonctionnalité de paiement.

> Une clause que nous ajoutons désormais systématiquement : toute mise à jour d'une extension de paiement ou d'expédition passe d'abord par l'environnement de recette, jamais directement en production, contrairement à certaines mises à jour de sécurité mineures qui peuvent être appliquées sans ce passage.

## La question des sauvegardes spécifiques aux commandes

Un contrat générique prévoit en général une sauvegarde quotidienne de la base de données dans son ensemble. Pour une boutique WooCommerce, cela ne suffit pas toujours : en cas de restauration après incident, il faut aussi préciser si les commandes passées entre la dernière sauvegarde et l'incident peuvent être reconstituées à partir des journaux de paiement du prestataire tiers, ou si elles sont purement et simplement perdues. Cette clause, rarement discutée en amont, devient critique le jour où elle est nécessaire.

## En résumé

Un contrat de maintenance pensé pour un site vitrine classique laisse un angle mort dangereux sur une boutique WooCommerce : les mécanismes de paiement et d'expédition, qui touchent directement au chiffre d'affaires du client, méritent des clauses dédiées, des délais différenciés selon la sévérité, et une politique claire sur le test préalable des mises à jour d'extensions premium.