{a}
" for q, a in FAQ) CONTENT = f"""Une boutique PrestaShop ne tombe jamais en panne le mardi matin. Elle tombe le vendredi à 18 h 40, pendant une opération commerciale, quand le module de paiement refuse toutes les cartes et que la seule personne qui connaît le serveur est en vacances. À ce moment précis, ce qui décide de la suite n'est ni ton hébergeur ni ta chance : c'est ce que tu as signé, ou pas signé, six mois plus tôt.
Le contrat de maintenance PrestaShop est le document le plus mal lu du e-commerce français. On le compare au prix, on regarde le nombre d'heures incluses, on signe. Et le jour de l'incident, on découvre que la sauvegarde vit sur le même serveur que le site, que « support réactif » n'engage à rien, et que le module développé sur mesure appartient au prestataire.
Ce guide déplie la question ligne par ligne : ce que la maintenance couvre vraiment, ce que le marché facture en 2026, les quatorze clauses qu'un contrat sérieux contient, les neuf pièges qui reviennent le plus souvent, et les douze questions à envoyer à ton prestataire actuel pour savoir en quinze minutes si tu es couvert ou juste facturé.
La réponse courte. Un contrat de maintenance PrestaShop coûte entre 50 et 600 € HT par mois selon le niveau de service, ou 60 à 120 € de l'heure en régie. Il doit contenir au minimum : le périmètre exact (core, modules, thème, serveur), les correctifs de sécurité avec un délai chiffré, des sauvegardes externalisées avec test de restauration, un monitoring du tunnel de commande, un SLA à deux niveaux en heures ouvrées définies, un volant d'heures dont le report est précisé, un rapport mensuel, la liste des exclusions, et la propriété du code avec les conditions de réversibilité.
Le mot recouvre quatre métiers différents, et l'essentiel des malentendus vient de là. Quand ton prestataire dit « maintenance » et que tu entends « on s'occupe de tout », vous parlez rarement de la même chose.
La maintenance corrective répare ce qui est cassé : le formulaire de contact qui n'envoie plus rien, la commande qui reste bloquée en attente de paiement, le PDF de facture qui sort vide. C'est la seule que tout le monde a en tête.
La maintenance préventive évite la panne avant qu'elle arrive : appliquer les correctifs de sécurité, surveiller l'espace disque, purger les logs, vérifier que les sauvegardes tournent, tester la restauration. Elle ne se voit jamais, ce qui la rend difficile à vendre et facile à couper. C'est pourtant elle qui fait la différence entre une boutique qui tient cinq ans et une boutique qu'il faut refaire.
La maintenance adaptative suit l'écosystème : PHP change de version, un transporteur modifie son API, la réglementation impose un bouton de rétractation, une plateforme de paiement déprécie sa méthode d'intégration. Personne ne l'a demandée, elle s'impose.
La maintenance évolutive ajoute des fonctionnalités. C'est du développement, pas de la maintenance, même quand on la vend dans le même forfait sous forme d'heures incluses.
Elle n'est pas l'hébergement. Ton hébergeur garantit que la machine tourne, pas que ton PrestaShop est à jour. Un serveur impeccable peut héberger une boutique truffée de failles.
Elle n'est pas l'infogérance système, qui couvre l'OS, PHP, MySQL, les certificats et la supervision serveur. Sur un mutualisé, l'hébergeur s'en charge. Sur un VPS, c'est une ligne à part, et une ligne oubliée.
Elle n'est pas la refonte, ni le marketing, ni le SEO. Un contrat de maintenance qui promet aussi « l'optimisation du référencement » dilue les trois. Vérifie combien d'heures sont réellement fléchées.
Elle n'est pas non plus la migration de version majeure. Passer de 1.7 à 8, ou de 8.2 à 9, se chiffre en jours de recette, pas en heures de forfait. J'ai détaillé la méthode dans mon guide de migration PrestaShop 1.7 vers 9 sans perdre le SEO.
Trois chantiers se télescopent cette année, et aucun ne se règle en une soirée.
Depuis la sortie de PrestaShop 9, la branche 8.2 ne reçoit plus que des correctifs de sécurité et de bugs critiques. Cette phase s'arrête à la sortie de PrestaShop 10 : ce jour-là, 8.2 n'est plus maintenue du tout. Si tu es en 8.2, tu n'as pas un problème immédiat, tu as une échéance. La différence, c'est que l'échéance se prépare et que le problème se subit.
Sur la seule année 2026, la branche 8.2 a reçu plusieurs publications de sécurité. Un aperçu, avec les scores CVSS annoncés par le projet :
| Version | Faille corrigée | Sévérité |
|---|---|---|
| 8.2.4 | Énumération de comptes par temps de réponse sur le login front-office | 5,3 / 10 |
| 8.2.5 | XSS stocké via variables non échappées dans les templates du back-office | 7,7 / 10 |
| 8.2.6 | XSS stocké dans la vue Service client du back-office | 9,3 / 10 |
| 8.2.8 | Injection de formule dans les exports CSV | 8,3 / 10 |
| 8.2.8 | SSRF via les URL d'images à l'import CSV | 8,2 / 10 |
| 8.2.8 | Usurpation d'adresse IP via l'en-tête X-Forwarded-For | 7,3 / 10 |
| 8.2.8 | Injection SQL via les filtres de listes du back-office | 6,5 / 10 |
Regarde la ligne 8.2.6 : un XSS stocké à 9,3 dans la vue Service client, c'est-à-dire une page que ton équipe ouvre tous les jours. Le correctif existe depuis sa publication. La question n'est pas de savoir si PrestaShop fait son travail, il le fait. La question est de savoir qui, chez toi, applique le patch dans les jours qui suivent. Sans contrat, la réponse est presque toujours « personne, on verra ce week-end », et ce week-end n'arrive jamais.
Pour ce qui suit la faille, c'est-à-dire l'injection de code dans le tunnel de paiement, j'ai écrit un guide complet de détection de skimmer sur PrestaShop et un article plus large sur la sécurisation d'une boutique PrestaShop. La surveillance de l'intégrité des fichiers est le complément qui manque à 90 % des contrats.
La version 9.2 est en feature freeze depuis le 9 juillet 2026, la bêta publique est sortie le 22 juillet, et la version stable est attendue à l'automne. Elle apporte un One Page Checkout natif, un assistant « Ask AI » en back-office et le système d'Extra Properties pour étendre les entités du core proprement. J'en ai détaillé les conséquences dans mon article sur PrestaShop 9.2, One Page Checkout et Extra Properties.
Pour un contrat de maintenance, ça se traduit simplement : si tu paies aujourd'hui un module de checkout en une page, tu vas devoir arbitrer. Et si tu as fait développer des champs personnalisés à coups d'overrides, tu as une dette à rembourser. Ces arbitrages appartiennent à la maintenance adaptative, celle que personne ne budgète.
Depuis le 1er septembre 2026, toutes les entreprises assujetties à la TVA en France doivent être capables de recevoir des factures électroniques. L'obligation d'émission suit selon la taille de l'entreprise. Pour une boutique, ça veut dire un raccordement à une plateforme agréée, des formats structurés à produire, et un composant supplémentaire dans la chaîne. Tout est détaillé dans mon guide sur la facturation électronique pour PrestaShop et WordPress. Un module de plus, c'est une ligne de plus à maintenir, à tester après chaque montée de version, et à surveiller quand la plateforme change son API.
Les versions de PHP se périment plus vite que les boutiques. Passer une boutique en PHP 8.4 casse régulièrement des modules anciens, comme je l'ai constaté côté WordPress dans mon test de compatibilité PHP 8.4 des plugins. Ajoute à ça les licences annuelles des modules payants, qui expirent en silence : le module continue de tourner, mais tu ne reçois plus ses mises à jour de sécurité. C'est un angle mort classique, que j'ai abordé dans le guide des modules PrestaShop indispensables.
La maintenance se vend mal parce qu'elle s'oppose à un coût invisible. Rendons-le visible.
Une boutique à 300 000 € de chiffre d'affaires annuel génère en moyenne 822 € par jour. Trois jours d'arrêt, et tu as dépensé l'équivalent d'un an de contrat standard, sans compter les paniers qui ne reviennent pas et les campagnes payantes qui tournent dans le vide pendant l'incident. Le calcul est volontairement simpliste : il ignore la saisonnalité, et un arrêt le 25 novembre coûte plusieurs fois la moyenne.
Le nettoyage d'une boutique compromise se facture généralement entre 1 500 et 4 000 € selon la profondeur de l'infection, et ça n'inclut ni la notification CNIL si des données personnelles ont fuité, ni la reconstruction de la confiance client, ni le déréférencement Google si le site a servi à du spam. Ajoute le risque contractuel avec ton prestataire de paiement, qui peut suspendre ton compte marchand le temps de l'enquête. Un skimmer dans le checkout, c'est-à-dire quelques lignes de JavaScript qui recopient les numéros de carte, tourne parfois pendant des mois sans que rien ne paraisse anormal côté marchand.
C'est le coût le plus sournois. Une boutique maintenue passe de version en version par petits sauts. Une boutique abandonnée trois ans se retrouve en 1.7 sur PHP 7.4, avec quinze modules dont l'éditeur a disparu, et la seule sortie devient une refonte à cinq chiffres. La maintenance ne fait pas économiser de l'argent sur l'année, elle évite le mur.
J'ai relevé les offres publiques du marché français en septembre 2026. Les prestataires ne s'accordent ni sur le vocabulaire ni sur le périmètre, mais les paliers de prix, eux, se ressemblent.
| Niveau | Prix HT / mois | Contenu typique | Pour qui |
|---|---|---|---|
| Veille | 50 à 120 € | Mises à jour mineures du core et des modules, sauvegarde hebdomadaire, monitoring de disponibilité, support au fil de l'eau | Boutique jusqu'à 100 k€ de CA, catalogue simple, peu de modules |
| Standard | 120 à 300 € | Tout le niveau veille, plus sauvegardes quotidiennes, tests après mise à jour, 1 à 2 h d'intervention incluses, rapport mensuel | Boutique de 100 à 500 k€, une quinzaine de modules, un ou deux transporteurs |
| Avancé | 300 à 600 € | Correctifs sans limite raisonnable, optimisation de performance mensuelle, réponse sous 4 h ouvrées, interlocuteur nommé | Boutique de 500 k€ à 2 M€, ERP connecté, développements spécifiques |
| Critique | 600 € et plus | Astreinte élargie, environnement de recette permanent, feuille de route trimestrielle, SLA contractuel avec engagement | Boutique où une heure d'arrêt se compte en milliers d'euros |
| Régie | 60 à 120 € / h | Tu paies ce qui est fait, rien d'autre | Boutique stable, ou marchand qui a déjà une compétence technique en interne |
Deux remarques sur ces chiffres. D'abord, un freelance spécialisé se situe en général sous le prix d'une agence à périmètre équivalent, parce qu'il n'y a pas de chef de projet à refacturer entre toi et la personne qui corrige. Ensuite, les écarts de prix à niveau annoncé identique s'expliquent presque toujours par une seule variable : les heures incluses. Un contrat à 99 € sans heure incluse et un contrat à 249 € avec quatre heures ne se comparent pas, ils ne vendent pas la même chose.
Le débat revient à chaque renouvellement. Voici comment je le tranche avec mes clients.
Le forfait mensuel a un mérite que la régie n'aura jamais : il finance le travail que personne ne demande. Les correctifs de sécurité, la vérification des sauvegardes, la purge des logs, personne ne t'appelle pour ça. En régie, ces tâches ne sont jamais commandées, donc jamais faites. Le forfait a un défaut symétrique : les mois calmes, tu paies pour rien de visible.
La régie convient si tu as déjà quelqu'un en interne qui suit la boutique, et que tu achètes du renfort ponctuel. Elle devient un piège dès que le prestataire n'est pas engagé sur un délai : le jour de l'incident, tu es un client parmi d'autres, et tu passes après ceux qui ont signé un SLA.
Le ticket à l'unité a sa place pour un besoin isolé et cadré : un bug identifié, un module à installer, une correction de faille précise. C'est exactement ce que couvre mon ticket d'intervention. Ça ne remplace pas un contrat, ça sert de porte d'entrée.
Le seuil de bascule, en pratique : en dessous de 100 000 € de chiffre d'affaires annuel, la régie ou une formule de veille suffit. Entre 100 000 et 500 000 €, le forfait standard devient rentable dès le premier incident évité. Au-dessus, la vraie question n'est plus le prix du contrat mais le délai d'intervention garanti.
Prends ton contrat actuel et coche. S'il en manque plus de quatre, tu as un devis, pas un contrat.
Quelles versions, quels modules, quel thème, quel serveur. Un contrat qui dit « votre site PrestaShop » ne dit rien. Le bon niveau de détail : le core, la liste nominative des modules couverts, le thème avec sa version, et une mention explicite du serveur, inclus ou exclu.
« Mises à jour de sécurité appliquées dans les 48 heures suivant la publication d'un correctif critique » est une phrase engageante. « Veille sécurité » n'en est pas une. Demande aussi ce qui se passe quand PrestaShop publie un correctif hors des heures ouvrées, ce qui est arrivé plus d'une fois.
Avec la distinction entre versions mineures, incluses, et versions majeures, facturées. Et une règle pour les modules tiers dont la licence a expiré : qui prévient, qui paie, sous quel délai.
Fréquence, lieu de stockage hors serveur principal, durée de rétention, et délai de restauration garanti. Une sauvegarde sans délai de restauration écrit ne vaut rien : tu ne sais pas si tu récupères ta boutique en deux heures ou en deux jours.
La ligne que presque personne n'écrit. Une sauvegarde qui n'a jamais été restaurée est une hypothèse, pas une garantie. Exige un test réel au moins trimestriel, sur un environnement séparé, avec un compte rendu.
La disponibilité de la page d'accueil ne suffit pas. Un site peut répondre 200 pendant que le tunnel de commande est cassé. Le monitoring utile surveille un parcours d'achat complet, les erreurs 500, l'expiration du certificat SSL et celle du nom de domaine.
Où sont testées les mises à jour avant la production ? Si la réponse est « directement en ligne, la nuit », change de prestataire. Un staging à jour, c'est la différence entre une mise à jour et un pari.
Voir la section suivante, c'est le sujet le plus maltraité de tous.
Combien d'heures incluses, ce qui les consomme, ce qui n'est pas décompté (un correctif de bug relève-t-il des heures incluses ou de la garantie ?), et si les heures non consommées se reportent. Le report est rare, mais il se négocie, souvent sur un trimestre glissant.
Lisible par quelqu'un qui n'est pas développeur : ce qui a été fait, la disponibilité du mois, les mises à jour appliquées, l'état des sauvegardes, les points à surveiller. Sans rapport, tu paies un abonnement dont tu ne peux rien dire au bout d'un an.
Qui tu appelles, et qui répond quand cette personne est absente. Le point faible du freelance, il faut le dire honnêtement, c'est la continuité. Un bon contrat freelance prévoit ce qui se passe en cas d'indisponibilité : un confrère identifié, ou un accès documenté que tu peux transmettre.
Un contrat qui ne dit pas ce qu'il ne couvre pas est un contrat qui te le dira le jour de la facture.
Tout ce qui est développé pour toi t'appartient, et les accès sont à ton nom, pas à celui du prestataire. Le nom de domaine surtout : vérifie aujourd'hui qui est le titulaire du tien, la surprise est fréquente.
À la fin du contrat, restitution des accès, des sauvegardes et de la documentation sous un délai chiffré. Sans clause de sortie, tu es captif, et le prix du renouvellement s'en ressentira.
Ton prestataire accède à des données personnelles de clients : il est sous-traitant au sens du RGPD, ce qui impose un contrat de sous-traitance conforme à l'article 28. Et vérifie son attestation de responsabilité civile professionnelle. Ces deux documents prennent cinq minutes à demander, et ils disent beaucoup sur le sérieux d'en face.
Un contrat n'est pas une assurance : il y a du travail dedans, réparti dans le temps. Voilà le rythme réel.
Le quotidien doit être automatisé : sauvegarde de la base et des fichiers, surveillance de la disponibilité et du tunnel, alerte sur les erreurs 500 et sur les modifications de fichiers non prévues. Si quelqu'un fait ça à la main, tu paies un humain pour le travail d'un cron.
Le mensuel est semi-manuel : appliquer les mises à jour de modules après lecture des notes de version, purger les logs et le cache, vérifier les performances, écrire le rapport. Une à deux heures pour une boutique standard.
Le trimestriel est là où se joue la vraie qualité : test de restauration réel, revue des performances mobiles, revue des accès back-office, c'est-à-dire supprimer les comptes des prestataires partis et des salariés qui ne sont plus là. Cette revue-là remonte plus de problèmes que toutes les autres réunies. Pour la partie perf, mon pack performance couvre le chantier quand il devient trop lourd pour un forfait.
L'annuel est stratégique : plan de version, revue des licences de modules, audit de sécurité complet, et un point sur ce que la boutique devra encaisser l'année suivante. C'est le moment où l'on décide de migrer vers PrestaShop 9, pas le jour où la 8.2 cesse d'être maintenue.
Toujours suivi de « dans la limite du raisonnable », et le raisonnable, c'est celui du prestataire. Demande le nombre d'heures moyen constaté sur un client comparable, et ce qui se passe au-delà.
Deux heures incluses par mois non reportables, sur une boutique stable, c'est vingt-quatre heures payées et peut-être six consommées. Négocie un report trimestriel, ou baisse le forfait.
Très répandu, parce que c'est gratuit. Inutile face à un ransomware, une erreur de manipulation ou une défaillance de l'hébergeur. Exige une copie externalisée.
« Nous nous engageons à traiter votre demande dans les meilleurs délais » n'engage personne. « Sous 48 heures » sans préciser ouvrées ou calendaires te fait perdre le week-end.
Le prestataire a développé un module de livraison spécifique, il en garde la propriété, et la licence s'éteint à la fin du contrat. Tu ne changes plus de prestataire, tu déménages. Fais écrire la cession des droits dès le devis.
Acceptable si le prix est bas et le contenu clair. Toxique quand le prestataire ne rend pas de compte : tu paies deux ans un service dont tu ne peux rien vérifier. Douze mois avec préavis de deux mois est un bon équilibre.
Je le remets ici parce que c'est le piège le plus fréquent et le plus grave. La sauvegarde est planifiée, tout le monde est rassuré, et le jour de la restauration on découvre que le dump de la base est tronqué depuis huit mois.
Beaucoup de contrats mentionnent la « supervision serveur » sans couvrir l'infogérance. Le jour où PHP doit passer une version majeure, tu découvres que ça n'est dans le périmètre de personne.
Ce n'est pas une clause, c'est pire : c'est un oubli. Vérifie le titulaire de ton nom de domaine dans le whois maintenant, avant d'en avoir besoin.
Un SLA utile tient en quatre éléments : une classification des incidents, un délai de prise en charge, un délai de rétablissement, et une plage horaire.
| Niveau | Exemples | Prise en charge | Contournement ou correctif |
|---|---|---|---|
| P1, bloquant | Site inaccessible, paiement refusé, commandes non enregistrées, faille exploitée | 4 h ouvrées | 8 h ouvrées |
| P2, majeur | Transporteur indisponible, e-mails transactionnels non envoyés, back-office inaccessible | 1 jour ouvré | 3 jours ouvrés |
| P3, mineur | Affichage cassé sur une page, export à corriger, texte à modifier | 3 jours ouvrés | Prochaine fenêtre de maintenance |
Trois précisions à faire figurer. Les heures ouvrées, définies précisément : 9 h - 18 h du lundi au vendredi hors jours fériés, par exemple. Le régime des périodes de pointe : Black Friday, soldes, fêtes de fin d'année, où un SLA standard ne suffit pas et où l'astreinte se facture. Et le canal d'alerte : un incident P1 signalé par e-mail à 19 h ne sera pas vu, il faut un numéro ou un canal dédié.
Sur les pénalités, sois pragmatique. Chez un freelance ou une petite structure, une clause pénale se négocie rarement et elle ne répare rien : ce que tu veux, c'est que le site reparte, pas 200 € d'avoir. Le vrai levier, c'est la clause de sortie sans préavis en cas de manquement répété au SLA.
Pose-la telle quelle à ton prestataire : « la dernière fois que tu as restauré ma boutique sur un environnement de test, c'était quand, et combien de temps ça a pris ? ». Une réponse hésitante te dit tout.
Le cadre à exiger tient en cinq points. Une sauvegarde quotidienne de la base et des fichiers pour une boutique active, hebdomadaire seulement si le catalogue ne bouge pas. Une copie hors serveur principal, chez un autre fournisseur si possible. Une rétention d'au moins 30 jours, parce qu'une compromission se découvre rarement le jour même. Un délai de restauration écrit, c'est ton RTO. Et un test réel trimestriel, documenté.
Ajoute une exigence que peu de contrats prévoient : la sauvegarde doit être immuable ou au moins inaccessible depuis le serveur du site. Si un attaquant qui prend la main sur ta boutique peut aussi effacer tes sauvegardes, tu n'as pas de sauvegardes, tu as une copie.
Un contrat honnête exclut explicitement une bonne partie des choses. Les licences des modules payants, à renouveler chaque année, restent à ta charge. L'hébergement aussi. Les migrations majeures se chiffrent en projet. Le remplacement d'un module devenu incompatible après une montée de version n'est pas un bug, c'est un achat. La refonte graphique et les nouvelles fonctionnalités sortent du périmètre par définition. Les interventions liées à une manipulation du client ou d'un tiers, également : si quelqu'un installe un module trouvé sur un forum et casse la production, ce n'est pas de la maintenance, c'est du dépannage.
Un prestataire qui n'exclut rien ne s'engage sur rien. La liste d'exclusions est un signe de sérieux, pas de mesquinerie.
Les trois plateformes ne demandent pas le même effort, et les contrats devraient le refléter.
Sur PrestaShop, le risque principal vient des overrides et des modules tiers. Le core est solide, mais chaque montée de version rejoue la question de la compatibilité de vingt modules. La maintenance y est un travail de recette autant que de correction, ce qui explique que les tarifs soient plus élevés que sur WordPress.
Sur WordPress, le volume de mises à jour est plus important mais chacune est plus légère, et l'automatisation couvre davantage de terrain. Le risque se déplace vers les plugins abandonnés et les thèmes premium jamais mis à jour. Détails sur ma page freelance WordPress.
Sur WooCommerce, tu cumules les deux : le rythme WordPress et la complexité e-commerce, avec des mises à jour majeures de WooCommerce qui touchent régulièrement le tunnel. Voir freelance WooCommerce.
Un point commun : sur les trois, le monitoring doit surveiller le parcours d'achat, pas la page d'accueil. Et le suivi de l'indexation compte autant que le suivi technique, sujet que j'ai traité dans le guide Google Search Console pour PrestaShop.
Copie ces douze questions, envoie-les à ton prestataire, et compare les réponses à ce que tu viens de lire. Les réponses évasives sont des réponses.
Un prestataire sérieux répond aux douze en une heure. S'il faut trois relances, tu connais déjà le comportement que tu auras le jour de l'incident.
Je suis Arnaud Mérigeau, freelance PrestaShop et WordPress, certifié PrestaShop Experts, basé à Bordeaux, missions partout en France. Plus de quinze ans sur ces socles, et l'essentiel de mon temps passé sur des boutiques que je n'ai pas construites moi-même. C'est utile : je passe autant de temps à lire du code écrit par d'autres qu'à en écrire.
Trois formules, sans engagement de 24 mois.
| Formule | Prix HT / mois | Ce qu'il y a dedans |
|---|---|---|
| Veille | {PRIX_VEILLE} | Correctifs de sécurité du core sous 48 h, mises à jour mineures, sauvegarde quotidienne externalisée, monitoring de disponibilité et du tunnel, rapport mensuel |
| Sérénité | {PRIX_SERENITE} | Tout Veille, plus 2 h d'intervention incluses reportables sur le trimestre, mises à jour de modules testées sur staging, test de restauration trimestriel, revue de performance |
| Critique | {PRIX_CRITIQUE} | Tout Sérénité, plus 4 h incluses, SLA bloquant sous 4 h ouvrées, astreinte pendant les opérations commerciales, feuille de route trimestrielle |
Ce que je mets systématiquement dans le contrat, et que tu peux exiger de n'importe qui d'autre : sauvegarde hors serveur avec test de restauration réel, correctifs de sécurité sous 48 heures, staging pour toute mise à jour, rapport mensuel lisible, propriété totale du code de ton côté, et réversibilité sous 5 jours ouvrés à la fin du contrat.
Ce que je ne fais pas : promettre de l'illimité, facturer une astreinte 24/7 que je ne pourrais pas tenir seul, ni maintenir une 1.6 indéfiniment sans plan de sortie. Sur ce dernier point, autant le dire tôt : si ta boutique est en 1.6 ou en 1.7 sur un PHP obsolète, la bonne dépense n'est pas un contrat de maintenance, c'est une migration.
Pour démarrer, trois entrées possibles. Un ticket d'intervention si tu as un problème isolé et que tu veux tester la collaboration. Le pack performance si le sujet est la vitesse. Ou directement le formulaire de contact avec l'URL de ta boutique, sa version, et ce qui t'inquiète : je réponds sous 24 h ouvrées avec un premier diagnostic. Tu peux aussi regarder mes réalisations et ma page freelance PrestaShop, ou l'article qui explique quel profil appeler selon le chantier.
Si tu veux vérifier ma méthode avant de me parler, tout est public : ma politique de sécurité pour les thèmes et modules, mon guide de optimisation du back-office et le reste du blog.
Un contrat de maintenance ne se juge pas au prix mensuel. Il se juge à trois choses : ce qui est écrit sur les sauvegardes, ce qui est écrit sur les délais, et ce qui est écrit sur la sortie. Le reste est de la mise en forme.
Si ton contrat actuel ne contient aucune de ces trois choses, tu ne paies pas une maintenance, tu paies une présence. Et le vendredi à 18 h 40, une présence ne répond pas.
Envoie-moi l'URL de ta boutique avec sa version et ton contrat actuel s'il y en a un. Je te dis en vingt minutes si tu es couvert, sur-facturé, ou les deux.
""" SOCIAL_WHO = f"""Je suis Arnaud Mérigeau, freelance PrestaShop & WordPress certifié Experts, basé à Bordeaux. +15 ans sur des boutiques que je n'ai pas construites moi-même. Une question sur ta maintenance ? Envoie l'URL. {CONTACT} """ SOCIAL_LINKEDIN = f"""« Sauvegarde quotidienne » figure dans ton contrat de maintenance. Question suivante : la dernière fois que quelqu'un l'a restaurée pour de vrai, c'était quand ? C'est la ligne qui manque dans la quasi-totalité des contrats PrestaShop que je relis. La sauvegarde est planifiée, tout le monde est rassuré, et le jour où il faut restaurer on découvre que le dump de la base est tronqué depuis huit mois. Pendant ce temps, sur la seule branche 8.2, PrestaShop a corrigé cette année un XSS stocké noté 9,3/10 dans la vue Service client, une injection de formule dans les exports CSV à 8,3 et une SSRF à 8,2. Les correctifs existent. La question, c'est qui les applique chez toi. J'ai écrit le guide que j'aurais aimé donner à mes clients avant qu'ils signent ailleurs : les 14 lignes qu'un contrat doit contenir, les tarifs réels du marché en 2026, les 9 clauses qui piègent, et 12 questions à envoyer tel quel à ton prestataire actuel. {ARTICLE_URL_PLACEHOLDER} """ + SOCIAL_WHO SOCIAL_X = f"""Ton contrat de maintenance PrestaShop dit « sauvegarde quotidienne ». La vraie question : quand a-t-elle été restaurée pour de vrai ? Les 14 lignes d'un contrat sérieux, les prix 2026 et les 9 pièges : {ARTICLE_URL_PLACEHOLDER} """ SOCIAL_FACEBOOK = f"""Combien coûte la maintenance d'une boutique PrestaShop ? Entre 50 et 600 € par mois selon le niveau. Mais le prix n'est pas le sujet : ce qui compte, c'est ce qui est écrit sur les sauvegardes, sur les délais d'intervention, et sur ce qui se passe quand tu pars. Guide complet : tarifs réels du marché 2026, les 14 lignes d'un contrat sérieux, les 9 clauses qui coûtent cher, et 12 questions à poser à ton prestataire actuel. {ARTICLE_URL_PLACEHOLDER} """ + SOCIAL_WHO def get_or_create_tag(base: str, user: str, password: str, name: str) -> int: slug = name.lower().replace(" ", "-").replace("é", "e").replace("è", "e") lookup = f"{base}/wp-json/wp/v2/tags?slug={urllib.parse.quote(slug)}" _, tags = wp_client._request("GET", lookup, user, password) if tags: return int(tags[0]["id"]) _, tag = wp_client._request( "POST", f"{base}/wp-json/wp/v2/tags", user, password, data=json.dumps({"name": name, "slug": slug}).encode("utf-8"), headers={"Content-Type": "application/json"}, ) return int(tag["id"]) def save_exports(article_url: str, content: str, post_id: int | None = None) -> Path: out = ROOT / "exports" / "contrat-maintenance-prestashop-2026" social = out / "social" article = out / "article" social.mkdir(parents=True, exist_ok=True) article.mkdir(parents=True, exist_ok=True) (article / "content.html").write_text(content.strip() + "\n", encoding="utf-8") (article / "seo.yaml").write_text( "\n".join( [ f"titre_seo: {YOAST_TITLE}", f"slug: {SLUG}", f"meta_description: {YOAST_DESC}", f"focus_keyword: {FOCUS}", "categorie_wp: PrestaShop, E-commerce", f"tags: {', '.join(TAG_NAMES)}", f'h1: "{TITLE}"', f"excerpt: {EXCERPT}", "", "requetes_cibles:", " - maintenance prestashop (1137 impressions/3 mois, pos 24)", " - freelance maintenance prestashop (487, pos 18.8)", " - maintenance site prestashop (411, pos 19.5)", " - maintenance site web prestashop (408, pos 15.2)", " - agence maintenance prestashop (325, pos 32)", " - contrat de maintenance prestashop (266, pos 39.9)", " - contrat maintenance prestashop (243, pos 37.9)", " - maintenance site internet prestashop (223, pos 16.9)", " - forfait maintenance prestashop (33, pos 24)", " - maintenance boutique prestashop (85, pos 21.5)", "", "variante_titre_seo_2: Maintenance PrestaShop : prix, contenu et pièges du contrat", "variante_meta_2: 50 à 600 €/mois selon le niveau. Les 14 lignes d'un contrat sérieux, les 9 clauses qui piègent, 12 questions à poser à ton prestataire.", "", "variante_titre_seo_3: Combien coûte la maintenance PrestaShop en 2026 ?", "variante_meta_3: Tarifs relevés du marché français, ce que couvre vraiment un contrat, et comment auditer le tien en 15 minutes.", "", ] ), encoding="utf-8", ) posts = { "linkedin.txt": SOCIAL_LINKEDIN.replace(ARTICLE_URL_PLACEHOLDER, article_url), "x.txt": SOCIAL_X.replace(ARTICLE_URL_PLACEHOLDER, article_url), "facebook.txt": SOCIAL_FACEBOOK.replace(ARTICLE_URL_PLACEHOLDER, article_url), } for name, text in posts.items(): (social / name).write_text(text.strip() + "\n", encoding="utf-8") (out / "README.txt").write_text( "Article pilier « Contrat de maintenance PrestaShop 2026 »\n" f"URL prévue : {article_url}\n" f"Post ID : {post_id or 'n/a'}\n\n" "À valider avant publication :\n" f"- tarifs des formules ({PRIX_VEILLE} / {PRIX_SERENITE} / {PRIX_CRITIQUE})\n" "- engagements SLA de la section 14\n\n" "Visuels : assets/contrat-maintenance-prestashop-2026-featured.png\n" " assets/maintenance-prestashop-2026-paliers.png\n" " assets/maintenance-prestashop-2026-cout-panne.png\n" " assets/maintenance-prestashop-2026-cycle.png\n", encoding="utf-8", ) return out def ping_indexnow(article_url: str) -> None: key = "5f8e4b8b35b143b988c607967725f4b9" payload = { "host": "www.arnaud-merigeau.fr", "key": key, "keyLocation": f"https://www.arnaud-merigeau.fr/{key}.txt", "urlList": [article_url], } req = urllib.request.Request( "https://api.indexnow.org/indexnow", data=json.dumps(payload).encode("utf-8"), headers={"Content-Type": "application/json; charset=utf-8"}, method="POST", ) try: with urllib.request.urlopen(req, timeout=20) as resp: print(f"IndexNow {resp.status} — {article_url}") except Exception as exc: # noqa: BLE001 print(f"IndexNow ignoré : {exc}") def main() -> int: publish = "--publish" in sys.argv cfg = load_config() base = cfg.wp_base_url.rstrip("/") if not cfg.wp_user or not cfg.wp_application_password: print("Credentials WP manquants dans .secrets/.env") return 1 print("Upload des visuels…") media_ids: dict[str, int] = {} media_urls: dict[str, str] = {} for path, alt in ( (IMG_FEATURED, "Contrat de maintenance PrestaShop 2026 : SLA, sauvegardes et correctifs de sécurité"), (IMG_PALIERS, "Les quatre paliers de tarifs de maintenance PrestaShop en 2026"), (IMG_PANNE, "Coût d'une journée d'arrêt d'une boutique PrestaShop selon le chiffre d'affaires"), (IMG_CYCLE, "Cycle quotidien, mensuel, trimestriel et annuel d'un contrat de maintenance PrestaShop"), ): if not path.is_file(): print(f" manquant : {path.name}") continue media = wp_client.upload_media( base, cfg.wp_user, cfg.wp_application_password, path, alt_text=alt, title=path.stem.replace("-", " "), ) media_ids[path.name] = int(media["id"]) media_urls[path.name] = media.get("source_url", "") print(f" {path.name} -> id {media['id']} ({media.get('source_url')})") content = CONTENT.strip() for token, name in ( ("__IMG_FEATURED__", IMG_FEATURED.name), ("__IMG_PALIERS__", IMG_PALIERS.name), ("__IMG_PANNE__", IMG_PANNE.name), ("__IMG_CYCLE__", IMG_CYCLE.name), ): url = media_urls.get(name) if not url: print(f" URL manquante pour {name}, le placeholder {token} reste dans le contenu") continue content = content.replace(token, url) print("Tags…") tag_ids = [ get_or_create_tag(base, cfg.wp_user, cfg.wp_application_password, t) for t in TAG_NAMES ] payload: dict = { "title": TITLE, "content": content, "excerpt": EXCERPT, "status": "publish" if publish else "draft", "slug": SLUG, "author": cfg.wp_author_id, "categories": CATEGORY_IDS, "tags": tag_ids, "meta": { "_yoast_wpseo_title": YOAST_TITLE, "_yoast_wpseo_metadesc": YOAST_DESC, "_yoast_wpseo_focuskw": FOCUS, }, } featured = media_ids.get(IMG_FEATURED.name) if featured: payload["featured_media"] = featured print("Création de l'article…") _, post = wp_client._request( "POST", f"{base}/wp-json/wp/v2/posts", cfg.wp_user, cfg.wp_application_password, data=json.dumps(payload).encode("utf-8"), headers={"Content-Type": "application/json"}, ) post_id = post.get("id") link = post.get("link") or f"{base}/{SLUG}/" print(f"{'Publié' if publish else 'Brouillon créé'} — ID {post_id}") print(f"Lien : {link}") print(f"Aperçu : {base}/?p={post_id}&preview=true") out = save_exports(f"{base}/{SLUG}/", content, post_id=post_id) print(f"Exports : {out}") if publish: ping_indexnow(link) return 0 if __name__ == "__main__": raise SystemExit(main())