Contrat de maintenance de site web : ce que vous achetez vraiment en signant

La maintenance d’un site web se vend comme une liste de tâches : mises à jour, sauvegardes, surveillance, « petites modifications comprises dans le forfait ». Ce que vous achetez est pourtant autre chose — un contrat. Et dans un contrat, trois points comptent, que les offres passent généralement sous silence : ce que vous obtenez quand une promesse n’est pas tenue, à qui appartient ce que le prestataire réalise, et qui détient les clés au moment de vous séparer.

Pour mesurer l’écart entre « quelqu’un s’occupe du site » et « quelqu’un en répond », un seul chiffre tiré des statistiques publiques de WordPress suffit.

Selon les statistiques de WordPress.org, 38 % des installations tournent aujourd’hui sur une version de PHP qui ne reçoit plus de correctifs de sécurité. Et 25 % de plus tournent sur PHP 8.2, dont le calendrier de php.net arrête le support au 31 décembre 2026. Dès le 1er janvier, ce sera 63 %.

La version de PHP n’apparaît pas dans le tableau de bord WordPress et aucune notification ne vous le rappelle. Elle se change sur le serveur, pas avec un bouton « mettre à jour ». C’est donc un bon test : sur bon nombre de ces sites, quelqu’un clique chaque mois sur les mises à jour des extensions et facture ce travail — et personne n’a inscrit dans le contrat que l’environnement sur lequel tourne le site fait aussi partie de sa mission.

Cet article parle du contrat, pas des tâches. Chacune d’elles mérite son propre texte.

Maintenance, suivi, administration — un seul service, quatre types de travail

Maintenance de site web, suivi technique, administration, support : dans les offres, ces termes sont interchangeables et aucun n’a de sens établi. Deux prestataires qui vendent du « suivi » peuvent mettre des choses totalement différentes dans leur forfait, et deux qui vendent de la « maintenance » et de l'« administration », exactement la même chose. Comparer les offres par le nom du service n’a donc pas de sens. On les compare selon les quatre types de travail qu’elles contiennent :

• Le travail courant — ce qui se fait sans que vous le demandiez : mises à jour, sauvegardes, surveillance de la disponibilité, renouvellement du domaine et du certificat. On peut le décrire à l’avance et le facturer au forfait.
• La réaction — ce qui se passe quand quelque chose casse : le site ne répond plus, le formulaire n’envoie rien, la boutique n’encaisse plus. Impossible à prévoir ; on peut seulement convenir de la rapidité et des horaires.
• Les modifications — ce que vous demandez : une nouvelle page, une correction de mise en page, des photos à remplacer, un nouveau champ de formulaire. C’est du développement, pas de la maintenance, même quand c’est petit.
• Le conseil — la réponse à « faut-il ? » avant que quiconque n’agisse : changer d’hébergement, ajouter une extension de réservation, passer à une version plus récente du système.

La plupart des offres détaillent le premier type — c’est le plus facile à décrire — et règlent les trois autres en une phrase. C’est dans ces trois-là que naissent les litiges.

Où s’arrête le périmètre

Le litige le plus fréquent en maintenance de site ne porte pas sur une panne, mais sur la phrase « c’était compris dans le forfait ». Il commence par une formule présente dans presque toutes les offres : « petites modifications incluses ». Pour vous, une petite modification, c’est ajouter un champ « numéro IDE » à un formulaire. Pour le prestataire, cela peut vouloir dire toucher au formulaire, à la validation, au modèle du courriel de confirmation et à l’export vers votre logiciel de vente — quatre endroits, deux heures.

Il existe deux manières honnêtes de trancher cela à l’avance :

Un crédit d’heures. Le forfait comprend un nombre d’heures par mois pour les modifications, et le prestataire indique combien il en a utilisé. L’avantage : aucune discussion sur ce qui est « petit ». La condition : un relevé détaillé par tâche, pas un seul chiffre sur la facture, et une règle claire sur les heures non utilisées — reportées ou perdues ?

Une liste de tâches. Le forfait énumère ce qu’il couvre, nommément, et tout le reste fait l’objet d’un devis avant exécution. L’avantage : une facture prévisible. La condition : une liste concrète. « Support courant » n’est pas un élément de liste ; « mise à jour de contenus sur les pages existantes, jusqu’à 10 modifications par mois » en est un.

