Shopify Scripts après le 30 juin 2026 : migrer vers Functions

Au 14 octobre 2026, les deux échéances de Shopify Scripts sont passées : la modification et la publication ont cessé le 15 avril, et l’exécution des Scripts le 30 juin. Consultez le rapport des personnalisations de Shopify et identifiez les comportements du paiement qui dépendaient de Scripts.

Ce guide explique comment évaluer les personnalisations concernées et utiliser Shopify Functions pour la logique de réduction, de livraison et de paiement prise en charge. Scripts gérait les comportements du paiement ; il ne permettait pas de modifier les commandes après achat, par exemple de changer une adresse de livraison après la commande.

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

Situation actuelle : Shopify Scripts a cessé de s’exécuter le 30 juin 2026. Shopify Functions fournit des API prises en charge pour les personnalisations du paiement, notamment les réductions, la livraison et les moyens de paiement. Les applications publiques utilisant Functions sont disponibles sur tous les forfaits ; les applications personnalisées contenant des Functions nécessitent Shopify Plus. Commencez par le guide de migration Shopify et le modèle d’extension généré par la CLI actuelle, puis validez le comportement dans une boutique de développement.

Ce qui a changé en 2026#

Les dates annoncées par Shopify sont passées. Script Editor est devenu accessible en lecture seule le 15 avril, et Scripts a cessé de s’exécuter le 30 juin 2026.

Si une boutique dépendait d’un Script, son comportement a cessé de s’exécuter après l’échéance, sauf s’il avait été remplacé ou reconfiguré d’une autre manière. Vérifiez le comportement réel du paiement dans la boutique ; ne supposez pas que chaque paramètre concerné revient au même fonctionnement par défaut.

Conseil : Consultez le rapport des personnalisations dans Shopify Admin pour inventorier les personnalisations concernées par l’arrêt de Scripts. Utilisez la documentation actuelle de migration Shopify pour confirmer la solution de remplacement de chacune.

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

Le changement d’architecture compte : Scripts consistait en des personnalisations Ruby dans Script Editor ; Functions consiste en des extensions d’application développées avec l’outillage pris en charge par Shopify. Leurs cibles d’extension et leurs exigences de forfait diffèrent : utilisez donc la documentation de migration pour associer chaque Script à une solution de remplacement prise en charge.

Associer chaque Script au bon type de Function#

Un Script peut être remplacé par une Function, une application publique, un autre paramètre pris en charge, ou ne disposer d’aucun remplacement. Utilisez le guide de migration Shopify pour vérifier l’option appropriée à chaque personnalisation.

Plusieurs Scripts peuvent correspondre à une seule Function ou nécessiter des remplacements distincts. Confirmez la correspondance et le comportement pour chaque cas avant de combiner la logique.

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#

Utilisez une version de Node.js prise en charge par la version actuelle de Shopify CLI ; vérifiez les exigences d’installation de la CLI avant de configurer le projet.

node --version
# Check the version required by your installed Shopify CLI

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

2. Shopify CLI actuelle#

Installez la version actuelle de Shopify CLI et vérifiez-la avec shopify version. Pour la crate Rust Function actuelle (2.0.0 et versions ultérieures), Shopify indique une CLI 3.85.0 ou supérieure.

3. 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-unknown-unknown
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 --name 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-10"
 
