App Shopify sur mesure ou app publique : quand construire, quand installer, quand étendre

Tout marchand Shopify passé une certaine taille se heurte au même mur. L'App Store offre 8 000 options. Aucune ne fait exactement ce dont l'entreprise a besoin. Il y a toujours une app à 79 $ par mois qui fait 80 pour cent du travail, et les 20 pour cent restants sont la part dont l'entreprise se soucie vraiment. La question devient : installer l'app publique et vivre avec l'écart, installer trois apps et les empiler, construire une app sur mesure depuis zéro, ou étendre une app existante par du développement custom. La mauvaise réponse peut coûter six chiffres et un an. La bonne est généralement évidente quand on pose la question correctement.

Cet article est le cadre build-vs-buy que nous appliquons chez Sentinu pour chaque client Shopify Plus qui cadre sa stratégie d'app. C'est aussi l'article qui aurait dû exister avant la moitié de nos missions d'app sur mesure, parce que les marchands qui sont arrivés après un an passé sur le mauvais chemin sont arrivés plus pauvres et plus en colère que ceux qui ont eu l'architecture correcte dès le départ.

Le vocabulaire qui embrouille tout le monde

Shopify a renommé et déprécié des catégories d'apps en 2022, et les anciens termes apparaissent encore sur des pages de vendeurs et des réponses Stack Overflow, donc commençons par poser le vocabulaire.

App publique. Listée dans le Shopify App Store. Disponible pour tous les marchands. Construite sur le flux OAuth. Tarification par abonnement définie par le développeur. C'est la catégorie qui inclut Recharge, Loox, et la majorité du catalogue.

App sur mesure (custom app). Construite pour un seul marchand (ou un petit groupe connu du développeur). Non listée dans l'App Store. Installée via un lien direct depuis le Shopify Partner Dashboard, ou créée directement dans l'admin du marchand sous Apps et canaux de vente. C'est ce qui s'appelait "private app" avant la dépréciation de janvier 2022.

Private app. Dépréciée. Si vous lisez du contenu sur les apps Shopify écrit avant 2022 qui utilise "private app", remplacez mentalement par "custom app". Les anciennes private apps ont été migrées automatiquement vers les custom apps en 2023.