Quel que soit le modèle, le contrat doit contenir une liste d’exclusions — ce qui n’entre en aucun cas dans le forfait. Typiquement : nouvelles fonctionnalités, modifications graphiques au-delà du remplacement de contenus, intégrations avec de nouveaux systèmes, réparation des conséquences de changements faits par un tiers, déménagement du site sur un autre serveur. Les exclusions ne sont pas une mauvaise nouvelle : c’est une information que vous payez à part et que vous connaissez avant de signer, plutôt qu’à la première facture supplémentaire.

Ce que tout cela coûte, nous le détaillons dans l’article sur les coûts de maintenance ; pour votre propre site, vous pouvez l’estimer avec le calculateur du coût de maintenance. Ici, la question est de savoir ce que vous obtenez pour ce montant.

Le délai de réaction n’est pas le délai de réparation

« Nous réagissons dans l’heure » est la promesse la plus courante des offres de maintenance et la plus souvent mal comprise. Le délai de réaction mesure le moment où quelqu’un accuse réception du ticket. Le délai de réparation mesure le moment où le site fonctionne de nouveau. Un contrat peut garantir le premier et ne rien dire du second : dans l’heure, vous recevez un courriel « bien reçu, nous regardons », et le site peut rester hors ligne jusqu’au lendemain, en toute conformité au contrat.

Cela ne signifie pas que le délai de réparation puisse être garanti. Il ne le peut pas, car la cause peut se trouver hors du prestataire — chez l’hébergeur, le prestataire de paiement, un service externe. Mais trois choses peuvent être écrites et ont une vraie valeur :

• Un délai de réaction par niveau de priorité. La priorité se fixe selon l’effet sur l’entreprise, pas selon ce qui est techniquement cassé : « le site est hors ligne ou les commandes sont impossibles » n’est pas « une photo est décalée sur une page », même si les deux demandent un travail comparable.
• Les horaires couverts. « Dans l’heure » en semaine de 9 h à 17 h signifie qu’une panne signalée le vendredi à 18 h attend lundi. C’est peut-être acceptable pour un site vitrine, pas pour une boutique en ligne, mais cela doit être écrit.
• Un délai pour un contournement ou un diagnostic. À la place d’une garantie de réparation, l’engagement de fournir dans un délai donné un diagnostic et un plan, ou une solution provisoire. Cela ne se promet pas sans savoir-faire, ce qui en fait un bon test du prestataire.

Le contrat SLA : ce qu’autorisent 99,9 % et ce que vous obtenez s’ils ne sont pas tenus

Un SLA (service level agreement, accord de niveau de service) est la partie du contrat qui exprime la disponibilité du service en pourcentage. Cela ressemble à une garantie, mais il vaut la peine de traduire ce pourcentage en heures, car l’intuition dit autre chose que l’arithmétique.

Une disponibilité de 99,9 % autorise 44 minutes d’indisponibilité chaque mois — et pendant ces 44 minutes, rien ne vous est dû, puisque le contrat est respecté. À 99 %, on dépasse déjà sept heures par mois. Si une offre avance un pourcentage sans un mot sur la manière de le calculer, il lui manque trois éléments qui décident de sa valeur :

• La période de mesure. 99,9 % mesurés sur l’année autorisent près de neuf heures d’indisponibilité en une seule journée, pourvu que le reste de l’année soit irréprochable. Mesurés sur le mois, non.
• Qui mesure, et avec quoi. Une mesure faite par le prestataire depuis son propre serveur peut ne pas voir que le site ne répond pas de l’extérieur. Le plus simple : une surveillance indépendante, à laquelle vous avez accès.
• Ce qui est exclu. Les interventions planifiées et annoncées ne comptent généralement pas comme indisponibilité. C’est raisonnable — à condition que le contrat précise avec quel préavis elles doivent être annoncées et dans quelles plages horaires elles sont permises.

