Shopify Functions : quand y avoir recours, quand rester dans les apps, quand passer au headless

Trois ans après le lancement des Shopify Functions, la plupart des développeurs avec qui nous parlons les décrivent encore comme "ce truc pour les remises custom". Il est vrai que les remises custom sont ce que les Functions livrent le plus souvent, et il est aussi vrai que ça passe à côté de la vue d'ensemble : les Functions sont le chemin le moins cher vers une logique commerce custom que Shopify ait jamais offert, et les marchands qui comprennent l'éventail complet des points d'extension livrent des avantages compétitifs que les apps custom imposaient autrefois.

Cet article est la vue d'ingénieur plus profonde des Shopify Functions en 2026. C'est l'article qui doit accompagner notre cadre de décision app custom vs publique plus tôt ce mois-ci, parce que les Functions sont souvent la bonne réponse à un problème que les apps custom revendiquaient. Il adresse aussi la question qui revient sur chaque mission Plus : comment les Functions s'intègrent-elles à un storefront headless, où le front-end tourne en dehors du runtime Shopify mais où le checkout dépend toujours de la logique Shopify.

Ce que sont réellement les Shopify Functions

Les Functions sont des morceaux de logique custom, écrits en Rust, JavaScript ou TypeScript, compilés en WebAssembly, et déployés dans le runtime de Shopify. Elles tournent de façon synchrone à des points d'extension précis dans le panier et le checkout, avec des budgets d'exécution stricts et un contrat entrée-sortie déterministe. Ce ne sont pas des webhooks. Ce n'est pas du code côté serveur que vous hébergez vous-même. Ce ne sont pas des theme extensions. C'est de la logique native à la plateforme qui devient partie intégrante de la façon dont Shopify traite le commerce.

L'importance architecturale de cette distinction : une Function tourne avec la commande, pas après. Une Function cart transform modifie ce que le client voit dans le panier en temps réel. Une Function discount s'applique avant que les totaux ne s'affichent. Une Function delivery détermine quels tarifs de livraison sont montrés. Ce ne sont pas des réactions asynchrones à des événements ; ce sont des décisions synchrones à l'intérieur du flux commerce de Shopify.

Les implications pour la stratégie d'app :

