Contrat de maintenance WordPress : les clauses qui protègent

Un contrat de maintenance WordPress n’est pas une simple ligne de dépense destinée à « garder le site à jour ». Il fixe ce qui sera réellement surveillé, sauvegardé, corrigé et documenté, mais aussi ce qui restera hors forfait. Cette précision est décisive : WordPress recommande de maintenir le cœur, les extensions et les thèmes à jour, tandis que ses propres documentations insistent sur la nécessité de disposer d’une sauvegarde actuelle avant une mise à jour. Une offre sérieuse ne devrait donc pas se limiter à annoncer des mises à jour ; elle doit expliquer comment le prestataire limite les risques et comment il revient en arrière si une opération échoue. ([wordpress.org](https://wordpress.org/documentation/article/plugins-themes-auto-updates/?utm_source=openai))

Le bon réflexe consiste à lire l’offre comme un dispositif de continuité de service. Que couvre-t-elle précisément ? À quel rythme ? Avec quels contrôles ? Qui intervient, par quel canal et dans quel délai ? Quelle preuve reçoit le client ? Ces questions permettent de différencier une prestation minimale, parfois adaptée à un petit site statique, d’un accompagnement réellement protecteur pour un site qui génère des demandes, des ventes, des comptes utilisateurs ou collecte des données personnelles.

Commencer par un périmètre écrit, mesurable et limité

La première clause utile est celle du périmètre. Elle doit identifier le ou les sites concernés, leurs environnements d’hébergement, les accès que le prestataire utilise, ainsi que les composants inclus : cœur WordPress, thème actif, thème enfant, extensions, base de données, fichiers téléversés, tâches planifiées, certificat TLS, configuration serveur ou cache, selon le service vendu. Cette liste évite une ambiguïté classique : une intervention sur WordPress peut nécessiter d’agir sur l’hébergement, le DNS, la messagerie transactionnelle ou un service tiers, sans que ces éléments soient forcément administrés par le mainteneur.

Le périmètre doit également distinguer les composants standards des développements spécifiques. WordPress rappelle qu’une mise à niveau touche les fichiers de l’installation principale et que les modifications effectuées directement dans ces fichiers peuvent être perdues. Les mises à jour de thème peuvent aussi écraser des adaptations si elles ne sont pas isolées dans un thème enfant ou dans une solution appropriée. Un contrat sérieux précise donc si le prestataire vérifie seulement la compatibilité des personnalisations, s’il les corrige, ou s’il établit un devis distinct. ([wordpress.org](https://wordpress.org/documentation/article/updating-wordpress/?utm_source=openai))

La même rigueur vaut pour les exclusions. Rédaction de contenu, création de pages, ajout de fonctionnalités, refonte graphique, optimisation SEO, migration d’hébergeur, correction d’un outil SaaS externe ou remise en conformité juridique ne doivent pas être supposés inclus parce que le mot « maintenance » apparaît dans l’intitulé. Une exclusion claire n’est pas un défaut : elle permet de savoir quand une demande relève du forfait, d’une régie ou d’un devis.

À demander : un inventaire initial des composants, des accès et des services tiers.
À faire préciser : les environnements inclus, par exemple production et préproduction, ainsi que les limites de responsabilité sur l’hébergement.
À vérifier : le traitement des extensions premium, dont les licences, renouvellements et accès aux mises à jour peuvent rester à la charge du client.
Signal d’alerte : une promesse de « maintenance complète » sans liste des opérations, des exclusions ni procédure d’acceptation des travaux hors forfait.

Les mises à jour : une opération préparée, pas un bouton automatique

Le socle préventif comprend les mises à jour du cœur de WordPress, des extensions, des thèmes et, lorsque cela entre dans le périmètre technique, des composants du serveur. WordPress indique que les développeurs d’extensions publient notamment des mises à jour pour ajouter des fonctions, améliorer la qualité du code et maintenir la sécurité ; sa documentation recommande de garder extensions et thèmes à jour. Le projet WordPress précise aussi que les correctifs de sécurité du cœur peuvent être publiés dans des versions de correction et distribués automatiquement aux sites concernés. ([wordpress.org](https://wordpress.org/documentation/article/manage-plugins/?utm_source=openai))

Mais « mises à jour incluses » ne signifie pas nécessairement « tout déployer immédiatement et sans contrôle ». Le contrat doit indiquer la fréquence de revue, la méthode de qualification, l’existence ou non d’un environnement de préproduction, la sauvegarde préalable, les vérifications après déploiement et la procédure de retour arrière. WordPress permet l’activation des mises à jour automatiques des extensions et des thèmes et envoie des notifications après les tentatives réussies ou échouées. Cette automatisation peut être utile, mais elle ne remplace ni une stratégie de sauvegarde ni un contrôle fonctionnel. ([wordpress.org](https://wordpress.org/documentation/article/plugins-themes-auto-updates/?utm_source=openai))

La fréquence doit être adaptée à l’exposition et à l’activité du site. Il n’existe pas un rythme universel valable pour tous les sites. En revanche, le contrat peut distinguer une revue planifiée des mises à jour ordinaires et un circuit accéléré pour les correctifs de sécurité jugés nécessaires. Il doit aussi dire qui décide lorsqu’une mise à jour présente un risque de compatibilité, quelle information est transmise au client et si le traitement d’une incompatibilité est inclus.

Une clause exploitable décrit une chaîne complète : sauvegarde, mise à jour, contrôle, correction ou retour arrière, puis traçabilité. Une clause vague se contente d’annoncer que le site sera « tenu à jour ».

Les sauvegardes : fréquence, contenu, conservation et restauration

Une sauvegarde WordPress complète ne se réduit pas à l’export de la base de données. La documentation officielle rappelle que les contenus et de nombreuses données sont dans la base, tandis que les fichiers comprennent notamment le cœur, les extensions, les thèmes, les images et d’autres fichiers de code. Elle recommande de sauvegarder à la fois le site et la base de données, avec des sauvegardes automatiques, et de réaliser une sauvegarde avant une mise à jour. ([fr.wordpress.org](https://fr.wordpress.org/support/article/wordpress-backups/?utm_source=openai))

Le contrat doit donc répondre à quatre questions concrètes. Premièrement, quoi : base de données, fichiers, configuration et, si nécessaire, éléments hors WordPress indispensables au fonctionnement. Deuxièmement, à quelle fréquence : le besoin dépend de la fréquence de publication et des transactions. WordPress propose précisément de partir de la perte de données acceptable si le site devenait indisponible à l’instant. ([fr.wordpress.org](https://fr.wordpress.org/support/article/wordpress-backups/?utm_source=openai)) Troisièmement, où et combien de temps : emplacement, séparation éventuelle du serveur principal, chiffrement ou contrôle d’accès, nombre de points de restauration et durée de rétention. Quatrièmement, comment restaurer : le délai et le périmètre de l’opération doivent être annoncés.

Il faut surtout exiger un test de restauration. La présence de fichiers de sauvegarde ne prouve pas qu’ils pourront restaurer un site exploitable. L’ANSSI recommande de définir les éléments à sauvegarder, les lieux de stockage et les droits d’accès, de réaliser les sauvegardes régulièrement, puis de documenter et tester les procédures de restauration. Son guide d’hygiène informatique recommande de planifier au moins un exercice annuel de restauration une fois la politique établie et de conserver une trace technique du résultat. ([messervices.cyber.gouv.fr](https://messervices.cyber.gouv.fr/documents-guides/anssi-guide-admin_securisee_si_v3-0.pdf?utm_source=openai))

Une offre minimale peut inclure une sauvegarde planifiée sans engagement de test ni accompagnement de restauration. Cela peut convenir à un site peu critique si le client accepte ce niveau de risque. Un accompagnement protecteur fait de la restauration un livrable : date du dernier test, périmètre testé, résultat et anomalies éventuelles figurent dans le reporting.

Surveillance et sécurité : définir les signaux observés et la réponse

La surveillance ne doit pas être confondue avec la maintenance. Elle consiste à observer des signaux utiles, par exemple l’accessibilité du site, l’expiration prochaine d’un certificat, l’échec d’une sauvegarde, une alerte de sécurité, l’espace disque, les erreurs applicatives ou des changements d’intégrité selon l’outillage prévu. La journalisation et son analyse régulière font partie des recommandations de l’ANSSI pour la supervision de sécurité ; l’ANSSI souligne également que la journalisation est utile pour détecter des activités inhabituelles et pour examiner un incident après coup. ([messervices.cyber.gouv.fr](https://messervices.cyber.gouv.fr/documents-guides/anssi-guide-admin_securisee_si_v3-0.pdf?utm_source=openai))

Le contrat doit donc annoncer les outils ou, au minimum, les catégories de contrôles, les plages de surveillance, les seuils d’alerte, le destinataire des alertes et l’action prévue. Une disponibilité surveillée en continu ne garantit pas une correction en continu : une sonde peut détecter une indisponibilité à toute heure alors que l’équipe d’intervention n’est active que pendant les jours ouvrés. Cette différence doit apparaître noir sur blanc.

La sécurité doit elle aussi être formulée comme une série d’actions et de responsabilités. Le projet WordPress indique que son équipe de sécurité travaille sur le cœur, sur des correctifs et sur des mesures d’atténuation avec des acteurs de l’hébergement et de l’écosystème. Cela ne signifie pas qu’un site donné est protégé automatiquement contre toutes les failles d’extensions, les mots de passe compromis, les droits excessifs ou les configurations serveur insuffisantes. ([wordpress.org](https://wordpress.org/about/security/?utm_source=openai)) Un bon contrat peut inclure une revue des comptes administrateurs, le principe du moindre privilège, la vérification des mises à jour, l’assistance en cas d’alerte et la conservation d’éléments utiles au diagnostic. Il doit aussi préciser ce qui relève de l’hébergeur, de l’éditeur d’une extension et du client.

Support et délais d’intervention : transformer une promesse en SLA lisible

Le support est souvent la partie la plus visible d’un forfait, mais aussi la plus ambiguë. Le contrat doit définir les canaux acceptés, par exemple ticket, courriel ou téléphone, les horaires, les contacts autorisés, la langue, le nombre de demandes éventuellement incluses et le mode de qualification. Il doit surtout séparer le délai de prise en compte, le délai de première réponse, le délai de rétablissement visé et le délai de résolution. Ces notions ne recouvrent pas la même obligation.

La criticité doit être définie par des cas concrets. Une indisponibilité totale du site de production, l’impossibilité de finaliser une commande ou une compromission présumée ne se traite pas comme une demande de modification de texte. Une grille simple peut classer les incidents selon leur impact, préciser les horaires applicables à chaque niveau et prévoir la cadence des informations envoyées au client jusqu’au rétablissement. Le délai doit être assorti de prérequis : accès disponibles, hébergeur joignable, licence valide, interlocuteur client habilité à valider une décision.

Il faut également lire les termes d’engagement avec précision. Un engagement de moyens consiste à mobiliser les actions prévues ; un engagement de résultat porte sur un résultat défini. Sans qualification juridique adaptée au contexte contractuel, il est plus prudent de demander des indicateurs opérationnels observables : délai de réponse constaté, heure de détection, heure de début d’intervention, état de la restauration et cause identifiée ou non. Pour les incidents complexes impliquant un tiers, le mainteneur ne maîtrise pas nécessairement le temps de résolution, mais il peut s’engager sur l’escalade, la coordination et l’information.

Maintenance préventive, corrective et évolutive : trois prestations différentes

La maintenance préventive cherche à réduire la probabilité ou l’impact d’un incident. Elle recouvre typiquement l’inventaire, les mises à jour, les sauvegardes, les contrôles de bon fonctionnement, la surveillance et certaines revues de sécurité. Elle est le cœur d’un contrat récurrent, car elle agit avant la panne.

La maintenance corrective intervient après la détection d’un dysfonctionnement : écran d’erreur, fonctionnalité cassée, extension en conflit, site indisponible ou restauration nécessaire. Le contrat doit fixer comment un incident est déclaré, qualifié, diagnostiqué et suivi. Il doit aussi indiquer le volume éventuellement inclus et la frontière avec une correction de développement spécifique. Les documentations WordPress signalent qu’un conflit d’extension ou de thème peut être une piste de diagnostic lorsqu’un comportement anormal survient, ce qui illustre pourquoi une correction peut nécessiter une investigation avant toute promesse de délai de résolution. ([wordpress.org](https://wordpress.org/support/topic/after-updating-to-wordpress-6-6-2-i-cant-update-plugins/?utm_source=openai))

La maintenance évolutive modifie le périmètre fonctionnel : nouvelle page, connecteur, tunnel de conversion, intégration métier, changement de thème ou ajout de fonctionnalités. Elle ne doit pas être absorbée artificiellement dans un forfait de sécurité et de support. Une offre protectrice peut prévoir un processus léger pour l’évolution, avec expression du besoin, estimation, validation, recette et mise en production ; elle ne prétend pas que toute évolution est comprise dans une mensualité fixe.

Reporting, accès et données personnelles : rendre la prestation contrôlable

Le reporting donne au client la capacité de vérifier la prestation sans avoir à suivre chaque action technique. Un rapport périodique utile récapitule les mises à jour réalisées, les sauvegardes et leurs échecs éventuels, les incidents, les interventions, les alertes significatives, les demandes en attente, les recommandations et le prochain cycle d’actions. La CNIL donne comme exemple de clause de maintenance la tenue d’un descriptif des opérations précisant date, nature et intervenants, ainsi que des registres pour les opérations de télémaintenance. ([cnil.fr](https://www.cnil.fr/fr/securite-encadrer-la-maintenance-et-la-destruction-des-donnees?utm_source=openai))

Le client doit conserver la maîtrise de ses actifs : compte d’hébergement, nom de domaine, messagerie, sauvegardes et accès administrateurs. Le contrat peut organiser les droits du prestataire, mais il doit prévoir leur révocation ou restitution à la fin de la relation. Lorsqu’un mainteneur traite des données personnelles pour le compte du client, une analyse RGPD est nécessaire. L’article 28 du RGPD prévoit qu’un tel traitement soit encadré par un contrat ou acte juridique précisant notamment l’objet et la durée du traitement, sa nature et sa finalité, les types de données, les catégories de personnes concernées ainsi que les obligations et droits du responsable de traitement. ([eur-lex.europa.eu](https://eur-lex.europa.eu/legal-content/EN-FR-ES/ALL/?from=EN&uri=CELEX%3A32016R0679&utm_source=openai))

La CNIL rappelle que les sous-traitants doivent présenter des garanties suffisantes, notamment en matière de sécurité, et que le responsable de traitement doit connaître le détail des mesures mises en œuvre afin de démontrer sa conformité. Il faut donc demander qui peut accéder aux données, depuis quels pays ou sous-traitants ultérieurs, comment les accès sont protégés, dans quels cas le prestataire est informé d’un incident et ce qu’il devient des données et des sauvegardes à la fin du contrat. ([cnil.fr](https://www.cnil.fr/fr/securite-gerer-la-sous-traitance?utm_source=openai))

Grille d’évaluation d’une offre de maintenance WordPress

Avant de signer, attribuez à chaque point ci-dessous une réponse : « écrit et précis », « annoncé mais imprécis » ou « absent ». L’objectif n’est pas d’exiger le même niveau de service pour tous les sites ; il est de savoir exactement quel niveau de protection est acheté.

Périmètre : les sites, composants, environnements, accès et exclusions sont-ils listés ?
Mises à jour : la fréquence, la sauvegarde préalable, les tests et le retour arrière sont-ils décrits ?
Sauvegardes : fichiers et base sont-ils inclus, avec fréquence, rétention, stockage et test de restauration ?
Surveillance : les éléments surveillés, horaires, alertes et actions associées sont-ils identifiés ?
Sécurité : les contrôles, responsabilités, gestion des accès et traitement des alertes sont-ils précisés ?
Support : canaux, horaires, contacts, délais de réponse et niveaux de priorité sont-ils écrits ?
Correction : la méthode de diagnostic, les limites du forfait et le traitement des tiers sont-ils prévus ?
Évolutions : le contrat distingue-t-il clairement les changements fonctionnels du maintien en condition ?
Reporting : le contenu, la fréquence et le format du rapport sont-ils définis ?
Fin de contrat : les accès, données, sauvegardes et documentations sont-ils restitués selon une procédure claire ?

Le critère décisif : la capacité à prouver et à restaurer

Une prestation minimale se reconnaît souvent à son vocabulaire général : mises à jour, sécurité, sauvegardes et assistance, sans fréquence, sans périmètre, sans compte rendu ni engagement de procédure. Elle peut satisfaire un besoin simple, mais elle laisse au client l’essentiel du risque d’interprétation lorsqu’un incident se produit.

Un accompagnement réellement protecteur ne promet pas qu’aucun incident n’arrivera. Il rend la prévention, la détection, la décision et le rétablissement plus prévisibles. Il précise ce qui est surveillé, sauvegardé et testé ; il distingue le support de la résolution ; il trace les interventions ; il encadre les accès aux données ; et il expose les limites du service avant la crise. C’est cette capacité à décrire, démontrer et restaurer qui donne au contrat de maintenance WordPress sa valeur concrète.