Prestataire digital : comment structurer la maintenance de son site après la livraison (TMA, contrat et coûts réels)

La livraison n'est pas la fin du projet, c'est le début du risque

Le site est en ligne. Les équipes se félicitent, la facture finale part, tout le monde passe au dossier suivant. Sauf que ce moment précis, c'est exactement là que le risque commence.

Un site web, ce n'est pas une plaquette imprimée. C'est un logiciel connecté à internet, posé sur un empilement de dépendances qui bougent toutes seules : le noyau du CMS, les extensions, la version de PHP, les API de paiement, les navigateurs, les exigences de Google. Rien de tout cela ne vous demande votre avis avant d'évoluer.

Et pourtant, dans la majorité des projets observés, la question de la maintenance arrive après coup. Quelques semaines après la mise en ligne. Parfois quelques mois. Parfois jamais, jusqu'au jour où le site affiche une erreur 500 un vendredi à 17 h.

Ce que coûte une année sans maintenance

Prenons un cas de figure très banal. Un site vitrine WordPress livré en janvier, sans contrat de suivi. Douze mois plus tard, voici ce qu'on retrouve typiquement lors d'un audit de reprise :

entre 15 et 40 mises à jour d'extensions en retard, dont deux ou trois corrigeant des failles connues et documentées publiquement ;
une version de PHP en fin de support, donc plus aucun correctif de sécurité côté serveur ;
des sauvegardes qui existent sur le papier mais que personne n'a jamais tenté de restaurer (ce qui revient à ne pas en avoir) ;
des formulaires de contact qui n'envoient plus rien depuis un changement de configuration SMTP, découvert trois mois trop tard ;
et, à peu près une fois sur trois, une régression de référencement invisible : un fichier robots.txt modifié par une mise à jour, des balises canoniques qui pointent au mauvais endroit, un plan de site vide.

Le coût ? Il n'est jamais sur une seule ligne. C'est là tout le problème. Une compromission demande entre 1 500 et 6 000 € de nettoyage et de remise en service, hors perte d'image. Une désindexation partielle, c'est trois à six mois pour revenir au niveau antérieur, quand ça revient. Et la dette technique accumulée transforme une mise à jour de routine en chantier de plusieurs jours.

Le calcul est brutal : ce qu'on économise en refusant un forfait à 120 € par mois, on le repaye au minimum en une seule intervention d'urgence.

Ce que ce guide donne concrètement

L'objectif n'est pas de faire peur, mais d'outiller la décision. À la fin de cette lecture, vous devez pouvoir :

distinguer les quatre familles de maintenance et savoir laquelle vous concerne vraiment ;
arbitrer entre un forfait simple, une TMA et de la régie, avec des fourchettes de prix réelles du marché français ;
relire un contrat en repérant les clauses qui vous protègent et celles qui protègent seulement le prestataire ;
poser les bonnes questions en entretien, y compris les questions gênantes.

Ce guide s'adresse au dirigeant de PME qui n'a pas d'équipe web interne, au responsable marketing à qui on a confié « le site » sans lui donner de budget de fonctionnement, et au DSI qui doit encadrer un prestataire sans compétence web dans son équipe.

Ce que « maintenance de site web » recouvre réellement

Premier écueil : l'expression est un fourre-tout. Deux devis affichant tous les deux « maintenance mensuelle » peuvent couvrir des périmètres qui n'ont presque rien en commun. D'où l'intérêt de reprendre les catégories une par une.

Maintenance corrective

C'est la plus intuitive : quelque chose ne fonctionne plus comme prévu, on le répare. Un bouton qui ne réagit plus, un panier qui perd son contenu, une page produit qui renvoie une erreur, un affichage cassé sur mobile après une modification.

Point de vigilance : le correctif porte sur ce qui a été livré et recetté. Si la fonctionnalité n'a jamais fonctionné et qu'elle figurait au cahier des charges, on est dans la garantie, pas dans la maintenance. La nuance a des conséquences budgétaires directes, et beaucoup de contrats l'entretiennent volontairement dans le flou.

Maintenance préventive

Le travail invisible. Celui pour lequel un client a régulièrement l'impression de payer pour rien, jusqu'au premier incident évité.

Concrètement : application des mises à jour du CMS, des extensions et des bibliothèques, vérification que rien n'a cassé après ces mises à jour, sauvegardes régulières avec test de restauration, surveillance de la disponibilité, contrôle des certificats SSL, purge des comptes utilisateurs inactifs, revue des journaux d'erreurs.

Un rythme mensuel constitue le minimum sérieux pour un site vitrine. Sur un e-commerce, on passe à un rythme hebdomadaire, parfois plus resserré pendant les périodes commerciales sensibles.

Maintenance évolutive

Là, on ne répare plus : on ajoute. Une nouvelle page de service, un champ supplémentaire dans un formulaire, l'intégration d'un outil de prise de rendez-vous, la refonte d'un tunnel de commande.

Cette famille est presque toujours facturée à part, ou consommée sur un quota d'heures. Et c'est logique : elle n'a pas de plafond naturel. Le vrai sujet, c'est de savoir ce qui bascule d'un côté ou de l'autre de la frontière.

Maintenance adaptative

La moins comprise, et souvent la plus coûteuse quand on l'a négligée trop longtemps. Ici, le site n'a pas changé, mais son environnement, oui.

Migration vers une version supérieure de PHP. Adaptation à une nouvelle version majeure du CMS. Mise en conformité après l'évolution d'une API tierce (transporteur, paiement, CRM). Prise en compte d'une nouvelle exigence RGPD ou d'une évolution du consentement aux cookies. Compatibilité avec un comportement de navigateur qui a changé.

Ces chantiers ne se déclenchent pas à votre initiative. Ils arrivent avec une date limite fixée par un tiers, et ignorer l'échéance coûte toujours plus cher que la traiter.

La zone grise qui génère l'essentiel des litiges

« Correction de bug » ou « évolution » ? Vous rirez peut-être, mais c'est là que se joue la quasi-totalité des tensions entre client et prestataire sur un contrat de maintenance.

Exemple vécu cent fois : le client demande que le formulaire de devis envoie aussi une copie au commercial concerné. Pour lui, c'est un réglage, deux minutes. Pour le prestataire, c'est une logique de routage à développer, à tester, à documenter, donc une évolution facturable.

Qui a raison ? Les deux, en réalité. Et c'est précisément pour ça que la définition doit être écrite noir sur blanc, avant signature. La formulation qui fonctionne le mieux en pratique :

Constitue une anomalie corrective tout écart entre le comportement observé et le comportement décrit dans les livrables de recette. Toute demande portant sur un comportement non décrit dans ces livrables relève de la maintenance évolutive.

