Maintenance de site web en Tunisie : ce qu’un contrat doit écrire

Un site web n’est pas terminé le jour de sa mise en ligne. WordPress publie des versions correctives, les extensions corrigent leurs failles, PHP arrête de maintenir ses anciennes branches, et un formulaire de contact qui marchait en mars cesse d’envoyer quoi que ce soit en novembre sans que personne ne s’en aperçoive. La maintenance est le travail qui empêche tout cela de s’accumuler. Le contrat qui l’encadre décide d’une chose simple : le jour où quelque chose casse, qui s’en occupe, en combien de temps, et à quel prix.

Cet article parle du site : son CMS, ses extensions, son thème, ses contenus, ses sauvegardes, et le lien avec l’hébergement. L’administration d’un serveur (système, pare-feu, paquets) a son propre article, sur administrer son serveur soi-même ou le confier. Ce texte s’adresse à une PME, une association ou un cabinet qui s’apprête à signer avec une agence ou un indépendant, et à ceux qui rédigent ces contrats. Les textes cités ont été consultés le 7 novembre 2026 ; la liste est en fin d’article.

L’essentiel en six points

• « Maintenance » ne veut rien dire tant que la liste n’est pas écrite : cœur du CMS, extensions, thème, version de PHP, sauvegardes, surveillance.
• L’hébergeur, le prestataire et vous avez chacun une part ; un contrat qui ne la répartit pas laisse un trou exactement là où arrive la panne.
• Un délai se compte par niveau de gravité, avec des jours et des heures, et distingue la prise en charge de la correction.
• Une sauvegarde qu’on n’a jamais restaurée n’est qu’une hypothèse. Le contrat prévoit des essais de restauration.
• Le domaine, l’hébergement et les licences sont à votre nom ; le prestataire y travaille avec un accès qui lui est propre.
• La fin du contrat s’écrit au début : ce qui vous est remis, sous quel délai, et ce que le prestataire efface.

Corrective, préventive, évolutive : trois travaux différents

Le mot recouvre trois activités qui ne se facturent pas de la même façon, et la plupart des malentendus viennent de ce qu’un devis les mélange.

• La maintenance corrective répare ce qui ne marche plus : une page blanche après une mise à jour, un formulaire qui n’envoie rien, un site infecté. Elle est imprévisible par nature ; le contrat fixe donc des délais plutôt qu’un volume.
• La maintenance préventive évite d’en arriver là : mises à jour du CMS, des extensions et du thème, suivi des failles annoncées, contrôle des sauvegardes, surveillance de la disponibilité, renouvellement du domaine et du certificat. C’est un travail régulier, qui se prête à un forfait.
• La maintenance évolutive change le site : une nouvelle page, une fonction de réservation, un changement de charte. Ce n’est plus de l’entretien, c’est du développement, et il se chiffre à la demande.

Un forfait qui couvre le préventif et une part de correctif, et renvoie l’évolutif au devis, est un montage sain. Le piège est de découvrir au premier incident que la réparation n’était pas comprise. Demandez que le contrat dise, pour chacune des trois, si elle est comprise, plafonnée ou facturée à part.

L’hébergeur, le prestataire, vous : qui fait quoi

Un site vit sur trois étages. L’hébergeur tient la machine et le logiciel qui fait tourner le site ; le prestataire de maintenance tient le site lui-même ; vous restez propriétaire de l’ensemble et responsable de ce qui y est publié. La frontière exacte dépend de l’hébergement choisi, et c’est elle que le contrat doit reprendre. Voici ce qu’elle donne chez nous sur un pack mutualisé, d’après nos pages et nos conditions générales, et, pour les versions de PHP proposées, d’après notre équipe technique :

Nos conditions générales le disent sans détour (article 7.3) : hors option d’infogérance, « le Client est seul responsable de l’administration, de la sécurisation, de la maintenance applicative et des sauvegardes de son Contenu ». Et l’article 8 exclut notre responsabilité pour un accès obtenu par « une faille de son Contenu (CMS, plugin, script) ». C’est la ligne de partage habituelle d’un hébergement : ce qui est au-dessus, quelqu’un doit le faire, et c’est l’objet du contrat de maintenance.

Sur un VPS ou un serveur dédié, la frontière remonte : le logiciel du serveur, PHP compris, passe à votre charge, sauf si vous confiez l’administration du serveur à une équipe. Notre infogérance est réservée à ces deux offres ; elle administre le système et ses services, et laisse le code du site à son auteur. Un prestataire qui maintient un site sur un VPS doit donc dire s’il prend aussi la machine, ou qui la prend.