Theme app extension. Un bloc de code qui s'injecte dans un thème Shopify via les App Embeds. Utilisé par les apps qui doivent afficher de l'UI sur le storefront (widgets d'avis, popups, sélecteurs de devise). Soumis à des limites de taille (100 Ko par défaut).

Shopify Functions. Une catégorie spécifique de logique custom qui tourne à l'intérieur du checkout et du panier Shopify (cart transform, discount, delivery customization, payment customization, fulfillment constraints). Déployée comme des modules WebAssembly. Disponible sur tous les plans pour certains types de Functions, Plus uniquement pour d'autres.

L'arbre de décision ci-dessous suppose que vous comprenez ces distinctions. La mauvaise question de terminologie, c'est "publique ou privée". La bonne, c'est "la réponse est-elle Functions, une app publique existante, un empilement d'apps, une app étendue, ou une app custom depuis zéro ?"

Les cinq chemins et quand chacun est correct

Chemin 1 : installer une app publique et accepter l'écart

Le défaut. Le moins cher en cash, le plus rapide en temps. La bonne réponse pour la plupart des boutiques, la plupart du temps, pour la plupart des besoins.

À utiliser quand :

• Le besoin est suffisamment générique pour qu'une bonne app publique couvre 80 pour cent ou plus
• Les 20 pour cent d'écart sont une gêne, pas du chiffre d'affaires
• Votre équipe n'est pas technique et ne peut pas maintenir du code custom
• Vous prévoyez que le besoin change dans 12 mois (le code custom devient legacy vite)

À arrêter quand :

• La mensualité de l'app commence à paraître significative face à la valeur qu'elle délivre
• Les 20 pour cent d'écart sont la part qui pilote le chiffre d'affaires (logique de bundle custom, flux B2B spécifiques, intégration ERP)
• Vous avez installé deux apps concurrentes parce qu'aucune ne couvre le cas seule
• Vous payez pour des fonctionnalités que vous n'utilisez pas parce que le tier tarifaire les impose

Chemin 2 : empiler plusieurs apps publiques

Le chemin sur lequel la majorité des boutiques se retrouvent sans en avoir eu l'intention. Loox pour les avis plus une app de prix custom plus une app de portail wholesale plus une app de règles de livraison.

À utiliser quand :

• Chaque app gère un sujet distinct et non chevauchant
• Les apps n'ont pas besoin de partager d'état ou de se déclencher entre elles
• Le coût mensuel total est sous 1 500 $ et n'augmente pas

À arrêter quand :

• La facture mensuelle d'apps dépasse 2 000 à 3 000 $ et grimpe
• Vous avez besoin de workflows inter-apps qu'aucune ne coordonne
• Deux apps doivent connaître le même état client sans se synchroniser
• La boutique est réellement lente à cause du JavaScript injecté par les apps (nous avons couvert ça dans notre audit Core Web Vitals)

Une facture mensuelle d'apps de 1 500 $, c'est 18 000 $ par an. Une app custom qui remplace les trois plus chères peut être construite et amortie en 12 à 18 mois, et vous possédez la logique.

Chemin 3 : étendre une app publique par du code custom

Un chemin moins reconnu. Certaines apps exposent des webhooks, des APIs et des theme app extensions qui permettent de construire au-dessus d'elles plutôt que contre elles. Recharge a des webhooks pour chaque événement d'abonnement. Le code custom qui écoute ces événements et fait du travail supplémentaire est souvent moins cher que remplacer l'app.

À utiliser quand :

• La fonctionnalité de base de l'app publique est solide mais il manque un comportement spécifique
• Ce comportement peut être déclenché par un événement émis par l'app (commande, abonnement, client)
• La logique custom vit dans votre infrastructure, l'app continue son travail

À arrêter quand :

• Vous vous retrouvez à reconstruire la majorité de la logique de l'app à l'extérieur
• Les limites de taux d'API de l'app étouffent votre workflow custom
• Le vendeur change son API et votre extension casse (un vrai risque sur les apps moins chères)

Chemin 4 : Shopify Functions

Le chemin le plus récent, et le plus sous-utilisé. Les Functions Shopify permettent d'injecter de la logique custom à des points d'extension précis dans le checkout, le panier et le fulfillment, déployée en WebAssembly. Elles tournent dans le runtime de Shopify, pas le vôtre.

À utiliser quand :

• La logique custom affecte le pricing, les remises, la livraison ou le paiement
• Vous avez besoin que la logique tourne dans le checkout (pas juste sur le storefront)
• Le comportement est étroit et bien défini (une Function fait une chose)
• Vous voulez que la surface de déploiement soit un artefact unique, pas une app hébergée

Exemples qui rentrent naturellement dans une Function :

• Pricing B2B par volume qui dépend du tier de l'entreprise du client
• Une promotion "achetez X obtenez Y" que le système de remises publiques ne peut pas modéliser
• Calcul de tarif de livraison qui tire depuis un service custom
• Restriction de méthode de paiement selon le contenu de la commande

À arrêter quand :

• La logique a besoin d'afficher de l'UI (les Functions sont sans UI ; pour l'UI utilisez une theme app extension ou une app custom)
• La logique a besoin d'état persistant entre sessions (les Functions sont sans état ; l'état vit dans les metafields ou votre backend)
• La logique est trop large pour une seule Function (plusieurs Functions peuvent s'empiler mais l'architecture devient fragile)

Nous couvrirons les Functions en profondeur dans notre prochain article ; cet article les traite comme un chemin parmi cinq, pas comme le focus central.

Chemin 5 : construire une app sur mesure depuis zéro

Le chemin qui devrait être le dernier recours et qui est souvent le premier. Une app custom, c'est votre code, votre hébergement, votre maintenance, votre responsabilité. Bien faite, c'est aussi votre avantage compétitif et votre plus grosse économie.

À utiliser quand :

• La fonctionnalité est sincèrement unique à votre business (aucune app publique ne le fait, aucune Function ne rentre)
• La boutique est suffisamment grosse pour amortir le coût (typiquement 10 M+ de GMV annuel)
• Vous avez une équipe d'ingénierie ou un partenaire pour maintenir
• La logique est au cœur de vos opérations, pas une fonctionnalité périphérique

Exemples qui justifient une app custom :

• Intégration ERP profonde avec NetSuite ou SAP et mapping de champs custom (nous couvrons ça dans l'article Shopify + NetSuite de la semaine prochaine)
• Un workflow d'approbation B2B avec routage multi-étapes
• Logique de catalogue custom où produits et prix viennent d'un moteur de pricing externe
• Conformité sectorielle (pharma, produits régulés) qu'aucune app publique ne gère

À arrêter quand :

• Vous construisez parce qu'une app publique vous agace, pas parce qu'elle ne peut pas faire le travail
• La fonctionnalité est suffisamment générique pour qu'une app publique apparaisse dans 6 mois
• Vous n'avez pas de plan de maintenance clair pour les 3 prochaines années

Le cadre de décision

Pour toute question "construire ou acheter" sur Shopify, nous notons quatre axes de 0 à 3 :

1. Unicité : cette logique est-elle spécifique à notre business (3), partiellement partagée avec notre segment (1), totalement générique (0) ?
2. Dépendance au chiffre d'affaires : cela pilote-t-il directement le CA (3), soutient indirectement le CA (1), opérationnel uniquement (0) ?
3. Échelle d'utilisation : la boutique fait-elle 10 M+ de GMV annuel (3), 1 M à 10 M (1), sous 1 M (0) ?
4. Capacité de maintenance : avons-nous une équipe dev pour 3 ans (3), un partenaire agence (1), aucun plan (0) ?

Score 0 à 3 : installez une app publique. Le chemin custom ne se rentabilisera pas. Même si l'app publique est imparfaite, le coût de construire est matériellement pire.

Score 4 à 6 : empilez des apps publiques ou étendez-en une. Le chemin custom est démesuré pour l'échelle.

Score 7 à 9 : Shopify Functions ou extension par code custom. La fonctionnalité est suffisamment étroite pour qu'une app custom complète soit excessive.

Score 10 à 12 : construisez une app custom. L'investissement se rentabilisera et vous avez la capacité de maintenir.

C'est une heuristique, pas un verdict. Nous avons livré des apps custom pour des clients scorant 8 parce qu'ils avaient des raisons d'architecture spécifiques (souveraineté de données, couplage ERP) que le cadre ne capture pas.

Le calcul de coût que personne ne publie

La question la plus dure à répondre pour les marchands qui évaluent le chemin custom, c'est "ça coûte vraiment combien ?" La fourchette honnête :

Le chiffre de maintenance est ce que la plupart des discussions de coût ratent. Une app custom a besoin de mises à niveau de version d'API deux fois par an (Shopify déprécie les versions plus anciennes sur un calendrier connu), de patches de sécurité, de mises à jour de dépendances, et du débogage occasionnel quand Shopify change un comportement. Sauter le budget de maintenance, c'est comme ça que les apps custom deviennent non maintenables en 18 mois.

Comparé au chemin d'abonnement public : une app à 200 $ par mois, c'est 7 200 $ sur trois ans. Une pile d'apps à 1 500 $ par mois, c'est 54 000 $ sur trois ans. Un build custom à 40 K$ avec 5 K$ de maintenance annuelle, c'est 55 K$ sur trois ans. Le point où le custom devient moins cher que l'abonnement, c'est autour du repère 1 500 $/mois en pile d'apps, à condition d'avoir la capacité de maintenance. En dessous, la pile d'apps publiques est presque toujours meilleure économiquement.

La question "sans abonnement mensuel"

Une partie des marchands viennent chez nous spécifiquement parce qu'ils veulent échapper aux abonnements d'apps récurrents. C'est une vraie motivation, pas toujours une bonne.

L'arithmétique à faire honnêtement : coût annuel total des abonnements d'apps que vous remplaceriez, moins coût annuel de maintenance de la version custom, égal économies annuelles. Divisez le coût du build custom par les économies annuelles pour obtenir la période de retour. Un retour sous 18 mois, c'est un oui clair. Un retour entre 18 et 36 mois, c'est un peut-être (dépend si les apps sont vraiment adaptées). Un retour au-delà de 36 mois, c'est presque toujours non.

Ce que ce calcul rate, et qui justifie souvent le build malgré tout :

• L'app custom fait le travail mieux, ce qui fait monter le chiffre d'affaires
• L'app custom retire le bloat JavaScript que les apps publiques injectent, ce qui améliore les Core Web Vitals et l'efficacité des dépenses pub
• Le marchand possède la donnée au lieu de la router via un tiers
• L'app custom gère le cas particulier qui coûtait du temps d'opérations manuel

Ce sont de vrais moteurs de valeur mais difficiles à quantifier à l'avance. Nous cadrons typiquement les builds custom contre les économies cash d'abord, puis nous traitons les bénéfices secondaires comme un upside.

Ce que nous livrons chez Sentinu

Patterns issus de missions d'app récentes :

• Un catalogue B2B français de pièces sur Shopify Plus, app custom pour le contrôle d'accès SKU par entreprise, une seule Shopify Function pour le pricing B2B par volume, portail acheteur basé sur Hydrogen. L'app custom gère ce qu'aucune app publique ne pouvait (logique d'accès par tier d'entreprise), la Function gère la règle de prix, le portail étend l'expérience B2B native. Trois outils, une architecture.
• Une marque D2C britannique qui remplace une pile de six apps (1 800 $ par mois) par un workflow n8n custom plus une app custom unique pour le routage de commandes. Retour sur 14 mois, amélioration Core Web Vitals de 30 pour cent en effet de bord du retrait du JavaScript injecté.
• Un fournisseur industriel canadien dont le premier réflexe était "tout construire custom" et que nous avons poussé vers NetSuite Connector plus deux Shopify Functions. Même résultat opérationnel, 70 pour cent moins cher, plus rapide à livrer.

Le pattern à travers tout ça : nous disons "oui, construisons custom" moins souvent que les clients ne s'y attendent, et "utilisez la bonne combinaison de publique, Function et custom" plus souvent. La bonne réponse est généralement une pile, pas un seul outil.

FAQ

Puis-je passer d'une app publique à une app custom sans perdre de données ?

Dans la plupart des cas, oui. Le chemin de migration dépend de l'app. Les apps qui stockent la donnée dans vos metafields Shopify (les bonnes) gardent leur donnée accessible après désinstallation. Les apps qui stockent uniquement dans leur backend (les mauvaises) perdent la donnée à la résiliation. Auditez la propriété des données avant de vous engager sur une app publique pour toute logique qui compte.

Combien de temps prend la construction d'une app Shopify custom ?

Une app custom focalisée mono-fonctionnalité (un workflow, une intégration, pas d'UI) se livre en 4 à 6 semaines. Une app custom de complexité moyenne avec UI admin, plusieurs flux de données et un composant storefront se livre en 10 à 16 semaines. Les builds enterprise avec intégration ERP et logique multi-régions tournent entre 4 et 6 mois. La variabilité est dans le périmètre, pas dans la plateforme.

Mon app custom doit-elle être dans le Shopify App Store ?

Non, et généralement non. Si l'app est pour un seul marchand, la distribution custom via lien d'installation direct est correcte. La soumission App Store n'est pertinente que si vous voulez vendre l'app à d'autres marchands, ce qui est une décision business séparée (produitiser ce qui a été construit sur mesure).

Et embaucher un freelance pour construire l'app custom ?

Possible mais risqué. Un freelance peut construire une app Shopify custom. Le risque, c'est la fenêtre de maintenance sur 3 ans. Si le freelance devient indisponible, l'app accumule de la dette technique, la version d'API Shopify déprécie, et le marchand est coincé. Soit choisissez un freelance avec un historique documenté et un contrat de maintenance écrit, soit utilisez une agence avec capacité de succession.

Comment les Shopify Functions affectent-elles cette décision ?

Elles baissent la barre vers "logique custom sans app complète". Beaucoup de choses qui demandaient une app custom en 2022 sont une Function en 2026. Si la logique custom rentre dans un point d'extension Function (remise, transformation panier, customization livraison, customization paiement), atteignez la Function en premier. Les apps custom restent justes pour tout le reste, et nous couvrons la décision Functions en détail dans notre article Shopify Functions.

Shopify va-t-il déprécier les apps custom comme il a déprécié les private apps ?

La dépréciation des "private apps" était un mouvement de sécurité (le modèle de token API était faible) et a migré tout le monde vers une meilleure fondation (OAuth, accès scopé). La catégorie custom app est désormais stable. Le risque plus gros, c'est la dépréciation de version d'API, qui affecte toutes les apps (custom et publiques) sur un cycle de 12 mois. Planifiez-le comme un coût de maintenance, pas un événement unique.

Shopify Plus change-t-il le calcul ?

Les boutiques Plus ont plus d'options (Shopify Functions custom sur tous les points d'extension, accès complet à la Storefront et Admin API, support dédié). Ça ne change pas le cadre build-vs-buy, mais ça élargit l'éventail de choses faisables sans quitter la plateforme. Pour les boutiques Plus, le seuil pour "construire custom" est plus élevé parce que plus est atteignable avec les fonctionnalités natives.

Pour aller plus loin

Si vous évaluez la construction d'une app Shopify custom et que le cadre ci-dessus vous a pointé vers le chemin custom, c'est là que notre pratique développement d'application Shopify prend le relais. Nous cadrons, architecturons et livrons des apps custom là où le calcul le supporte, et nous repoussons quand le calcul dit le contraire. Si le projet implique aussi l'intégration API avec un ERP ou un CRM, nos services d'intégration API sont le complément. Et si vous pesez le chemin app custom contre les Shopify Functions pour le même problème métier, le prochain article de cette série déroule la décision spécifique aux Functions en profondeur.