← Tous les articles Shopify Liquid: Le guide de référence complet pour marchands et développeurs

Shopify Liquid: Le guide de référence complet pour marchands et développeurs

Maîtrisez Shopify Liquid avec ce guide de référence: objets, filtres, balises, schémas de sections, métachamps et les changements 2026.

Shopify Liquid est le langage de templating open-source qui alimente chaque vitrine Shopify. Il connecte les données du backend de votre boutique (produits, collections, panier, client) au HTML que voient vos clients, utilisant trois primitives: objets, balises et filtres. Maîtriser ces trois éléments fait la différence entre un thème qui convertit et un thème qui vous coûte des centaines d'euros par mois en abonnements d'applications et interventions de développeurs.

Points clés à retenir

  • Les trois primitives de Liquid sont les objets {{ }}, les balises {% %} et les filtres |. Chaque personnalisation que vous effectuez sur un thème Shopify passe par ces trois éléments.
  • La balise {% render %} a remplacé {% include %} en 2019 et c'est la seule balise d'inclusion qu'Online Store 2.0 supporte. Échanger les deux est toujours le gain de performance le plus rapide sur les thèmes hérités.
  • Les nouveaux filtres ajoutés en 2025-2026 incluent image_tag avec les attributs fetchpriority et sizes, ainsi que metafield_tag pour le rendu structuré des métachamps.
  • Une seule boucle de collection non optimisée avec vérifications de balises imbriquées peut ajouter 2-4 secondes au LCP et coûte environ 7% du revenu mobile par seconde de ralentissement.
  • Remplacer 3-5 applications de milieu de gamme par des sections Liquid natives économise généralement 100-300 euros par mois et supprime 150-600 KB de JavaScript tiers par page.

Qu'est-ce que Shopify Liquid?

Liquid est un langage de templating qui vous permet de créer un seul modèle pour accueillir du contenu statique et insérer dynamiquement des informations selon ce qui est en cours de rendu. Un modèle de produit, par exemple, contient tous vos attributs de produit standard et insère dynamiquement le bon contenu pour chaque URL de produit.

La version Shopify de Liquid étend la version open-source avec des objets spécifiques à la boutique (product, collection, cart, customer, shop) et des filtres créés pour le commerce (money, image_url, metafield_tag). À partir du 13 janvier 2026, Shopify a également mis à jour la façon dont elle traite le code Liquid en interne pour rendre le rendu des thèmes plus fiable, sans aucune action requise de la part des marchands.

Les trois primitives

1. Objets

Les objets produisent des données dynamiques en utilisant des accolades doubles:

{{ product.title }}
{{ product.price | money }}
{{ shop.name }}

Les objets globaux clés que vous utiliserez sur chaque construction de thème:

ObjetCe qu'il expose
productTitre, prix, variantes, images, métachamps
collectionProduits, filtres, pagination
cartArticles du panier, prix total, nombre d'articles
customerNom, email, historique des commandes, tags
shopNom, devise, locale, métachamps
requestType de page actuel, locale, hôte

Les objets peuvent représenter une valeur unique ou exposer plusieurs propriétés. L'objet request est particulièrement utile pour le rendu conditionnel en fonction du type de page.

2. Balises

Les balises ajoutent de la logique et un contrôle de flux en utilisant la syntaxe {% %}. Les catégories que vous devez connaître:

Contrôle de flux liquid {% if product.available %} <button>Ajouter au panier</button> {% else %} <button disabled>Rupture de stock</button> {% endif %}

Itération liquid {% for product in collection.products limit: 24 %} {% render 'product-card', product: product %} {% endfor %}

Assignation de variables liquid {% assign sale_price = product.compare_at_price | minus: product.price %} {% capture button_label %}Ajouter {{ product.title }}{% endcapture %}

Balises de thème (sections, snippets, layouts) liquid {% render 'product-card', product: product, show_vendor: true %} {% section 'announcement-bar' %} {% layout 'checkout' %}

3. Filtres

Les filtres modifient la sortie en utilisant le caractère pipe |. Les filtres multiples se chaînent de gauche à droite:

{{ product.title | upcase | truncate: 50 }}
{{ product.price | money }}
{{ product.featured_image | image_url: width: 800 | image_tag: loading: 'lazy', widths: '200,400,600,800' }}

