Fin de Shopify Scripts : passez à Shopify Functions avant le 30 juin 2026

Nous sommes le 16 avril 2026. Hier, le 15 avril, Shopify a définitivement verrouillé Script Editor. Vous ne pouvez plus créer ni publier de nouveau Script. Cette échéance touche particulièrement la logique après achat : les changements d’adresse de livraison sont la première modification demandée après achat et représentent 30,2 % de toutes les commandes modifiées (Revize, 2026). Tout Script qui gère encore ces modifications est désormais figé. L’exécution s’arrêtera dans 75 jours, le 30 juin 2026.

Si vous développez pour une boutique Shopify Plus, ou si votre agence en gère une, et que vous avez repoussé cette migration au « prochain sprint » pendant douze mois, le problème est urgent. Le 1er juillet à minuit, votre paiement (checkout) risque de ne plus fonctionner comme prévu. Au fil des années, la plupart des boutiques Plus ont accumulé entre 5 et 20 Scripts. Chacun applique discrètement une règle de réduction, masque un mode d’expédition ou bloque un moyen de paiement, parfois sans que personne ne se souvienne de l’avoir écrit.

Ce guide est le manuel technique de migration que nous aurions aimé avoir en janvier. Il couvre le code, au-delà de la stratégie. Vous apprendrez à créer la structure d’une Function avec Shopify CLI, à écrire sa logique en Rust ou en JavaScript pour les réductions, les personnalisations de livraison et les personnalisations de paiement, à la tester sur un sous-ensemble de clients identifiés par une balise, puis à la mettre en production sans perturber votre paiement actuel.

Passons vos Scripts sur Functions.

Réponse rapide : passer de Scripts à Functions en 60 secondes#

La migration en un paragraphe : Shopify Scripts (du code Ruby dans Script Editor, réservé à Plus) est remplacé par Shopify Functions (des modules WebAssembly écrits en Rust ou en JavaScript, disponibles sur tous les forfaits). Vous créez la structure d’une Function avec shopify app generate extension, écrivez une requête run.graphql pour récupérer les données nécessaires du panier, puis un fichier run.rs ou run.js qui renvoie des opérations (réductions, modes d’expédition masqués, etc.). Vous la déployez ensuite avec shopify app deploy et l’activez dans Shopify Admin ou par une mutation GraphQL. Les Functions s’exécutent sous forme de WASM compilé en moins de 5 ms, fonctionnent sur tous les forfaits et constituent la seule voie de personnalisation que Shopify prendra en charge à l’avenir.

Ce qui change réellement le 30 juin#

Avant de toucher au code, retenez les deux dates. Elles comptent toutes les deux.

La migration est binaire. Si votre Function est déployée avant le 30 juin, votre paiement continue de fonctionner comme prévu. Sinon, chaque panier concerné revient discrètement aux prix et tarifs d’expédition standard, avec tous les moyens de paiement activés. Il n’y a pas de solution intermédiaire. Un Script s’exécute ou non ; après le 30 juin, il ne s’exécutera plus.

Conseil : ouvrez Settings → Checkout → Customizations Report dans Shopify Admin. Ce rapport répertorie chaque Script actif de votre boutique, son rôle et le type de Function recommandé pour le remplacer. Commencez par là.

Functions et Scripts : qu’est-ce qui a changé ?#

Le changement d’architecture est important. Avec Scripts, on ajustait du Ruby dans un champ de texte. Avec Functions, on écrit une véritable application, on suit ses versions, on la teste en local et on la déploie dans un pipeline d’intégration continue. La prise en main demande davantage de travail. Mais Functions représente l’engagement à long terme de Shopify pour la logique du paiement, contrairement à Scripts, qui s’est révélé transitoire.

Associer chaque Script au bon type de Function#

Chaque Script que vous utilisez aujourd’hui correspond à une API de Function précise. Gardez ce tableau à portée de main.

Si vous avez dix Scripts, vous créerez probablement trois à cinq Functions. Plusieurs Scripts peuvent souvent être réunis dans une seule Function avec une logique conditionnelle plus claire.

Prérequis : préparer votre environnement de développement local#

Avant de créer une Function, installez localement les trois outils suivants. Vérifiez-les dans votre terminal.

1. Node.js 18+

node --version
# Must be >= 18.0.0

Si votre version est plus ancienne, installez Node.js avec nvm ou téléchargez-le sur nodejs.org.

2. Shopify CLI 3+