[[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-unknown-unknown --release"
path = "target/wasm32-unknown-unknown/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 CreateAutomaticDiscount($startsAt: DateTime!) {
  discountAutomaticAppCreate(
    automaticAppDiscount: {
      title: "Volume Discount (5+ collection items)"
      functionHandle: "volume-discount-fn"
      discountClasses: [ORDER]
      startsAt: $startsAt
    }   
  ) {
    automaticAppDiscount { discountId }
    userErrors { field message }
  }  
}  

Dans le volet Query Variables de GraphiQL, définissez startsAt sur un horodatage ISO 8601 futur. Examinez tout autre champ obligatoire pour votre version d’API avant d’exécuter la mutation.

Cela crée la réduction automatique qui appelle la Function déployée ; la Function remplace la logique du Script pour ce cas d’usage.

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.

Les tutoriels 2 et 3 utilisent les modèles JavaScript actuels. Conservez les cibles générées et les exports de src/index.js, définissez api_version = "2026-10" dans le fichier shopify.extension.toml de chaque extension et exécutez shopify app function typegen dans le répertoire de chaque extension après avoir remplacé sa requête d’entrée.

Étape 2.1 : créer la structure#

shopify app generate extension --template delivery_customization --flavor vanilla-js --name hide-express-fn

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

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

Étape 2.3 : logique (src/cart_delivery_options_transform_run.js)#

// @ts-check
/**
 * @typedef {import("../generated/api").CartDeliveryOptionsTransformRunInput} CartDeliveryOptionsTransformRunInput
 * @typedef {import("../generated/api").CartDeliveryOptionsTransformRunResult} CartDeliveryOptionsTransformRunResult
 */
           
/** @type {CartDeliveryOptionsTransformRunResult} */
const NO_CHANGES = { operations: [] };
const THRESHOLD = 500.0;
const HIDE_TITLES = ["Express", "Overnight"];
            
/** 
 * @param {CartDeliveryOptionsTransformRunInput} input
 * @returns {CartDeliveryOptionsTransformRunResult}
 */ 
export function cartDeliveryOptionsTransformRun(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) => ({
        deliveryOptionHide: { deliveryOptionHandle: opt.handle },
      }))
  );
              
  return { operations };
}    

Étape 2.4 : créer et activer la personnalisation de livraison#

Après shopify app deploy et l’installation de l’application sur la boutique cible, exécutez deliveryCustomizationCreate via le client GraphQL Admin authentifié de cette application avec le périmètre d’accès write_delivery_customizations. Définissez la variable functionHandle sur la valeur de handle de l’extension dans shopify.extension.toml (par exemple, hide-express-fn).

mutation CreateDeliveryCustomization($functionHandle: String!) {
  deliveryCustomizationCreate(deliveryCustomization: {
    functionHandle: $functionHandle
    title: "Hide express shipping above cart threshold"
    enabled: true
  }) {
    deliveryCustomization { id enabled }
    userErrors { field message }
  }
}

Vérifiez que la réponse renvoie une personnalisation activée et aucun userErrors, puis contrôlez Paramètres → Expédition et livraison → Personnalisations de livraison et testez le comportement au paiement. Le déploiement fournit la Function ; cette mutation crée et active la personnalisation de la boutique.

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 --flavor vanilla-js --name hide-cod-b2b-fn

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

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

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

// @ts-check
/**
 * @typedef {import("../generated/api").CartPaymentMethodsTransformRunInput} CartPaymentMethodsTransformRunInput
 * @typedef {import("../generated/api").CartPaymentMethodsTransformRunResult} CartPaymentMethodsTransformRunResult
 */
/** @type {CartPaymentMethodsTransformRunResult} */
const NO_CHANGES = { operations: [] }; 
               
/**
 * @param {CartPaymentMethodsTransformRunInput} input
 * @returns {CartPaymentMethodsTransformRunResult}
 */
export function cartPaymentMethodsTransformRun(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: [{ paymentMethodHide: { paymentMethodId: codMethod.id } }],
  };
}      

Étape 3.4 : créer et activer la personnalisation de paiement#

Après le déploiement et l’installation de l’application sur la boutique cible, exécutez paymentCustomizationCreate via le client GraphQL Admin authentifié de cette application avec le périmètre d’accès write_payment_customizations. Définissez functionHandle sur la valeur de handle de l’extension de paiement dans shopify.extension.toml (par exemple, hide-cod-b2b-fn).

mutation CreatePaymentCustomization($functionHandle: String!) {
  paymentCustomizationCreate(paymentCustomization: {
    functionHandle: $functionHandle
    title: "Hide Cash on Delivery for B2B-tagged customers"
    enabled: true
  }) {
    paymentCustomization { id enabled }
    userErrors { field message }
  }
}

Vérifiez que la réponse contient une personnalisation de paiement activée sans userErrors. Contrôlez-la sous Paramètres → Paiements → Personnalisations de paiement, puis testez le paiement avec des clients portant le tag B2B et des clients sans ce tag.

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

