Workflows multi-agents pour le développement de thèmes Shopify

À retenir

• Le développement Shopify multi-agents signifie répartir le travail sur le thème entre différents rôles - un agent planifie, un autre écrit le Liquid, un autre révise - au lieu de demander à un seul chat de tout faire.
• La répartition la plus rentable : un planificateur (planner) qui fait des recherches et rédige une spécification, un builder qui l’implémente, et un reviewer qui valide le résultat avant le déploiement.
• Parallélise uniquement le travail indépendant. Deux agents modifiant le même fichier de section vont s’écraser l’un l’autre. Exécute les sections, snippets ou templates séparés en parallèle.
• La validation est le point de passage. Fais passer le Liquid et le GraphQL générés par le Dev MCP de Shopify pour que chaque agent travaille à partir d’un artefact vérifié, pas d’une supposition.
• Tu n’as pas besoin de construire ça toi-même. Fudge, l’opérateur IA pour les boutiques Shopify, donne à ton équipe un workflow tout prêt de planification, construction et révision, avec chaque changement préparé sous forme de draft que tu approuves, pour profiter des avantages d’une configuration multi-agents sans avoir à la concevoir et la connecter.

Le développement Shopify multi-agents répartit le travail en rôles. Un agent fait des recherches et planifie. Un autre implémente le Liquid, JavaScript et CSS. Un troisième révise et valide avant que quoi que ce soit n’atteigne ton thème. Les tâches indépendantes s’exécutent côte à côte au lieu d’un seul long fil de discussion.

Utiliser un seul chat IA pour reconstruire tout un thème a tendance à dériver. Le contexte se remplit, l’agent oublie la spec qu’il a écrite il y a une heure, et une seule passe de révision laisse passer le Liquid qui casse silencieusement sur un panier vide.

Ce guide part du principe que tu as déjà un agent de code comme Claude Code, Cursor ou Codex connecté à Shopify. Si ce n’est pas le cas, commence par notre guide de configuration de Claude Code ou notre guide de configuration de Cursor.

Pourquoi vous pouvez nous faire confiance

Jacques a plus de 15 ans d’expérience en développement et a travaillé avec des centaines de boutiques Shopify. Nous créons Fudge, l’opérateur IA pour les boutiques Shopify, avec une note de 4.9 sur le Shopify App Store. Nous utilisons des workflows de code multi-agents sur du code de thème tous les jours, donc les modèles (patterns) ici viennent du travail en production, pas de la théorie.

Que signifie vraiment le développement Shopify multi-agents ?

Un agent classique possède une seule fenêtre de contexte et fait une seule chose à la fois. Une configuration multi-agents exécute plusieurs agents ciblés, chacun avec un poste bien précis, coordonnés par vous ou par un agent orchestrateur.

Claude Code peut générer des sous-agents nativement : l’agent parent délègue une tâche stricte, le sous-agent fait remonter un résumé des actions effectuées, et le parent ne conserve que la conclusion au lieu d’ingérer l’intégralité du raisonnement.¹ Cursor et Codex fonctionnent selon des modèles similaires via des sessions séparées ou des tâches en arrière-plan.

Si cette approche fonctionne si bien sur des thèmes, c’est pour des raisons spécifiques à Shopify :

• Les thèmes se composent de nombreux petits fichiers. Les sections, snippets, templates et assets sont pour la plupart indépendants. Cela correspond parfaitement à l’utilisation d’agents distincts.
• Le Liquid échoue silencieusement. L’oubli d’une condition {% if product.available %} ne posera pas de problème visuel majeur, jusqu’au premier produit en rupture de stock. Un réviseur dédié rattrape les erreurs que le constructeur aurait laissées passer.
• Le contexte est le goulot d’étranglement. Un seul agent faisant à la fois la recherche, la planification et l’implémentation va brûler sa fenêtre de contexte en lisant la documentation, au point d’oublier son propre plan. La séparation des agents permet de garder chaque contexte parfaitement propre.