La seconde question compte davantage que la première : que se passe-t-il quand le SLA n’est pas respecté ? La norme du marché est un remboursement partiel des frais de service. On le voit bien dans l’un des SLA publics les plus cités, celui d’Amazon EC2. Amazon s’engage sur 99,99 % de disponibilité par région. S’il ne tient pas cet engagement, le client récupère 10 % des frais ; sous 99 %, 30 % ; sous 95 %, 100 %. Et le contrat précise qu’il s’agit de ses « sole and exclusive remedies » — son seul et unique recours.

Ce n’est pas un reproche à Amazon : c’est ainsi que fonctionne le mécanisme. Mais appliqué à un site d’entreprise, voici un calcul à faire avant de signer : une journée entière hors ligne correspond à une disponibilité mensuelle d’environ 96,7 %, soit, à cette échelle de remboursement, 30 % des frais. Avec un forfait de quelques centaines de francs par mois, toute la compensation pour une journée sans ventes représente une à deux centaines de francs. Votre chiffre d’affaires perdu n’entre pas dans le calcul. Un SLA est donc avant tout une information — un engagement mesurable qui permet de constater que le service est mauvais — et non une assurance.

Si vous avez besoin de plus qu’une information, le droit des contrats offre un outil qui fonctionne autrement : la peine conventionnelle — une somme fixe que le prestataire s’engage à payer s’il n’exécute pas ou exécute mal, inscrite comme clause distincte. Contrairement au remboursement du SLA, elle ne dépend pas du montant du forfait, mais du montant que vous fixez ensemble pour le manquement. Elle joue dans les deux sens — le prestataire l’intégrera dans son prix — et n’a donc de sens que là où une interruption coûte vraiment, pas comme argument de négociation par principe. Sa mise en œuvre dépend du droit applicable au contrat : une raison de plus de faire relire un contrat important par un juriste.

Qui détient les clés

Le problème le plus coûteux de la maintenance ne survient pas pendant la collaboration, mais à sa fin — quand il apparaît que le domaine est enregistré au nom du prestataire, que le compte d’hébergement a été ouvert par l’un de ses employés et que le mot de passe du tableau de bord n’est connu que d’une personne qui a quitté l’entreprise. Tout cela se récupère, mais chaque étape coûte du temps, et certaines, la bonne volonté de celui que vous êtes en train de quitter.

La règle est unique : tout ce qui constitue « le site » doit être enregistré au nom de votre entreprise, et le prestataire doit disposer d’un accès qui lui est accordé — pas d’un accès qui lui appartient. La différence : un accès accordé se retire en un clic.

Le nom de domaine est l’élément le plus sérieux de la liste, car c’est le seul qui peut passer à un parfait inconnu après un renouvellement oublié — ce qui se passe alors, nous le décrivons avec les coûts de maintenance. Le reste du tableau ne demande aucune connaissance technique : à la signature, posez la question pour chaque ligne — au nom de qui est-ce enregistré aujourd’hui ? — et notez la réponse.

À qui appartient ce que le prestataire réalise — et à qui appartiennent les données

La seconde moitié du même problème ne concerne pas les accès, mais les droits. Vous avez payé le site, l’intuition dit donc qu’il est à vous. C’est le contrat et le droit qui le régit qui en décident — et les règles varient d’un pays à l’autre, y compris entre la Suisse et ses voisins. Ceci n’est pas un conseil juridique ; pour un contrat important, faites-le relire par un juriste. Voici les questions à poser, valables quel que soit le droit applicable.

Le contrat cède-t-il les droits, ou les concède-t-il seulement en licence ? Payer la facture ne vous remet pas, à lui seul, les droits sur le code, les graphismes et les textes. Le contrat doit dire quelque part ce que vous obtenez : la cession des droits, ou une licence d’utilisation. Dans certains systèmes juridiques, le droit d’auteur ne peut pas être cédé du tout, seuls des droits d’utilisation peuvent être accordés — une clause « tous les droits passent au client » peut donc ne pas signifier ce qu’elle semble dire. L’essentiel est que vos droits soient assez larges pour ce dont vous aurez besoin.

Les utilisations sont-elles énumérées ? Une clause sans liste de ce que vous pouvez faire de l’œuvre — la reproduire, la publier en ligne, la modifier — peut couvrir moins qu’il n’y paraît, car une cession floue tend à être interprétée restrictivement, selon le but du contrat. Pour un site web, le droit de modifier est le plus important : sans lui, un autre prestataire ne devrait pas, formellement, toucher à ce code.

