Tray vs Shopify en 2026 : personnalisation et intégrations

L'essentiel (BLUF)

Tray n'est pas « trop fermée pour exister ». Elle est assez fermée pour bloquer exactement ce dont une boutique de marque et une opération pilotée par la publicité ont besoin une fois les débuts passés : HTML et JS sur la vitrine, personnalisation fine du thème, et intégrations qui ne s'appuient pas sur une app générique ou sur GTM comme béquille.

Sur la page officielle des offres, Lançamento (Lancement) indique la personnalisation par éditeur visuel. HTML et CSS apparaissent à partir de Crescimento (Croissance) (offres Tray). Même avec le HTML débloqué, la documentation officielle demande de dupliquer le thème publié avant de modifier le code, le support n'accompagne pas ces modifications, et il est impossible de créer ou supprimer des fichiers dans pages/, layouts/ et configs/ (modifier le HTML, modification via HTML).

Shopify, en contraste utile, propose un thème en Liquid avec les Theme App Extensions dans l'éditeur et les Checkout UI Extensions au paiement (Theme App Extensions, Checkout UI Extensions). Le coût compte, mais ici il est une conséquence du plafond technique, pas la thèse centrale.

---

Si vous opérez sur Tray, vous avez sans doute déjà entendu l'une de ces phrases de la part d'un développeur ou d'une agence :

1. « On peut changer la couleur et la bannière, mais cette règle de mise en page ne rentre pas dans l'éditeur. »
2. « Le pixel / script du partenaire ne passe que par GTM, et sur le checkout on ne garantit pas le déclenchement. »
3. « Pour ce webhook / cette synchro sur mesure, il faut une app accréditée et un ticket au support. »
4. « On ne peut pas modifier le thème en ligne ; il faut le dupliquer, travailler sur la copie et republier. »

Aucune de ces phrases n'est de la « haine envers Tray ». Ce sont des limites documentées ou des effets de bord du modèle de plateforme. La suite de ce texte organise ces limites selon trois axes : HTML/JS, personnalisation du thème, intégrations. Shopify intervient comme contraste là où le contraste change la décision. À la fin, les coûts viennent en appui pour savoir quand le plafond est déjà devenu trop cher.

---

1. HTML et JavaScript : ce que Tray débloque vraiment

La barrière de l'offre

Avant de discuter de qualité de code, regardez ce que Tray vend elle-même :

Source : tray.com.br/planos. Si la boutique est sur l'offre d'entrée et que le brief demande une landing page avec son propre HTML, un composant JS sur la fiche produit ou une surcharge fine de template, la conversation commence déjà par un changement d'offre, pas dans l'éditeur.

Le flux officiel de modification du code

Avec le HTML débloqué, le chemin documenté par Tray est :

1. Ne pas modifier le thème publié.
2. Dupliquer le thème.
3. Ouvrir Editar HTML (Modifier le HTML) sur la copie.
4. Publier la copie ensuite.

La base de connaissances le dit explicitement : le service client n'apporte pas d'aide pour ces modifications ; soit vous savez programmer, soit vous engagez quelqu'un (Comment modifier le HTML de votre thème).

En pratique, cela crée trois frictions opérationnelles :

• Cycle lent. Chaque changement sérieux devient dupliquer → modifier → tester → publier, au lieu d'une branche/preview continue comme dans les flux de thème modernes.
• Risque de régression. Qui a touché au Twig/HTML et supprimé des marqueurs obligatoires de la plateforme casse un module, le SEO ou l'analytics. La documentation des thèmes insiste sur la structure standardisée et le mode de fonctionnement de la plateforme (Comprendre le thème).
• Plafond de fichiers. En modification via HTML, il est impossible de créer ou supprimer des fichiers dans pages/, layouts/ et configs/ ; l'installation de thèmes est limitée à 25 (modification via HTML). Landing page sur mesure, nouveau layout et configuration structurelle ne se résument pas à « créer le fichier et c'est fini ».

JavaScript et scripts tiers : GTM comme porte principale

Tray documente Google Tag Manager comme le moyen d'inclure du code sans modifier le HTML du thème, via Configurações → Integrações → Ferramentas Google (Paramètres → Intégrations → Outils Google) (intégrer GTM). C'est utile pour GA4, Ads et les pixels. C'est aussi un signal d'architecture : la vitrine n'est pas votre terrain de jeu pour injecter librement dans le head/body.

Ce qui fait généralement mal au quotidien :