Catégories de filtres critiques:

  • Filtres de devise: | money, | money_with_currency, | money_without_trailing_zeros. Ne codez jamais en dur les symboles de devise. Le filtre | money respecte la devise, la locale et les paramètres de formatage de votre boutique. Un symbole $ codé en dur ne fonctionne plus dès que vous activez les devises multiples dans Shopify Markets.
  • Filtres d'image: | image_url: width: X suivi de | image_tag. Les filtres modernes image_url et image_tag ont remplacé les anciens img_url et img_tag et livrent des images responsives avec les attributs srcset, sizes, lazy loading et fetchpriority appropriés dans une seule chaîne.
  • Filtres de tableau: | where, | map, | sort, | uniq, | join, | concat. Utilisez | where pour filtrer les tableaux sans boucles.
  • Filtres de chaîne: | upcase, | downcase, | truncate, | strip_html, | escape, | split.
  • Filtres mathématiques: | plus, | minus, | times, | divided_by, | ceil, | floor, | round.
  • Filtres de couleur: | color_lighten, | color_darken, | color_mix, | color_contrast. Le filtre color_contrast renvoie le ratio de contraste entre deux couleurs, ce qui est essentiel pour la conception accessible des badges et boutons.
  • Filtres de localisation: | t (traduction), | format_address, | currency_selector.

Une note sur la bizarrerie du | where: le filtre est sensible à la casse. | where: 'tags', 'Sale' ne correspondra pas à un tag 'sale'. Utilisez | downcase avant la comparaison.

Sections et la balise {% schema %}

Online Store 2.0 a rendu les sections disponibles partout, pas seulement sur la page d'accueil. Chaque section que vous construisez doit avoir un bloc {% schema %} complet afin que les marchands puissent modifier le contenu depuis l'éditeur de thème sans ouvrir un fichier de code.

Chaque section ne peut avoir qu'une seule balise {% schema %}, qui doit contenir du JSON valide. En avoir plus d'une, ou l'imbriquer dans une autre balise Liquid, produit une erreur de syntaxe.

Un schéma de section minimal mais complet:

{% schema %}
{
  "name": "Bannière vedette",
  "tag": "section",
  "settings": [
    {
      "type": "text",
      "id": "heading",
      "label": "Titre",
      "default": "Notre promesse"
    },
    {
      "type": "image_picker",
      "id": "image",
      "label": "Image d'arrière-plan"
    }
  ],
  "blocks": [
    {
      "type": "feature",
      "name": "Article vedette",
      "settings": [
        { "type": "text", "id": "feature_text", "label": "Vedette", "default": "Livraison gratuite" }
      ]
    }
  ],
  "max_blocks": 4,
  "presets": [{ "name": "Bannière vedette" }]
}
{% endschema %}

Règle critique: traitez les valeurs d'id de paramètre comme des noms de colonnes de base de données. Elles deviennent des clés persistantes dans le JSON du modèle sur chaque boutique qui installe votre section. Renommer un id rend orphelines les valeurs existantes. Changer un paramètre text en image_picker ne migre pas les données. Préfixez lorsque les sections deviennent grandes: utilisez hero_heading plutôt que heading si vous avez aussi card_heading dans les blocs.

Les sections avec des présets ne doivent pas être rendues statiquement. Les sections rendues statiquement ne peuvent pas être supprimées ou réordonnées par les marchands.

La balise {% render %} (et pourquoi {% include %} est morte)

La balise {% render %} est la seule façon d'inclure des snippets dans les thèmes Shopify modernes. {% include %} partageait la portée des variables entre les snippets, ce qui causait des conflits de noms et rendait le profilage de performance peu fiable. {% render %} crée une portée isolée: les snippets ne peuvent pas lire les variables parent à moins qu'elles ne soient passées en tant que paramètres nommés.

