Shipt Kits : préserver la promesse d’une offre quand le stock varie selon le magasin

Un kit de courses peut être cohérent dans un catalogue central et incomplet dans le magasin où le client veut commander. Pour éviter cette rupture entre offre affichée et produits disponibles, il faut décider ce qui rend le kit valide localement, quelles règles limitent sa diffusion et ce qui se passe quand un catalogue répond lentement. Le cas Shipt apporte des exemples concrets de ces arbitrages, sans démontrer qu’une architecture identique conviendrait à tout site marchand.

Dans un article publié par InfoQ le 14 octobre 2026, l’équipe décrit la conception de Shipt Kits, une fonction permettant d’ajouter en un clic au panier un ensemble de produits associé à une occasion. Chaque kit présenté devait tenir compte du magasin du client.

Les choix d’architecture évoqués ci-dessous sont ceux rapportés dans le récit de l’architecture de Shipt Kits publié par InfoQ.

Choisir entre un assortiment universel et une offre locale

Un catalogue universel simplifie la définition éditoriale : la même composition est préparée une fois et présentée partout. Mais cette simplicité peut masquer un problème opérationnel. Si les produits ne sont pas disponibles dans le magasin choisi, le kit peut sembler complet dans l’outil de gestion tout en décevant le client au moment de l’achat.

À l’inverse, une offre résolue localement vérifie ce qui peut réellement être proposé dans le contexte du client. Elle demande de traiter séparément la composition souhaitée et sa matérialisation dans chaque enseigne ou magasin. Le compromis n’est donc pas seulement technique : l’entreprise choisit entre une promesse uniforme et une promesse conditionnée par la disponibilité locale.

Choix	Ce qu’il simplifie	Point à maîtriser
Assortiment commun	La création éditoriale et la définition d’une offre centrale	Les écarts entre le contenu prévu et le stock du magasin
Résolution locale	L’adaptation des produits proposés au magasin concerné	Les règles de disponibilité, d’éligibilité et de réponse des catalogues

Avant Kits, l’assemblage reposait sur une chaîne manuelle : sélectionner des UPC, les convertir en identifiants propres aux distributeurs, construire une catégorie puis une liste, avant de raccorder celle-ci à l’emplacement de la promotion.

Le cas rapporté par InfoQ indique que cette méthode ne garantissait pas que tous les articles soient disponibles dans le magasin du client. Pour les responsables produit et SI, le besoin à cadrer est donc précis : à quel moment l’offre devient-elle locale, et quel contrat l’interface doit-elle respecter lorsqu’elle ne peut pas être servie ?

Définir ce qui rend encore le kit reconnaissable

Retirer tout article indisponible n’est pas toujours acceptable. Si un produit est central à la promesse — l’exemple donné par l’équipe est celui d’un kit de grillade sans viande — le kit restant peut ne plus correspondre à son intitulé. Shipt distingue ces articles essentiels, appelés « anchor items », des autres produits de la composition.

Le kit n’est présenté que si tous ses items d’ancrage sont disponibles dans le magasin et si le nombre total d’articles disponibles atteint le seuil minimal défini. Ce mécanisme transforme une décision éditoriale en règle vérifiable : il ne suffit pas de tester si un article est absent, il faut définir ce qui invalide l’offre entière.

Une PME qui conçoit une offre groupée gagnera à fixer cette règle avec les métiers avant le développement : quels produits sont indispensables, quel niveau de substitution est toléré et à partir de quelle composition l’offre doit-elle disparaître ? Ces critères doivent devenir des cas de recette, plutôt que rester des attentes implicites.

Faire porter les règles locales au bon niveau

Le modèle décrit sépare les items, les listes de courses et les kits. Un item représente une unité de catalogue ; une liste organise des items ; un kit porte notamment les informations éditoriales et les références aux éléments qui le composent. Les items peuvent être réutilisés dans plusieurs listes et kits, au lieu d’être copiés dans chaque offre.

Les items ne sont pas propres à un distributeur : la résolution vers l’identifiant produit d’un magasin intervient au moment de l’affichage, et non lors de la modélisation de l’item. Cette séparation permet de distinguer l’identité métier d’un produit de sa correspondance dans un catalogue local. Elle évite aussi de faire de chaque nouvelle offre une copie indépendante de ses produits.

