Pourquoi un forfait de maintenance Shopify TMA mérite un cadrage écrit ?
Parce qu’une boutique Shopify ne « s’entretient » pas toute seule une fois publiée. Shopify porte l’hébergement et les mises à jour de la plateforme. Le thème, les apps installées, les intégrations et les parcours que vous avez composés restent sous votre responsabilité opérationnelle. Sans partenaire clair, les bugs s’accumulent, les apps se contredisent, et les évolutions de plateforme arrivent sans propriétaire nommé.
Ce guide sert aux décideurs e-commerce qui veulent lire (ou rédiger) un contrat de maintenance boutique Shopify sans se contenter d’un volume d’heures flou. Il détaille le périmètre d’une tierce maintenance applicative Shopify, ce qui est souvent oublié, comment distinguer correctif et évolutif, quels indicateurs suivre, et ce qu’il faut exiger d’une agence. Pour un accompagnement chez Lighthouse (Paris) : Maintenance et évolutions Shopify.
Qu’est-ce qu’une maintenance Shopify TMA (tierce maintenance applicative) ?
La TMA Shopify désigne le fait de confier à un prestataire le suivi technique de ce qui vous appartient sur la boutique : thème Liquid (ou Hydrogen si vous êtes hors Online Store classique), apps publiques et custom, connecteurs, scripts, et petites évolutions métier. Ce n’est ni du support Shopify Support (compte, facturation plateforme, incidents côté Shopify), ni un projet de refonte totale déguisé en forfait mensuel.
| Sujet | Côté Shopify (plateforme) | Côté TMA / marchand |
|---|---|---|
| Hébergement et infra boutique | Oui (Online Store, admin, checkout plateforme) | Non : vous ne « patchez » pas les serveurs Shopify |
| Thème et sections | Mises à jour Theme Store si thème compatible | Oui : revue, report des personnalisations, tests, publication |
| Apps App Store | Non (responsabilité de l’éditeur) | Oui : suivi des mises à jour, conflits, nettoyage après désinstallation |
| Apps custom / intégrations | APIs versionnées, changelog, alertes Dev Dashboard | Oui : upgrades API, monitoring, corrections de flux |
| Contenu catalogue / merch | Outils admin | Hors TMA sauf si explicitement inclus (ops éditoriale) |
Si votre ensemble technique repose sur une app privée critique, croisez ce guide avec Pourquoi développer une app Shopify sur mesure et le suivi de santé des apps custom dans le Developer Dashboard.
Ce qu’un forfait de maintenance doit inclure (et exclure clairement)
Le flou naît quand le forfait mélange urgence de production, liste des évolutions produit et « petites idées » sans règle. Un bon contrat sépare ce qui est inclus dans le volume récurrent, ce qui consomme le volume mais reste plafonné, et ce qui sort systématiquement en devis projet.
| Poste | À inclure en TMA (souvent) | À exclure ou traiter en projet |
|---|---|---|
| Correctif (bug prod) | Régression thème, conflit d’app, parcours cassé, erreur de sync connue | Refonte UX complète, nouveau tunnel hors périmètre |
| Évolutif léger | Ajustement de section, règle métier bornée, paramétrage app | Nouveaux modules métier, migration de thème, redesign |
| Mises à jour thème / apps | Revue des notes de version, tests, report des personnalisations, publication | Changement de famille de thème, OS 2.0 depuis vintage non cadré |
| API et changelog | Suivi des versions, correctifs de dépréciation sur vos apps / connecteurs | Réécriture d’intégration ERP complète |
| Performance | Diagnostics ciblés, corrections de poids JS / images / sections | Campagne perf « à partir de zéro » sans baseline |
| Contenu | Support technique pour publier (si convenu) | Rédaction SEO, shooting, merchandising quotidien |
Maintenance corrective et évolutive : comment les distinguer dans le contrat ?
La maintenance corrective répare un comportement attendu qui ne fonctionne plus (ou jamais) : bouton inactif, prix faux, webhook perdu, section qui casse le mobile. La maintenance évolutive modifie un comportement voulu : nouvelle règle de panier, section merch, champ metafield exposé, paramètre d’app. Mélanger les deux sans priorité écrite fait perdre les urgences derrière la liste des évolutions marketing.
Règles simples à faire écrire
- 01
Définition d’incident
Qui décide qu’un ticket est un incident (impact CA, panier, checkout, sync stock) vs une demande d’évolution ? Nommez les rôles côté marchand et côté agence.
- 02
File priorisée
Une liste unique (outil partagé) avec criticité, impact, estimation relative. Pas trois canaux Slack + mail + Notion sans propriétaire.
- 03
Quota évolutif
Une part du forfait peut être réservée à l’évolutif léger. Au-delà, devis ou report au mois suivant, selon la règle contractuelle.
- 04
Critère d’achèvement
Recette sur thème brouillon / environnement de test, scénarios nominaux et d’erreur, puis publication documentée.
SLA et délais de prise en charge : quoi négocier sans inventer de « standard » ?
Il n’existe pas de SLA universel pour la TMA Shopify. Les délais dépendent de la criticité, des horaires de couverture, de l’accès aux comptes (collaborateurs Shopify, Dev Dashboard, apps éditeurs), et de la complexité de l’ensemble technique. Ce qu’il faut exiger, ce sont des définitions mesurables : prise en charge (accusé + qualification) vs résolution, canaux d’urgence, et exclusions (attente éditeur d’app, incident plateforme Shopify, accès manquant).
| Élément | Ce qu’il faut clarifier | Pourquoi ça compte |
|---|---|---|
| Horaires de couverture | Jours / heures, fuseau, jours fériés | Un « sous 4 h » hors fenêtre n’engage rien |
| Prise en charge vs résolution | Délai d’accusé + qualification vs délai de correctif | Évite le glissement sémantique |
| Niveaux de criticité | P1 (checkout / sync critique) à P3 (cosmétique) | Sans niveaux, tout est « urgent » |
| Canal d’urgence | Un seul canal documenté, hors bruit quotidien | Les incidents se noient dans le chat |
| Exclusions | Dépendance éditeur app, incident Shopify, accès manquant | Mesure la responsabilité réelle |
| Astreinte | Incluse ou non, sur quelles surfaces | Coût et disponibilité à arbitrer explicitement |
Mises à jour de thème et d’apps : que doit faire la TMA ?
Shopify documente un processus de mise à jour pour les thèmes installés depuis le Theme Store : notification de nouvelle version, ajout en thèmes brouillon, revue des notes de version, puis publication. Les personnalisations de code peuvent nécessiter un report manuel si elles entrent en conflit. Les thèmes uploadés hors Theme Store ne bénéficient pas de ce flux de mise à jour standard. Online Store 2.0 (sections sur toutes les pages, sources dynamiques) et les architectures plus récentes (theme blocks) changent aussi ce qu’une « mise à jour » signifie : parfois il s’agit d’une migration, pas d’un clic.
Périmètre TMA raisonnable sur le thème
- 01
Surveiller les versions Theme Store
Quand une mise à jour est proposée, l’agence ajoute la copie brouillon, lit les notes, et compare avec votre thème publié.
- 02
Préserver les personnalisations
Reporter le code / sections spécifiques après analyse des conflits. Documenter ce qui a été repris ou volontairement abandonné.
- 03
Recetter les parcours critiques
Accueil, collection, PDP, panier, checkout (surfaces concernées), comptes clients. Mobile inclus.
- 04
Publier et garder une sortie de secours
Conserver l’ancienne version en brouillon ou une archive téléchargeable avant bascule.
Côté apps, la TMA doit suivre les mises à jour éditeur, les changements d’autorisations, les scripts injectés, et le nettoyage après désinstallation (souvent oublié). Pour trancher Theme Store vs sur mesure avant d’alourdir la maintenance, voir Thème Shopify existant ou sur mesure.
Suivi des changements de plateforme : changelog, versions d’API et dépréciations
Shopify publie des versions d’API stables selon un calendrier trimestriel (noms datés du type 2026-10). Chaque version stable est supportée au minimum douze mois, avec un chevauchement d’au moins neuf mois entre versions consécutives. Les dépréciations sont annoncées (changelog développeur, référence API, alertes Dev Dashboard) puis retirées dans une version ultérieure. Une app ou un connecteur qui reste sur une version inaccessible est basculé automatiquement par Shopify vers la plus ancienne version stable encore accessible : ce n’est pas une stratégie de maintenance.
| Source | Usage pour la boutique | Action TMA typique |
|---|---|---|
| Developer changelog (shopify.dev/changelog) | Changements incompatibles, webhooks, thèmes, apps | Revue périodique filtrée sur vos surfaces |
| Versions d’API (Admin, Storefront, webhooks…) | Apps custom, middleware, Functions | Plan d’upgrade avant fin de support |
| Alertes Dev Dashboard | Appels dépréciés, deadlines | Correctif priorisé si flux critique |
| Notes de version thème Theme Store | Nouvelles sections / correctifs | Mise à jour en brouillon + recette |
| Notes éditeurs d’apps | Autorisations, scripts, tarifs, ruptures UX | Test sur environnement de test / boutique de test si possible |
Quand une app custom porte stock, commandes ou ERP, le suivi de santé (volume API, erreurs, webhooks) fait partie du forfait utile : voir Santé des apps custom Shopify.
Monitoring et performance : quels indicateurs suivre en TMA ?
Sans signaux, la maintenance devient réactive et émotionnelle. Un forfait sérieux définit quelques indicateurs, des seuils d’escalade, et un rythme de revue. L’objectif n’est pas un tableau de bord cosmétique : c’est de détecter un panier cassé, une sync qui dérive, ou un storefront qui s’alourdit avant le pic commercial.
| Indicateur | Où le lire | Signal d’alerte typique |
|---|---|---|
| Erreurs / volume API apps custom | Developer Dashboard | Hausse d’erreurs, webhooks en échec |
| Parcours checkout / panier | Analytics, tests manuels, monitoring synthétique si en place | Chute de conversion sans cause marketing |
| Poids scripts apps / thème | Rapport perf Shopify, outils Web Vitals | Régression après installation ou mise à jour d’app |
| Stocks / commandes sync | Logs middleware, écarts opérationnels | Survente, commandes non poussées |
| Tickets ouverts / âge moyen | Outil de tickets TMA | File qui grossit sans priorisation |
Côté vitrine Liquid, les pratiques de performance (streaming HTML, assets, sections) restent un levier : voir storefronts Liquid plus rapides. La TMA peut corriger des régressions ciblées ; une campagne perf complète sans baseline relève plutôt d’un chantier cadré.
Sauvegarde du thème : ce qu’il faut exiger avant chaque bascule
Shopify permet de télécharger un thème (fichier .zip envoyé à l’email du collaborateur) et de conserver jusqu’à une limite de thèmes dans l’admin. Ce téléchargement n’embarque pas produits, collections, menus, pages, articles de blog ni fichiers média : c’est une archive du code / réglages de thème, pas un backup boutique complet. Dupliquer le thème avant une intervention critique reste la première barrière ; le .zip complète pour archivage hors admin ou si vous approchez la limite de thèmes.
Checklist sauvegarde avant intervention risquée
- 01
Dupliquer le thème publié
Garder une copie nommée avec date et motif (ex. avant la mise à jour 15.2).
- 02
Télécharger un .zip si besoin d’archive externe
Utile avant gros report de code ou si l’admin est saturé en brouillons.
- 03
Noter les apps et scripts critiques
Liste des apps qui injectent du JS storefront : elles ne sont pas dans le .zip thème.
- 04
Plan de rollback
Qui republie l’ancienne version, sous quel délai, avec quel test rapide de non-régression.
Ce qu’il faut exiger d’une agence avant de signer un forfait TMA
Le bon partenaire ne vend pas seulement des heures. Il prouve qu’il peut lire votre boutique, nommer les risques, et s’engager sur un mode de travail. Voici les exigences qui séparent un forfait utile d’un abonnement décoratif.
Exigences de cadrage
- 01
Diagnostic de reprise
Inventaire thème (Theme Store / upload / sur mesure), apps, autorisations, intégrations, points de douleur déjà connus. Livrable écrit avant engagement long.
- 02
Périmètre nommé
Surfaces couvertes, exclusions, règle correctif / évolutif, gestion des dépassements.
- 03
Accès et rôles
Collaborateurs Shopify avec permissions minimales nécessaires, accès Dev Dashboard si apps custom, contacts éditeurs d’apps critiques.
- 04
Outil de tickets et reporting
Un canal principal, historique consultable, synthèse périodique (volume consommé, incidents, liste des évolutions).
- 05
Compétences Shopify visibles
Capacité thème Liquid / OS 2.0, apps, API versionnées, et honnêteté sur ce qui sort en projet (refonte, ERP lourd).
- 06
Réversibilité
Documentation des interventions, code dans un dépôt si custom, procédure de fin de contrat (restitution accès, archives).
Signaux d’alerte : quand le forfait ne protège plus la boutique
Un contrat signé ne garantit pas une boutique saine. Les signaux ci-dessous justifient une revue de prestataire ou un recentrage du périmètre.
| Signal | Ce que ça révèle | Action fréquente |
|---|---|---|
| Pas de file priorisée | Tout se décide au feeling | Imposer un outil + rituels |
| Aucune revue changelog / API | Dette silencieuse sur apps custom | Ajouter une veille au forfait |
| Mises à jour de thème jamais testées | Peur de casser le custom | Budget recette ou projet de dette |
| Mêmes incidents qui reviennent chaque mois | Pas de documentation / pas de cause racine | Exiger post-mortems courts |
| Volume toujours « plein » sans livrable | Heures brûlées sans impact | Mesurer correctif vs évolutif |
| Accès uniquement sur le laptop d’une personne | Risque de dépendance à une seule personne | Comptes collaborateurs + dépôt |
Checklist : lire un contrat de maintenance boutique Shopify
Avant de signer (ou de reconduire)
- 01
Surfaces nommées
Thème, apps App Store, apps custom, middleware, éventuellement Hydrogen.
- 02
Correctif vs évolutif
Définitions, quotas, file unique.
- 03
SLA mesurable
Fenêtre de couverture, criticités, prise en charge vs résolution, exclusions.
- 04
Mises à jour thème et apps
Qui déclenche, qui recette, qui publie.
- 05
Veille plateforme
Changelog, versions d’API, alertes Dev Dashboard.
- 06
Monitoring
Indicateurs, seuils, rythme de revue.
- 07
Sauvegardes et rollback
Duplication thème, archives, plan de retour arrière.
- 08
Reporting et réversibilité
Comptes rendus, documentation, sortie de contrat.
Ensuite, si le chantier touche aussi une app privée ou un choix de thème, enchaînez sur app Shopify sur mesure et thème existant ou sur mesure.
FAQ : maintenance Shopify TMA et forfaits
Qu’est-ce que la maintenance Shopify TMA ? C’est la tierce maintenance applicative de ce qui vous appartient sur la boutique (thème, apps, intégrations, évolutions légères), distincte du support plateforme Shopify. Un forfait formalise le volume, les priorités et les règles d’intervention.
Que doit couvrir un contrat de maintenance boutique Shopify ? Au minimum : correctifs de production, processus de mise à jour thème / apps quand applicable, veille des changements d’API qui touchent vos connecteurs, un canal de tickets, et une règle claire sur l’évolutif. Le reste (refonte, nouveau middleware, migration de thème) doit être exclu ou devisé.
Comment séparer maintenance corrective et évolutive ? Le correctif rétablit un comportement attendu. L’évolutif change un comportement voulu. Sans niveaux de criticité et sans file partagée, l’évolutif marketing mange le correctif.
Faut-il un SLA avec des délais fixes ? Il faut des engagements mesurables (prise en charge, criticités, horaires), adaptés à votre ensemble technique. Méfiez-vous des délais « standards » copiés-collés sans diagnostic de reprise ni exclusions écrites.
Qui doit suivre le changelog et les dépréciations d’API ? Le prestataire TMA si vous avez des apps custom ou un middleware, en lien avec vos équipes. Shopify publie un calendrier trimestriel de versions et des annonces de dépréciation ; encore faut-il quelqu’un d’assigné pour les lire et planifier les upgrades.
Comment Lighthouse intervient-il ? Sur le diagnostic de reprise, la priorisation correctif / évolutif, les mises à jour de thème et d’apps, le suivi des points de vigilance et les évolutions retenues, depuis Paris. Détails sur Maintenance et évolutions Shopify.