Le modèle général suit la logique planifier, étaler en parallèle (fan-out), puis réduire. Un agent produit une spec. Plusieurs agents construisent à partir de celle-ci en parallèle. Puis un dernier agent vérifie et fusionne le tout.

Les trois rôles clés

La majorité du travail sur un thème s’adapte bien à une répartition en trois rôles. Vous pouvez tout à fait les exécuter comme des sous-agents Claude Code distincts, des chats Cursor séparés ou des sessions de terminal indépendantes.

Le planificateur (recherche et spec)

Le planificateur ne fait strictement aucune implémentation. Son travail consiste à lire le thème existant, rechercher les infos pertinentes dans la documentation Shopify actuelle et rédiger une spec que le constructeur pourra suivre pas à pas.

Le rendu idéal d’un planificateur va lister les fichiers exacts à modifier, les paramètres de schéma à ajouter, les cas limites (edge cases) à gérer et les critères d’acceptation. Exemple de prompt :

Tu vas faire de la planification uniquement. N'écris pas de code.
Lis sections/featured-collection.liquid et le fichier
settings_schema.json du thème. Je veux une nouvelle section "Bundle highlight"
qui affiche trois produits avec un badge pour valoriser l'économie réalisée.
Résultat attendu : les fichiers à créer/modifier, le bloc de paramètres du schéma,
les cas limites en Liquid à gérer (collection vide, prix comparatif
manquant), et les critères d'acceptation.

La spec du planificateur devient le contrat de base pour le rôle suivant. Pour découvrir une liste plus poussée de prompts de planification et d’implémentation, consultez notre guide sur les prompts Claude pour Shopify.

Le constructeur (implémentation)

Le constructeur prend la spec en entrée et s’occupe d’écrire le Liquid, le JavaScript et le CSS. Il ne refait pas de recherche sur les besoins - il suit simplement le contrat. Lui fournir une spec fixe empêche ce deuxième agent de remettre en question ou repenser des décisions que le planificateur a déjà arrêtées.

Limitez la portée du constructeur à une seule unité de travail : une section, un snippet, un template. Un constructeur à qui l’on dit de “refaire la page produit” aura tendance à s’éparpiller. En revanche, un constructeur à qui l’on demande d‘“implémenter sections/bundle-highlight.liquid conformément à la spec” restera ultraprécis.

Le réviseur (validation et critique)

Le réviseur agit avec une méfiance totale envers le résultat produit par le constructeur. Il vérifie le code généré face à trois choses :

1. La validité du schéma - le GraphQL ou le Liquid passe-t-il la validation native ?
2. La spec - le constructeur a-t-il véritablement géré tous les cas limites repérés par le planificateur ?
3. Les conventions du thème - cela correspond-il aux règles et habitudes existantes du thème au niveau des noms, des espaces et des paramètres ?

C’est lors du passage du réviseur qu’un oubli comme une boucle non protégée ou qu’une couleur codée en dur qui devrait être un paramétrage du schéma vont être détectés au vol. Voyez son autorisation de déploiement comme une barrière stricte, pas juste comme un conseil amical.

Comment fonctionnent les transferts entre agents

Le passage de relais est la partie délicate. Chaque rôle transmet un artefact, pas une conversation.

Deux règles pratiques permettent de garder des passages de relais propres :

• Écrivez la spécification dans un fichier. Un PLAN.md ou un fichier temporaire dans le dépôt survit aux réinitialisations de contexte et permet à n’importe quel agent de reprendre le fil. L’historique des conversations ne le permet pas.
• Transmettez des résumés, pas des transcriptions. Lorsqu’un sous-agent fait un rapport, il doit renvoyer le diff et un résultat court, pas tout son raisonnement. L’orchestrateur conserve la conclusion.¹

Quand paralléliser (et quand ne pas le faire)

Le parallélisme est le principal avantage, et la façon la plus courante de corrompre un thème.

Sûr à exécuter en parallèle - des fichiers indépendants sans état partagé (shared state) :