• Pixel Meta, scripts d'affiliation, chat, heatmap et tests A/B se concurrencent dans GTM, avec ordre de déclenchement, consentement et CSP/nonce.
• Les événements de checkout, d'ajout au panier et d'achat dépendent d'un dataLayer stable. Si la page de paiement ou le parcours de compte change, les tags cassent sans que le marchand s'en aperçoive.
• Les scripts qui doivent vivre dans le template (au-dessus de la ligne de flottaison, bloquant le CLS, lisant le Liquid/Twig du produit) échappent au modèle « GTM uniquement ».

Le contraste Shopify. Dans le thème, Liquid + assets + Theme App Extensions permettent d'injecter de l'UI et de la logique dans la vitrine via l'éditeur, sans que le marchand colle du code au milieu du thème (Theme App Extensions). Pour le checkout, la voie officielle est la Checkout UI Extension, pas un script isolé à l'étape de paiement (Checkout UI Extensions). Le propos n'est pas « Shopify laisse tout chambouler dans le head ». C'est que la plateforme sépare vitrine et checkout avec des extensions de premier rang, au lieu de tout pousser vers GTM + HTML dupliqué.

---

2. Personnalisation du thème et de la vitrine

Twig + éditeur visuel : une liberté sur rails

Les thèmes Tray utilisent Twig avec HTML, CSS, JavaScript et JSON, dans une structure de répertoires définie par la plateforme (Comprendre le thème). On peut construire un thème de niche et le vendre sur la boutique de thèmes. Cela signifie aussi que la boutique roule sur les rails de Tray, pas sur un framework front libre.

L'éditeur visuel (glisser-déposer de sections dans le Tema Padrão 3.0 et équivalents) gère bien :

• bannières, vitrines produits, marques, pied de page, barre d'informations ;
• changement de l'ordre des sections sans développeur ;
• ajustements d'apparence pour un marchand sans HTML.

Il ne gère pas bien :

• une mise en page produit avec une UX propriétaire (guide des tailles, configurateur, composeur de kits) ;
• des pages de campagne avec une structure hors de ce que le thème expose ;
• des composants qui dépendent d'un état côté client au-delà de ce que le thème/l'API de la vitrine expose ;
• un design system maison avec typographie, motion et composants partagés entre landing page, collection et checkout.

Ce que le marchand ressent au quotidien

La bonne question n'est pas « Tray a-t-elle de beaux thèmes ? ». Elle en a. La question est : quelle part du brief de marque tient dans l'éditeur et dans le Twig autorisé sans devenir du bricolage.

Quand la réponse est « moins de la moitié », la boutique paie déjà une agence pour contourner la plateforme, pas pour accélérer la marque.

---

3. Intégrations : API, webhooks, apps, checkout et pixel

API et webhooks

Tray a un écosystème de développeurs et une API. Le système de notifications (webhook) envoie un POST en application/x-www-form-urlencoded avec seller_id, scope_id, scope_name, act, app_code et url_notification vers l'URL enregistrée dans l'application accréditée (Tray Developers).

Implications pratiques :

• Une intégration « pour de vrai » passe par une app, pas par un endpoint isolé que le marchand colle dans le back-office.
• Le payload n'est pas le JSON typé que la plupart des équipes d'ingénierie attendent par défaut ; un mauvais parsing = une synchro muette.
• Les scopes au-delà de la base (commande, stock, produit, etc.) exigent souvent une activation et une discipline de retry : si l'URL ne répond pas 200, la plateforme renvoie.

Cela convient aux ERP et aux hubs de marketplaces. Cela devient lourd quand vous voulez :

• une automatisation maison (n8n, worker propre) sans app publiée ;
• des événements granulaires de vitrine (view_item, begin_checkout) avec un contrat stable ;
• une extension de checkout avec sa propre UI.

Le contraste Shopify. Admin API (REST/GraphQL), webhooks JSON, extensions d'app et un App Store mature. Pour la vitrine, les Theme App Extensions ; pour le paiement, les Checkout UI Extensions. Le coût d'ingénierie baisse parce que le contrat est public, versionné et conçu pour les apps tierces.

Checkout : le trou noir de la personnalisation

Le checkout est l'endroit où le HTML/JS « presque débloqué » du thème cesse de s'appliquer.

Sur Tray, l'opération typique règle paiement, livraison et antifraude avec ce que la plateforme et les apps natives fournissent. Personnaliser étape par étape, ajouter un champ fiscal, un upsell natif au paiement ou une UI de réassurance à l'étape critique finit généralement en :

• app de la marketplace Tray ;
• script via GTM avec un déclencheur fragile ;
• ou « impossible ».

Sur Shopify, la personnalisation du checkout se fait via des extensions officielles, pas via un checkout.liquid éternel. Les theme app blocks ne s'affichent pas sur les pages de checkout ; la voie documentée est la Checkout UI Extension (Theme App Extensions, Checkout UI Extensions).