Le cas d’octobre 2026 : qui devait mettre PHP à jour ?

Le 21 octobre 2026, PHP a corrigé deux failles critiques surnommées « PHP2Shell », qui permettaient d’exécuter du code sur le serveur sans aucun compte. Ce que chacun devait faire, les versions corrigées et la façon de s’assurer que le correctif est en place sont détaillés dans notre article sur la faille PHP2Shell. Ce qui nous intéresse ici, c’est ce que la semaine a révélé des contrats.

La faille était dans le moteur PHP, pas dans WordPress ni PrestaShop : mettre à jour le CMS n’y changeait rien. Sur un mutualisé, la correction revenait à l’hébergeur (les nôtres l’ont reçue le 22 octobre). Sur un VPS, elle revenait à celui qui administre la machine. Le piège typique : un contrat qui parle de « mises à jour » sans dire lesquelles, une agence qui tient PHP pour l’affaire de l’hébergeur, et un VPS, loué au nom du client, que personne n’administre.

Un contrat bien écrit aurait déclenché, sans discussion, une suite de gestes datés :

1. Une veille nommée : le prestataire suit les bulletins de sécurité, dont ceux du tunCERT de l’ANCS, et ceux des logiciels qu’il maintient.
2. Un délai propre aux failles critiques, plus court que celui d’une panne ordinaire, qui court à partir de la publication de l’alerte et non de votre appel.
3. Une répartition écrite : sur le mutualisé, le prestataire obtient de l’hébergeur la confirmation de la correction ; sur un VPS sans infogérance, il corrige lui-même ou dit par écrit qu’il ne le fait pas.
4. Une recherche de traces sur la période où la faille était connue, et non une simple mise à jour.
5. Un compte rendu : ce qui a été vérifié, à quelle date, avec la réponse de l’hébergeur.

La même question reviendra à date fixe. Selon le calendrier de PHP, chaque branche reçoit deux ans de corrections, puis deux ans de correctifs de sécurité seulement ; la branche 8.2 ne reçoit plus de correctif de sécurité après le 31 décembre 2026, la 8.3 après le 31 décembre 2027. Un site encore en 8.2 doit donc passer à une branche plus récente, après essai. Le contrat doit dire qui le fait et quand, plutôt que de le laisser au jour de la prochaine faille. Le choix de la version selon le CMS est traité dans notre article sur la version de PHP à utiliser avec WordPress.

Le périmètre : écrire la liste, pas le mot

La clause la plus utile d’un contrat de maintenance est une liste, la plus dangereuse est un mot. « Maintenance technique du site » ne vous protège de rien ; une liste vous permet de vérifier chaque mois ce qui a été fait. Elle devrait nommer au moins :

• Le cœur du CMS, avec la règle : versions de sécurité appliquées sous quel délai, versions majeures après essai. WordPress n’assure officiellement que sa dernière version, et ne reporte ses correctifs sur les anciennes que par courtoisie.
• Les extensions et le thème, avec leur liste nominative en annexe, mise à jour à chaque ajout. Une extension ajoutée sans prévenir par le client sort-elle du contrat ? Écrivez-le.
• La version de PHP et son passage à la branche suivante avant sa fin de support.
• Les sauvegardes et leurs essais de restauration (voir plus bas).
• La sécurité : veille, correction des failles annoncées, nettoyage en cas d’infection, revue des comptes administrateurs.
• La surveillance : disponibilité, expiration du domaine et du certificat, envoi des formulaires.
• Les petites corrections de contenu, s’il y en a : combien par mois, et ce qu’on entend par « petite ».

Puis ce qui est exclu, aussi précisément : refonte, nouvelles fonctions, rédaction de contenus, référencement, messagerie, correction d’un dommage causé par une modification que le client a faite lui-même. Une exclusion écrite n’est pas un mauvais signe ; elle évite le conflit le jour où la demande arrive. L’absence de toute exclusion en est un, parce qu’elle sera tranchée au cas par cas, après coup.

Pour les failles d’extensions, l’exemple récent est dans notre article sur les failles WordPress d’octobre 2026 ; les réglages de fond qui réduisent le risque sont dans le guide pour sécuriser WordPress.

Sauvegardes : hors de la machine, et restaurées pour de vrai