Cette phrase suppose qu'il existe des livrables de recette. S'il n'y en a pas, on part déjà avec un handicap sérieux : la référence est absente, donc tout devient négociable au coup par coup.

Tableau de correspondance

Type	Porté par	Fréquence	Mode de facturation
Corrective	Prestataire technique	À la demande, sous SLA	Inclus au forfait
Préventive	Prestataire technique	Mensuelle à hebdomadaire	Inclus au forfait
Évolutive	Prestataire ou tiers	Selon feuille de route	Quota d'heures ou devis
Adaptative	Prestataire technique	1 à 3 chantiers par an	Devis dédié le plus souvent
Surveillance SEO	Acteur distinct, idéalement	Continue + avant chaque mise en production	Prestation séparée

TMA : ce que signifie vraiment la Tierce Maintenance Applicative

Une notion importée de l'informatique de gestion

La TMA n'est pas née dans le web. Le terme vient du monde des applications d'entreprise, où l'on confie à un tiers la maintenance d'un applicatif que l'on n'a pas développé soi-même, avec des engagements de service formalisés.

Transposé au web, le mot a un peu perdu de sa rigueur. Beaucoup d'agences écrivent « TMA » sur une offre qui est en réalité un forfait de maintenance classique, parce que l'acronyme sonne mieux. Ce n'est pas malhonnête, mais ça brouille la comparaison des devis.

La vraie différence : le niveau d'engagement

Un contrat de maintenance simple engage sur des moyens : « nous appliquons les mises à jour chaque mois, nous répondons à vos demandes ». Une TMA digne du nom engage sur des résultats mesurables : un taux de disponibilité, des délais de rétablissement par niveau de criticité, un dispositif de pilotage, et des conséquences contractuelles si les engagements ne sont pas tenus.

Le test est simple. Posez la question suivante : « Que se passe-t-il, contractuellement, si le délai de rétablissement n'est pas respecté trois fois dans le trimestre ? » Si la réponse tient en « on fera au mieux », vous n'avez pas une TMA. Vous avez un abonnement.

Quand la TMA se justifie

Applicatif métier sur mesure, dont l'indisponibilité bloque une activité interne.
E-commerce avec un chiffre d'affaires quotidien significatif : chaque heure d'arrêt a un coût calculable.
Plateforme intégrée à d'autres systèmes (ERP, CRM, logistique), où une panne se propage.
Site à fort trafic pour lequel la performance est un enjeu de conversion et de référencement.
Contexte réglementé imposant traçabilité et preuve des interventions.

Quand elle est manifestement surdimensionnée

Un site vitrine de douze pages sous WordPress n'a pas besoin d'une TMA. Il a besoin de mises à jour propres, de sauvegardes testées, d'une surveillance de disponibilité et de quelqu'un qui décroche quand ça casse.

Repère utile : en dessous d'environ 5 000 € annuels de budget de maintenance, la structure de pilotage d'une TMA (comités, reporting formalisé, engagements chiffrés) consomme une part disproportionnée du budget. Autant mettre cet argent dans du temps d'intervention réel.

Interne, externalisée, mixte

Trois configurations, trois points de bascule.

La TMA interne suppose au moins deux profils techniques disponibles, sinon le départ d'une personne emporte toute la connaissance du système. C'est le scénario le plus fragile quand on ne l'assume pas complètement.

La TMA externalisée est la norme en PME et sur les sites de taille moyenne. Elle transfère la charge et l'astreinte, au prix d'une dépendance qu'il faut encadrer contractuellement.

La configuration mixte, enfin, garde en interne le pilotage et les évolutions fonctionnelles, et externalise le socle technique et l'astreinte. C'est souvent le meilleur compromis à partir d'une certaine taille, à condition que le partage des responsabilités soit écrit. Sinon, chacun attend l'autre le jour de l'incident.

Le prestataire qui a développé le site : continuité ou dépendance ?

Question inconfortable, mais elle mérite d'être posée franchement.

Rester avec l'agence qui a construit le site présente des avantages réels : elle connaît le code, les choix d'architecture, les compromis faits en cours de route. Le temps de montée en compétence est nul, ce qui n'est pas rien sur un développement spécifique.

L'inconvénient est tout aussi réel : cette même agence est juge et partie. Une anomalie née d'un choix technique discutable lui coûte de l'argent à corriger gratuitement, ou lui en rapporte si elle la classe en évolution. Ce conflit d'intérêts n'est pas théorique, il structure les discussions.

La position raisonnable consiste à accepter la continuité technique, tout en confiant à un tiers deux missions : l'audit de reprise initial, et la surveillance des régressions, notamment côté référencement. Deux regards valent mieux qu'un, surtout quand le premier a des intérêts dans le diagnostic.

Structurer le contrat : les clauses qui protègent réellement

Un contrat de maintenance tient rarement plus de dix pages. Ce qui compte n'est pas sa longueur mais la présence de quelques points précis. Passons-les en revue.

Le périmètre applicatif

À rédiger en liste, composant par composant : le CMS et sa version, les extensions couvertes (nommées), les développements spécifiques, les intégrations tierces, les domaines et sous-domaines concernés.

Et surtout, la liste des exclusions explicites. Un périmètre qui ne dit pas ce qu'il exclut n'est pas un périmètre. Les exclusions classiques : les contenus saisis par le client, les extensions installées sans validation, les modifications faites directement en production par un tiers, le matériel et le réseau du client.

Les SLA : la nuance que beaucoup exploitent

Deux délais différents, souvent confondus dans les propositions commerciales.

Le délai de prise en compte est le temps entre le signalement et l'accusé de réception avec qualification. « Nous avons vu votre ticket, c'est un P1, nous intervenons. » Facile à tenir, peu engageant.

Le délai de rétablissement est le temps entre le signalement et le retour au fonctionnement normal, éventuellement via une solution de contournement. Voilà l'engagement qui compte réellement.

Un contrat qui annonce fièrement « prise en compte en 2 h » sans dire un mot du rétablissement ne promet rien d'exploitable. On peut accuser réception en deux heures et corriger trois semaines plus tard sans manquer à sa parole.

La grille de criticité

Trois niveaux suffisent dans la plupart des cas, à condition que chacun soit illustré par des exemples issus de votre activité réelle.

Niveau	Définition	Exemples concrets	Rétablissement visé
P1 bloquant	Site inaccessible ou fonction vitale hors service	Erreur 500 généralisée, tunnel de commande cassé, formulaire de devis muet, site marqué comme dangereux par Google	4 h ouvrées
P2 majeur	Dégradation forte, contournement possible	Recherche interne inopérante, images produits non affichées, lenteur extrême sur mobile	1 à 2 jours ouvrés
P3 mineur	Gêne visuelle ou fonctionnelle limitée	Défaut d'alignement, faute dans un libellé, icône manquante	Prochain cycle mensuel