• Différentes sections (hero.liquid, testimonials.liquid, faq.liquid)
• Des snippets séparés qui ne s’incluent pas mutuellement
• Des templates distincts (product.json vs collection.json)
• Des tâches de recherche qui font seulement de la lecture, jamais d’écriture

À ne pas paralléliser :

• Deux agents modifiant le même fichier - la deuxième écriture écrase la première
• Des modifications sur un snippet partagé utilisé par plusieurs sections
• Des changements dans settings_schema.json ou le CSS global par plus d’un agent
• Tout ce où la sortie d’une tâche est l’entrée d’une autre - c’est une chaîne, pas un fan-out (traitement en parallèle)

Une règle qui marche : fan-out (parallélise) pour la largeur, enchaîne pour les dépendances. Si trois sections sont vraiment indépendantes, donne à chacune son propre builder. Si la section B a besoin d’un snippet que la section A crée, exécute-les dans l’ordre.

Si tu veux un vrai fan-out, demande-le explicitement et précise le nombre, comme le fait la documentation des sous-agents de Claude Code dans leur exemple de recherche en parallèle.¹ Par exemple : “Génère trois builders, un par section, chacun limité à son propre fichier.”

La validation est l’étape clé du transfert

Ce qui rend la gestion d’un thème avec des intelligences artificielles redoutable d’efficacité et digne de confiance absolue, c’est cette fameuse validation tampon entre les rôles. À l’inverse, sans validation concrète et méthodique de chaque pièce du puzzle, vous vous exposez simplement au risque grandissant d’haluciner les filtres d’un Liquid vital.

La fonctionnalité serveur Dev MCP (Model Context Protocol) de Shopify garantit aujourd’hui aux agents virtuels d’accéder à un environnement fiable. Elle rend possible une validation efficace des requêtes GraphQL face aux schémas en direct. En plus de cette prouesse, la vérification est effectuée grâce au puissant mécanisme intrinsèque Theme Check de Shopify : ce dernier pointe du doigt automatiquement la moindre petite syntaxe douteuse, et flaggue haut et fort quelles best-practices de l’univers e-commerce viennent de se faire piétiner allégrement, et tout ça avant que quiconque n’y comprenne rien, une fois le code injecté sauvagement sur un thème d’environnement de prod.² À noter que le composant Dev MCP intègre le support d’une telle qualité de contrôle (validation syntaxique des instructions associées à Liquid) officiellement au mois d’octobre 2025.²

Intégrez tout ça dans un processus comme suit :

1. Le constructeur conçoit et génère un bout de fonctionnalité ou une requête précise.
2. Le constructeur auto-valide ensuite le tout en utilisant très bêtement le process basique d’exploration lié à son module de validation sur son propre script MCP.
3. Le réviseur repasse méticuleusement et indépendamment derriere ce script fraîchement pondu, tout en s’assurant scrupuleusement que les paramètres coïncident au besoin validé initialement par le Planificateur.
4. Si et seulement si un artefact valide 100% de cette check-list invisible (donc qu’il correspond point par point sans ambiguité), là ce bout de code devient admissible.

Maintenant vous avez le cœur de la raison qui force à utiliser cette compartimentation par rôles. Le concepteur-développeur, l’agent artificiel ou encore l’ouvrier unique derrière votre process global, si en plus chargé d’auto-auditer et d’auto-s’assigner un contrôle qualité final et strict à l’encontre de la validité de son propre taf, ne fera rien d’autre que tout expédier, au mépris flagrant des conséquences d’intégration. Séparer l’audit permet d’avoir la garantie d’une absence redoutable et stricte en termes de simple biais émotionnel vis à vis d’un simple investissement personnel orienté code.

Si les rouages ou le set-up orienté Dev MCP de ces approches concrètes vous semblent complexes, filez consulter notre guide de config pour Claude Code couvrant l’installation, MCP, les configurations expertes et finalement votre vraie première Query dument audité.

Exemple de workflow : construire une section saisonnière

Voici concrètement comment les rôles se partagent la vedette sur une mission classique – l’ajout d’une section package du Black Friday (BFCM).