npm install -g @shopify/cli@latest
shopify version
# Should output 3.x or higher

3. La chaîne d’outils Rust (uniquement si vous écrivez vos Functions en Rust)

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rustup target add wasm32-wasip1
cargo --version

Les Functions en JavaScript ne nécessitent pas Rust. Choisissez un langage pour votre équipe et conservez-le : mélanger les deux alourdit la maintenance.

4. Une boutique de développement

Connectez-vous à votre tableau de bord Partner pour créer une boutique de développement, ou utilisez une boutique existante. Vous y déploierez vos Functions avant de les mettre en production.

Créer la structure de votre première Function#

La CLI génère l’essentiel des fichiers de départ. Depuis n’importe quel répertoire :

# Create a new Shopify app (skip if you already have one)
shopify app init my-checkout-functions
cd my-checkout-functions

# Generate a Function extension
shopify app generate extension

La CLI vous guide avec quelques questions. Pour une Function de réduction, choisissez :

• Type : Function
• Modèle : discount (ou cart_checkout_validation, delivery_customization, payment_customization, etc.)
• Langage : Rust ou JavaScript
• Nom : par exemple volume-discount-fn

Elle crée extensions/volume-discount-fn/ avec :

extensions/volume-discount-fn/
├── shopify.extension.toml      # Function config — targets, build, version
├── src/
│   ├── cart_lines_discounts_generate_run.graphql   # Input query
│   └── cart_lines_discounts_generate_run.rs        # Function logic
├── Cargo.toml                  # Rust dependencies (Rust only)
└── README.md

Vous modifierez surtout trois fichiers : .toml (configuration), .graphql (données d’entrée) et .rs / .js (logique). C’est tout.

Tutoriel 1 : remplacer un Line Item Script (réduction sur quantité)#

Supposons que votre ancien Script appliquait 10 % de réduction sur le sous-total de la commande dès que le panier contenait au moins 5 articles d’une collection donnée. Voici l’équivalent avec une Function.

Étape 1.1 : la configuration (shopify.extension.toml)#

api_version = "2026-01"

[[extensions]]
name = "volume-discount-fn"
handle = "volume-discount-fn"
type = "function"

[[extensions.targeting]]
target = "cart.lines.discounts.generate.run"
input_query = "src/cart_lines_discounts_generate_run.graphql"
export = "cart_lines_discounts_generate_run"

[extensions.build]
command = "cargo build --target=wasm32-wasip1 --release"
path = "target/wasm32-wasip1/release/volume-discount-fn.wasm"
watch = ["src/**/*.rs"]

Étape 1.2 : la requête d’entrée (src/cart_lines_discounts_generate_run.graphql)#

query Input {
  cart {
    lines {
      id
      quantity
      cost {
        subtotalAmount {
          amount
        }
      }
      merchandise {
        ... on ProductVariant {
          product {
            inAnyCollection(ids: ["gid://shopify/Collection/123456789"])
          }
        }
      }
    }
  }
  discount {
    discountClasses
  }
}

Conseil : une Function ne voit que les données demandées dans la requête. Limitez les champs GraphQL au nécessaire : chaque champ omis rend l’exécution plus rapide et moins coûteuse.

Étape 1.3 : la logique (src/cart_lines_discounts_generate_run.rs)#

use super::schema;
use shopify_function::prelude::*;
use shopify_function::Result;

#[shopify_function]
fn cart_lines_discounts_generate_run(
    input: schema::cart_lines_discounts_generate_run::Input,
) -> Result<schema::CartLinesDiscountsGenerateRunResult> {
    // Bail if discount class doesn't match
    let has_order_discount = input
        .discount()
        .discount_classes()
        .contains(&schema::DiscountClass::Order);

    if !has_order_discount {
        return Ok(schema::CartLinesDiscountsGenerateRunResult { operations: vec![] });
    }

    // Sum quantities of items in the target collection
    let qualifying_qty: i64 = input
        .cart()
        .lines()
        .iter()
        .filter(|line| {
            if let schema::Merchandise::ProductVariant(v) = line.merchandise() {
                *v.product().in_any_collection()
            } else {
                false
            }
        })
        .map(|line| *line.quantity())
        .sum();

    if qualifying_qty < 5 {
        return Ok(schema::CartLinesDiscountsGenerateRunResult { operations: vec![] });
    }

    // Apply 10% off the order subtotal
    Ok(schema::CartLinesDiscountsGenerateRunResult {
        operations: vec![schema::CartOperation::OrderDiscountsAdd(
            schema::OrderDiscountsAddOperation {
                selection_strategy: schema::OrderDiscountSelectionStrategy::First,
                candidates: vec![schema::OrderDiscountCandidate {
                    targets: vec![schema::OrderDiscountCandidateTarget::OrderSubtotal(
                        schema::OrderSubtotalTarget {
                            excluded_cart_line_ids: vec![],
                        },
                    )],
                    message: Some("Volume discount: 10% off".to_string()),
                    value: schema::OrderDiscountCandidateValue::Percentage(
                        schema::Percentage { value: Decimal(10.0) }
                    ),
                    conditions: None,
                    associated_discount_code: None,
                }],
            },
        )],
    })
}