La documentation de WordPress conseille de sauvegarder avant une mise à jour et, dans sa procédure manuelle, de vérifier que les copies existent et sont utilisables, étape qu’elle qualifie d’essentielle. Deux choses font la valeur d’une sauvegarde, et un contrat doit les écrire toutes les deux.

Où elle est. Une copie rangée sur le même serveur que le site disparaît avec lui. Le contrat précise la fréquence, la durée de conservation, et l’endroit où est gardé au moins un exemplaire hors de la machine. Chez nous, l’outil de sauvegarde de Plesk est compris dans les packs et ses copies comptent dans l’espace du pack ; la sauvegarde externalisée quotidienne, en option, garde trente jours de copies sur un site distant. Nos propres sauvegardes de serveur servent à remettre le service en route après un incident chez nous : elles ne sont pas faites pour restaurer un site à une date choisie. Un prestataire qui vous dit « l’hébergeur sauvegarde » sans plus de précision ne vous a rien promis.

Si elle se restaure. Seul un essai le prouve : demandez-en un à intervalle fixe, sur une copie et non sur le site réel, avec un compte rendu : date de la copie restaurée, ce qui a été vérifié (pages, base, formulaires, paiements), durée de l’opération. Cette durée est celle que vous subirez le jour d’une vraie panne : mieux vaut la connaître avant.

Le rythme et le nombre de copies sont traités dans notre guide de la sauvegarde d’un site ; le contrat, lui, nomme qui sauvegarde, qui restaure, et ce que coûte une restauration demandée.

Les mises à jour qui cassent : la copie de test

Bien des pannes viennent d’une mise à jour, pas d’une attaque : une extension devenue incompatible avec le thème, un module de paiement qui ne suit pas la nouvelle version de la boutique. WordPress installe d’office ses versions mineures, celles de maintenance et de sécurité, et sa documentation déconseille fortement de les désactiver. Les versions majeures, les extensions et le thème demandent davantage de prudence.

La parade est une préproduction, ou copie de test : un double du site, à une adresse séparée, où l’on applique les mises à jour avant de les reporter sur le site réel. Le contrat peut l’exiger pour toute version majeure et pour toute extension qui touche aux commandes, aux paiements ou aux formulaires. Il dit aussi ce qui se passe quand une mise à jour casse malgré tout : retour à la copie de la veille, dans quel délai, et à la charge de qui.

Sur nos packs WordPress, la copie de test (« staging ») est comprise à partir de WP BUSINESS ; la marche à suivre, dans l’ordre, est décrite dans le guide pour mettre à jour WordPress, ses thèmes et ses extensions sans casser le site. Sur un site qui reçoit des commandes, rappelez au prestataire qu’une copie remise en place écrase ce qui a été enregistré entre-temps : le contrat prévoit une fenêtre d’intervention où le site ne vend pas, ou une méthode qui ne touche pas à la base.

Délais d’intervention : par gravité, avec des horaires

« Intervention rapide » ne se mesure pas. Un délai utile a trois composantes : un niveau de gravité, un délai de prise en charge (quelqu’un a commencé à travailler) distinct d’un délai de rétablissement (le site remarche), et des jours et heures pendant lesquels le compteur tourne. Un délai de quatre heures « ouvrées » qui commence un vendredi soir n’expire que le lundi.

Les durées se négocient, et se paient, selon ce que vous perdez quand le site s’arrête ; ce qui ne se négocie pas, c’est qu’elles soient écrites. Pour comparaison, notre infogérance de serveurs affiche des prises en charge de 6 à 48 heures selon la formule, avec les jours couverts pour chacune : c’est la forme attendue, quel que soit le prestataire. Précisez aussi le canal : un message WhatsApp à un salarié en congé ne fait courir aucun délai.

Le domaine, les comptes et les accès au nom du client

Le plus coûteux des litiges de fin de contrat ne porte pas sur une facture, mais sur un nom de domaine enregistré au nom de l’agence, ou un hébergement ouvert sur son compte. Le contrat de maintenance doit constater, dès sa signature, que sont au nom du client :

• le nom de domaine, avec son adresse de contact ;
• le compte d’hébergement et son espace client ;
• les licences des thèmes et extensions payants ;
• les comptes des services reliés au site : outils de statistiques et de suivi du référencement, envoi d’e-mails, solution de paiement, réseaux sociaux.