Un conseil, et il vaut de l'argent : faites figurer vos propres exemples dans le contrat, pas ceux du modèle générique du prestataire. Un formulaire de devis en panne est un P1 pour une entreprise de services, un P3 pour un site institutionnel qui reçoit trois messages par mois. Personne ne peut trancher cela à votre place.

Horaires de couverture et astreinte

Trois régimes, trois budgets.

Les heures ouvrées (9 h-18 h, du lundi au vendredi) conviennent à l'immense majorité des sites B2B. C'est le régime standard, sans surcoût particulier.

Le 5j/7 étendu ou 6j/7 s'impose sur les sites dont le trafic culmine le soir et le week-end : e-commerce grand public, loisirs, restauration. Comptez 30 à 60 % de plus.

Le 24/7 avec astreinte suppose une organisation de garde, donc une équipe suffisante. Le surcoût va du doublement au triplement du forfait. Il ne se justifie que si une heure d'indisponibilité nocturne a un coût réel et chiffrable.

Le quota d'heures : trois pratiques du marché

La question tient en une ligne : que devient une heure non consommée en fin de mois ?

Perte sèche. Le plus fréquent, et le plus favorable au prestataire. Acceptable si le forfait est calibré au plus juste, pénalisant s'il est surdimensionné.
Report plafonné. Les heures non utilisées basculent sur le mois suivant, avec un plafond (souvent deux à trois mois de quota). C'est l'équilibre le plus sain, parce qu'il permet de constituer une réserve pour un chantier plus lourd.
Report illimité. Rare, et pas forcément souhaitable : le prestataire finit avec une dette d'heures ingérable, ce qui dégrade sa réactivité pour tout le monde.

Autre point à ne pas oublier : l'unité de décompte. Un ticket de dix minutes facturé une heure pleine change complètement l'économie du contrat. Demandez la granularité, elle est rarement écrite spontanément.

Pénalités et crédits de service

Un SLA sans conséquence en cas de manquement est une intention, pas un engagement. Le mécanisme habituel prend la forme d'un crédit de service : un pourcentage du forfait mensuel remboursé ou déduit lorsque les délais ne sont pas tenus.

Les ordres de grandeur usuels vont de 5 à 20 % du forfait mensuel par manquement constaté, avec un plafond global. L'objectif n'est pas de gagner de l'argent sur les pénalités, il est d'aligner les intérêts. Un prestataire qui refuse tout mécanisme de ce type vous dit quelque chose sur la confiance qu'il accorde à ses propres engagements.

Réversibilité et clause de sortie

La clause qu'on ne lit jamais à la signature et qu'on relit fébrilement le jour où l'on veut partir. Elle doit préciser :

la liste des livrables de sortie : code source complet, base de données, documentation technique, procédures de déploiement ;
l'inventaire des accès à restituer : hébergement, registrar, DNS, CMS, dépôt de code, outils de suivi ;
le délai de transfert, avec une période d'accompagnement du prestataire entrant (deux semaines à un mois selon la complexité) ;
si cet accompagnement est inclus ou facturé, et à quel tarif.

Sans cette clause, le départ se négocie en position de faiblesse. Ce n'est jamais confortable.

Propriété intellectuelle

Le code du CMS et des extensions libres reste sous leur licence d'origine, ce point ne se négocie pas. En revanche, les développements spécifiques réalisés et facturés doivent vous être cédés, ou au minimum concédés en licence perpétuelle, transférable et irrévocable.

Attention aux formulations du type « le prestataire concède un droit d'usage pendant la durée du contrat ». Traduction : si vous partez, vous perdez le droit d'utiliser ce que vous avez payé. Cette clause existe, et plus souvent qu'on ne le croit.

Hébergement inclus ou séparé ?

Le pack tout-en-un séduit par sa simplicité. Une seule facture, un seul interlocuteur, et l'assurance qu'on ne se renvoie pas la balle entre l'hébergeur et le développeur.

Mais il concentre le risque. Si la relation se dégrade, votre site, vos sauvegardes et parfois votre nom de domaine sont chez la personne avec qui vous êtes en désaccord. La dissociation, elle, coûte un peu plus cher et demande un minimum de coordination, en échange de quoi vous restez maître de vos actifs.

Position minimale, quelle que soit l'option retenue : le nom de domaine est enregistré au nom de votre société, et vous détenez les accès du registrar. Sur ce point, il n'y a aucune place pour la souplesse.

Sous-traitance et RGPD

L'oubli le plus répandu. Dès lors que le prestataire accède à des données personnelles hébergées sur le site (clients, prospects, formulaires, comptes utilisateurs), il agit comme sous-traitant au sens du RGPD. Un contrat de sous-traitance conforme à l'article 28 est alors obligatoire.

Il doit couvrir la nature des traitements, les catégories de données concernées, les mesures de sécurité, la localisation de l'hébergement, la liste des sous-traitants ultérieurs, la procédure de notification en cas de violation de données, et le sort des données en fin de contrat.

En cas de contrôle, l'absence de ce document est un manquement du responsable de traitement, donc le vôtre. Pas celui du prestataire.

Durée, reconduction, révision tarifaire

Un engagement de douze mois est standard et légitime : la mise en place d'une maintenance représente un investissement initial pour le prestataire. Au-delà de vingt-quatre mois sans clause de sortie intermédiaire, la question mérite d'être discutée.

Sur la révision des tarifs, exigez une formule d'indexation explicite plutôt qu'un « révisable annuellement » laissé à l'appréciation du prestataire. Une indexation sur un indice public, plafonnée, avec un préavis de trois mois, protège les deux parties.

Les 12 points à vérifier avant signature

Le périmètre liste les composants couverts et les exclusions.
La définition « anomalie / évolution » est écrite, avec un critère objectif.
Le délai de rétablissement est chiffré, pas seulement la prise en compte.
La grille de criticité contient vos exemples métier.
Les horaires de couverture sont explicites, jours fériés compris.
Le sort des heures non consommées est précisé, ainsi que l'unité de décompte.
Un mécanisme de crédit de service existe.
La clause de réversibilité liste les livrables et le délai de transfert.
La propriété des développements spécifiques vous est acquise.
Le nom de domaine est à votre nom, accès registrar inclus.
Un contrat de sous-traitance RGPD article 28 est annexé.
La révision tarifaire suit une formule indexée et plafonnée.

Douze points, une heure de relecture. Le meilleur rapport temps/protection de tout le projet.