• La logique qui demandait autrefois une app avec un serveur hébergé (avec le coût de l'hébergement, la surface de sécurité des tokens OAuth, la charge de maintenance d'un service déployé à l'extérieur) peut maintenant tourner comme quelques centaines de lignes de Rust que vous déployez et oubliez
• La logique qui demandait autrefois des contournements non supportés (code de thème qui se bat avec Shopify, JavaScript injecté dans le checkout, modification manuelle de commande via l'admin) a maintenant un chemin supporté, documenté et performant
• Pour les storefronts headless où vous faites déjà tourner votre propre infrastructure frontend, les Functions vous permettent de garder toute la logique de checkout sur Shopify plutôt que de livrer un checkout parallèle

Les cinq points d'extension

En 2026, les Functions sont livrées sur cinq types d'extension principaux. Chacun résout un problème différent et chacun a ses propres contraintes.

Product discount et order discount

La catégorie originale de Function, toujours la plus utilisée. Remplace le système de remise automatique de Shopify pour toute logique que le moteur de remise natif ne peut pas modéliser.

Ce qu'elle peut faire : remises conditionnelles selon le contenu du panier, les attributs client ou les metafields. Pricing par tier où la remise change selon les fourchettes de quantité. Logique "achetez X obtenez Y" custom où la variante native du système ne peut pas capturer la règle. Remises par tier client qui lisent un metafield sur le client (statut de fidélité, tier B2B, prix contractuel).

Ce qu'elle ne peut pas faire : calculer depuis des données hors Shopify (pas d'appel HTTP pendant l'exécution). Maintenir un état entre les mises à jour de panier. Appliquer des remises déclenchées manuellement (les remises Function sont automatiques par définition).

Quand elle gagne face à une app : quand la logique de remise est basée sur des règles et déterministe depuis l'état du panier. Une règle "achetez deux de la catégorie A, obtenez un de la catégorie B gratuit" que Shopify natif ne peut pas modéliser est une Function. Une remise par tier basée sur les metafields client est une Function.

Quand une app gagne : quand la logique de remise demande de la donnée externe en temps réel (prix concurrent live, surge pricing dynamique). Quand le marchand a besoin d'une UI pour que du personnel non technique gère les règles de remise (les Functions se livrent par déploiement de code ; les règles gérées par le marchand demandent une app avec un dashboard).

Delivery customization

Modifie les options de livraison que le client voit au checkout. Cacher, renommer, trier ou modifier les méthodes de livraison selon le contenu du panier, les attributs client ou la valeur de la commande.

Ce qu'elle peut faire : cacher la livraison express pour les commandes contenant des articles encombrants. Trier les options de livraison par prix croissant ou par date de livraison. Renommer les options de livraison selon le pays de destination. Appliquer des seuils de livraison offerte avec une logique non triviale (livraison offerte uniquement sur certaines catégories de produits au-dessus d'un certain montant).

Ce qu'elle ne peut pas faire : ajouter de nouveaux tarifs de livraison qui n'existent pas comme tarifs calculés par transporteur ou configurés manuellement. Modifier les valeurs de tarif réelles (un type de Function séparé, "delivery method customization", est en cours chez Shopify mais limité). Appeler des APIs de livraison externes pendant l'exécution.

Quand elle gagne : quand la logique est "montrer ou cacher des tarifs existants selon l'état du panier". Remplace une catégorie d'apps qui faisaient exactement ça par injection fragile de scripts checkout.

Quand une app gagne : quand vous avez besoin de tarifs calculés par transporteur depuis un transporteur non supporté, ce qui demande encore une app intégrée à la Shopify Carrier Service API.

Payment customization

Modifie les méthodes de paiement que le client voit au checkout. Cacher, renommer, trier ou modifier les options de paiement selon le contenu du panier.

Ce qu'elle peut faire : cacher le paiement par carte pour les commandes au-dessus d'une certaine valeur (forcer le virement pour les commandes B2B à forte valeur). Cacher les options buy-now-pay-later pour les catégories de produits restreintes. Renommer les options de paiement pour les comptes B2B. Trier les méthodes de paiement pour faire remonter l'option à plus forte marge en premier.

Ce qu'elle ne peut pas faire : ajouter de nouvelles méthodes de paiement (les intégrations de passerelle de paiement sont encore des apps). Refuser les commandes selon la méthode de paiement (utilisez une Function cart transform pour faire ça plus tôt).

Quand elle gagne : quand la logique est "montrer ou cacher des options de paiement existantes". Les boutiques B2B utilisent ça régulièrement pour imposer les conditions de paiement selon le tier client ou la valeur de la commande.

Quand une app gagne : quand vous avez besoin de nouvelles intégrations de méthode de paiement ou de détection de fraude complexe qui demande de la donnée externe.

Cart transform

Le type de Function le plus puissant et le plus complexe. Modifie le contenu du panier lui-même avant que les remises et totaux ne soient calculés. Remplace une catégorie de travail qui demandait auparavant soit des apps custom avec mutations cart API soit du JavaScript fragile qui se battait avec le panier natif Shopify.

Ce qu'elle peut faire : regrouper des produits en une ligne unique virtuelle (un bundle qui apparaît comme une ligne à un prix mais contient plusieurs SKU pour l'inventaire et le fulfillment). Étendre une ligne unique en plusieurs lignes (l'inverse : un bundle "kit de démarrage" qui se décompose en ses composants à l'ajout au panier). Ajouter des cadeaux gratuits selon le contenu du panier (le pattern "achetez ceci, obtenez X gratuit", mais comme de vraies lignes de panier plutôt qu'une remise). Mettre à jour les propriétés des lignes selon une logique au niveau panier.

Ce qu'elle ne peut pas faire : lire de la donnée externe pendant l'exécution. Opérer entre plusieurs paniers (chaque appel de Function ne voit que le panier actuel). Modifier le client ou l'adresse de livraison.

Quand elle gagne : logique de bundle que le type de produit bundle natif ne peut pas modéliser. Logique de cadeau gratuit qui doit apparaître comme de vraies lignes plutôt que des remises. Toute manipulation de panier qui demandait auparavant des mutations cart API depuis une app hébergée.

Quand une app gagne : quand la composition du bundle doit venir d'un système externe (un configurateur qui construit des kits custom selon l'input utilisateur pas dans Shopify). Quand la logique demande de l'UI pour que le client interagisse en cours de panier.