Étape 1.4 : tester, déployer, activer#

# Local development with hot reload
shopify app dev

# When ready, deploy
shopify app deploy

# In the GraphiQL panel that opens (press `g` in the dev terminal),
# create the automatic discount that uses your Function:

mutation {
  discountAutomaticAppCreate(
    automaticAppDiscount: {
      title: "Volume Discount (5+ collection items)"
      functionHandle: "volume-discount-fn"
      discountClasses: [ORDER]
      startsAt: "2026-04-16T00:00:00Z"
    }
  ) {
    automaticAppDiscount { discountId }
    userErrors { field message }
  }
}

La Function est active, ses versions sont suivies et elle remplace entièrement l’ancien Script.

Tutoriel 2 : remplacer un Shipping Script (masquer un mode d’expédition au-delà d’un seuil)#

Voici un Script courant : « Masquer l’expédition express quand le sous-total du panier dépasse $500 pour éviter une livraison coûteuse dès le lendemain sur les grosses commandes. » Voici sa version avec une Function Delivery Customization.

Étape 2.1 : créer la structure#

shopify app generate extension --template delivery_customization --name hide-express-fn

Étape 2.2 : requête d’entrée (src/run.graphql)#

query Input {
  cart {
    cost {
      subtotalAmount {
        amount
      }
    }
    deliveryGroups {
      deliveryOptions {
        handle
        title
      }
    }
  }
}

Étape 2.3 : logique (src/run.js — version JavaScript)#

// @ts-check
/**
 * @typedef {import("../generated/api").RunInput} RunInput
 * @typedef {import("../generated/api").FunctionRunResult} FunctionRunResult
 */

const NO_CHANGES = { operations: [] };
const THRESHOLD = 500.0;
const HIDE_TITLES = ["Express", "Overnight"];

/**
 * @param {RunInput} input
 * @returns {FunctionRunResult}
 */
export function run(input) {
  const subtotal = parseFloat(input.cart.cost.subtotalAmount.amount);
  if (subtotal < THRESHOLD) return NO_CHANGES;

  const operations = input.cart.deliveryGroups.flatMap((group) =>
    group.deliveryOptions
      .filter((opt) => HIDE_TITLES.some((t) => opt.title.includes(t)))
      .map((opt) => ({
        hide: { deliveryOptionHandle: opt.handle },
      }))
  );

  return { operations };
}

Étape 2.4 : activer dans Shopify Admin (sans GraphQL)#

Les personnalisations de livraison disposent d’une interface intégrée à Shopify Admin. Après shopify app deploy :

1. Ouvrez Settings → Shipping and delivery
2. Faites défiler jusqu’à la section Customizations, en bas de la page
3. Cliquez sur Add customization, puis sélectionnez votre Function
4. Enregistrez

La règle qui masque le mode d’expédition est active en production. Aucune mutation n’est nécessaire.

Tutoriel 3 : remplacer un Payment Script (masquer le paiement à la livraison pour le B2B)#

Ancien Script : « Masquer le paiement à la livraison pour tout client portant la balise “B2B”. » Voici la version Payment Customization.

Étape 3.1 : créer la structure#

shopify app generate extension --template payment_customization --name hide-cod-b2b-fn

Étape 3.2 : requête d’entrée#

query Input {
  cart {
    buyerIdentity {
      customer {
        hasTags(tags: [{ tag: "B2B" }]) {
          tag
          hasTag
        }
      }
    }
  }
  paymentMethods {
    id
    name
  }
}

Étape 3.3 : logique (src/run.js)#

const NO_CHANGES = { operations: [] };