La gouvernance opérationnelle : comment ça se passe au quotidien

Un canal unique, et un seul

Portail de tickets, outil de suivi partagé ou adresse e-mail dédiée : peu importe le support, ce qui compte est l'unicité. Toute demande passe par là, sans exception.

Pourquoi bannir le téléphone et les messages directs ? Parce qu'une demande orale ne laisse aucune trace. Six semaines plus tard, personne ne se souvient de ce qui a été dit, ni du temps consommé, ni de l'arbitrage rendu. Et le jour où l'on veut comprendre pourquoi le quota est épuisé, il n'y a rien à examiner.

Le téléphone reste utile, évidemment, pour un P1 en cours de nuit. Mais l'appel s'accompagne d'un ticket, avant ou juste après. Pas à la place.

Le comité de pilotage

Mensuel sur un contrat de taille moyenne, trimestriel sur un forfait léger. Quarante-cinq minutes suffisent si l'ordre du jour est stable :

revue des tickets du mois : volume, répartition par criticité, respect des SLA ;
consommation du quota et projection sur le trimestre ;
incidents notables et actions correctives engagées ;
état de la dette technique et arbitrages à rendre ;
feuille de route des évolutions pour les deux mois suivants.

Un comité qui se transforme en tour de table sans décision est un comité inutile. Chaque point ouvert doit ressortir avec un responsable et une date.

Les environnements : le minimum non négociable

Une production. Une préproduction identique à la production. Et un environnement de recette où le client valide avant déploiement.

Trois environnements, c'est la norme. Deux, à la rigueur, sur un petit site vitrine. Un seul, c'est-à-dire modifier directement en production, ne devrait plus exister en 2026 et pourtant se rencontre encore régulièrement lors des audits de reprise. Chaque intervention devient alors un pari.

Le processus de mise en production

Quatre éléments à formaliser une fois pour toutes.

La fenêtre de déploiement : jamais un vendredi après-midi, jamais la veille d'une opération commerciale. Cela paraît évident, et c'est pourtant l'une des causes les plus fréquentes de week-end gâché.

Le plan de retour arrière : sauvegarde complète avant intervention, procédure de restauration testée, durée estimée du retour arrière. Si personne ne sait combien de temps prend un rollback, c'est qu'il n'a jamais été testé.

La validation client sur l'environnement de recette, avec un périmètre de test défini à l'avance. « Vous validez ? » sans liste de contrôle ne vaut rien.

Le contrôle post-déploiement : vérification fonctionnelle immédiate, et vérification technique dans les vingt-quatre heures. Nous reviendrons sur ce point dans la partie référencement, parce qu'il y a beaucoup à dire.

Le reporting mensuel utile

Un bon rapport de maintenance tient sur une page et répond à cinq questions : combien de tickets, pour quel temps consommé, avec quel taux de respect des SLA, quel taux de disponibilité mesuré, et où en est la dette technique.

Ce dernier point est celui qui distingue un prestataire sérieux. Un rapport qui ne mentionne jamais de dette technique décrit soit un site parfait, soit un prestataire qui préfère ne pas en parler. La première hypothèse n'existe pas.

Le registre des accès

Document ennuyeux, valeur inestimable. Un tableau listant, pour chaque brique, le détenteur du compte, le titulaire réel et la procédure de récupération : registrar, DNS, hébergement, base de données, administration du CMS, dépôt de code, outils de mesure d'audience, Search Console, comptes de messagerie transactionnelle, services tiers payants.

À tenir à jour et à conserver de votre côté, pas seulement chez le prestataire. C'est ce document qui fait la différence entre un changement de prestataire en trois semaines et une reprise laborieuse sur plusieurs mois.

Les coûts réels : fourchettes et angles morts

Entrons dans le vif du sujet. Les montants qui suivent correspondent au marché français, hors grands comptes, et s'entendent hors taxes.

Modèle 1 : forfait mensuel simple, 50 à 150 € par mois

Ce que couvre réellement cette tranche : mises à jour du CMS et des extensions, sauvegardes automatisées, surveillance de disponibilité, certificat SSL, et une petite réserve d'intervention (souvent trente minutes à une heure par mois).

Ce qu'elle ne couvre pas : les évolutions, les incidents complexes, les migrations techniques majeures, et généralement l'astreinte. C'est un socle d'hygiène, pas un filet de sécurité complet.

Pour un site vitrine de moins de vingt pages, sans fonctionnalité spécifique, ce niveau est cohérent. Au-delà, il devient trompeur : le forfait rassure sans protéger.

Modèle 2 : forfait avec quota d'heures, 300 à 1 500 € par mois

La formule dominante en PME, et souvent la plus rationnelle. Le socle préventif est inclus, plus un volume d'heures mensuel utilisable en correctif ou en évolutif : typiquement de deux à dix heures selon le montant.

À ce niveau, on attend un interlocuteur identifié, un canal de tickets, des SLA écrits et un rapport mensuel. Si l'un de ces éléments manque à 800 € par mois, la question mérite d'être posée.

Modèle 3 : TMA au forfait avec engagement, à partir de 1 500 à 5 000 € par mois

On change de nature. Ici, le prestataire s'engage sur une disponibilité mesurée, des délais de rétablissement par criticité, et accepte des crédits de service. Cela implique une équipe suffisamment dimensionnée pour absorber les absences, une supervision automatisée, et parfois une astreinte.

Ce niveau se justifie sur un e-commerce à volume, un applicatif métier ou une plateforme intégrée. Sur un site de contenu classique, c'est de la sur-assurance.

Modèle 4 : régie et tickets d'heures, TJM 400 à 800 €

Pas de forfait, on achète du temps. Soit à la journée, soit par lots d'heures prépayés (dix, vingt, cinquante heures) consommables sur douze à vingt-quatre mois.

C'est le modèle le plus rationnel dans deux cas de figure. Premier cas : votre besoin est irrégulier, deux mois calmes puis un chantier de trois jours. Second cas : vous disposez d'une compétence technique interne capable de piloter, et vous n'achetez que de la capacité d'exécution.

Son point faible : sans forfait préventif à côté, personne ne surveille. Les mises à jour attendent qu'on y pense, et on y pense rarement à temps. La combinaison qui fonctionne le mieux associe un petit forfait préventif et un lot d'heures pour le reste.

Le repère du marché : 15 à 20 % par an du coût de développement

Règle empirique largement partagée dans la profession, et remarquablement robuste dans les faits. Un site développé pour 20 000 € nécessite un budget annuel de maintenance de 3 000 à 4 000 €, soit 250 à 330 € par mois.