Fulfillment constraints

La catégorie de Function la plus récente. Applique des règles sur ce qui peut être expédié ensemble selon la location d'inventaire, les attributs produit ou la configuration de commande.

Ce qu'elle peut faire : empêcher les articles fragiles et lourds d'être expédiés dans le même colis. Router le fulfillment vers l'entrepôt le plus proche selon l'adresse de livraison. Bloquer les commandes qui ne peuvent pas être fulfillées depuis une seule location.

Ce qu'elle ne peut pas faire : appeler un WMS pendant l'exécution. Surcharger les décisions de livraison du transporteur.

Quand elle gagne : quand la logique de fulfillment est basée sur des règles et déterministe depuis l'état de la commande.

Quand une app gagne : quand la logique demande de la donnée d'inventaire en temps réel depuis une source non-Shopify ou un routage complexe qui demande un moteur d'optimisation externe.

La décision Function vs app vs headless

Le cadre pour choisir entre ces trois chemins pour un problème donné de logique commerce :

1. La logique peut-elle être exprimée comme des règles déterministes sur de la donnée connue de Shopify ? Si oui, Function. Si non, envisagez app ou intégration externe.
2. La logique doit-elle tourner à l'intérieur du checkout (où les décisions client se prennent) ? Si oui, Function. Si la logique peut tourner avant ou après (dans un workflow séparé), envisagez une app ou une automatisation externe comme n8n.
3. La logique demande-t-elle une UI pour que le personnel marchand la configure ? Si oui, il vous faut une app avec des pages admin (une Function seule n'a pas d'UI admin ; le marchand la configure via metafields, ce qui est acceptable pour des équipes techniques et inacceptable pour des opérationnels non techniques).
4. La logique doit-elle lire de la donnée externe en temps réel ? Si oui, il vous faut une app avec backend hébergé. Les Functions n'ont pas d'accès réseau pendant l'exécution.
5. Le storefront est-il headless ? Les Functions s'appliquent toujours ; elles tournent dans le checkout Shopify quel que soit l'endroit où le storefront est hébergé. Un front-end headless Hydrogen ou Next.js plus des Functions pour la logique de checkout est une architecture cohérente, souvent plus que headless plus logique de checkout custom.

Le cadre réduit dramatiquement la question "quel outil". La bonne réponse est souvent "Function pour le moteur de règles, app pour l'UI marchand, storefront headless pour la présentation client, et ils coexistent tous".

Une architecture réelle : B2B avec Functions, app et Hydrogen

Pour illustrer comment les pièces s'imbriquent, l'architecture d'un client Shopify Plus B2B récent chez Sentinu :

Trois Functions gèrent la logique commerce au checkout. Une app custom gère l'administration côté marchand (parce que les commerciaux doivent mettre à jour les assignations de tier B2B sans implication d'ingénierie). Un storefront Hydrogen gère l'UX côté client avec un design de marque et la navigation du catalogue B2B.

Chaque pièce fait ce qu'elle fait le mieux. Functions pour de la logique rapide, déterministe, en-checkout. App pour l'UI admin dont les non-développeurs ont besoin. Headless pour la présentation client qui demandait un design spécifique de marque.