Le prestataire y travaille avec un accès à son nom : un compte administrateur WordPress personnel, un accès délégué au panneau, et non le mot de passe du dirigeant. On sait alors qui a fait quoi, et l’accès se retire d’un geste à la fin du contrat. Nos conditions générales rappellent que le client protège ses identifiants et reste responsable de ce qui est fait depuis son compte tant qu’il n’a pas signalé une compromission (article 7.2) : un accès partagé brouille précisément cette preuve.

Si l’agence porte elle-même l’hébergement de ses clients, ce qui est un montage légitime, le contrat doit dire comment le site est transféré au client qui part. Les montages possibles et leurs conséquences sont décrits dans notre article pour les agences et les indépendants qui hébergent leurs clients.

La fin du contrat : ce qui vous est remis

La réversibilité est la clause qu’on lit le moins à la signature et qu’on cherche le plus à la rupture. Elle fixe ce que le prestataire remet, sous quel délai après la fin, et dans quel état :

• les accès qu’il détenait, ou la confirmation de leur suppression ;
• une sauvegarde complète et récente, fichiers et base, dans un format standard ;
• le code qu’il a écrit pour vous, ou l’accès au dépôt où il est versionné ;
• la liste à jour des extensions, de leurs licences et de leurs dates d’échéance ;
• les réglages particuliers : tâches planifiées, redirections, configuration de l’envoi d’e-mails ;
• l’historique des interventions.

Pensez au calendrier de l’hébergement. Chez nous, après la fin d’un service, le client dispose de 72 heures pour récupérer son contenu, et les données d’un hébergement sont conservées au plus 30 jours après une échéance non renouvelée avant suppression définitive (article 6 des conditions générales). Si le prestataire qui part était aussi celui qui renouvelait l’hébergement, le délai de remise du contrat de maintenance doit tenir à l’intérieur de cette fenêtre.

Données personnelles : le prestataire est un sous-traitant

Un mainteneur qui accède à la base d’un site voit des données personnelles : comptes clients, commandes, messages reçus par formulaire. La loi organique n° 2004-63 distingue le responsable du traitement, « toute personne physique ou morale qui détermine les finalités et les moyens du traitement », c’est-à-dire votre entreprise, et le sous-traitant qui agit pour son compte (article 6).

Elle impose à quiconque traite des données, directement ou par un tiers, de « prendre toutes les précautions nécessaires pour assurer la sécurité de ces données » (article 18), et parmi les mesures que détaille l’article 19 figurent le contrôle des accès et des copies de sauvegarde sécurisées. L’article 20 vise la sous-traitance : le responsable choisit son sous-traitant avec soin, celui-ci n’agit que dans les limites fixées par le responsable et dispose des moyens techniques adéquats, et les deux sont responsables civilement en cas de manquement. La loi pose aussi des conditions au sous-traitant et à ses agents (article 22) : « Être de nationalité tunisienne ; Être résident en Tunisie ; Être sans antécédents judiciaires » ; un prestataire installé à l’étranger mérite donc qu’on en parle avec un juriste. L’article 23 étend l’obligation de confidentialité au sous-traitant et à ses agents, même après la fin du traitement.

Traduit en points de contrat : ce que le prestataire a le droit de faire des données (maintenir le site, rien d’autre), l’interdiction d’en garder des copies sur ses propres postes au-delà du nécessaire, la confidentialité de son personnel, l’information sans délai en cas d’incident, et l’effacement de tout ce qu’il détient à la fin du contrat. Les autres obligations de l’entreprise, déclarations comprises, sont dans notre article sur la protection des données personnelles en entreprise. La rédaction de ces clauses relève d’un juriste.

Durée, résiliation, facturation

Quelques questions suffisent à lire cette partie du contrat :

• Durée et reconduction. Le contrat est-il annuel, reconduit tacitement, et avec quel préavis peut-on y mettre fin ?
• Ce que paie le forfait. Un nombre d’heures, une liste de tâches, ou les deux ? Les heures non consommées sont-elles perdues, reportées, ou remboursées ?
• Le tarif hors forfait. Le prix d’une heure d’intervention supplémentaire, et l’accord préalable exigé au-delà d’un montant.
• La révision du prix, et le préavis qui l’accompagne.
• Ce qui n’est pas compris dans le prix de la maintenance : domaine, hébergement, licences. Qui les paie, et à quel nom arrivent les factures ?
• La résiliation pour manquement : si les délais ne sont pas tenus, le client peut-il partir avant le terme ?