Deux ajustements à connaître. Un e-commerce ou une application métier se situe plutôt dans le haut de la fourchette, parfois jusqu'à 25 %, parce que la surface fonctionnelle exposée est plus grande. À l'inverse, un site statique très simple peut descendre en dessous, à condition d'assumer que le périmètre restera minimal.

L'intérêt de cette règle est surtout de servir d'alerte à l'achat. Si un prestataire propose un développement à 40 000 € et une maintenance à 80 € par mois, l'un des deux chiffres est faux. Le plus souvent le second, et vous le découvrirez à l'usage.

Les coûts oubliés dans les devis

Le forfait de maintenance n'est presque jamais la dépense totale. À ajouter systématiquement :

licences premium des extensions et thèmes, renouvelables chaque année (de 200 à 1 500 € selon la pile technique) ;
hébergement, souvent hors forfait quand la maintenance est dissociée ;
CDN et protection anti-attaques sur les sites exposés ;
outils de supervision et de suivi des erreurs ;
sauvegardes externalisées, distinctes de celles de l'hébergeur, parce qu'une sauvegarde stockée chez l'hébergeur ne protège pas d'un problème chez l'hébergeur ;
et le poste le plus systématiquement ignoré : le temps interne côté client. Rédiger un ticket correct, valider une recette, participer au comité, arbitrer une priorité. Comptez deux à cinq heures par mois pour un contrat de taille moyenne. Ce temps existe, il est simplement invisible parce qu'il n'apparaît sur aucune facture.

Le coût de l'inaction, chiffré

Trois scénarios, avec des ordres de grandeur constatés.

Indisponibilité. Le calcul est direct : chiffre d'affaires en ligne annuel divisé par le nombre d'heures d'ouverture, multiplié par la durée de la panne, plus le manque à gagner sur les commandes non reprises. Sur un e-commerce à 500 000 € annuels, une journée d'arrêt représente environ 1 400 € de ventes directes, sans compter les paniers abandonnés qui ne revenaient jamais.

Désindexation ou régression de référencement. Plus insidieux, parce que la perte s'installe sans bruit. Un fichier robots.txt bloquant laissé en place quinze jours, et la remontée demande deux à quatre mois. Sur un site dont le référencement naturel génère cinquante contacts qualifiés par mois, deux mois de dégradation à 40 % coûtent quarante contacts perdus. Le chiffre parle de lui-même dès qu'on connaît sa valeur de contact.

Compromission. Entre 1 500 et 6 000 € de nettoyage, restauration et sécurisation. Auxquels s'ajoutent la levée éventuelle d'un signalement Google, la notification à la CNIL et aux personnes concernées si des données personnelles sont touchées, et un délai de rétablissement de la confiance qui ne se chiffre pas.

Comparatif sur trois ans

Type de site	Développement initial	Maintenance annuelle	Coût total 3 ans
Vitrine 15 pages	6 000 à 12 000 €	1 000 à 1 800 €	9 000 à 17 400 €
Site de contenu, blog actif	15 000 à 25 000 €	2 500 à 5 000 €	22 500 à 40 000 €
E-commerce catalogue moyen	25 000 à 60 000 €	6 000 à 15 000 €	43 000 à 105 000 €
Plateforme métier sur mesure	60 000 à 200 000 €+	12 000 à 40 000 €	96 000 à 320 000 €+

Ce que ce tableau montre le mieux : sur trois ans, la maintenance pèse entre un quart et un tiers du coût total de possession. La traiter comme une variable d'ajustement en fin de négociation revient à sous-budgéter un tiers du projet.

Le volet SEO de la maintenance : la partie que presque tous les contrats ignorent

Un sujet de référencement, pas seulement d'informatique

Voilà le point aveugle du marché. Les contrats de maintenance sont rédigés par des techniciens, pour des techniciens, avec des critères techniques : le site répond-il, les mises à jour sont-elles appliquées, les sauvegardes tournent-elles ?

Toutes ces questions sont légitimes. Aucune ne détecte qu'une mise à jour vient de faire disparaître les balises de titre de trois cents pages.

Le site fonctionne. Il s'affiche parfaitement. Les tests de disponibilité sont au vert. Et le trafic organique commence une descente que personne ne relie à l'intervention de la semaine précédente, parce que la corrélation se fait avec deux à six semaines de décalage. C'est exactement ce qui rend ces régressions si coûteuses : le temps de les identifier, le mal est fait.

Les régressions silencieuses les plus fréquentes

Liste tirée d'audits de reprise, par ordre de fréquence décroissante :

Balises de titre et méta-descriptions perdues après la mise à jour d'une extension SEO ou un changement de thème. Les données existent souvent encore en base, mais ne sont plus affichées.
Redirections cassées. Une table de redirections stockée dans une extension, et une mise à jour qui réinitialise la configuration. Toutes les anciennes URL renvoient soudain une erreur 404.
Balises canoniques erronées pointant vers la page d'accueil, ou vers l'environnement de préproduction. Ce dernier cas est un classique du déploiement mal fini.
Robots.txt de préproduction déployé en production. La régression la plus violente et la plus banale : quelques lignes qui bloquent l'exploration du site entier.
Balise noindex oubliée sur un gabarit de page après un test.
Données structurées invalidées par un changement de balisage, avec disparition des résultats enrichis.
Plan de site XML vide ou figé, ne référençant plus les nouvelles pages.
Dégradation des Core Web Vitals après l'ajout d'un script tiers ou d'une extension mal optimisée.
Images perdant leurs attributs alt lors d'une migration de médiathèque.

Aucun de ces problèmes ne déclenche d'alerte technique. Tous sont détectables en quinze minutes par quelqu'un qui sait où regarder.

Ce qui doit figurer au contrat

Une section dédiée, courte mais explicite, engageant le prestataire à contrôler après chaque mise en production :

l'intégrité du fichier robots.txt et l'absence de directive bloquante ;
la présence et la validité des balises canoniques sur chaque type de gabarit ;
l'absence de balise noindex non intentionnelle ;
le bon fonctionnement des redirections, sur un échantillon représentatif ;
la génération et l'exhaustivité du plan de site XML ;
la conservation des balises de titre et méta-descriptions ;
la validité des données structurées ;
les indicateurs Core Web Vitals sur les gabarits principaux.

Huit points. Vingt minutes de vérification pour quelqu'un d'outillé. Et pourtant, cette section est absente de la grande majorité des contrats en circulation.

Surveillance de l'indexation

Au-delà du contrôle ponctuel, il faut une surveillance continue : évolution du nombre de pages indexées, apparition d'erreurs d'exploration, alertes de sécurité, chutes de position sur les requêtes stratégiques.