Un nouveau prestataire peut-il corriger les erreurs ? De nombreux systèmes juridiques permettent à celui qui utilise légitimement un programme d’en corriger les erreurs, sauf clause contraire. Cela protège les corrections courantes après un changement de prestataire, pas les développements — et le contrat peut l’exclure : vérifiez que le vôtre ne le fait pas.

En pratique, cela se résume à une clause à vérifier dans le contrat de réalisation : cède-t-il ou accorde-t-il les droits par écrit, avec les utilisations énumérées, droit de modification compris ? Dans un contrat de maintenance, la même chose vaut pour tout ce que le prestataire ajoute en cours de route — nouvelles pages, fonctionnalités, graphismes.

Les données font l’objet d’un accord distinct. Si le prestataire a accès à un tableau de bord contenant des demandes de contact, des comptes clients ou des commandes, il traite des données personnelles pour votre compte. Le droit suisse de la protection des données a ses propres règles sur le traitement par des tiers, et si vous servez aussi des clients dans l’Union européenne, le RGPD s’applique en plus à ce traitement. Dans tous les cas, la relation doit figurer dans un accord écrit — et pour la maintenance, son point le plus important est la sortie : en fin de mandat, le prestataire restitue ou supprime toutes les données personnelles et en efface les copies, selon votre choix. C’est une clause de sortie, écrite avant même le début de la collaboration.

Changer de prestataire de maintenance

Si les deux sections précédentes sont en ordre, changer de prestataire est une procédure, pas une crise. Cinq étapes, dans cet ordre :

1. L’inventaire. La liste du tableau ci-dessus, avec une réponse à chaque ligne : au nom de qui, qui a accès, où cela se trouve. Plus la liste des extensions, intégrations et services externes payés à part — ce sont eux qui refont le plus souvent surface après la remise, quand ils cessent de fonctionner.
2. L’export. Le code (dépôt ou copie complète des fichiers), la base de données, les fichiers envoyés par les utilisateurs, la configuration du serveur, la documentation si elle existe. Plus une cession ou concession écrite des droits, s’il n’y en avait pas.
3. Le test de restauration. Le nouveau prestataire remonte une copie du site à partir de ce qu’il a reçu. Seule une copie qui fonctionne prouve que l’export est complet ; une archive de fichiers ne prouve rien, comme nous le détaillons dans l’article sur les sauvegardes.
4. La période de recouvrement. Une ou deux semaines pendant lesquelles l’ancien prestataire répond encore aux questions. Ce qui coûte le moins dans ce travail, c’est la réponse à « pourquoi est-ce fait ainsi ? ».
5. La fermeture des accès. Changer les mots de passe de tout l’inventaire, supprimer les comptes de l’ancien prestataire, retirer ses droits dans Search Console et le gestionnaire de balises. Et une confirmation écrite de la restitution ou de la suppression des données personnelles, comme le prévoit l’accord de traitement.

Avec une maintenance bien tenue, la première étape prend une heure, parce que l’inventaire existe déjà. Avec une maintenance mal tenue, c’est elle qui dure le plus longtemps — et c’est la meilleure mesure de ce que vous avez réellement acheté pendant toutes ces années.

Maintenance WordPress — ce qui change

La maintenance WordPress, en pratique, ce sont deux choses, et aucune n’est « entretenir WordPress ».

La première, ce sont les extensions. Selon le rapport annuel de Patchstack sur la sécurité de WordPress, que nous détaillons avec les mises à jour, 91 % des vulnérabilités découvertes en 2025 dans l’écosystème WordPress concernaient des extensions, et le cœur lui-même — six seulement, toutes de faible priorité. La maintenance WordPress est donc surtout une discipline des extensions : combien il y en a, lesquelles sont encore maintenues, dans quel ordre les mettre à jour et que faire quand l’une présente une faille sans correctif. Depuis la version 5.5, WordPress sait mettre à jour les extensions automatiquement, mais l’automatisme ne remplace pas cette décision — en cas de panne, on ne sait pas quelle mise à jour l’a causée.