{# DÉPRÉCIÉ - partage la portée parent #}
{% include 'product-card' %}

{# CORRECT - portée isolée, entrées explicites #}
{% render 'product-card', product: product, show_vendor: true %}

{# Forme de boucle #}
{% render 'product-card' for collection.products as product %}

La portée isolée signifie que les snippets sont sûrement réutilisables sur les pages de détail de produit, les résultats de recherche, les réponses du panier AJAX et les demandes Section Rendering API sans réécriture. Remplacer {% include %} par {% render %} efface aussi chaque erreur Theme Check qui bloque la soumission au Shopify Theme Store.

Métachamps dans Liquid

Les métachamps vous permettent d'étendre le modèle de données de Shopify avec des données personnalisées (guides des tailles, ingrédients, instructions d'entretien, spécifications) sans applications. Les types de métachamps les plus puissants pour le développement Liquid sont:

  • JSON pour les données structurées (rendu avec | metafield_tag ou analyse de la valeur)
  • Texte enrichi pour la copie du corps HTML éditable par les marchands
  • Référence de fichier pour les images et vidéos attachées aux produits
  • Référence de produit/collection pour les relations explicites entre ressources

Modèle d'accès:

{% assign size_chart = product.metafields.custom.size_chart %}
{% if size_chart != blank %}
  {{ size_chart.value | metafield_tag }}
{% endif %}

La garde != blank est non négociable. Omettez-la et les produits sans guide des tailles rendront un <table> vide qui casse la mise en page sur Safari mobile.

Créez toujours les définitions de métachamps via Paramètres > Données personnalisées dans l'administrateur Shopify, jamais à la volée via l'API. Les définitions vous donnent la validation des types, des étiquettes conviviales pour les marchands et la visibilité de l'administrateur. Les applications tierces comme Yotpo et Klaviyo lisent ces définitions, donc un schéma propre alimente le reste de votre pile.

Modèles de performance qui comptent vraiment

Optimisation des boucles

Les boucles imbriquées sont le tueur de performance le plus courant dans les thèmes Liquid que j'audite. Une boucle externe sur 50 produits combinée à une boucle interne sur 20 tags par produit exécute 1 000 itérations par rendu de page. Utilisez plutôt l'opérateur contains:

{# MAUVAIS: O(n*m) - 50 produits x 20 tags = 1 000 itérations #}
{% for product in collection.products %}
  {% for tag in product.tags %}
    {% if tag == 'featured' %}...{% endif %}
  {% endfor %}
{% endfor %}

{# BON: une passe, la vérification contains est O(1) #}
{% for product in collection.products limit: 24 %}
  {% if product.tags contains 'featured' %}...{% endif %}
{% endfor %}

Ajoutez toujours limit: aux boucles de collection. Une seule boucle non optimisée peut ajouter 2-4 secondes au LCP sur mobile.

Rendu d'image

{# MAUVAIS: pas de dimensions, pas de srcset, le navigateur ne peut pas réserver l'espace (CLS) #}
<img src="{{ product.featured_image | img_url: 'master' }}">

{# BON: srcset, lazy loading, indice de largeur explicite #}
{{ product.featured_image
  | image_url: width: 800
  | image_tag:
      loading: 'lazy',
      widths: '200,400,600,800',
      sizes: '(min-width: 768px) 400px, 100vw',
      alt: product.title }}

Le filtre image_tag fait en une ligne ce qui nécessitait auparavant trois lignes de HTML avec construction manuelle de srcset.

Contrôle des espaces blancs

Liquid produit des espaces blancs autour de chaque balise. Sur les grands modèles, cela gonfle le HTML et ralentit le TTFB. Utilisez le modificateur - pour le supprimer:

{%- for product in collection.products -%}
  {{- product.title -}}
{%- endfor -%}

API de rendu de section

L'API de rendu de section permet aux sections d'être rendues indépendamment via AJAX, ce qui permet des transitions de page plus rapides et des mises à jour du panier dynamiques sans rechargements complets de page. C'est la fondation pour les expériences de type application dans les thèmes Liquid standard, sans la surcharge d'aller headless.

Theme Check et outils

Theme Check 2.0 est maintenant intégré à Shopify CLI et détecte les problèmes de performance, les problèmes d'accessibilité et l'utilisation de modèles dépréciés avant le déploiement. Exécutez-le à chaque commit. Il signale:

  • Les appels {% include %} (dépréciés)
  • Les attributs alt manquants sur les balises d'image
  • L'utilisation de img_url (remplacé par image_url)
  • Les boucles sans limit:
  • L'absence de content_for_header dans theme.liquid

L'overlay de l'inspecteur de thème affiche les temps de rendu Liquid directement sur votre vitrine, afin que vous puissiez voir quelles sections, snippets et boucles sont lents avant d'optimiser.

À partir de 2026, le Dev MCP de Shopify permet aussi aux agents IA de générer du code Liquid validé et de générer automatiquement les schémas de sections, ce qui accélère le travail passe-partout. Traitez la sortie de l'IA comme un premier brouillon et relisez toujours pour les cas limites spécifiques à Shopify.

Remplacement d'applications: ce que Liquid peut faire nativement

Remplacer 3-5 applications par thème par des sections Liquid natives économise généralement 100-300 euros par mois et supprime 150-600 KB de JavaScript tiers. La surcharge des applications coûte 40-200 ms par script tiers sur mobile, ce qui est exactement la plage qui fait tomber les scores Lighthouse mobiles de 80 à 60.

Les fonctions que Liquid gère nativement (aucune application requise):

  • Bannières de compte à rebours avec dates de fin contrôlées par schéma
  • Accordéons FAQ avec architecture bloc par question
  • Grilles de témoignages avec évaluations en étoiles et avis stockés dans des métachamps
  • Barres d'ajout au panier collantes via IntersectionObserver plus une section de produit Liquid
  • Tableaux de comparaison de caractéristiques utilisant des métachamps JSON
  • Curseurs d'image avant/après avec JS vanilla et deux paramètres de sélectionneur d'image

Les sections surpassent les applications sur trois axes: elles se rendent avant la peinture (sans décalage de mise en page), elles vivent dans votre dépôt de thème (le contrôle de version est trivial) et elles exposent les paramètres de schéma afin que les marchands modifient le contenu sans développeur.

Liquid vs. Hydrogen: la réponse honnête

Liquid reste le bon choix pour la grande majorité des boutiques Shopify car il offre un développement plus rapide, des coûts de maintenance plus bas et un accès complet à l'infrastructure CDN et d'hébergement de Shopify. Headless (Hydrogen/Oxygen) a du sens pour les marques avec des équipes d'ingénierie frontend dédiées et des architectures multi-vitrines complexes.

Allez headless lorsque vous avez une équipe frontend dédiée, trois vitrines ou plus partageant un backend, ou un modèle d'interaction que Liquid ne peut vraiment pas atteindre. Pour tout le monde d'autre, la question n'est pas "Liquid ou Hydrogen" mais "comment écrire du Liquid qui ne me fait pas honte dans deux ans?"

Si vous avez besoin d'aide pour auditer ou construire un thème selon ces normes, consultez la page de services développeur de thème Shopify, ou explorez optimisation de la vitesse Shopify si la performance est le goulot d'étranglement spécifique.

Antisèche de référence rapide

Syntaxe de sortie

{{ product.title }}              {# sortie de chaîne #}
{{ product.price | money }}      {# sortie filtrée #}
{{- product.title -}}            {# espaces blancs supprimés #}

Contrôle de flux

{% if %} / {% elsif %} / {% else %} / {% endif %}
{% unless %} / {% endunless %}
{% case product.type %}{% when 'Apparel' %}...{% endcase %}

Boucles

{% for item in array limit: 24 offset: 0 %}
  {{ forloop.index }} sur {{ forloop.length }}
{% else %}
  Aucun article trouvé.
{% endfor %}

Filtres les plus utilisés en un coup d'oeil

| money               {# sortie de prix sécurisée pour la devise #}
| image_url: width: X {# URL d'image redimensionnée par CDN #}
| image_tag           {# balise <img> responsive complète #}
| metafield_tag       {# rend la valeur de métachamp avec le HTML correct #}
| where: 'key', val   {# filtrer le tableau sans boucle #}
| map: 'property'     {# extraire une propriété du tableau d'objets #}
| json                {# sortie JSON sécurisée pour les balises de script #}
| t                   {# recherche de clé de traduction #}
| handleize          {# chaîne vers poignée sécurisée pour URL #}
| date: '%B %d, %Y'  {# sortie de date formatée #}

Mettez en signet la référence Liquid officielle à côté de cet article. La documentation officielle couvre chaque propriété d'objet et paramètre de filtre en détail.

shopify liquiddéveloppement de thèmeshopifyfiltres liquidonline store 2.0

Questions fréquentes

À quoi sert Shopify Liquid?

Shopify Liquid est le langage de templating qui connecte les données de votre boutique (produits, collections, panier, client) au HTML que voient vos clients. Il alimente chaque thème Shopify à travers trois éléments de base: les objets qui produisent les données, les balises qui ajoutent la logique et les boucles, et les filtres qui formatent la sortie.

Liquid est-il toujours pertinent en 2026 ou devrais-je aller headless?

Liquid reste le bon choix pour la grande majorité des boutiques Shopify. Il offre un développement plus rapide, des coûts de maintenance plus bas et un accès complet à l'infrastructure CDN de Shopify. Headless Hydrogen n'a du sens que pour les marques avec des équipes d'ingénierie frontend dédiées et des besoins multi-vitrines complexes.

Quelle est la différence entre la balise render et la balise include dans Shopify Liquid?

La balise render crée une portée de variable isolée, afin que les snippets ne puissent pas accidentellement lire ou modifier les variables du modèle parent. La balise include partageait la portée, ce qui causait des conflits de noms et rendait le profilage de performance peu fiable. Shopify a déprécié include et render est la seule balise d'inclusion supportée par Online Store 2.0.