Le montant juste dépend du site, du nombre d’extensions et des délais demandés ; nous ne citons pas de fourchette de marché, faute de source qui en publie une. La place de la maintenance dans le budget d’un site est traitée dans notre article sur ce que coûte un site web.

Le compte rendu : la preuve que la maintenance a eu lieu

Une maintenance préventive réussie ne se voit pas : le site marche, comme avant. Le compte rendu, mensuel ou trimestriel, est la seule trace du travail. Demandez qu’il contienne :

• les versions du CMS, du thème, des extensions et de PHP, avant et après ;
• les mises à jour appliquées, et celles reportées avec leur raison ;
• la date de la dernière sauvegarde vérifiée et du dernier essai de restauration ;
• les alertes de sécurité examinées et la suite donnée ;
• les incidents, avec l’heure du signalement, de la prise en charge et du rétablissement ;
• le temps consommé sur le forfait ;
• ce qui approche de son terme : fin de support d’une branche de PHP, licence ou domaine à renouveler.

Il sert aussi de preuve en cas de désaccord, avec le prestataire comme avec l’hébergeur : nos propres conditions générales demandent au client d’appuyer une contestation sur des constats horodatés, des journaux techniques ou des échanges écrits (article 7.6).

Juger un devis : les questions à poser

Avant de comparer des montants, comparez des réponses. Posez les mêmes questions à chaque prestataire, par écrit :

1. Quels logiciels maintenez-vous exactement, et où en est la liste ?
2. Qui met à jour PHP sur mon hébergement, et quand passerez-vous à la branche suivante ?
3. Sous quel délai appliquez-vous une correction de sécurité critique, à compter de quoi ?
4. Testez-vous les mises à jour sur une copie avant le site réel ?
5. Où sont gardées les sauvegardes, combien de temps, et quand avez-vous fait le dernier essai de restauration ?
6. Quels jours et quelles heures votre délai couvre-t-il ? Qui répond pendant vos congés ?
7. À quel nom sont le domaine, l’hébergement et les licences ?
8. Que me remettez-vous si nous arrêtons, et en combien de jours ?
9. Qu’est-ce qui n’est pas compris, et quel est le tarif hors forfait ?
10. Que faites-vous des données de mes clients auxquelles vous accédez ?

Un prestataire sérieux répond à chacune en une phrase ; « on s’occupe de tout » n’est une réponse à aucune.

Points à vérifier avant de signer

Ce qui suit n’est pas un modèle de contrat, c’est une liste de contrôle pour relire un projet. La rédaction, et son adaptation au droit tunisien des contrats, reviennent à un juriste ou à un avocat.

1. Corrective, préventive, évolutive : ce qui est compris pour chacune.
2. En annexe, la liste des logiciels maintenus, version de PHP comprise.
3. Le partage écrit avec l’hébergeur.
4. Sauvegardes hors du serveur, essais de restauration datés.
5. Copie de test et retour arrière pour les mises à jour majeures.
6. Délais par gravité, dont un délai propre aux failles critiques.
7. Domaine, hébergement, licences au nom du client ; accès nominatifs.
8. Réversibilité compatible avec le délai de l’hébergeur.
9. Clauses de sous-traitance des données personnelles.
10. Durée, préavis, tarif hors forfait, résiliation pour manquement, compte rendu.

Sources

Pages consultées le 7 novembre 2026.

• Loi organique n° 2004-63 du 27 juillet 2004 portant sur la protection des données à caractère personnel, texte publié par legislation-securite.tn (articles 6, 18, 19, 20 et 23).
• PHP — Supported Versions (durée de support des branches, fin des correctifs de sécurité de 8.2 et 8.3).
• WordPress — Security (seule la dernière version est officiellement prise en charge, correctifs reportés sur les anciennes à titre de courtoisie).
• WordPress — Upgrading WordPress (sauvegarde et vérification avant mise à jour, mises à jour mineures automatiques par défaut).
• ANCS — tunCERT, centre de réponse aux urgences de l’Agence nationale de la cybersécurité, qui publie les bulletins de vulnérabilités.
• NovaHoster — conditions générales de vente (articles 6, 7.2, 7.3, 7.6 et 8).
• NovaHoster — packs d’hébergement (déploiement par Git, sauvegardes, Imunify360, ce que couvre le support) et infogérance des VPS et serveurs dédiés (délais de prise en charge, partage des tâches).