Rythme réaliste : un contrôle hebdomadaire des indicateurs d'alerte, une revue mensuelle approfondie, et un contrôle systématique après chaque mise en production, quelle que soit son ampleur. Y compris pour une intervention « sans risque », formule qui précède souvent les mauvaises surprises.

Le protocole de non-régression avant mise en production

Simple, reproductible, à intégrer au processus de déploiement.

Relevé de référence avant intervention : exploration complète du site, sauvegarde des balises, liste des URL indexées, mesure de performance sur cinq gabarits types.
Contrôle sur l'environnement de recette : les huit points ci-dessus, avant tout déploiement.
Déploiement, puis contrôle immédiat des mêmes points en production.
Comparaison différentielle à vingt-quatre heures : nouvelle exploration, écart avec le relevé de référence.
Surveillance renforcée pendant sept jours sur l'indexation et les positions.

Le point 4 est celui qui attrape le plus de régressions. Une comparaison automatisée avant/après ne coûte presque rien et remonte immédiatement toute balise disparue.

Le cas des refontes partielles

Refondre une section, migrer le blog, réorganiser un catalogue : ces chantiers de taille moyenne échappent souvent aux procédures. Ils ne sont pas assez gros pour mobiliser une checklist de migration complète, et pas assez petits pour être sans conséquence.

Résultat, ce sont eux qui produisent les pertes les plus nettes. Le plan de redirections doit être établi avant le développement, à partir d'une exploration exhaustive des URL existantes, avec correspondance page par page. Pas de redirection en masse vers la page d'accueil : c'est du gaspillage pur.

Pourquoi séparer la surveillance SEO du prestataire technique

Le raisonnement est le même que pour l'audit de reprise, et il n'a rien de personnel.

Demander à un prestataire de détecter et documenter ses propres régressions le place dans une situation intenable. Non pas qu'il soit malhonnête, mais parce qu'il regarde son travail avec les yeux de celui qui l'a fait. On ne voit pas les erreurs qu'on ne s'attend pas à avoir commises. C'est humain, et cela vaut pour tout le monde.

Un acteur tiers apporte trois choses : un regard neutre, des outils différents, et une compétence spécifiquement orientée sur le référencement plutôt que sur le fonctionnement. La combinaison qui donne les meilleurs résultats reste celle-ci : l'agence de développement maintient, un spécialiste SEO surveille et alerte.

Choisir son prestataire : la méthode d'évaluation

Rester ou changer : matrice de décision

Situation	Rester avec le développeur	Changer de prestataire
Développement spécifique complexe, code peu documenté	Recommandé	Risqué et coûteux
CMS standard, peu de spécifique	Possible	Sans difficulté
Relation dégradée, délais non tenus	Déconseillé	Recommandé
Prestataire seul, sans continuité	Risque de dépendance	À privilégier
Besoin d'astreinte ou de SLA fermes	Selon capacité réelle	Souvent nécessaire

Les dix questions à poser, et les réponses qui doivent alerter

Combien de personnes peuvent intervenir sur mon site ? Une seule, et vous avez un risque de continuité.
Que se passe-t-il si cette personne est en congé pendant un incident P1 ? Un silence gêné en dit long.
Comment définissez-vous la frontière entre correction et évolution ? S'il n'y a pas de critère écrit, il n'y a pas de frontière.
Quel est votre délai de rétablissement, pas de prise en compte, sur un site inaccessible ?
Utilisez-vous un système de versionnage ? Un « non » disqualifie, sans discussion.
Testez-vous vos restaurations de sauvegarde, et à quelle fréquence ? « Les sauvegardes tournent » n'est pas une réponse.
Que contrôlez-vous côté référencement après une mise en production ? Attendez-vous à un blanc chez la majorité des candidats.
Puis-je voir un exemple de rapport mensuel anonymisé ? Un refus est un signal.
Quelle est l'ancienneté moyenne de vos clients en maintenance ? En dessous de dix-huit mois, cherchez pourquoi.
Que me restituez-vous si je décide de partir, et sous quel délai ? La réponse doit être immédiate et précise.

Vérifier la capacité réelle

Un discours commercial se prépare, une capacité opérationnelle se vérifie. Demandez le nombre de sites actuellement sous contrat rapporté à la taille de l'équipe technique. Au-delà de trente à quarante sites par technicien, la maintenance devient nécessairement superficielle.

Demandez aussi deux ou trois références joignables, en maintenance depuis plus de deux ans. Un appel de dix minutes à un client existant apporte plus d'information qu'une plaquette de trente pages.

L'audit de reprise

Indispensable avant tout engagement sur un site existant, dans les deux sens.

Pour vous, il révèle l'état réel : dette technique, failles ouvertes, qualité du code, absence de sauvegardes, régressions SEO déjà installées. Vous savez ce que vous confiez.

Pour le prestataire, il permet de calibrer honnêtement son forfait. Un prestataire qui accepte de reprendre un site sans l'auditer prend un risque, et ce risque finira par se traduire soit en refus d'intervention, soit en avenant.

Comptez entre 800 et 3 000 € selon la complexité, souvent déductibles des premiers mois de contrat. C'est l'un des investissements les plus rentables du cycle de vie d'un site.

Freelance, agence, ESN, plateforme

Le freelance offre réactivité, coût maîtrisé et relation directe. Sa limite est structurelle : pas de continuité en cas d'absence, spectre de compétences forcément borné. Convient très bien jusqu'à un site de contenu de taille moyenne, à condition d'avoir prévu un plan B écrit.

L'agence apporte la pluridisciplinarité et la continuité. Elle coûte plus cher, et la qualité dépend beaucoup de l'organisation interne. À partir d'un e-commerce ou d'un site à enjeu commercial fort, c'est le choix par défaut.

L'ESN se justifie sur les applicatifs métier, avec des processus formalisés et une capacité à absorber de gros volumes. Elle est souvent surdimensionnée et coûteuse pour un site web classique.

Les plateformes et offres packagées séduisent par leur prix. Elles fonctionnent pour du préventif standardisé sur un site simple. Dès que le site sort du cadre, l'absence d'interlocuteur qui connaît votre contexte devient handicapante.

Les signaux d'alerte

Certains éléments doivent mettre fin à la discussion, sans négociation possible :

refus de céder les accès administrateur ou registrar ;
nom de domaine enregistré au nom de l'agence ;
absence de système de versionnage du code ;
aucun environnement de test, modifications faites en production ;
forfait « tout illimité » à prix plancher, qui ne peut fonctionner qu'en ne faisant presque rien ;
refus de fournir un contrat écrit, ou contrat de moins de deux pages ;
absence de contrat de sous-traitance RGPD, présenté comme non applicable.