Pour cadrer un projet comparable, documentez les objets métier, leurs responsabilités et les règles qui leur appartiennent. Un bon cahier des charges informatique doit préciser les résultats attendus et les critères d’acceptation sans figer trop tôt une solution.

Pour les interfaces entre composants, la définition des contrats et de leur évolution rejoint les enjeux d’une API maintenable.

Traiter l’éligibilité comme une règle explicite

La disponibilité ne suffit pas toujours à autoriser une offre. Dans l’exemple Shipt, le magasin doit aussi appartenir aux distributeurs autorisés pour le kit et, dans certains cas, satisfaire des conditions supplémentaires. L’équipe décrit une résolution par intersection entre les magasins accessibles au client, ceux autorisés pour le kit et ceux qui répondent aux critères particuliers de la catégorie.

Pour les kits d’alcool, le type porte les contrôles d’éligibilité et de juridiction, au lieu de disperser ces règles dans le parcours générique du kit. L’article décrit notamment la vérification de la licence du magasin et des contraintes associées à la zone de livraison. C’est une manière de garder les règles particulières attachées à la catégorie concernée, plutôt que d’accumuler des exceptions dans chaque étape commune.

Ce choix ne dispense pas de préciser les responsabilités : qui maintient les règles d’éligibilité, quelles données les alimentent et comment leur résultat est testé ? Il aide en revanche à rendre visibles les différences entre une offre ordinaire et une offre soumise à des contraintes spécifiques.

Empêcher un catalogue lent de bloquer toute l’offre

Une offre locale peut dépendre de plusieurs catalogues de distributeurs. L’équipe de Shipt indique avoir interrogé les catalogues éligibles en parallèle, plutôt que l’un après l’autre. Les appels aux catalogues des détaillants sont exécutés en parallèle ; si un détaillant ne répond pas dans son délai, son résultat est omis de la vue du kit plutôt que de bloquer ou faire échouer la requête.

Cette dégradation partielle suppose une décision produit : l’absence d’un distributeur peut-elle être tolérée si d’autres résultats restent disponibles ? La réponse dépend de la promesse faite au client et des règles du kit. Le même principe ne convient pas si l’information manquante est indispensable pour garantir une offre correcte.

Le traitement des produits sponsorisés illustre cette différence. Dans l’architecture décrite, le comportement face à un article sponsorisé indisponible peut être défini par kit : masquer l’article ou masquer le kit. Le contrat commercial et l’expérience client doivent donc être arbitrés ensemble, puis traduits en règle testable.

Prévoir les contrôles avant de modifier une offre publiée

Le modèle décrit autorise la modification de kits publiés sans cycle complet de brouillon et de publication. L’équipe rapporte avoir compensé ce choix par plusieurs garde-fous, dont un avertissement persistant et une confirmation au premier changement. Cela rappelle un arbitrage de livraison important : si une validation complète n’est pas disponible, les contrôles allégés doivent être conçus autour des risques réels, pas ajoutés comme une simple formalité.

Pour estimer un projet similaire, séparez les postes à instruire : administration des offres, correspondance des produits par magasin, règles de validité, intégrations de catalogues, gestion des délais de réponse et protection des modifications en production.

Le récit d’InfoQ indique que l’équipe disposait de trois semaines pour le lancement, avec l’API réalisée en dix jours puis le travail sur l’interface d’administration, les surfaces client et la mise en condition opérationnelle. Ce calendrier décrit ce projet précis ; il ne constitue pas une estimation applicable à une autre entreprise.

• Définir quels produits sont indispensables à chaque offre et comment traiter leur indisponibilité.
• Identifier les magasins autorisés et les règles propres aux catégories particulières.
• Décider quand un résultat partiel reste présentable et quand le kit doit être masqué.
• Demander des critères de recette couvrant la disponibilité locale, les délais et les modifications d’offres publiées.

La décision centrale n’est donc pas de rendre chaque offre « composable » par principe. Elle consiste à rendre explicite la promesse faite au client, puis à vérifier que le modèle métier, les règles locales et le comportement en cas d’incident la respectent. Dans le cas Shipt, ces règles sont rapportées comme des choix d’une plateforme particulière : leur intérêt pour une PME est d’offrir des questions de cadrage, pas une architecture à recopier.