Le dashboard store : ce qui est construit, et ce qui est débranché
Date : 2026-09-20 · Demandé par : le propriétaire · Méthode : mesure, pas lecture
Date : 2026-09-20 · Demandé par : le propriétaire · Méthode : mesure, pas lecture
« Assure-toi qu'il ne manque rien, assure-toi que tout est bien cohérent et surtout, assure-toi que nous n'avons pas créé des choses dans la code base qui ne servent absolument à rien actuellement ou du moins qui n'est pas encore connecté. Le but, c'est de tout récupérer, de tout connecter et de tout utiliser ou de nettoyer. »
Ce que cet audit corrige d'abord
Une réponse donnée le même soir, et fausse : « collections, menus, metafields, metaobjects, discounts, markets sont absents ».
C'était vrai de la surface MCP. Ce ne l'est pas du code. La correction est le résultat principal de cet audit, parce qu'elle inverse la décision qu'elle allait provoquer : on s'apprêtait à écrire des ingestions qui dorment déjà dans le dépôt.
Le chiffre
src/features/shopify/mcp/shopify/client.ts implémente 72 méthodes.
70 n'ont aucun appelant.
for m in $(grep -oE "^ async [a-zA-Z]+" src/features/shopify/mcp/shopify/client.ts | sed 's/ async //'); do
n=$(grep -rn "\.$m(" src/ --include=*.ts --include=*.tsx | grep -v "mcp/shopify/client.ts" | wc -l)
echo "$n $m"
done
Les deux vivantes : execute (18 appels, la primitive GraphQL) et
getProduct (1). Tout le reste est écrit, typé, et n'est atteint par
aucune surface.
Ce n'est pas du code mort au sens de knip : ces méthodes sont
appelables, correctes, et c'est précisément ce qui les rend coûteuses.
Elles donnent l'illusion d'une capacité que le produit n'expose pas.
L'écart, famille par famille
| Famille | Écrit dans le client | Exposé par le MCP |
|---|---|---|
| Produits | getProduct(s), updateProduct | getProduct, listProducts |
| Collections | getCollection(s), updateCollection | rien |
| Menus / navigation | getMenu, getMenus | rien |
| Metafields | getMetafields, setMetafield, setMetafieldsBulk, deleteMetafield | rien |
| Metaobjects | getMetaobjects, getMetaobjectDefinitions, create / update / delete | rien |
| Pages | getPage(s), createPage, updatePage | listPages (lecture seule) |
| Blog / articles | getBlogs, getArticle(s), createArticle, updateArticle | rien |
| Thème | getThemeFiles, updateThemeFile, upsertThemeFiles, deleteThemeFile | getTheme, listThemes |
| Marchés / locales | getMarket(s), updateMarket, getShopLocales, getPublications | rien |
| Remises | getDiscountNodes, createBasicDiscountCode | rien |
| Clients | getCustomer(s), getCustomerSegments | rien |
| Traductions | getTranslatableResources, registerTranslations, removeTranslations | rien |
| Opérations en masse | bulkOperationRunQuery, bulkOperationRunMutation, currentBulkOperation | rien |
| Redirections, gift cards, fulfillments, inventaire, paniers abandonnés, webhooks | écrits | rien |
Le MCP expose 19 outils, dont 12 touchent Shopify, et presque tous en
lecture. L'écriture passe par la seule échappatoire générique,
shopifyAdminGraphQL : rien de typé, rien de mis en cache, rien qu'un
System puisse relire.
Le seul vrai manque : la Files library
C'est le trou que le propriétaire avait identifié seul, et le seul de cette page qui demande d'écrire du neuf plutôt que de brancher.
Aucun fileCreate, aucun stagedUploadsCreate, aucune requête files
racine. Les trois occurrences de files( dans le client sont des
fichiers de thème, pas la médiathèque.
Conséquence mesurable : un visuel généré par le Studio vit sur Vercel Blob et ne peut être attaché à rien dans Shopify sans qu'un humain le télécharge et le re-téléverse dans l'admin. Le pont doit aller dans les deux sens : lire la librairie pour savoir ce que la marque possède déjà, y pousser nos rendus pour qu'ils deviennent attachables partout.
Trois autres écarts, mesurés
Le registre Systems ne câble rien. Son propre en-tête l'écrit :
ai.toolName, ai.skillId, mcp.endpoint et pricing.* « sont lus
uniquement pour être AFFICHÉS sur les pages marketplace ». Ajouter un
System aujourd'hui ajoute une page marketing, pas une capacité. C'est le
blocage de « n'importe quel système » : sans lui, chaque générateur se
branche à la main, une fois par format.
Six connecteurs, aucun de distribution. figma, google, klaviyo,
meta, notion, shopify-partners. Un marchand ne peut connecter aucun
réseau social. Postiz est notre outil interne, authentifié par une clé
unique — la nôtre — donc un brouillon poussé depuis la boutique d'un
client atterrirait sur nos comptes. Ce n'est pas une limite à contourner,
c'est la preuve qu'il faut l'autre modèle : un connecteur par réseau que
le marchand possède, portant SON jeton.
L'analytique n'a pas été mesurée. Ni ce que les connecteurs Meta et Google lisent réellement. C'est une lacune de cet audit, pas un constat : l'affirmer sans l'avoir mesurée serait exactement le défaut que cette page corrige.
Ce qu'il faut en faire
L'ordre découle du chiffre, pas d'une préférence.
- Brancher avant d'écrire. Soixante-dix méthodes attendent une surface. Chaque outil MCP ajouté est une ligne de registre et un scope, pas une intégration.
- Rendre le registre Systems exécutant. Sinon le point 1 se refait à la main à chaque famille.
- Écrire le pont Files library, le seul neuf.
- Un connecteur par réseau que le marchand possède.
- Mesurer l'analytique, qui est le trou de cet audit.
Ce que cette page ne prouve pas
Qu'une méthode sans appelant est correcte. Elles n'ont jamais été exercées contre une vraie boutique par un chemin de production. Les brancher, c'est les tester pour la première fois : chaque famille a besoin de sa vérification, pas seulement de sa ligne de registre.