Maintenance d’un site internet : que doit comprendre le contrat ?
Un hébergement payé ne dit pas qui corrige le site, teste le formulaire ou restaure les données. Un contrat de maintenance doit rendre ces responsabilités lisibles, avec un périmètre, des délais et des limites que l’entreprise comprend.
06 chapitres
Lister ce qui fait fonctionner le site
Retrouver les composants et les accès
Le site visible n’est qu’une partie du service. Il dépend du domaine, de l’hébergement, du code ou du CMS, des extensions et parfois du paiement, d’un agenda ou d’un service de courriel. Listez ces éléments et les personnes qui peuvent les administrer.
Séparer hébergement et application
Distinguez la gestion de l’hébergement et la maintenance de l’application. Un serveur peut répondre normalement pendant qu’un formulaire ou une boutique ne fonctionne plus. Demandez quels parcours sont contrôlés et qui traite une panne provenant d’un service externe.
Cadrer la reprise du site
Le guide sur la propriété du site aide à retrouver les comptes. Cette étape est particulièrement utile lors d’une reprise : le prestataire doit savoir ce qu’il prend en charge avant de promettre un forfait.
- Domaine, hébergement, code ou CMS et licences.
- Paiement, courriel, agenda et autres services connectés.
- Parcours importants : contact, achat, connexion, publication.
- Titulaires des comptes et intervenants autorisés.
Séparer entretien, réparation et évolution
Distinguer entretien, correction et évolution
L’entretien préventif réduit les problèmes évitables : mises à jour, contrôles et vérification des sauvegardes. La maintenance corrective traite un défaut. L’évolution ajoute ou modifie un usage : un nouveau formulaire, une rubrique ou une connexion ne relève pas automatiquement du même forfait.
Qualifier chaque demande
Le contrat doit dire comment chaque demande est qualifiée. Une modification de texte peut être incluse, facturée au temps passé ou laissée à l’équipe formée à l’administration. Ce choix est acceptable s’il est explicite avant la première demande.
Prévoir les composants sans support
Demandez aussi le traitement des technologies sans support et des extensions abandonnées. Maintenir un site ne permet pas toujours de conserver indéfiniment tous ses composants. Une reprise technique peut demander un chantier distinct, avec un devis et une recette.
Vérifier ce qui se passe après une mise à jour
Contrôler les usages après intervention
Une liste de versions à jour n’est pas une recette du site. Après une intervention, il faut contrôler les usages essentiels : se connecter, envoyer une demande, publier, commander si la boutique existe. Le niveau de test dépend du site et doit être prévu dans le périmètre.
Préparer le retour en arrière
Avant une modification importante, conservez une version récupérable et préparez le retour en arrière. Sur un site marchand actif, restaurer une ancienne base peut effacer des commandes récentes. La stratégie doit distinguer le code, les fichiers et les données produites pendant l’intervention.
Annoncer et documenter l’intervention
Fixez une fenêtre d’intervention lorsque le changement peut interrompre le service. Un compte rendu court indique ce qui a changé, les contrôles réalisés et les points restant à traiter. L’entreprise n’a pas besoin du détail de chaque commande technique pour comprendre l’état du site.
Demander une restauration testée, pas seulement une sauvegarde
Préciser le contenu des copies
Une sauvegarde peut être présente et inutilisable : base absente, fichiers incomplets, accès perdu ou format illisible. Le contrat doit préciser ce qui est sauvegardé, à quelle fréquence, pendant combien de temps et où les copies sont conservées.
Tester une restauration séparée
- Le test utile consiste à restaurer dans un environnement séparé, puis à ouvrir les pages et les fonctions nécessaires.
- Notez la date, les éléments restaurés et le résultat.
- Ce contrôle ne doit pas risquer d’écraser le site en production.
Fixer la perte et l’arrêt acceptables
Définissez deux besoins avec l’entreprise : la quantité de données qu’elle peut accepter de perdre et le temps pendant lequel le service peut rester indisponible. Un catalogue rarement modifié et une boutique qui reçoit des commandes n’appellent pas la même organisation.
Copier, protéger et tester
La CNIL recommande des sauvegardes régulières, protégées et contrôlées par des essais de restauration.
- Copies
Séparées du service
Éviter qu’un même incident touche le site et toutes ses copies.
- Protection
Des accès encadrés
Les données sauvegardées restent des données à protéger.
- Essai
Une reprise vérifiée
Contrôler l’intégrité et la capacité de restauration.
Distinguer la prise en charge du retour à la normale
Préciser ce que couvre le délai
- « Intervention sous quatre heures » peut désigner l’accusé de réception, le début du diagnostic ou une remise en service.
- Demandez lequel.
- Précisez aussi les horaires couverts, le canal d’alerte et ce qui définit une urgence.
Adapter la priorité à l’impact
Une page secondaire mal alignée, un formulaire indisponible et un paiement bloqué n’ont pas le même impact. Le contrat peut prévoir des priorités différentes. Il doit indiquer qui informe l’entreprise, qui contacte l’hébergeur et comment les décisions sont validées.
Prévoir le circuit d’information
Lorsqu’un incident implique des données personnelles, les obligations dépassent le simple redémarrage. Le prestataire et l’entreprise doivent connaître leurs responsabilités et le circuit d’information. L’offre d’infrastructure et sécurité se cadre avec ces usages, pas uniquement avec une capacité serveur.
Un prestataire et un circuit d’information identifiés
La CNIL demande d’encadrer la sous-traitance, notamment la gestion des incidents et la fin de prestation.
- Incident
Qui avertit qui ?
Décrire le canal et les responsabilités d’information.
- Sortie
Que devient la donnée ?
Prévoir la restitution et le traitement des copies restantes.
Lire le budget avec les exclusions et les conditions de sortie
Comparer à périmètre égal
Comparez les forfaits à périmètre égal : contrôle des parcours, temps d’intervention, sauvegarde, restauration et heures incluses. Séparez les frais d’hébergement, les licences, les évolutions et les interventions hors horaires. Un prix mensuel seul ne permet pas cette comparaison.
Exemple : les limites d’un forfait
Pour un exemple fictif, un forfait peut couvrir les mises à jour et les contrôles mensuels tout en excluant la création d’une nouvelle page. L’entreprise doit savoir comment cette demande sera estimée et validée, avant qu’elle soit exécutée. N’en déduisez pas qu’un forfait plus cher couvre davantage : lisez les tâches.
Préparer le changement de prestataire
La fin du contrat doit permettre une reprise ordonnée : comptes, code selon les droits convenus, exports, documentation et calendrier de transfert. Le guide de vérification des devis complète cette lecture. Faites vérifier les accès et une restauration avant de retirer les droits de l’ancien intervenant.
- Tâches incluses et exclusions clairement nommées.
- Horaires et sens exact des délais annoncés.
- Tarification et validation des demandes supplémentaires.
- Comptes, données et documents remis à la sortie.
Les points qui restent à trancher
L’hébergement comprend-il la maintenance du site ?
Cela dépend du contrat. L’hébergement fournit un environnement d’exécution ; il ne couvre pas automatiquement les mises à jour du site, la réparation du formulaire ni les tests des parcours.
Une sauvegarde quotidienne suffit-elle ?
La fréquence doit correspondre aux données produites. Il faut aussi vérifier le contenu, la protection, la conservation et la restauration de la copie. Une fréquence élevée ne corrige pas une sauvegarde incomplète.
Les changements de textes doivent-ils être inclus ?
Ils peuvent l’être, ou être réalisés par l’entreprise dans son administration. Le contrat doit nommer ce choix et le coût des demandes qui dépassent le périmètre.
Comment reprendre un site confié à un autre prestataire ?
Commencez par un inventaire des comptes, des composants et des droits. Vérifiez une sauvegarde et un export exploitable, puis organisez le transfert et les tests avant de révoquer les anciens accès.
Confronter le guide à un projet réel.
Quelques lignes suffisent : contexte, contrainte principale et résultat attendu.