export function run(input) {
  const tagCheck = input.cart?.buyerIdentity?.customer?.hasTags?.[0];
  const isB2B = tagCheck?.hasTag === true;
  if (!isB2B) return NO_CHANGES;

  const codMethod = input.paymentMethods.find((pm) =>
    pm.name.toLowerCase().includes("cash on delivery")
  );
  if (!codMethod) return NO_CHANGES;

  return {
    operations: [{ hide: { paymentMethodId: codMethod.id } }],
  };
}

Étape 3.4 : activer#

Les personnalisations de paiement ont aussi une interface dans Shopify Admin, sous Settings → Payments → Customizations. Procédez comme pour la livraison : sélectionnez votre Function, puis enregistrez.

Puisque vous êtes ici : un mot sur l’après-achat#

Précisons que vous lisez le blog de Revize. Revize prend en charge ce que Functions ne peut pas modifier une fois la commande passée : les clients veulent ajouter un article, changer de taille, corriger l’adresse de livraison ou appliquer une réduction oubliée. Functions intervient au paiement. Revize intervient après. Functions détermine ce qui est autorisé dans le panier. Revize permet ensuite à vos clients et à votre équipe d’assistance de modifier la commande sans devoir la rembourser et la recréer. C’est utile pour deux types de boutiques : celles dont le volume de commandes rend les modifications manuelles intenables (les boutiques Plus, bien sûr, mais aussi les boutiques Advanced à fort débit), et celles qui placent l’expérience client au cœur de leur marque, pour lesquelles un courriel disant « désolé, nous ne pouvons pas faire ce changement » peut faire perdre un prochain achat.

Si votre plan couvre la migration de Scripts vers Functions, mais pas les modifications de commande après achat, vous rencontrerez bientôt une autre difficulté. Notre guide récemment publié sur la gestion des commandes présente l’ensemble des options après le paiement.

Revenons à la migration.

Stratégie de test : identifier les clients avec une balise#

Functions ne propose pas de « mode brouillon » à activer dans l’interface d’administration. La méthode consiste à réserver la nouvelle Function aux clients portant une balise, à faire fonctionner l’ancien Script et la nouvelle Function en parallèle, à vérifier que leurs résultats sont identiques pour ces clients, puis à étendre la Function à tous.

Étape 1 : ajouter une balise à vos utilisateurs de test#

Dans Customers, ajoutez la balise FN-TESTER à deux ou trois comptes internes.

Étape 2 : conditionner la Function à la présence de la balise#

// At the top of your run function
let is_tester = input
    .cart()
    .buyer_identity()
    .and_then(|bi| bi.customer())
    .map(|c| c.has_any_tag())
    .unwrap_or(&false);

if !*is_tester {
    return Ok(default_result);  // Fall through to existing Script
}

// New Function logic only runs for tagged users

Étape 3 : ajouter hasAnyTag à votre requête d’entrée#

cart {
  buyerIdentity {
    customer {
      hasAnyTag(tags: ["FN-TESTER"])
    }
  }
}

Étape 4 : vérifier au paiement#

Connectez-vous avec un compte portant la balise, effectuez un paiement et vérifiez que la Function s’exécute. Connectez-vous ensuite avec un compte sans balise et vérifiez que l’ancien Script s’exécute toujours. Si les résultats concordent pendant quelques jours, retirez la vérification de la balise pour que la Function s’applique à tous.

Étape 5 : annuler la publication de l’ancien Script#

Ouvrez Apps → Script Editor → [Your Script] → Unpublish. Une fois sa publication annulée, seule la Function détermine le résultat.

Un processus de déploiement qui tient la charge#

Ne déployez pas indéfiniment depuis l’ordinateur d’un développeur. Après avoir migré un ou deux Scripts, mettez en place un pipeline d’intégration continue.

Le processus minimal#

# .github/workflows/deploy-functions.yml
name: Deploy Shopify Functions
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - uses: dtolnay/rust-toolchain@stable
        with: { targets: wasm32-wasip1 }
      - run: npm install -g @shopify/cli@latest
      - run: shopify app deploy --force
        env:
          SHOPIFY_CLI_PARTNERS_TOKEN: ${{ secrets.SHOPIFY_CLI_PARTNERS_TOKEN }}

Générez le jeton Partner dans votre tableau de bord Partner, sous Settings → Tokens. Désormais, chaque fusion dans main déploie vos Functions. Plus besoin de demander sur Slack si Mike a effectué le déploiement.

Gestion des versions et retour en arrière#

shopify app deploy crée un instantané avec un numéro de version. Pour revenir à une version précédente :

