Contrat de maintenance PrestaShop (TMA) : ce qu’il doit couvrir

Un contrat de TMA (tierce maintenance applicative) PrestaShop se juge sur trois questions, et aucune n’est « est-ce que l’agence est réactive ». Combien de temps achetez-vous, et que devient celui que vous ne consommez pas ? Qui s’aperçoit d’une panne, et en combien de temps ? Comment revient-on en arrière quand une mise à jour casse quelque chose ?

Cet article décrit comment on y répond chez Mintfull, avec les chiffres de notre contrat. Il vous servira aussi à relire celui que vous avez déjà.

Ce que couvre une TMA, concrètement

Trois types d’interventions, qui puisent dans le même volume de temps :

• le correctif : un bug, un tunnel de commande bloqué, un module de paiement qui renvoie une erreur après une mise à jour de l’API de la banque ;
• le préventif : les versions de PHP, de PrestaShop et des modules, les failles connues, la place disque, les performances qui se dégradent lentement ;
• l’évolutif : un nouveau transporteur, un export pour l’ERP, une page de catégorie à refaire.

Un contrat qui ne couvre que le correctif vous fait payer les pannes et jamais ce qui les évite. Le préventif est la partie la moins visible, et c’est celle qui coûte le moins cher à l’année.

Le temps : un volume annuel, pas un abonnement

Notre TMA se vend en jours, à l’année : à partir de 6 jours par an, soit 0,5 jour par mois en moyenne (350€ HT par mois). Le temps se consomme au rythme de la boutique, pas au rythme du calendrier :

• un mois calme ne consomme presque rien, une refonte du tunnel avant les soldes consomme beaucoup ;
• les jours non consommés ne sont pas perdus au 1er du mois : ils se reportent sur l’année suivante, jusqu’à un trimestre de volume ;
• un point trimestriel ajuste le volume si l’activité change ;
• chaque intervention est tracée avec son temps, et le solde se suit en temps réel.

C’est la première ligne à vérifier dans un contrat existant. Un forfait mensuel « use it or lose it » paie souvent des heures qui n’existent pas, et pousse le prestataire à remplir le mois plutôt qu’à résoudre vite.

Les délais : ce qu’on écrit, et ce qu’on n’écrit pas

Deux engagements, et pas un de plus :

• un incident critique en production (site en panne, tunnel de commande bloqué, faille exploitée) est pris en charge sous 2 heures ouvrées, par un développeur qui connaît déjà la boutique ;
• toute autre demande reçoit une réponse sous 24 heures ouvrées.

On ne propose pas d’astreinte la nuit et le week-end, et on ne l’écrit donc pas. Méfiez-vous des contrats qui promettent « 24h/24 » sans dire qui décroche à 3 heures du matin, ni combien ça coûte : soit c’est facturé à part, soit ce n’est pas tenu.

Un délai de prise en charge n’est d’ailleurs utile que si quelqu’un sait qu’il y a une panne. D’où le point suivant.

La détection : savoir avant le client

Sur les 40 sites qu’on suit, c’est la supervision qui doit donner l’alerte, pas un client qui n’arrive plus à payer. On utilise pour ça Minty Monito, notre outil interne :

• disponibilité mesurée en continu par UptimeRobot, avec une alerte sur un changement réel (le site tombe, le site revient) et pas à chaque relevé ;
• versions de PrestaShop et des modules comparées aux failles connues publiées, et sur PrestaShop les commandes et les fichiers suivis par notre module de collecte ;
• une tâche par site et par sujet pour chaque faille, mise à jour de module de paiement ou régression de performance, suivie jusqu’à sa résolution ;
• trois cas seulement en temps réel : site coupé et confirmé, commandes à l’arrêt, fichier suspect au scan. Le client est prévenu par e-mail, et une urgence va au développeur de garde.

C’est cette supervision qui a mesuré le gain de la refonte de Micro Mobility : le temps de réponse serveur médian est passé de 538 à 371 ms, relevé avant et après la bascule. Une TMA sans mesure ne peut pas dire si la boutique va mieux ou moins bien qu’il y a six mois.

Le retour arrière : la question que personne ne pose

Une mise à jour finit toujours par casser quelque chose. La différence entre un incident de dix minutes et une journée perdue tient à la façon dont on revient en arrière. Chez nous, chaque ticket suit le même circuit :

1. une branche Git par ticket, pas de modification directement sur le serveur ;
2. une préproduction identique à la production (même PHP, même configuration), avec les tests fonctionnels et, sur les boutiques qui en ont, les tests de bout en bout ;
3. un déploiement par le même mécanisme qu’à l’habitude, qui permet de revenir sur la version précédente ;
4. des sauvegardes quotidiennes de la base et des fichiers, stockées hors de l’infrastructure qui les produit ;
5. un compte rendu dans le ticket : le temps passé, ce qui a été fait, et pourquoi.

Le point 4 se vérifie facilement dans votre contrat actuel : où sont stockées les sauvegardes ? Si la réponse est « sur le même serveur », elles disparaîtront avec lui.

Reprendre une boutique maintenue par une autre agence

C’est le cas de la plupart des boutiques qu’on maintient aujourd’hui. Le point de départ est presque toujours le même : plus de contact avec le prestataire, des mises à jour jamais passées, un PHP en fin de vie. On procède dans cet ordre :

1. récupérer les accès et faire une sauvegarde complète hors infrastructure, sous 72 heures ouvrées, avant de toucher à quoi que ce soit ;
2. auditer l’existant (version, modules, surcharges, hébergement), audit offert quand la TMA démarre ;
3. traiter les urgences, puis planifier le préventif.

Galerie Auto Direct, repris en juin 2026, a été remis en ordre en un mois. Les sept boutiques de 36 Factory, reprises après un incident de sécurité, n’ont connu aucune nouvelle intrusion depuis. Le détail de la démarche est sur notre page de reprise de site PrestaShop.

Les questions à poser à votre prestataire actuel

Si vous relisez un contrat existant, ces six questions suffisent à le situer :

1. Le temps non consommé est-il reporté, ou perdu en fin de mois ?
2. Quel délai de prise en charge pour une panne critique, et en heures ouvrées ou calendaires ?
3. Qui détecte une panne : vous, vos clients, ou une supervision ?
4. Où sont stockées les sauvegardes, et quand une restauration a-t-elle été testée pour la dernière fois ?
5. Les modifications passent-elles par une préproduction et un historique Git, ou directement sur le serveur ?
6. Chaque intervention est-elle tracée avec son temps ?

Questions fréquentes

Le détail de l’offre est sur la page maintenance et évolution.