Mettre en place la maintenance : plan de démarrage en 90 jours

Jours 1 à 15 : état des lieux

Audit technique complet : versions, dette, failles connues, qualité du code spécifique, performance. En parallèle, inventaire exhaustif des accès, avec identification du titulaire réel de chaque compte, ce qui produit toujours au moins une surprise.

À cela s'ajoute la cartographie des dépendances : extensions critiques, API tierces, services externes, tâches planifiées. Quelle brique casse quoi si elle tombe ? Une page suffit.

Enfin, relevé de référence SEO : exploration complète, positions actuelles, état de l'indexation. Ce relevé servira de point de comparaison pour toute la suite.

Jours 16 à 45 : remise à niveau

On traite la dette critique avant de contractualiser un régime de croisière, sinon le forfait mensuel est immédiatement absorbé par le rattrapage.

Priorités, dans cet ordre : failles de sécurité connues, version de PHP hors support, sauvegardes automatisées avec test de restauration effectif, supervision de disponibilité et d'erreurs, création de l'environnement de recette.

Cette phase se facture souvent à part, en régie. C'est normal et sain : la remise à niveau n'est pas de la maintenance, c'est un chantier.

Jours 46 à 75 : formalisation

Le contrat s'écrit maintenant, une fois l'état réel connu. C'est le bon ordre, et pourtant l'inverse est la pratique courante.

Au programme : rédaction du périmètre à partir de la cartographie, grille de criticité alimentée par vos exemples métier, SLA calibrés sur les enjeux réels, mise en place du canal de tickets, formalisation du plan de sauvegarde et de reprise, annexe RGPD, et la fameuse section de non-régression SEO.

Jours 76 à 90 : premier cycle

Un test d'incident simulé, d'abord. Déclarez un faux P1 et mesurez le temps réel de prise en compte et de qualification. L'écart avec le discours commercial est parfois instructif.

Puis un test de restauration sur l'environnement de recette : combien de temps pour remettre le site debout à partir de la dernière sauvegarde ? Si personne ne connaît le chiffre, la sauvegarde n'est pas une protection, c'est une croyance.

Premier comité de pilotage ensuite, avec revue du quota consommé, et ajustement si nécessaire. Un quota mal calibré au départ est la règle plutôt que l'exception, et il vaut mieux le corriger au troisième mois qu'au douzième.

Le tableau de bord à mettre en place dès le premier mois

Indicateur	Source	Fréquence	Seuil d'alerte
Disponibilité	Outil de supervision	Continue	Moins de 99,5 % sur le mois
Tickets ouverts / résolus	Outil de tickets	Mensuelle	Encours croissant sur 2 mois
Respect des SLA	Outil de tickets	Mensuelle	Moins de 90 %
Quota consommé	Rapport prestataire	Mensuelle	Plus de 100 % deux mois de suite
Mises à jour en retard	Administration CMS	Mensuelle	Toute faille de sécurité connue
Dernière restauration testée	Registre d'exploitation	Trimestrielle	Plus de 6 mois
Pages indexées	Search Console	Hebdomadaire	Variation de plus de 10 %
Core Web Vitals	Données terrain	Mensuelle	Sortie de la zone verte

Cas concrets et arbitrages types

Site vitrine WordPress, PME régionale

Vingt pages, un formulaire de contact, pas de boutique. Le référencement local génère l'essentiel des demandes entrantes.