Pour les changements après paiement, Revize propose le libre-service admissible avant traitement via la page de statut ou un lien de confirmation pendant la période définie par le marchand. Le changement et l’ajout de produits nécessitent Pro ; la modification par le personnel est en développement. Les clients vérifient le solde supplémentaire et paient via Shopify Checkout. Le Gestion des commandes Shopify 2026 : le guide opérationnel Plus couvre le parcours natif après paiement.

Revenons à la migration.

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

Utilisez une boutique de développement et des jeux d’entrée représentatifs pour tester le remplacement selon vos exigences documentées ou les résultats de tests Scripts enregistrés. Scripts ne s’exécute plus : un test parallèle en direct Script/Function n’est donc plus possible. Un filtre par balise client peut limiter la Function de test aux comptes internes ; séparez le déploiement en production de ces tests.

É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#

// Rust example: return this target's empty result for non-testers
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);  // No operations from this Function
}       
                   
// 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 utilisateur balisé et vérifiez les paniers admissibles et non admissibles, les combinaisons de réductions et les options de livraison et de paiement. Répétez avec un utilisateur sans balise pour confirmer que cette Function ne renvoie aucune opération. Comparez avec le comportement attendu enregistré de l’ancienne logique ; testez aussi le paiement invité avant de retirer le filtre.

Étape 5 : vérifier l’activation en production#

Activez le remplacement testé dans la configuration de réduction, de livraison ou de paiement appropriée. Consignez la version déployée de l’application et le plan de retour arrière, puis retirez les instructions Scripts obsolètes de la documentation de l’équipe.

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: '22' }
      - uses: dtolnay/rust-toolchain@stable
        with: { targets: wasm32-unknown-unknown }
      - run: npm install -g @shopify/cli@latest
      - run: shopify app deploy --force
        env:
          SHOPIFY_APP_AUTOMATION_TOKEN: ${{ secrets.SHOPIFY_APP_AUTOMATION_TOKEN }}

Créez un App Automation Token dans le Dev Dashboard Shopify et enregistrez-le comme secret du dépôt indiqué ci-dessus. La CLI actuelle nécessite Node.js 22.12 ou supérieur. Associez le projet à sa configuration d’application avant d’utiliser la CI ; ajoutez vos tests et vérifications de version avant déploiement. Cet exemple déploie lors d’un push vers main : adaptez le déclencheur à la politique de votre équipe.

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#

Voici les pièges courants de migration à vérifier avant de mettre une Function en production.

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. Confondre les autorisations de l’application avec les données d’entrée de la Function. Une Function lit les champs exposés par sa requête d’entrée et les champs méta configurés ; elle n’obtient pas d’accès à l’Admin API par l’ajout de read_customers ou de read_orders. N’ajoutez des autorisations d’application que pour des opérations distinctes de l’Admin API, et vérifiez les règles d’entrée et de configuration de l’API Function pour l’extension que vous développez.

3. Omettre les tests de parité. Comparez la Function à l’ancien Script avec des paniers représentatifs et les cas limites pertinents avant la mise en production. N’utilisez un déploiement progressif que si votre extension et votre configuration le prennent en charge.

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 vérification de la migration#

Utilisez cette liste pour examiner l’état actuel d’une migration de Scripts.

Puisque l’échéance d’exécution est passée, donnez la priorité à l’audit du comportement du paiement en production et aux remplacements restant à effectuer.

Prochaines étapes#

1. Consultez le rapport des personnalisations et le guide actuel de migration Shopify.
2. Testez les cas de paiement pertinents dans une boutique de développement.
3. Confirmez quelles Functions ou applications publiques prennent en charge la logique requise sur votre forfait.
4. Vérifiez chaque remplacement en production et documentez son responsable et sa configuration.

Séparez les tests des règles de paiement de ceux des modifications après achat. Pour chaque système, consignez l’application responsable, les fonctions activées et le traitement des commandes et paiements pour attribuer clairement les changements futurs.

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

À lire aussi : Statistiques sur la modification des commandes Shopify (2026) · Comment permettre aux clients de modifier leurs propres commandes Shopify (2026)