Votre boutique prend des commandes, votre application produit des devis, votre site reçoit des demandes. Tout fonctionne, jusqu’au jour où une mise à jour bloque un paiement ou où un export ne part plus. Vous appelez le prestataire. Qui intervient ? Dans quel délai ? Et combien de temps peut-il engager sans vous consulter ?
Un contrat de maintenance évolutive doit permettre de répondre à ces questions avant l’incident. Le nombre d’heures mensuelles et le tarif comptent, mais ils ne décrivent pas à eux seuls le service acheté. Il faut aussi définir les responsabilités, les conditions d’intervention et la manière dont l’existant pourra évoluer.
Clarifier ce que couvre le mot « maintenance »
La maintenance corrective remet en état une fonction attendue : un formulaire n’envoie plus de message, un calcul donne un résultat erroné, un import s’interrompt. Il faut pouvoir décrire le comportement prévu et reproduire l’écart.
La maintenance préventive réduit les risques : mises à jour, contrôle des erreurs, revue des accès, vérification des sauvegardes. Une extension mise à jour sans contrôle des parcours importants peut provoquer une panne ; le contrat doit prévoir ce contrôle, pas seulement l’installation des nouvelles versions.
La maintenance évolutive répond à un besoin nouveau : ajouter un champ, adapter un export, faire évoluer une recherche ou connecter un outil métier. Elle nécessite une décision sur le résultat attendu et une validation après livraison.
Ces trois activités peuvent partager une enveloppe, à condition que leurs règles soient explicites. Sinon, les urgences absorbent le budget et les améliorations sont constamment reportées. Demandez comment le prestataire réserve du temps au préventif et arbitre les évolutions.
Nommer les composants et répartir les responsabilités
« Maintenance du site » reste imprécis. Une boutique peut dépendre de WordPress, WooCommerce, d’un thème spécifique, d’une plateforme de paiement et d’un service d’emailing. Certaines briques appartiennent au client, d’autres sont exploitées par des fournisseurs.
Une annexe courte doit identifier les domaines, les environnements et les composants concernés, puis distinguer ce qui est entretenu de ce qui fait seulement l’objet d’une coordination.
| Sujet | Point à faire préciser |
|---|---|
| Code, thème et extensions | Quels éléments sont couverts, avec quelles versions ou réserves connues ? |
| Hébergement et services tiers | Qui surveille, ouvre un ticket et suit l’incident auprès du fournisseur ? |
| Licences et abonnements | Qui détient les comptes, paie les renouvellements et reçoit les alertes ? |
| Petites évolutions | Quel budget ou niveau de complexité permet de les traiter dans le contrat ? |
| Migration ou refonte | À quel moment un devis et une validation séparés deviennent-ils nécessaires ? |
Un fournisseur de paiement peut être indisponible sans que le mainteneur puisse le rétablir. En revanche, celui-ci peut vérifier l’impact sur la boutique et transmettre les informations utiles. Le contrat doit dire si cette coordination est incluse et comment elle est facturée.
Prévoir une prise en main avant les engagements courants
Un prestataire qui découvre une application ne connaît pas encore ses points fragiles. Une phase de reprise distincte rend les engagements suivants plus réalistes.
Elle doit livrer au minimum une carte des composants, la liste des parcours critiques, des accès utilisables, un état des dépendances et une procédure de déploiement. La sauvegarde et la restauration méritent un contrôle spécifique. Les anomalies déjà présentes doivent être consignées pour éviter de les confondre avec de nouveaux incidents.
Cette étape fournit aussi une première liste de priorités : ce qui doit être sécurisé immédiatement, ce qui peut attendre et ce qui demande un projet séparé. Si votre application repose sur Laravel, notre guide consacré à la reprise d’une application Laravel détaille cette démarche.
Le contrat doit préciser la date de début des engagements, les prérequis nécessaires et les réserves liées à l’état initial du système.
Distinguer prise en charge, rétablissement et résolution
Ces trois délais décrivent des résultats différents :
- Prise en charge : une personne qualifiée examine l’incident et engage le diagnostic. Un accusé de réception automatique ne suffit pas.
- Rétablissement : le service redevient utilisable, éventuellement avec un contournement ou un retour à la version précédente.
- Résolution : la cause est corrigée et la correction vérifiée.
Exiger une « intervention sous quatre heures » ne dit pas lequel de ces résultats est promis. Les horaires couverts, le canal d’alerte et le point de départ du délai doivent également être écrits. Une astreinte le soir ou le week-end demande une organisation et un prix correspondants.
La priorité dépend ensuite de l’impact sur l’activité. Cette grille est un exemple à adapter, pas un engagement de délai WEVE :
| Priorité | Situation | Objectif immédiat |
|---|---|---|
| Critique | Tous les paiements sont bloqués ou une fonction centrale est inaccessible | Limiter l’impact et rechercher un rétablissement |
| Élevée | Une fonction importante est dégradée sans contournement acceptable | Diagnostiquer et traiter en priorité |
| Courante | Défaut limité avec une solution temporaire | Planifier la correction |
| Évolution | Nouveau besoin, sans panne de l’existant | Définir, estimer et faire valider |
La difficulté technique peut varier fortement à l’intérieur d’un même niveau. Un délai de prise en charge maîtrisé ne garantit donc pas, à lui seul, un délai identique de résolution.
Vérifier ce que permet réellement la sauvegarde
Une sauvegarde quotidienne peut être correcte pour un site éditorial et insuffisante pour une boutique qui enregistre des commandes toute la journée. Deux questions aident à dimensionner le dispositif : quelle quantité de données pourriez-vous perdre, et pendant combien de temps pourriez-vous travailler sans le service ?
La première correspond à l’objectif de perte de données maximale, mesurée en temps, souvent appelé RPO. Avec une sauvegarde chaque nuit, une restauration peut faire perdre les écritures intervenues depuis cette sauvegarde. La seconde correspond à l’objectif de durée de rétablissement, ou RTO : temps de récupération, restauration et contrôles compris. Ces notions sont détaillées dans le glossaire de sauvegarde Microsoft.
Ce sont des objectifs à convenir selon l’activité et les moyens disponibles. Ils demandent une procédure et des essais, pas seulement deux chiffres dans une annexe.
Le contrat doit indiquer les données sauvegardées, la fréquence, la conservation, le lieu de stockage et la personne chargée de restaurer. Il doit aussi prévoir la vérification des restaurations. Pour une boutique, remettre en place une ancienne base peut effacer des commandes alors que les paiements existent toujours chez le prestataire de paiement. Le rapprochement de ces données fait partie du travail à anticiper.
Enfin, revenir sur une modification du code ne nécessite pas toujours de restaurer toute la base. La procédure de retour arrière doit distinguer ces opérations.
Décrire le chemin d’une demande jusqu’à sa validation
Pour une évolution, le fonctionnement peut rester simple : le client décrit le besoin ; le prestataire clarifie le résultat, estime l’effort et obtient l’accord ; le changement est réalisé puis vérifié avant déploiement. Le client valide les règles métier, le prestataire contrôle le fonctionnement technique. Un environnement de test est prévu lorsque le risque le justifie.
En urgence, ce circuit doit être plus court. Il faut donc convenir à l’avance des actions autorisées sans nouvel accord, du budget mobilisable et de la personne à prévenir.
Prenons un exemple fictif : après une mise à jour, aucun paiement n’aboutit. Le diagnostic confirme le défaut et un retour à la version précédente permet de rétablir les achats. L’équipe vérifie ensuite les commandes et transactions concernées, puis teste la correction durable avant de la déployer. Le rétablissement précède ici la résolution. Un contrat clair organise ces décisions ; il ne pousse pas à annoncer « problème réglé » dès que la page fonctionne de nouveau.
Rendre le budget lisible, y compris en cas de dépassement
Le forfait peut rémunérer une enveloppe de temps, une disponibilité, des opérations définies ou une combinaison de ces éléments. Comparez la mécanique, pas seulement le total mensuel.
Faites préciser si le temps inutilisé est reporté, ce qui consomme l’enveloppe et le seuil nécessitant un accord supplémentaire. Diagnostic, réunions, tests, déploiement et documentation peuvent représenter une part importante de l’intervention. Une correction de quelques lignes n’est pas forcément une intervention de quelques minutes.
Le suivi doit permettre de rattacher le temps à une demande et à un résultat. Lorsqu’une évolution dépasse le cadre, le prestataire doit l’estimer et obtenir une validation avant de l’engager. Les achats de licences et services externes doivent rester identifiables.
Encadrer les accès et les données personnelles
Le prestataire peut avoir accès aux comptes d’administration, aux commandes, aux formulaires et aux journaux. Prévoyez des comptes individuels, des droits limités au besoin et une transmission des secrets adaptée. Une copie de production utilisée pour des tests doit elle aussi être encadrée.
Lorsque le prestataire traite des données personnelles pour votre compte, le cadre contractuel de sous-traitance doit respecter les exigences applicables de l’article 28 du RGPD. La CNIL rappelle notamment la nécessité de définir les responsabilités, la sécurité, la gestion des incidents et les conditions de restitution ou destruction des données. Sa fiche Gérer la sous-traitance permet d’identifier ces sujets avec votre interlocuteur juridique ou votre délégué à la protection des données.
Demander un bilan et préparer la réversibilité
Le bilan périodique doit expliquer ce qui a changé, le temps consommé, les erreurs récurrentes et les risques restant à traiter. Il sert à décider des prochaines priorités, notamment lorsqu’une dette technique empêche les petites évolutions de rester petites.
Les cas publics WEVE donnent deux exemples de cette complexité. Dans un site institutionnel maintenu dans la durée, les interventions concernent les contenus, la recherche, les événements, les formulaires et des parcours de paiement, en coordination avec une agence partenaire. Le contrat doit donc préciser les interlocuteurs et la validation des parcours concernés.
Dans un écosystème e-commerce et contenus privés, WordPress et WooCommerce s’articulent avec des applications, un CRM et des intégrations d’emailing. Limiter le périmètre au seul site laisserait plusieurs dépendances sans responsable clairement désigné.
Préparer la sortie du contrat complète ce travail. Qui conserve le code, les comptes et la documentation ? Sous quel format les données sont-elles restituées ? Combien de temps de passation est inclus ? Le changement de prestataire doit pouvoir s’organiser sans dépendre d’un mot de passe partagé ou d’une connaissance uniquement orale.
Les questions à poser avant de signer
- Quels composants et parcours sont couverts ?
- Quels contrôles préventifs sont réellement prévus ?
- Que signifie le délai annoncé et quels horaires couvre-t-il ?
- Qui peut autoriser une intervention urgente ou un dépassement ?
- Les sauvegardes ont-elles été restaurées et vérifiées ?
- Comment les demandes sont-elles estimées, testées et validées ?
- Comment sont suivis le budget et les services tiers ?
- Qu’est-ce qui sera transmis en fin de contrat ?
Un contrat utile rend les décisions compréhensibles lorsque tout fonctionne encore. C’est ce cadre qui permet ensuite de corriger les incidents et de faire évoluer le système avec moins d’improvisation.
Vous souhaitez définir un cadre de maintenance pour votre site ou votre application ?