Pour une boutique avec beaucoup de trafic payant, c'est important parce que l'abandon moyen documenté est de 70,22 %, et 48 % abandonnent à cause de frais supplémentaires trop élevés ou révélés tard (Baymard). Si vous ne contrôlez pas l'expérience de l'étape de paiement, vous optimisez vos annonces pour un tunnel que la plateforme verrouille.

Pixel, head/body et scripts marketing

Résumé opérationnel sur Tray :

1. Préférence officielle : GTM dans le back-office, sans le HTML du thème (GTM).
2. HTML du thème : seulement avec l'offre adéquate + duplication + prudence avec la structure Twig.
3. Checkout et zones authentifiées : valider le déclenchement en conditions réelles, pas seulement dans le Preview de GTM.

Si le responsable acquisition a besoin de CAPI + pixel + événements de tunnel avec déduplication, le budget d'implémentation grimpe vite. Non pas parce que « Tray n'a pas GTM », mais parce que GTM ne remplace pas une vitrine et un checkout extensibles.

---

4. Coûts réels : un appui, pas une thèse

Abonnement et commission comptent. Ils ne décident simplement pas seuls quand le problème est un plafond d'ingénierie.

Référence officielle (ne comparez pas que le prix affiché)

Le coût invisible sur Tray, dans cet article, est ailleurs :

• Heures d'agence pour contourner l'éditeur/le Twig.
• Apps qui existent parce que le thème ne fournit pas la règle.
• Reprises de GTM à chaque changement de tunnel.
• Expériences perdues : des tests A/B d'UX sur le checkout qui ne tournent tout simplement pas.

Si la somme mensuelle des « contournements techniques » dépasse déjà l'écart de plateforme, la migration n'est plus une affaire de goût technique, elle est devenue une limitation des pertes.

---

5. Quand rester sur Tray et quand Shopify a du sens

Restez sur Tray si

• Votre site est un canal d'appoint et la vente se fait sur les marketplaces.
• L'éditeur visuel + les apps officielles couvrent le brief de marque.
• Vous ne dépendez ni de JS sur mesure sur la fiche produit/le checkout ni d'un webhook maison.
• L'équipe accepte GTM comme porte principale des scripts.

Évaluez sérieusement Shopify si

• La marque exige une vitrine hors des rails du thème Tray.
• Vous avez besoin d'extensions d'app au bon endroit de la page, sans patcher le HTML publié.
• Le checkout et les événements de conversion sont au cœur du ROI publicitaire.
• L'équipe d'ingénierie veut une API/des webhooks au contrat moderne et des apps versionnées.
• Vous payez déjà une « taxe de contournement » chaque mois (agence + apps + GTM fragile).

Règle pratique : si le brief de personnalisation et d'intégration ne tient pas dans ce que Tray documente (offre, duplication du thème, dossiers verrouillés, GTM, app accréditée), la discussion sur un abonnement en dollars est secondaire.

---

6. Checklist avant de décider

Répondez avec des preuves tirées de la boutique, pas au feeling :

1. Votre offre Tray débloque-t-elle HTML/CSS ou seulement l'éditeur visuel ? (offres)
2. Combien de fois le trimestre dernier avez-vous dupliqué le thème juste pour publier du HTML ?
3. Quels scripts critiques dépendent uniquement de GTM, et lesquels ont cassé au checkout ?
4. Y a-t-il une intégration bloquée parce qu'elle nécessitait une app accréditée / un scope de webhook ?
5. Combien dépensez-vous par mois en agence/apps uniquement pour contourner les limites du thème ?
6. Votre site est-il le moteur des ventes, ou les marketplaces portent-elles encore 80 %+ ?

Si les points 2 à 5 font mal et que la réponse au 6 est « notre site », le plafond vous coûte déjà.

---

Conclusion

Tray reste solide pour les débuts au Brésil et pour les opérations centrées sur les marketplaces. La limite qui pèse le plus en 2026 n'est pas le prix affiché de l'abonnement : c'est le combo HTML/JS derrière une barrière d'offre avec flux de copie, thème Twig sur les rails de la plateforme, et intégrations qui poussent les scripts vers GTM et l'automatisation vers une app accréditée.

Shopify se démarque là où l'opération a besoin d'une vitrine et d'un checkout réellement extensibles. Les coûts entrent dans le calcul une fois que vous admettez le plafond technique.

Si vous voulez le diagnostic de votre boutique (ce qui tient dans le thème actuel vs. ce qui est déjà du contournement), ouvrez Contact sur oailton.dev/fr/contato avec votre plateforme, votre offre et deux exemples de personnalisations qui ont bloqué. Je vous rends le verdict sur la base du brief, pas d'un slogan.