Nous avons demandé à Shopify un nouveau type d'intention Sidekick. Ils l'ont livré.

Comment faire ajouter un type d'intention application/* pour votre catégorie - et ce que nous avions mal compris des intentions à la première tentative.

Si vous développez une application Shopify dont l'objet central n'est ni un produit, ni une commande, ni un client, vous avez probablement buté sur ce mur : les extensions d'application Sidekick utilisent un vocabulaire d'intentions fixe, et votre objet n'y figure pas.

Quand nous avons commencé à câbler QuotWay dans Sidekick, la liste prise en charge était application/{ad, campaign, email, faq, loyalty-program, return, review, shipment, ticket}, plus shopify/{customer, order, product}. Nous développons une application de devis et de négociation B2B. Il n'y avait pas de quote.

Ce n'est pas une limite souple que l'on contourne. shopify app deploy est atomique et rejette d'emblée un type d'intention non pris en charge : une mauvaise intention n'échoue donc pas seule, elle emporte toute votre version d'application. Nous avons livré des outils de lecture seule et mis le reste de côté. (Cette première phase est racontée à part dans construire une extension d'application Shopify Sidekick.)

Puis nous avons demandé. Shopify a ajouté application/quote à l'écosystème - pour toutes les applications de devis, pas seulement la nôtre.

Voici ce que nous avons appris, y compris la partie que nous avions entièrement mal modélisée.

Il existe une porte d'entrée, et c'est un dépôt public

Les types d'intention sont gouvernés à ciel ouvert, dans Shopify/app-intent-types. Vous ouvrez une discussion, présentez votre argumentaire, et un ingénieur de la plateforme vous répond. Au 7 octobre 2026, le dépôt liste quatorze types - onze application/* (ad, campaign, email, faq, loyalty-program, optimization-plan, quote, return, review, shipment, ticket) et trois shopify/* (customer, order, product) - et le guide des actions d'application de Shopify en ajoute un quinzième, shopify/Discount, pour les applications de réduction construites sur une Shopify Function. La liste reste courte, et le vôtre n'y est probablement pas encore.

Ce qui a fait aboutir la nôtre, par ordre d'importance approximatif :

Plaidez pour la catégorie, pas pour votre application. Nous avons demandé quote parce que les applications de devis et de négociation forment une classe reconnaissable d'applications Shopify, avec un objet commun, et non parce que QuotWay en avait besoin. Un type ajouté pour un éditeur est une dette de maintenance ; un type qui sert une catégorie est une fonctionnalité de plateforme. Rédigez la demande comme Shopify devrait la justifier en interne.

Apportez l'objet réel. Nous avons décrit ce qu'est réellement un devis - une demande d'acheteur qui est chiffrée, négociée sur plusieurs tours, puis convertie en commande - et quels champs portent du sens dans toutes les applications de la catégorie. Cette question (« que doit contenir le schéma ? ») est celle qu'il faut trancher avant de livrer quoi que ce soit : y répondre d'emblée supprime la principale raison de reporter.

Proposez des actions concrètes. Nous avons proposé open, send_proposal, counter et convert. Toutes ont été refusées. C'est malgré tout la partie la plus utile de la demande, car les raisons du refus nous ont enseigné le modèle - voir la section suivante. Une proposition concrète mais fausse vaut mieux qu'une proposition vague : elle donne à l'équipe plateforme quelque chose de précis à corriger.

Proposez de faire le travail. Nous avons proposé d'ouvrir la demande de fusion ajoutant l'entrée dans types/. Ils ont décliné et l'ont fait eux-mêmes, mais l'offre signale que vous maintiendrez ce que vous demandez.

Durée totale : demande déposée début juillet, approuvée le 27 août. Plus lent qu'une fonctionnalité que vous maîtrisez ; bien plus rapide que de contourner le manque pour toujours.

Ce que nous avions mal compris : une intention est un passage de relais, pas une commande

Voici la réponse qui a tout recadré, de l'ingénieur plateforme qui a approuvé le type :

« Nous n'ajoutons ni open, ni send_proposal, ni counter, ni convert : chaque type application/* prend en charge exactement create et edit. Une intention est un passage de relais, pas une commande. Le travail de Sidekick s'arrête quand le marchand se trouve dans votre application, avec le bon contexte chargé, et c'est votre interface qui décide de la suite. »

Nous avions modélisé les intentions comme une API de télécommande : une intention par verbe de notre produit. C'est faux, et une fois qu'on voit pourquoi, toute la surface se simplifie.

Deux conséquences à intégrer :

open est déjà ce que veut dire edit. Il n'existe pas d'action « juste montrer » distincte, parce que edit est un contrat de navigation, pas une mutation. Vous déclarez edit:application/quote et Sidekick amène le marchand sur votre page. Que cette page soit un éditeur ou une vue en lecture seule ne regarde que vous. Les extensions de référence de Shopify s'appellent littéralement open-email et open-campaign - et toutes deux déclarent action = "edit".

Vos verbes ne sont pas des intentions, ce sont des outils dans la page. send_proposal, counter et convert n'ont pas été abandonnés, ils ont été déplacés. Ce sont des outils qui s'exécutent une fois le devis ouvert et préparent l'action dans votre propre interface de confirmation. C'est-à-dire là où le marchand allait de toute façon appuyer sur le bouton. Nous essayions de hisser toute la surface de notre produit dans le vocabulaire d'intentions ; la plateforme vous dit de ne pas le faire.

Si vous vous apprêtez à déposer une demande pour six verbes, épargnez-vous un aller-retour : demandez le type, et concevez les verbes comme des outils.

La moitié qu'on oublie facilement

Déclarer l'intention ne fait rien à elle seule. Les deux conditions doivent être réunies :

1. vous déclarez une intention pour application/quote ;
2. vos résultats de recherche portent mimeType: "application/quote".

« C'est la correspondance entre le mimeType d'un lien de ressource et un type d'intention qui rend un résultat de recherche actionnable. »

C'est la connexion. Votre extension de données renvoie des liens de ressource ; un lien dont le mimeType correspond à une intention déclarée devient quelque chose que le marchand peut ouvrir, plutôt qu'une fiche qu'il ne peut que lire.

Nous émettions un type propriétaire - application/vnd.quotway.quote - ce qui était correct tant qu'aucun type standard n'existait, et qui est devenu le point bloquant dès qu'il en a existé un. Le correctif tient en deux chaînes :

-const QUOTE_MIME = "application/vnd.quotway.quote";
+const QUOTE_MIME = "application/quote";

-  uri: `gid://application/quotway.quote/${q.id}`,
+  uri: `gid://application/quote/${q.id}`,

Gardez les types propriétaires pour tout ce qui n'a pas de type d'intention. Nos synthèses de pipeline et nos règles de ciblage utilisent toujours application/vnd.quotway.*, parce qu'on ne peut pas ouvrir une synthèse de pipeline. Les marquer d'un type standard promettrait au marchand une action qui n'existe pas.

Le câblage, concrètement

Une extension d'intention est un admin_link, pas un ui_extension :

[[extensions]]
name = "Open quote"
description = "Open a specific QuotWay quote, quote request (RFQ), proposal or counteroffer…"
handle = "quotway-open-quote"
type = "admin_link"

  [[extensions.targeting]]
  target = "admin.app.intent.link"
  url = "/app/quotes/{id}"
  tools = "./tools.json"
  instructions = "./instructions.md"

    [[extensions.targeting.intents]]
    type = "application/quote"
    action = "edit"
    schema = "./intent-schema.json"

Et le schéma, où l'URL est réellement complétée :

{
  "$schema": "https://extensions.shopifycdn.com/shopifycloud/schemas/v1/intent.json",
  "value": {
    "type": "string",
    "description": "The GID of the quote to open.",
    "mapTo": "param",
    "fieldName": "id"
  },
  "inputSchema": {
    "$ref": "https://extensions.shopifycdn.com/shopifycloud/schemas/v1/application/quote.json",
    "type": "object",
    "properties": {
      "buyer_email": { "type": "string", "description": "…" },
      "company":     { "type": "string", "description": "…" },
      "total":       { "type": "number", "description": "…", "minimum": 0 },
      "message":     { "type": "string", "description": "…" }
    }
  }
}

Quatre points qui vous feront gagner du temps :

mapTo: "param" et fieldName remplissent le {id} de votre url. Les noms n'ont pas besoin de correspondre : fieldName est l'aiguillage.

Les GID sont tronqués pour vous. Quand une valeur associée à un param est un GID, Sidekick ne substitue que le segment après le dernier /. Ainsi, gid://application/quote/clx123abc arrive sous la forme clx123abc. Notre route existante attendait déjà cet identifiant, donc aucun changement de route - mais cela implique que la fin de votre GID doit être ce que votre routeur attend.

Les schémas publiés sont volontairement minimaux. application/quote publie id avec additionalProperties: true. Tout ce qui est propre au domaine - buyer_email, company, total, message - vous le déclarez vous-même sous inputSchema.properties. Le type standard est une poignée de main, pas un modèle de données.

Les outils étaient obligatoires. Jusqu'au 28 septembre 2026, Sidekick ignorait une extension qui déclarait des intentions sans outils : une cible de lien d'intention sans tools.json se déclarait sans erreur et ne se déclenchait jamais - c'est ce que nous avons rencontré. Shopify a changé cela : une extension est désormais éligible avec des outils, des intentions ou les deux, et une extension qui n'a que des intentions doit avoir un extensions_summary dans shopify.app.toml, sans quoi le déploiement suivant échoue. Ce sont toujours les outils qui permettent à Sidekick d'agir une fois la page ouverte.

Deux pièges

api_version n'est pas autorisé sur une extension admin_link. Nous l'avions recopié depuis nos fichiers TOML de ui_extension, et la configuration était invalide. Détecté par :

shopify app config validate --json

Lancez cela avant chaque déploiement. Le déploiement est atomique : une extension invalide n'échoue pas seule, elle fait échouer la version.

Le budget est plus serré qu'il n'y paraît : 5 intentions, et 20 outils partagés entre toutes les extensions que vous livrez. Notre extension de données en déclarait déjà 15. Ajouter trois outils de préparation dans la page plus un outil de pré-remplissage nous a menés à 19 sur 20. Si vous prévoyez une extension de données riche et des actions, budgétez d'abord les outils : vous manquerez d'outils bien avant de manquer d'intentions.

Si vous êtes dans cette situation

C'est probablement le cas si l'objet central de votre application ne figure pas dans la liste. En gros :

1. Regardez Shopify/app-intent-types - quelqu'un a peut-être déjà demandé.
2. Ouvrez une discussion pour votre catégorie, pas pour votre application. Décrivez l'objet, les champs qui se généralisent, et ce que les marchands demandent à voix haute.
3. Demandez le type ; concevez vos verbes comme des outils. create et edit sont ce que vous obtenez. Cela suffit.
4. Livrez l'extension de données en attendant. Les outils en lecture seule ne touchent pas au vocabulaire d'intentions : ils ne sont jamais bloqués. Quand votre type arrive, changer le type MIME est une modification de deux lignes.
5. Validez avant de déployer.

Le vocabulaire ressemble à un mur. C'est une file d'attente.

Sources

Revérifié le 7 octobre 2026 :

• Shopify/app-intent-types - la liste publiée, les deux voies pour proposer un type, et le partage create/edit pour application/* contre import/import+bulk pour shopify/Customer, shopify/Order et shopify/Product
• Shopify : créer des actions d'application pour Sidekick - la liste complète des types pris en charge, dont shopify/Discount avec create et edit, et l'entrée du changelog du 28 septembre 2026 qui a rendu éligibles les intentions sans outils
• Shopify : les extensions d'application Sidekick - le budget par application de 20 outils et 5 intentions, la limite de 4 000 jetons par réponse, et les budgets de réponse d'une seconde (données) et de trois secondes (action)

Le calendrier de la demande, la réponse citée et le nombre d'outils viennent de notre propre construction, en juillet et août 2026.

---

QuotWay est une application de devis et de négociation B2B pour Shopify. Le type d'intention application/quote est disponible pour toutes les applications de la catégorie - si vous en développez une, il est aussi à vous. Si vous êtes marchand plutôt que développeur, l'article destiné aux marchands explique ce que cela permet concrètement dans l'interface d'administration. L'intégration Sidekick de QuotWay fonctionne sur tous les forfaits, y compris le Lite gratuit - voir les forfaits et tarifs.