Nous avons couvert l'architecture de portail B2B en détail dans notre article Shopify Plus B2B ; voici la même architecture avec la couche Function rendue explicite.

Combien coûte une Function à livrer

Fourchettes de coûts honnêtes pour les missions de développement de Function :

La variance est dans le modèle de données en entrée et la surface de test. Les Functions sont sans état et bien typées, ce qui rend le code lui-même rapide à écrire. Le travail est dans la définition du schéma de metafield, le test des cas particuliers, et la vérification que la Function ne régresse pas sur les commandes existantes.

La maintenance continue est minime comparée aux apps. Une Function n'a pas de backend hébergé à maintenir, pas de rotation de clé d'API, pas d'outages serveur. La préoccupation de maintenance principale est la version d'API Shopify que la Function cible, qui se déprécie sur le même cycle de 12 mois que le reste de la plateforme Shopify.

Quand vous ne devez pas utiliser les Functions

Les contre-exemples honnêtes. Les Functions ne sont pas la bonne réponse à chaque problème commerce.

Quand vous avez besoin d'une UI marchand. Les Functions n'ont pas d'interface admin. Le marchand les configure par metafields, ce qui est acceptable quand le marchand est développeur ou travaille avec une agence dédiée mais inacceptable quand le marchand veut changer une règle de remise depuis l'admin Shopify sans déposer de ticket. Pour de la logique configurable par le marchand, vous construisez une app admin au-dessus de la Function (le pattern d'architecture de l'exemple B2B ci-dessus).

Quand la logique demande de la donnée externe en temps réel. Les Functions n'ont pas d'accès réseau pendant l'exécution. Si votre règle de remise doit appeler une API de prix concurrent en temps réel, vous ne pouvez pas utiliser une Function seule. Soit vous pré-calculez la donnée et la stockez dans des metafields que la Function lit (bon pour de la donnée rafraîchie quotidiennement), soit vous utilisez une app avec backend hébergé (bon pour du vrai temps réel).

Quand vous avez besoin d'une configuration gérée par marchand à haute fréquence. Un déploiement de Function est un déploiement de code. Un marchand qui veut changer une règle quotidiennement ne doit pas déployer des Functions quotidiennement. La même Function plus une configuration pilotée par metafield résout ça, mais ça veut dire du travail de design pour définir le schéma de configuration.

Quand le marchand a zéro capacité d'ingénierie. Les Functions sont du code. Quelqu'un doit les écrire, les tester et les maintenir. Pour un marchand dont l'équipe est entièrement non technique, le chemin App Store reste correct parce que le coût de maintenance est le problème du vendeur d'app, pas du marchand.

Ce que nous livrons chez Sentinu

Des missions récentes sur les Functions illustrent l'éventail :

• Une marque D2C française avec des promotions saisonnières "achetez 3 dans cette collection, le moins cher est offert" que le moteur de remise natif ne pouvait pas modéliser proprement. Une Function cart transform plus une Function product discount, déployées une fois, configurées via metafields sur les collections, tournent depuis 18 mois sans modification.
• Un distributeur de pièces B2B britannique avec un pricing par tier qui dépendait des conditions contractuelles client stockées dans metafields. Trois Functions (product discount, order discount, delivery customization) ont remplacé un abonnement d'app à 400 $/mois qui peinait sur la logique de tier spécifique du marchand. Retour sur 5 mois.
• Un marchand canadien avec contraintes de fulfillment dont les produits avaient des incompatibilités d'expédition spécifiques (produits chimiques qui ne pouvaient pas voyager par air, articles fragiles qui demandaient des colis dédiés). Deux Functions de fulfillment constraint plus une petite app admin pour que l'équipe opérations gère les règles. A remplacé un processus manuel de revue de commande qui attrapait les erreurs après expédition.

Le pattern : les Functions sont la réponse quand la logique est basée sur des règles, déterministe et vit au checkout. Elles ne sont pas la réponse quand la logique demande de l'UI, de la donnée externe ou de la flexibilité opérationnelle que seule une app fournit. L'architecture est généralement un mélange des deux, et la discipline c'est de savoir quelle part va où.