Le bon dosage : forfait préventif de 80 à 150 € par mois (mises à jour, sauvegardes testées, supervision, une heure d'intervention incluse), complété par un lot de dix heures annuelles pour les évolutions. Budget total 1 500 à 2 500 € par an.

Le point à ne pas rater ici : le formulaire de contact. C'est le seul point de conversion du site, et sa panne est silencieuse. Un test automatisé d'envoi, une fois par semaine, résout le problème pour un coût dérisoire. Combien d'entreprises ont perdu des mois de demandes sans le savoir ? Beaucoup plus qu'on ne l'imagine.

E-commerce PrestaShop ou Shopify

Le budget ne va pas là où on l'attend. La part préventive reste modeste, l'essentiel est absorbé par les intégrations tierces : transporteurs, paiement, gestion de stock, marketplaces. Chaque API évolue à son rythme, sans coordination.

Sur PrestaShop, ajoutez la question des modules payants : licences annuelles, compatibilité entre versions, modules abandonnés par leur éditeur. Un module non maintenu peut bloquer une montée de version majeure pendant des mois.

Ordre de grandeur : 500 à 1 500 € par mois selon le catalogue et le nombre d'intégrations, avec une couverture élargie au samedi si le trafic le justifie. Et un gel des déploiements sur les périodes commerciales fortes, écrit au contrat.

Application métier sur mesure

Ici, la TMA n'est plus un luxe. Pas de communauté, pas de mises à jour éditeur, pas de documentation publique : toute la connaissance est dans le code et dans la tête de ceux qui l'ont écrit.

Trois exigences non négociables : documentation technique maintenue à jour et livrable, au moins deux personnes capables d'intervenir, et jeu de tests automatisés sur les parcours critiques. Sans cela, chaque intervention est un pari, et le départ d'un développeur devient un événement d'entreprise.

Site multilingue et multi-domaines

La complexité cachée du périmètre. Combien de domaines exactement ? Combien de versions linguistiques ? Les annotations hreflang sont-elles couvertes, et par qui ?

Piège classique constaté à répétition : une extension multilingue mise à jour, et les annotations de langue disparaissent. Google se met alors à mélanger les versions, à servir l'anglais aux visiteurs français, et le trafic se dégrade sans qu'aucune alerte technique ne se déclenche. Le site fonctionne parfaitement, il est simplement mal compris.

À faire figurer explicitement au périmètre : contrôle des annotations hreflang après chaque mise en production, sur chaque paire de langues.

Reprise d'un site abandonné depuis deux ans

Séquence à respecter, et l'ordre compte plus qu'on ne le croit.

D'abord une sauvegarde complète de l'existant, avant toute intervention, y compris si le site est déjà compromis. On ne touche à rien sans filet.

Ensuite un contrôle de compromission : le site a-t-il déjà été piraté ? Une mise à jour appliquée sur une installation infectée ne fait que consolider la porte dérobée.

Puis la reconstitution d'un environnement de test à l'identique, où l'on applique les mises à jour de façon incrémentale, jamais en une seule passe. Une extension à la fois, avec vérification entre chaque étape. C'est long, c'est fastidieux, et c'est le seul moyen d'identifier ce qui casse quoi.

Enfin, contrôle SEO complet avant remise en production, puis surveillance renforcée pendant un mois.

Budget réaliste : entre 2 000 et 8 000 € pour la remise en service, avant même le premier mois de maintenance. C'est le prix de deux ans d'économies apparentes.

Questions fréquentes

Quelle différence entre maintenance et TMA ?

La maintenance classique engage sur des moyens : appliquer les mises à jour, répondre aux demandes, sauvegarder. La TMA engage sur des résultats mesurables : taux de disponibilité, délais de rétablissement par niveau de criticité, avec des crédits de service en cas de manquement. Elle suppose aussi un dispositif de pilotage formalisé. En pratique, beaucoup d'offres commerciales portent le nom de TMA sans en avoir les engagements : vérifiez si les délais sont chiffrés et si un mécanisme de pénalité existe.

Combien coûte la maintenance d'un site vitrine par an ?

Pour un site vitrine standard de quinze à vingt-cinq pages sous CMS, comptez entre 1 000 et 2 500 € par an, soit 80 à 200 € par mois. Ce budget couvre les mises à jour, les sauvegardes testées, la supervision et un volume limité d'intervention. Les licences d'extensions premium et l'hébergement s'ajoutent généralement. Le repère du marché reste 15 à 20 % du coût de développement initial par an.

La maintenance est-elle obligatoire ?

Aucune obligation légale d'avoir un contrat. En revanche, deux obligations de résultat s'appliquent : la sécurité des données personnelles au titre du RGPD, et l'accessibilité pour certaines organisations. Un site non maintenu qui subit une fuite de données expose son responsable de traitement, indépendamment de l'existence d'un contrat. Autrement dit : le contrat est facultatif, la responsabilité ne l'est pas.

Peut-on changer de prestataire sans refaire le site ?

Oui, dans la très grande majorité des cas, à condition de détenir les accès et le code source. La séquence habituelle : audit de reprise par le nouveau prestataire, transfert des accès, période de recouvrement de deux à quatre semaines, puis reprise complète. Les vraies difficultés viennent de l'absence de documentation, d'un code très spécifique, ou d'un ancien prestataire qui traîne pour restituer les accès. D'où l'importance de la clause de réversibilité, signée avant d'en avoir besoin.

Qui est responsable en cas de piratage ?

Cela dépend entièrement de ce que dit le contrat. Si le prestataire s'était engagé à appliquer les mises à jour et que la compromission exploite une faille connue non corrigée, sa responsabilité contractuelle peut être engagée. S'il s'agit d'une faille inconnue au moment de l'attaque, ou d'un mot de passe faible côté client, la responsabilité se déplace. Vis-à-vis des personnes dont les données ont fuité, en revanche, c'est vous qui répondez en tant que responsable de traitement, avec un recours possible contre le sous-traitant.

Faut-il inclure le SEO dans le contrat de maintenance ?

Le contrôle de non-régression SEO, oui, absolument : robots.txt, balises canoniques, redirections, plan de site, balises de titre, données structurées. C'est de la maintenance technique, cela relève du prestataire. La stratégie de référencement, en revanche, est un autre métier et un autre budget. Et la surveillance des régressions gagne à être confiée à un tiers, pour la même raison qu'on ne fait pas contrôler ses comptes par celui qui les tient.

Que se passe-t-il si le prestataire cesse son activité ?

Tout dépend de votre niveau de préparation. Si vous détenez le nom de domaine, les accès à l'hébergement, une copie du code et une sauvegarde récente, la reprise prend quelques semaines. Si ces éléments sont chez le prestataire, la situation devient sérieuse, notamment en cas de liquidation où les accès se retrouvent bloqués dans une procédure. Le réflexe protecteur : conserver de votre côté une copie mensuelle du site et de sa base, indépendamment du prestataire.

Les mises à jour peuvent-elles casser mon référencement ?

Oui, et cela arrive plus souvent qu'on ne le dit. Les cas les plus fréquents : disparition des balises de titre après la mise à jour d'une extension SEO, réinitialisation des redirections, déploiement accidentel d'un robots.txt de préproduction, invalidation des données structurées. Aucun de ces incidents ne rend le site indisponible, donc aucun ne déclenche d'alerte technique. Seul un contrôle de non-régression systématique après chaque mise en production permet de les attraper avant que le trafic ne le signale.

Trois décisions à prendre avant la fin du projet

Résumons ce qui compte vraiment.

Première décision : le modèle. Forfait préventif, forfait avec quota d'heures, TMA avec engagements ou régie ? Le choix découle de la criticité réelle du site, pas du budget disponible. Un site qui génère la moitié des demandes entrantes ne se maintient pas comme une plaquette en ligne.

Deuxième décision : le porteur. Agence de développement, prestataire tiers, ou configuration mixte ? Et surtout : qui surveille les régressions ? Ce rôle doit être attribué à quelqu'un, nommément. Dans les faits, il ne l'est presque jamais, et c'est précisément là que les pertes s'accumulent.

Troisième décision : le budget, dès le cahier des charges. Pas après la livraison, quand l'enveloppe est consommée et que la maintenance devient une dépense supplémentaire difficile à justifier en interne.

La règle des 15 %

Une seule ligne à ajouter au cahier des charges : « Provision annuelle de maintenance : 15 % du montant du développement, sur trois ans minimum. »

Cette ligne change la nature de la discussion. Elle transforme la maintenance en composante du projet plutôt qu'en option négociable en fin de parcours. Et elle rend visible le coût total de possession, ce qui aide à comparer honnêtement deux propositions de développement.

Une remarque pour finir, tirée de l'observation de dizaines de reprises de sites. Les projets qui vieillissent bien ne sont pas ceux qui ont eu le plus gros budget de développement. Ce sont ceux dont quelqu'un s'est occupé, régulièrement, sans attendre l'incident. La différence de coût sur trois ans est modeste. La différence de résultat, elle, ne se rattrape pas.

Le rôle de FDSEO dans ce dispositif

Notre intervention se situe précisément sur l'angle mort décrit plus haut : ce que la maintenance technique ne voit pas.

Deux prestations complémentaires du travail de votre prestataire technique. L'audit de reprise SEO établit l'état réel du site avant tout engagement : régressions déjà installées, redirections perdues, balises manquantes, dette de référencement accumulée. Un point de départ chiffré, opposable, qui sert de référence pour la suite.

La surveillance de non-régression prend le relais ensuite : contrôle systématique après chaque mise en production, suivi de l'indexation et des positions, alerte immédiate quand un indicateur décroche. Votre prestataire maintient, nous vérifions que la maintenance ne coûte rien en visibilité.

Un échange de trente minutes suffit pour situer votre configuration et estimer le niveau de surveillance pertinent. Sans engagement, et avec des chiffres plutôt que des promesses.