Un contrat de maintenance WordPress ne devrait pas se limiter à une liste de tâches vagues comme “mises à jour”, “sauvegardes” ou “support technique”. Lorsqu’un site joue un rôle important dans l’activité d’une entreprise, il faut savoir exactement ce qui est inclus, ce qui ne l’est pas, à quelle fréquence les actions sont réalisées et dans quels délais les demandes sont traitées.
C’est là qu’intervient le SLA, ou accord de niveau de service.
Un SLA permet de clarifier les engagements entre le client et le prestataire : délais de réponse, périmètre de maintenance, canaux de communication, fréquence des vérifications, suivi des incidents, exclusions, rapports et procédures d’escalade.
L’objectif n’est pas de compliquer la relation. Au contraire, un bon contrat de maintenance WordPress permet d’éviter les malentendus et de mieux protéger les deux parties.
Pourquoi un contrat de maintenance WordPress doit être clair ?
Après la mise en ligne d’un site WordPress, beaucoup d’entreprises pensent être couvertes parce qu’elles ont “une maintenance”. Mais ce mot peut vouloir dire beaucoup de choses.
Pour certains prestataires, la maintenance signifie uniquement appliquer les mises à jour une fois par mois. Pour d’autres, elle inclut les sauvegardes, les tests, la surveillance, le support technique, les rapports et certaines corrections. Dans certains cas, des demandes de contenu ou d’évolution sont aussi incluses. Dans d’autres, elles sont facturées séparément.
Sans cadre précis, les problèmes apparaissent rapidement :
- le client pense qu’une intervention est incluse ;
- le prestataire considère que la demande dépasse le contrat ;
- les délais de réponse ne sont pas clairs ;
- les urgences ne sont pas priorisées ;
- les corrections deviennent difficiles à suivre ;
- personne ne sait exactement ce qui a été fait.
Un bon contrat évite ces zones grises. Il définit les attentes avant qu’un problème survienne.
Si vous voulez comprendre ce qui peut être inclus dans une offre de suivi, vous pouvez aussi consulter notre guide sur le forfait de maintenance WordPress. Ici, nous allons plus loin sur la structure du contrat et du SLA.
Qu’est-ce qu’un SLA dans un contrat de maintenance WordPress ?
Un SLA, pour “Service Level Agreement”, est un accord de niveau de service. Dans un contrat de maintenance WordPress, il précise les engagements concrets du prestataire.
Il peut définir :
- les délais de réponse ;
- les délais d’intervention ;
- les horaires de prise en charge ;
- les niveaux de priorité ;
- les tâches incluses ;
- les exclusions ;
- les canaux de communication ;
- la fréquence des rapports ;
- les procédures en cas d’urgence ;
- les responsabilités du client et du prestataire.
Le SLA ne garantit pas que le site n’aura jamais de problème. Il garantit surtout qu’un cadre existe pour traiter les demandes, prioriser les incidents et éviter l’improvisation.
C’est particulièrement important pour les sites qui génèrent des prospects, des ventes, des réservations ou des demandes clients.
Les éléments essentiels d’un contrat de maintenance WordPress
Un vrai contrat de maintenance WordPress doit être suffisamment précis pour répondre à une question simple : qui fait quoi, quand, comment et dans quelles limites ?
Voici les éléments à inclure.
1. Le périmètre exact de la maintenance
Le contrat doit d’abord préciser ce qui est couvert.
Par exemple :
- mises à jour du cœur WordPress ;
- mises à jour des extensions ;
- mises à jour du thème ;
- sauvegardes ;
- vérification des sauvegardes ;
- tests après mise à jour ;
- surveillance de disponibilité ;
- vérification des formulaires ;
- monitoring des erreurs ;
- suivi WooCommerce ;
- petites corrections ;
- rapport de maintenance ;
- accompagnement technique.
Il faut éviter les formulations trop générales. Une phrase comme “maintenance complète du site” peut créer des attentes différentes selon les personnes.
Il vaut mieux écrire clairement :
La maintenance inclut les mises à jour WordPress, extensions et thème, après sauvegarde préalable, avec vérification des pages principales et rapport mensuel.
Cette formulation donne un cadre plus précis.
Pour mieux comprendre les différentes catégories d’intervention, consultez notre article sur les types de maintenance WordPress.
2. La fréquence des interventions
Le contrat doit indiquer à quelle fréquence les actions sont réalisées.
Exemples :
| Action | Fréquence possible |
| Mises à jour WordPress | Mensuelle ou selon criticité |
| Sauvegardes | Quotidienne, hebdomadaire ou en temps réel |
| Vérification des formulaires | Mensuelle ou hebdomadaire |
| Monitoring uptime | Continu |
| Rapport de maintenance | Mensuel |
| Revue technique | Trimestrielle |
| Test de restauration | Trimestriel ou ponctuel |
La fréquence doit être adaptée au type de site.
Un site vitrine simple n’a pas les mêmes besoins qu’une boutique WooCommerce. Un site avec espace membre, réservation ou formulaires critiques demande un suivi plus serré.
Pour les sauvegardes, la fréquence doit dépendre de l’activité réelle du site. Un site qui reçoit des commandes chaque jour ne devrait pas être sauvegardé au même rythme qu’un site vitrine peu modifié. Vous pouvez consulter notre guide sur la fréquence de sauvegarde WordPress.
3. Les délais de réponse
Le délai de réponse indique en combien de temps le prestataire accuse réception d’une demande.
Ce n’est pas forcément le délai de résolution.
Exemple :
| Niveau de priorité | Exemple de situation | Délai de réponse |
| Critique | Site inaccessible, paiement bloqué | 2 à 4 heures ouvrables |
| Élevé | Formulaire principal en panne | 1 jour ouvrable |
| Normal | Modification mineure, question technique | 2 à 3 jours ouvrables |
| Faible | Demande non urgente, amélioration future | Selon planification |
Cette distinction est importante. Répondre rapidement ne veut pas dire que tout peut être corrigé immédiatement, surtout si le problème demande un diagnostic, une restauration ou une intervention externe.
Le contrat doit donc préciser les délais de réponse, mais aussi les conditions d’intervention.
4. Les délais d’intervention ou de résolution
Le délai d’intervention correspond au moment où le prestataire commence réellement à traiter la demande. Le délai de résolution dépend du problème.
Un site hors ligne peut parfois être remis en ligne rapidement. Mais si le problème vient d’un conflit complexe entre extensions, d’un hébergeur, d’un module de paiement ou d’un code personnalisé, la résolution peut demander plus de temps.
Un bon SLA doit éviter les promesses irréalistes.
Il peut plutôt définir :
- un délai de prise en charge ;
- une première analyse ;
- une priorisation ;
- une estimation si le problème dépasse le périmètre ;
- une communication régulière jusqu’à résolution.
Exemple de formulation :
Pour les incidents critiques, une première analyse est lancée dans les 4 heures ouvrables suivant la réception de la demande. Le délai de résolution dépend de la cause identifiée et du périmètre couvert par le contrat.
Cette approche est plus réaliste qu’une promesse de correction garantie en une heure.
5. Les niveaux de priorité
Toutes les demandes ne doivent pas être traitées de la même manière.
Un bon contrat de maintenance WordPress doit distinguer les priorités.
Priorité critique
Exemples :
- site complètement inaccessible ;
- erreur critique sur tout le site ;
- tunnel de paiement bloqué ;
- WooCommerce incapable de recevoir des commandes ;
- problème de sécurité visible ;
- tableau de bord inaccessible pour une intervention urgente.
Priorité élevée
Exemples :
- formulaire principal qui ne fonctionne plus ;
- page stratégique cassée ;
- problème mobile majeur ;
- courriel transactionnel important non envoyé ;
- fonctionnalité de réservation bloquée.
Priorité normale
Exemples :
- modification de contenu ;
- ajout d’image ;
- ajustement de page ;
- correction visuelle mineure ;
- question technique ;
- petite amélioration.
Priorité faible
Exemples :
- demande d’évolution non urgente ;
- amélioration future ;
- idée à planifier ;
- ajustement esthétique secondaire.
Cette classification permet de traiter rapidement ce qui impacte réellement l’activité, sans transformer toutes les demandes en urgences.
6. Les exclusions du contrat
Un contrat de maintenance WordPress sérieux doit aussi préciser ce qui n’est pas inclus.
C’est souvent ce qui évite les malentendus.
Exclusions possibles :
- refonte complète du site ;
- création de nouvelles fonctionnalités importantes ;
- développement sur mesure ;
- correction de problèmes causés par un tiers ;
- intervention hors horaires prévus ;
- migration d’hébergement ;
- nettoyage d’un site piraté ;
- optimisation SEO complète ;
- optimisation de performance avancée ;
- rédaction de contenu ;
- création graphique ;
- configuration avancée WooCommerce ;
- correction d’un problème lié à un service externe ;
- achat de licences premium ;
- frais d’hébergement ou de domaine, si non inclus.
Ces exclusions ne veulent pas dire que le prestataire ne peut pas faire ces tâches. Elles signifient qu’elles doivent être estimées séparément ou traitées dans une banque d’heures.
Le but n’est pas de limiter la collaboration. Le but est de savoir ce qui relève de la maintenance régulière et ce qui relève d’un mandat distinct.
7. Les canaux de communication
Un SLA doit préciser comment les demandes doivent être envoyées.
Exemples :
- courriel ;
- formulaire de support ;
- outil de ticket ;
- téléphone pour les urgences ;
- canal Slack ou Teams ;
- plateforme projet.
Il faut aussi préciser si les demandes envoyées par SMS, message personnel ou réseaux sociaux sont considérées comme officielles ou non.
Sans canal clair, les demandes se dispersent. Certaines se perdent. D’autres sont traitées sans contexte. Un bon canal d’entrée permet de garder une trace et de mieux prioriser.
Exemple :
Les demandes de maintenance doivent être envoyées par courriel ou via le formulaire de support. Les demandes critiques peuvent être signalées par téléphone après l’ouverture d’un ticket.
8. Le canal d’escalade en cas d’urgence
Un contrat de maintenance WordPress BOFU doit rassurer le client sur les situations critiques.
Le contrat doit indiquer quoi faire si :
- le site est hors ligne ;
- une mise à jour casse le site ;
- WooCommerce ne prend plus de commandes ;
- une erreur critique apparaît ;
- un formulaire principal ne fonctionne plus ;
- le prestataire principal n’est pas disponible ;
- le problème vient de l’hébergeur.
Un canal d’escalade peut prévoir :
- une adresse prioritaire ;
- un numéro pour les urgences ;
- une procédure de qualification ;
- une personne responsable ;
- un délai de première réponse ;
- une règle de priorisation.
Cela ne veut pas dire que tout est corrigé instantanément. Cela signifie que le client sait quoi faire et à qui s’adresser.
9. Les rapports de maintenance
Un bon contrat doit prévoir un rapport périodique.
Le rapport peut inclure :
- mises à jour réalisées ;
- sauvegardes vérifiées ;
- incidents détectés ;
- corrections effectuées ;
- tests réalisés ;
- recommandations ;
- points à surveiller ;
- demandes hors périmètre ;
- temps utilisé, si banque d’heures ;
- prochaines actions proposées.
Le rapport est important pour deux raisons.
Premièrement, il donne de la visibilité au client. Deuxièmement, il montre que la maintenance n’est pas une action invisible ou improvisée.
Pour un site d’entreprise, un rapport mensuel simple est souvent suffisant. Pour un site plus critique, un suivi plus détaillé peut être nécessaire.
10. Les responsabilités du client
Un contrat clair ne définit pas seulement les responsabilités du prestataire. Il précise aussi celles du client.
Par exemple, le client doit généralement :
- fournir les accès nécessaires ;
- informer le prestataire avant de modifier le site ;
- éviter d’installer des extensions sans validation ;
- signaler rapidement les problèmes ;
- maintenir ses licences actives, si elles sont à sa charge ;
- payer les frais d’hébergement, domaine ou outils externes ;
- valider les demandes dans les délais ;
- fournir les contenus nécessaires aux évolutions.
Cette partie est souvent négligée. Pourtant, elle protège la qualité de la maintenance.
Un prestataire ne peut pas garantir un suivi propre si plusieurs personnes modifient le site sans prévenir, installent des extensions ou changent les accès.
11. La gestion des licences, hébergement et outils tiers
Un site WordPress dépend souvent d’éléments externes :
- hébergement ;
- nom de domaine ;
- certificat SSL ;
- extensions premium ;
- thème premium ;
- outil SMTP ;
- CRM ;
- passerelle de paiement ;
- outil de réservation ;
- outil d’infolettre ;
- CDN ;
- service de sauvegarde.
Le contrat doit préciser qui gère quoi.
Questions à clarifier :
- Qui paie les licences ?
- Qui renouvelle les extensions premium ?
- Qui détient les accès ?
- Qui gère l’hébergement ?
- Qui contacte le support de l’hébergeur ?
- Qui est responsable du nom de domaine ?
- Qui configure les outils externes ?
- Qui intervient si une intégration externe tombe ?
Ces éléments peuvent devenir critiques en cas d’urgence. Si le domaine expire ou si une licence bloque une mise à jour, il faut savoir qui est responsable.
12. Le périmètre des petites demandes
Un contrat de maintenance peut inclure certaines petites demandes, mais il faut les définir.
Exemples :
- modification de texte ;
- remplacement d’image ;
- ajout d’un lien ;
- changement d’horaire ;
- ajustement d’un bouton ;
- petite correction visuelle ;
- ajout d’une actualité simple.
Le contrat peut préciser une limite :
- nombre d’heures incluses ;
- nombre de demandes par mois ;
- temps maximum par demande ;
- délai de traitement ;
- exclusion des demandes complexes.
Exemple :
Le forfait inclut jusqu’à 1 heure par mois de petites modifications de contenu. Les demandes non utilisées ne sont pas reportables, sauf mention contraire.
Cette précision évite qu’une “petite modification” devienne une refonte de page complète.
13. La banque d’heures pour les besoins évolutifs
Les besoins évolutifs sont difficiles à prévoir. Une entreprise peut vouloir ajouter une landing page, modifier un formulaire, connecter un CRM, ajuster WooCommerce ou améliorer une page de conversion.
Ces demandes ne relèvent pas toujours du contrat de maintenance de base.
Une banque d’heures peut être utile pour :
- demandes ponctuelles ;
- évolutions mineures ;
- améliorations continues ;
- ajustements de contenu ;
- support technique ;
- intégrations simples ;
- accompagnement WordPress.
Le contrat doit préciser :
- le nombre d’heures ;
- la durée de validité ;
- le tarif ;
- les tâches admissibles ;
- la méthode de suivi ;
- le processus d’approbation.
La banque d’heures permet de garder de la souplesse sans mélanger maintenance régulière et évolution du site.
14. La procédure après une mise à jour problématique
Un bon contrat doit prévoir quoi faire si une mise à jour casse le site.
La procédure peut inclure :
- identification de la mise à jour concernée ;
- vérification de la sauvegarde ;
- rollback de l’extension ou du thème ;
- restauration si nécessaire ;
- tests des pages critiques ;
- documentation de l’incident ;
- recommandation pour éviter la répétition.
Cette procédure doit être réaliste. Certaines mises à jour peuvent être annulées rapidement. D’autres demandent une analyse plus poussée.
Si votre site a déjà été touché, vous pouvez consulter notre guide : site WordPress cassé après mise à jour.
15. La durée du contrat et les conditions de résiliation
Le contrat doit préciser :
- durée d’engagement ;
- renouvellement ;
- préavis de résiliation ;
- transfert des accès ;
- remise des sauvegardes ;
- fin du monitoring ;
- gestion des licences ;
- paiement des soldes ;
- continuité ou arrêt des services.
Cette partie est importante pour éviter les tensions en fin de collaboration.
Le client doit pouvoir récupérer ses accès et comprendre ce qui se passe si la maintenance prend fin. Le prestataire doit aussi pouvoir fermer proprement les outils, les alertes et les accès utilisés pour le suivi.
Exemple de structure d’un SLA WordPress
Voici une structure simple pour un SLA de maintenance WordPress :
| Section | Ce qu’elle doit préciser |
| Périmètre | Tâches incluses et non incluses |
| Fréquence | Rythme des mises à jour, sauvegardes, vérifications |
| Priorités | Critique, élevée, normale, faible |
| Délais | Réponse, prise en charge, suivi |
| Canaux | Courriel, ticket, téléphone, urgence |
| Escalade | Procédure en cas d’incident critique |
| Rapports | Fréquence, contenu, recommandations |
| Responsabilités | Client, prestataire, tiers |
| Exclusions | Hors périmètre, projets séparés, services externes |
| Évolutions | Banque d’heures ou estimation séparée |
| Fin de contrat | Résiliation, transfert, accès, sauvegardes |
Cette structure donne un cadre clair sans rendre le contrat inutilement lourd.
Comment savoir si votre contrat de maintenance WordPress est suffisant ?
Votre contrat est probablement trop vague si vous ne savez pas répondre à ces questions :
- En combien de temps mon prestataire répond-il à une urgence ?
- Qu’est-ce qui est considéré comme urgent ?
- Les sauvegardes sont-elles incluses ?
- À quelle fréquence sont-elles vérifiées ?
- Les mises à jour sont-elles testées après intervention ?
- Les formulaires sont-ils testés ?
- Le site est-il surveillé entre deux maintenances ?
- Les petites modifications sont-elles incluses ?
- Les corrections après incident sont-elles incluses ?
- Les évolutions sont-elles facturées à part ?
- Est-ce que je reçois un rapport ?
- Quel canal dois-je utiliser en cas de problème ?
Si les réponses ne sont pas claires, le contrat mérite d’être précisé.
Ce qu’un contrat de maintenance WordPress ne doit pas promettre
Un SLA sérieux ne doit pas promettre l’impossible.
Il ne devrait pas promettre :
- zéro panne ;
- zéro bug ;
- correction immédiate de tous les problèmes ;
- compatibilité garantie de toutes les extensions ;
- résolution automatique des problèmes causés par un tiers ;
- restauration sans aucune perte dans tous les cas ;
- sécurité absolue ;
- disponibilité totale sans infrastructure adaptée.
Un bon contrat doit être rassurant, mais réaliste. Il doit encadrer la prévention, la surveillance, les délais et la réponse aux incidents.
Le rôle du SLA n’est pas de garantir qu’aucun problème n’arrivera. Son rôle est de définir comment les problèmes seront surveillés, priorisés et traités.
Pourquoi Capsuleweb formalise la maintenance WordPress
Capsuleweb accompagne les entreprises qui veulent un suivi WordPress clair, structuré et adapté à leur réalité.
L’objectif est d’éviter les zones floues :
- ce qui est inclus ;
- ce qui ne l’est pas ;
- les délais ;
- les priorités ;
- les canaux ;
- les rapports ;
- les responsabilités ;
- les besoins évolutifs.
Un contrat bien défini permet de mieux protéger le site, mais aussi de travailler plus sereinement avec le prestataire.
Si votre site WordPress est important pour vos demandes clients, vos ventes ou votre crédibilité, il mérite un cadre de maintenance sérieux.
Vous pouvez nous contacter pour revoir votre contrat actuel ou mettre en place une maintenance WordPress avec un niveau de service clair.
Conclusion
Un contrat de maintenance WordPress doit clarifier beaucoup plus que les mises à jour. Il doit préciser le périmètre, les fréquences, les délais, les priorités, les exclusions, les rapports, les responsabilités et le canal d’escalade en cas d’urgence.
C’est ce cadre qui transforme une maintenance floue en véritable accord de service.
Pour une entreprise, le bénéfice est simple : savoir ce qui est couvert, comment les demandes sont traitées et quoi faire lorsqu’un problème apparaît.
Un bon SLA ne promet pas un site sans aucun incident. Il promet surtout une méthode claire pour surveiller, maintenir, prioriser et intervenir correctement.
FAQ
Qu’est-ce qu’un contrat de maintenance WordPress ?
Un contrat de maintenance WordPress définit les services inclus après la mise en ligne d’un site : mises à jour, sauvegardes, vérifications, monitoring, rapports, délais de réponse et conditions d’intervention.
Qu’est-ce qu’un SLA WordPress ?
Un SLA WordPress est un accord de niveau de service. Il précise les engagements du prestataire : délais de réponse, priorités, périmètre, exclusions, canaux de communication, rapports et procédure d’escalade.
Que doit contenir un contrat de maintenance WordPress ?
Il doit contenir le périmètre des tâches, la fréquence des interventions, les délais de réponse, les niveaux de priorité, les exclusions, les responsabilités du client, les rapports et les conditions de fin de contrat.
Quelle est la différence entre un forfait et un contrat de maintenance WordPress ?
Le forfait décrit souvent les services inclus et le tarif. Le contrat ou SLA précise plus finement les engagements, les limites, les délais, les responsabilités et les procédures en cas de problème.
Un SLA garantit-il que le site ne tombera jamais en panne ?
Non. Un SLA ne garantit pas l’absence totale de panne. Il définit plutôt comment les incidents sont surveillés, priorisés, communiqués et traités.