shopify app versions list
shopify app release --version <previous-version-id>

Avec Scripts, revenir en arrière signifiait retrouver l’ancien code et le recoller. Ici, le processus est bien plus simple.

Les erreurs les plus fréquentes#

Après avoir accompagné des marchands Plus dans cette migration au cours de l’année écoulée, nous voyons revenir les cinq mêmes erreurs.

1. Transposer chaque Script tel quel dans une Function. Une seule Function peut remplacer trois Scripts avec une logique conditionnelle plus claire. Faites l’inventaire de vos Scripts comme un ensemble avant de les réécrire.

2. Oublier les autorisations de lecture. De nombreuses Functions nécessitent read_customers, read_orders ou write_discounts. Ajoutez ces autorisations à scopes dans shopify.app.toml, puis autorisez de nouveau l’application. Sinon, votre requête d’entrée renverra null.

3. Exécuter les Functions pour les clients sans balise avant de comparer les résultats. Même si votre code semble correct, les cas particuliers (panier vide, cartes-cadeaux, crédit en boutique, brouillons B2B) peuvent révéler des problèmes. Un déploiement limité par balise vous coûte deux jours et peut vous éviter une panne de priorité P1.

4. Ignorer le rapport Customizations Report. C’est le meilleur inventaire de ce qui fonctionne réellement dans votre boutique. Fondez votre migration sur ce rapport, pas sur vos souvenirs.

5. Inscrire en dur les identifiants de collection et les balises clients. Si les marchands doivent pouvoir ajuster ces valeurs, utilisez une configuration de Function fondée sur des métachamps. La CLI peut générer cette structure ; consultez la documentation Shopify sur la configuration des Functions.

Liste de contrôle pour les 75 prochains jours#

Voici un calendrier réaliste, semaine par semaine, pour arriver sereinement au 30 juin.

Si vous commencez cette semaine, vous avez une marge. Si vous commencez en juin, vous n’en avez plus.

Ce que vous devez faire cette semaine#

Ne refermez pas cet article sans agir. Faites ces quatre choses dans les sept prochains jours.

1. Récupérez le rapport Customizations Report. Ouvrez Settings → Checkout → Customizations Report. Exportez-le. Ce sera votre liste de travaux pour la migration.

2. Préparez votre environnement de développement. Installez Node 18+, Shopify CLI et Rust si nécessaire. Vérifiez que shopify version fonctionne. Durée totale : 30 minutes.

3. Créez et déployez une petite Function sur une boutique de développement. Choisissez votre Script le plus simple, généralement une règle qui masque un moyen de paiement. Migrez-le de bout en bout. Même si cette Function n’arrive jamais en production, vous aurez validé votre chaîne d’outils.

4. Réservez du temps dans votre calendrier pour les huit prochaines semaines. Une migration ne se fait pas dans les rares moments libres entre deux sprints. Bloquez un créneau régulier, par exemple chaque mardi et jeudi après-midi, et traitez-le comme une mise en production.

Parmi les équipes que nous avons vues migrer, le schéma est constant : deux semaines à repousser le travail, trois semaines de migration effective et une semaine de finalisation. Soit six semaines. Vous en avez dix. Consacrez cette marge à la revue de code et aux tests d’assurance qualité, sans retarder le démarrage.

Une fois votre logique de paiement migrée, la prochaine étape pour beaucoup d’équipes concerne l’après-achat : changements d’adresse demandés par les clients, échanges d’articles et ajout de réductions après la commande. Si ces besoins figurent dans votre feuille de route, que vous gériez une boutique Plus à fort volume ou une boutique Advanced axée sur l’expérience client, Revize est disponible sur le Shopify App Store et fonctionne avec toutes les Functions que vous créerez ici.

Ressources#

• Présentation de Shopify Functions — documentation Shopify pour les développeurs
• Migrer de Shopify Scripts vers Functions
• Tutoriel pour créer une Function de réduction
• Référence de l’API Delivery Customization Function
• Référence de l’API Payment Customization Function
• Documentation de Shopify CLI

Mis à jour en août 2026. Revize est une application Shopify qui permet aux clients de modifier eux-mêmes leur commande après achat : changer l’adresse de livraison, échanger une variante ou un produit, annuler et obtenir un remboursement ou un crédit en boutique avant le traitement des commandes (fulfillment), sans contacter l’assistance. Découvrez comment permettre aux clients de modifier eux-mêmes leurs commandes Shopify ou retrouvez Revize sur le Shopify App Store.