La seconde, c’est PHP — le graphique du début de cet article. La version de PHP est une couche que le propriétaire du site ne voit pas, et c’est elle qui décide si le serveur reçoit des correctifs de sécurité. Pour 38 % des installations, ce n’est plus le cas. Changer de version de PHP n’est pas une mise à jour mais un changement d’environnement : cela peut casser une extension ou un thème ancien, donc il faut une sauvegarde, un test et quelqu’un qui sait quoi vérifier. Et l’échéance de PHP 8.2 au 31 décembre 2026 concerne un quart des installations ; ce qu’elle implique pour tout le site, nous l’expliquons dans l’article sur le moment où un site doit être modernisé.

D’où un test simple pour toute offre de maintenance WordPress. Posez deux questions au prestataire : sur quelle version de PHP tourne votre site aujourd’hui, et jusqu’à quand est-elle supportée, et combien d’extensions sont installées et lesquelles n’ont pas été mises à jour depuis un an. Un prestataire qui s’occupe du site répondra en quelques minutes, de mémoire ou à partir d’un rapport. Un prestataire qui se contente de cliquer sur les mises à jour devra vérifier — et c’est aussi une réponse.

L’administration de WordPress concerne aussi les comptes du tableau de bord. Après quelques années, la liste des utilisateurs disposant de droits d’administrateur ne ressemble généralement plus à ce dont on se souvient. C’est une question de sécurité, mais la vérification de cette liste devrait figurer dans tout forfait de maintenance.

Un administrateur interne ou un prestataire externe

La question « engager ou externaliser » a, en maintenance de site, une particularité qui la tranche souvent plus vite que n’importe quel calcul : une seule personne ne peut pas assurer une permanence. Elle tombe malade, part en vacances, dort. Un SLA à 99,9 % — 44 minutes d’indisponibilité par mois — est irréalisable avec une seule personne, quelles que soient ses compétences : une panne qui attend une seule journée son retour de vacances dépasse plus de trente fois le quota mensuel.

Le calcul mérite d’être fait avec vos propres chiffres plutôt qu’avec des montants qui circulent : le salaire d’un administrateur web interne, plus les charges, le matériel, les licences et la formation, face au forfait mensuel d’un prestataire. Les niveaux de salaire varient trop selon les régions et les profils pour qu’un chiffre national soit utile ; nous n’en donnons donc pas.

Il en découle une limite, pas un verdict. Un poste interne a du sens quand le site fait partie du travail quotidien de l’entreprise — une boutique dont l’assortiment change chaque jour, un portail, un système dans lequel travaillent vos clients — et quand il y a assez de travail pour un poste complet, avec quelqu’un d’autre pour les incidents hors horaires. Un prestataire externe a du sens quand le travail représente quelques heures par mois, ce qui est le cas de la plupart des sites d’entreprise : vous payez alors la disponibilité d’une équipe, pas le temps d’une personne. Un modèle mixte — quelqu’un dans l’entreprise centralise les demandes et gère les contenus, le prestataire s’occupe de la technique et de la permanence — combine les avantages des deux, à condition que la répartition soit écrite.

Ce que cet article laisse volontairement de côté

• Les prix et fourchettes — les coûts de maintenance, répartis en quatre couches de la facture, et pour votre cas le calculateur du coût de maintenance.
• La façon de mettre à jour — les mises à jour du site, dans un ordre qui ne casse rien.
• Faire des sauvegardes et les vérifier — la sauvegarde du site.
• La vitesse du site — ce sont les Core Web Vitals, les métriques que Google utilise réellement.
• La mise en place de la surveillance — le monitoring du site, traité à part.
• Le déménagement du site — la migration de site.

Le résumé le plus court : avant de signer un contrat de maintenance, vérifiez non pas la liste des tâches, mais trois clauses — ce que vous obtenez quand le prestataire ne tient pas une promesse, à qui appartient ce qu’il réalise, et au nom de qui sont enregistrés le domaine, l’hébergement et les comptes. N’importe quel prestataire exécutera les tâches. Ces trois clauses distinguent un service dont quelqu’un répond d’un service que quelqu’un se contente d’exécuter.