1. L’agent planificateur. Il épluche la version actuelle du site web, recherche directement des bouts d’architecture via les archives standard de la doc Shopify, puis formalise un prompt brut PLAN.md : comment s’appellera la nouveauté, que regroupe le fichier (heading textuel, des curseurs associés aux futurs sélecteurs de vos produits fétiches de Novembre, sans oublier les bordures du mini label en encart) et des exemples cruciaux de ratés (fiche avec zéro référence associée, aucun tarif indicatif…).

2. L’agent constructeur. Prend en note ce fameux PLAN.md, produit en direct la structure interne du sections/bundle-highlight.liquid en veillant bien aux contraintes éditées plus bas par le Planificateur initial… Finalement il le passe à l’auto-scan intra-Dev MCP lié de base.

3. L’agent réviseur. S’occupe d’un second check en back-office de la requête complète issue des points 1. et 2. ; puis certifie manuellement la fiabilité liée notamment aux prix indicatifs comparatifs. Ce censeur confirme ou rejette si le modèle final ou code global mis bout-à-bout fait figure d’exception, par exemple quant à l’espacement vis à vis des règles de base des formats web déjà exploités ou actifs au sein du cœur de base actuel, soumettant si problème par retour un avis formel sur un margin.

4. Vous. Vous passez à l’étape clé suite aux remarques du réviseur et d’une seule clique vous injectez l’innovation temporaire du “Draft” pour visualisation in vivo de la vitrine non statique… pour clore l’opération en publication complète.

Chaque étape s’accompagne à coup sûr d’un travail propre. Un agent ne s’empoussière jamais à garder toute l’info coincée par rapport au volume standard à administrer et de toute façon l’intervention humaine n’empêche de commettre cette gaffe fatale : la publication sans check up !

Ce fonctionnement démontre sa pleine efficacité par des solutions poussées dans notre dossier consacré à ce type précis : le développement Shopify orienté AI-first qui vous détaille la technique experte pour transformer n’importe quel site internet web par IA… du lourd en somme.

Les limites de cette approche

Les configurations multi-agents ajoutent un coût de coordination. Elles valent le coup pour un gros travail sur le thème ; c’est disproportionné (overkill) pour une correction CSS d’une ligne.

• Les petits changements n’ont pas besoin de trois agents. Une seule session concentrée est plus rapide pour une modification rapide.
• Les transferts (handoffs) perdent en nuance. Une spec ne peut pas capturer tout ce qu’il y a dans la tête du planificateur. Des critères d’acceptation stricts aident, mais attends-toi à des allers-retours.
• Les changements de données de la boutique n’ont pas de draft. Les modifications de l’API Admin qu’un agent exécute via la CLI (produits, prix, metafields) s’appliquent immédiatement, sans prévisualisation ni annulation. La boucle de validation vérifie l’exactitude, pas l’intention.

Cette dernière lacune est la vraie limite des workflows IA orientés code (code-first). La validation confirme que le Liquid respecte le schéma. Elle ne peut pas te dire si la section convertit, et elle ne donne pas à un non-développeur un moyen sûr de réviser avant de publier.

C’est là que Fudge entre en jeu. Fudge offre à ton équipe une version clé en main de ce workflow, pour que tu n’aies pas à le concevoir et le gérer toi-même - pas d’agents à configurer, pas de spec à rédiger, pas de handoffs à gérer et aucune validation à câbler à la main. Tu décris le changement, ou tu donnes un objectif à Fudge et tu le laisses déterminer ce qui vaut la peine d’être fait ; Fudge planifie le travail et le construit en arrière-plan.

Le résultat est ce que ce guide s’efforce de bien faire : du Liquid, du JS et du CSS natifs dans ton thème, sans enfermement propriétaire (lock-in). Chaque changement atterrit sous forme de draft avec sa justification, et une fois en ligne, Fudge compare les métriques de la page avant et après, ce qu’une boucle de validation ne peut pas t’indiquer.

Pour l’édition basée sur des prompts d’une boutique existante, consulte le Shopify store editor.

FAQ