FAQ

Les Shopify Functions sont-elles Plus uniquement ?

Non, pas entièrement. Les Functions de remise et de delivery customization sont disponibles sur tous les plans. Les Functions de payment customization et cart transform sont Plus uniquement. Les Functions de fulfillment constraint sont Plus uniquement. Pour les boutiques non Plus, les catégories de Function disponibles couvrent les cas d'usage les plus courants.

Dans quel langage dois-je écrire les Functions ?

Rust est le langage principal officiel et le plus supporté dans la documentation. TypeScript et JavaScript sont aussi supportés et se livrent vers la même cible WebAssembly. Pour la majorité des équipes, JavaScript ou TypeScript est le bon choix parce que le vivier de recrutement est plus large et que les exemples du SDK Shopify les couvrent bien. Rust est le meilleur choix pour les équipes qui utilisent déjà Rust ailleurs ou pour les Functions qui ont besoin de performance maximale.

Comment les Functions interagissent-elles avec Shopify Flow ?

Flow est asynchrone ; les Functions sont synchrones. Flow tourne après que les événements se produisent (commande passée, client créé) ; les Functions tournent pendant l'événement (panier mis à jour, checkout consulté). Ils se complètent. Une Function peut appliquer une remise pendant le checkout ; un Flow peut envoyer au client un email de remerciement après que la commande se termine. Nous avons couvert Flow indirectement dans notre comparaison automation workflow, où les mêmes principes opérationnels s'appliquent.

Puis-je tester les Functions en local avant de déployer ?

Oui. Shopify livre une CLI qui fait tourner les Functions contre des inputs d'exemple en local. La boucle de développement est similaire à l'écriture de fonctions serverless dans d'autres écosystèmes : écrire, tester contre des fixtures, déployer, vérifier dans une boutique de développement. Le développement de Functions qualité production à notre échelle utilise du CI/CD qui fait tourner la Function contre une batterie de cas de test avant déploiement.

Quel est le budget de temps d'exécution d'une Function ?

Strict. Les Functions doivent se terminer dans un petit nombre de millisecondes (le nombre exact varie selon le type de Function mais reste généralement sous les 50 ms). Les Functions qui dépassent le budget sont tuées et le checkout du marchand continue sans la logique de la Function, ce qui est souvent une expérience pire que ce que le marchand a designé. C'est pour ça que les Functions ne peuvent pas faire d'appels réseau ; le budget de latence serait dépassé par toute dépendance externe.

Les Functions sont-elles versionnées ?

Oui. Chaque déploiement de Function crée une nouvelle version. Les versions plus anciennes restent associées à leur date de déploiement et on peut y revenir. C'est l'un des avantages opérationnels face aux apps, où revenir à une version précédente demande souvent de coordonner avec le vendeur d'app.

Les Shopify Functions vont-elles remplacer Shopify Flow ?

Non. Ils résolvent des problèmes différents. Flow est l'outil de workflow asynchrone pour l'automatisation post-événement. Les Functions sont les points d'extension synchrones à l'intérieur du flux commerce de Shopify. Une boutique Shopify Plus moderne utilise typiquement les deux.

Pour aller plus loin

Si vous cadrez un problème de logique commerce et que les Functions semblent être le bon chemin mais que vous voulez une validation contre la forme spécifique de votre business, c'est ce que couvre notre pratique développement d'application Shopify. Nous avons livré des Functions, des apps custom et des storefronts headless dans chaque combinaison, et nous vous dirons honnêtement laquelle convient au problème. Si la question plus large est de savoir si les Functions, les apps custom ou le commerce headless sont l'ajustement architectural correct pour votre boutique, nos articles app custom vs publique et Hydrogen vs Next.js sont les compléments à lire. La bonne architecture pour une boutique Shopify Plus moderne est rarement un seul de ces outils ; c'est la bonne combinaison des trois.