Build vs buy : ce que doit faire tourner une custom app Shopify de RFQ en 2026

Développez une custom app de RFQ sur Shopify quand le workflow de devis est lui-même le produit - une règle d'achat, une négociation dictée par un contrat, un document qu'aucune application ne produit - et que quelqu'un financera l'entretien de l'application au rythme du calendrier de Shopify aussi longtemps que la boutique vendra. Achetez quand le workflow est la boucle standard : demande, prix, négociation, validation, conversion. Ne développez que la différence quand un seul composant est unique et que le reste est standard. La partie difficile de la décision est rarement le premier développement ; c'est la seconde moitié de la première phrase, parce que Shopify change selon un calendrier trimestriel, que quelqu'un regarde ou non.

B2B natif, application de devis, développement sur mesure ou CPQ est la décision à quatre branches. Cette page est la version approfondie de sa branche « sur mesure » : ce qu'est une custom app en 2026 et où Shopify place une limite Plus, les vingt composants dont se compose réellement un système de RFQ sur Shopify, le journal de maintenance daté d'une application de devis en production - la nôtre - et une grille pour chiffrer les obligations plutôt que le lancement.

Tout ce qui concerne Shopify ci-dessous a été vérifié sur les pages de Shopify le 7 octobre 2026, en version d'API 2026-10 ; les sources sont en fin de page. Le journal de maintenance est une observation de QuotWay : l'historique d'une seule application sur quelques mois, pas un taux.

Ce qu'est une custom app en 2026

Une custom app (application personnalisée) est une application créée « exclusivement pour votre boutique Shopify ». Depuis la fermeture de la voie de l'admin, elle se crée et se gère dans le Dev Dashboard et se développe avec Shopify CLI, puis s'installe par un lien que vous générez. Les règles qui pèsent sur une décision de développement :

• Distribution. La distribution personnalisée installe l'application sur une seule boutique, ou sur les boutiques d'une seule organisation Shopify Plus. La distribution publique implique une fiche sur l'App Store et un examen. Ce que Shopify dit lui-même de qui utilise quoi : « La plupart des applications créées pour un marchand précis ou pour le client d'une agence utilisent la distribution personnalisée. »
• Le choix est définitif. Selon Shopify, la méthode de distribution ne peut plus être changée une fois choisie. Une agence qui pourrait un jour vendre la même application à d'autres marchands doit le décider maintenant.
• Pas d'examen, pas de Billing API. La distribution personnalisée échappe à l'examen des applications, et l'application ne peut pas facturer par la Billing API de Shopify - l'agence facture en dehors de Shopify.
• Plus d'applications créées dans l'admin. Depuis le 1er janvier 2026, les custom apps ne peuvent plus être créées dans l'admin Shopify. Les applications déjà créées dans l'admin continuent de fonctionner, mais elles n'ont jamais pu utiliser App Bridge ni les extensions d'application, et ne sont donc pas un point de départ pour un système de RFQ.
• Plusieurs clients, une seule base de code. La distribution personnalisée s'arrête à une organisation Plus : une agence qui sert des boutiques sans lien entre elles déploie une fiche d'application par boutique cliente à partir du même code - le guide de déploiement de Shopify autorise plusieurs fiches d'application sur une même base de code - ou passe en distribution publique.

Ce qu'une custom app peut utiliser, et où Plus décide

Surface	Dans une custom app	La limite de Shopify
Admin GraphQL API et webhooks	Oui	Étendues d'accès ; certaines exigent l'approbation de Shopify (read_users, pour l'identité du personnel, exige Plus ou Advanced)
Interface d'admin intégrée (App Bridge)	Oui	-
Extensions d'application de thème (bouton en boutique, blocs, intégration d'application)	Oui	Limites de taille par extension
Extensions d'interface de compte client (le portail de l'acheteur)	Oui	64 Ko par extension, 128 Ko pour une page complète
Extensions d'interface de paiement sur les étapes informations, livraison et paiement	Oui	Disponible uniquement sur Shopify Plus - pour toutes les applications, pas seulement les custom apps
Shopify Functions (validation, transformation du panier, remises)	Oui	Uniquement sur les boutiques Plus pour une custom app ; les applications publiques les utilisent sur tous les forfaits
Déclencheurs et actions Shopify Flow	Oui	Uniquement sur les boutiques Plus pour une custom app
Extensions d'application Sidekick	Non précisé	Les pages Sidekick de Shopify ne disent ni oui ni non
Billing API	Non	La distribution personnalisée ne peut pas l'utiliser
Built for Shopify	Sans objet	Un programme de l'App Store, avec des prérequis d'installations et d'avis

Shopify formule la règle des extensions par la négative : les extensions d'application ne sont indisponibles que pour les applications créées dans l'admin. Une custom app développée avec la CLI peut les utiliser, dans les limites ci-dessus.

Jetons, données et hébergement

Jetons d'accès. Une application intégrée obtient son jeton par échange de jetons (token exchange) ; une application non intégrée par l'octroi de code d'autorisation (authorization code grant) ; une intégration côté serveur qui ne touche que les boutiques de votre propre organisation peut utiliser l'octroi par identifiants client (client credentials grant), qui émet des jetons de 24 heures sans écran d'approbation du marchand. Les jetons hors ligne expirants (une heure, renouvelables pendant 90 jours) deviennent obligatoires pour les applications publiques le 1er janvier 2027 - et Shopify précise que « cela ne s'applique pas aux applications personnalisées ni aux applications créées par les marchands », dont les jetons restent valides jusqu'à la désinstallation de l'application ou la révocation de son secret client. Passez quand même aux jetons expirants : un identifiant permanent détenu par une agence est exactement ce que la revue de sécurité d'une boutique est chargée de trouver.

Étendues d'accès. « Toute étendue qui permet d'écrire une ressource accorde aussi l'accès en lecture à celle-ci » - et la liste des étendues accordées de Shopify n'affiche alors que l'étendue d'écriture. Cette seule phrase a causé un bug en production dans notre propre application (voir plus bas). read_orders couvre les 60 derniers jours ; les commandes plus anciennes exigent read_all_orders, qui doit être demandée.

Données clients. Les données clients protégées de niveau 1 et de niveau 2 sont « toujours disponibles » pour les custom apps sans examen, là où les applications publiques doivent passer un examen ; Shopify « encourage toutes les applications » à respecter les mêmes exigences, et le centre d'aide ajoute que les « applications personnalisées avec des données personnelles de niveau 2 » exigent le forfait Grow ou supérieur. Les trois webhooks de conformité sont une exigence de l'App Store, mais Shopify envoie customers/data_request à toute application installée qui a accès aux clients ou aux commandes, et la loi sur la protection des données du marchand s'applique quoi qu'il arrive - un développement sur mesure implémente donc lui aussi ces handlers.

Hébergement. « Shopify n'héberge que le code de votre extension. » Le backend, sa base de données, sa file d'attente et chaque endpoint que Shopify appelle - les récepteurs de webhooks avec leur délai de cinq secondes, le proxy d'application derrière le formulaire en boutique - tournent sur un hébergement que vous choisissez et entretenez.

Les vingt composants d'un système de RFQ sur Shopify

Shopify n'a pas d'objet devis. Une commande provisoire est remplacée en bloc à chaque mise à jour et supprimée au bout d'un an sans modification : elle peut porter l'accord conclu à la fin, mais pas la négociation qui le précède (pourquoi une commande provisoire n'est pas un devis). Tout le reste est à développer :

#	Composant	Surface Shopify sur laquelle il repose	La partie difficile
1	Capture de la demande : bouton, formulaire, devis depuis le panier	Extension d'application de thème ; proxy d'application pour les envois signés	L'éligibilité par acheteur et par entreprise sans aller-retour lent ; la variété des thèmes ; le poids en boutique
2	Visibilité des prix	Extension d'application de thème ; une condition Liquid dans le thème pour garder les prix hors du HTML	Un masquage en CSS ou en script n'est que visuel (masquer les prix)
3	Enregistrement du devis et versions immuables	Votre base de données	Une version envoyée ne change jamais ; un changement est une nouvelle version
4	Négociation et contre-propositions	Votre base de données et une surface acheteur	À qui c'est le tour ; une ligne que l'acheteur n'a pas retenue reste ouverte, elle n'est pas perdue
5	Prix de départ	contextualPricing pour le site de l'entreprise (avec auditTrail à partir de 2026-10)	La priorité entre catalogues ; jamais une seconde liste de prix (le prix de départ)
6	Totaux et montants	Votre code ; draftOrderCalculate pour la vue de Shopify	Stocker le montant convenu ; ne jamais re-sommer les lignes affichées
7	Validations et piste d'audit	Votre base de données ; l'identité du personnel via une étendue soumise à approbation	Application des règles côté serveur, décisions en ajout seul (matrice de validation)
8	Documents	Votre backend	Un document par version ; ce qu'un devis doit contenir
9	Notifications par e-mail	Votre backend et un fournisseur d'e-mail	Délivrabilité, listes de suppression, renvois sans risque
10	Portail acheteur	Extension d'interface de compte client et un backend que vous hébergez	Authentifier l'extension auprès de votre backend ; les invités sans compte (construire le portail)
11	Conversion en commande provisoire	draftOrderCalculate, draftOrderCreate avec purchasingEntity, prix forcés, conditions de paiement	Pas de clé d'idempotence sur draftOrderCreate, même en 2026-10 (exactement une commande provisoire) ; l'écart entre devis et conversion (17 modes de défaillance)
12	Webhooks et réconciliation	orders/*, draft_orders/*, app/* et les sujets de conformité	Doublons, ordre d'arrivée, la commande qui arrive avant votre propre écriture, un balayage pour les livraisons manquées
13	Interface d'admin	Application intégrée (App Bridge, Polaris), blocs d'admin facultatifs	Chaque écran est à construire et à garder au pas de l'admin Shopify
14	Permissions du personnel	Votre propre modèle	Qui peut envoyer, valider et convertir (devis par les commerciaux)
15	Multidevise et marchés	Prix contextuels par pays ; devise de présentation sur la commande provisoire	Figer le taux au moment du devis
16	Traductions	Fichiers de langue par extension, plus vos propres chaînes	Chaque chaîne visible par l'acheteur, dans chaque surface
17	Statistiques	Votre base de données - les rapports Shopify ne voient pas les devis	Valeur proposée contre valeur acceptée ; répartition des devises
18	Intégrations et automatisation	Extensions Flow (uniquement sur les boutiques Plus dans une custom app), votre propre API et vos webhooks, extensions Sidekick	Chaque surface a son propre versionnage (modèles ERP, CRM et PIM)
19	Conformité et données	Webhooks de conformité, données clients protégées	L'effacement dans chaque table qui contient des données d'acheteur
20	Hébergement et exploitation	Votre hébergement, base de données, file d'attente, suivi des erreurs	La disponibilité des endpoints que Shopify appelle ; sauvegardes ; secrets

Pour donner l'échelle, voici la forme d'une application de devis livrée - la nôtre, lue dans son dépôt le 7 octobre 2026 : 27 extensions d'application (une extension d'application de thème avec une intégration d'application et quatre blocs ; deux extensions d'interface de compte client ; un bloc d'admin ; 19 extensions Flow - dix déclencheurs, trois actions, six modèles ; trois extensions Sidekick), 10 sujets de webhook (les trois sujets de conformité plus sept) et 53 modèles de données. Dans une custom app sur une boutique qui n'est pas sur Plus, les 19 extensions Flow seraient indisponibles.

Ce que la maintenance représente vraiment

Voici l'historique d'une seule application, tenu par ses mainteneurs. Ce n'est pas un taux - mais chaque élément est arrivé au rythme de Shopify, pas au nôtre.

Dix-huit jours de changements Shopify. En revérifiant nos faits Shopify pour la version 2026-10, nous avons consigné 17 changements datés sur la surface B2B et applications entre le 20 septembre et le 7 octobre 2026. Parmi eux :

• Sidekick a commencé à invoquer les extensions qui ne déclarent qu'une intention (28 septembre).
• Une nouvelle intention d'application pour les remises (30 septembre).
• L'API 2026-10 est passée stable, avec 2027-01 en release candidate et 2025-10 hors support à partir du 16 octobre.
• priceRule a été retiré des avertissements de remise des commandes provisoires, et orderUpdate a commencé à recalculer la taxe quand l'adresse de livraison change.
• Les relations parent-enfant entre marchés sont arrivées.
• La Customer Account API a perdu lastIncompleteCheckout.
• Les Events sont passés en disponibilité générale, à côté des webhooks classiques.
• Les modifications de commande demandées par l'acheteur sont arrivées.

La même passe a corrigé neuf de nos propres affirmations publiées. La compréhension du mainteneur dérive elle aussi, pas seulement l'API ; la revérification consigne les deux.

Une montée de version est un audit, pas une modification de configuration. Notre passage de l'API 2026-04 à 2026-07 a modifié 40 fichiers : versions des bibliothèques, version d'API dans les 24 configurations d'extension, et un schéma régénéré contre lequel chaque opération d'admin a été validée. Le changelog de Shopify n'indiquait aucun changement cassant sur notre surface. La validation du schéma a pourtant trouvé deux opérations invalides depuis toujours - une recherche de commande provisoire qui demandait un champ inexistant, ce qui faisait échouer une tâche de réconciliation sur chaque ligne, et une mutation appelée avec une mauvaise forme d'argument. Pour 2026-10, une recherche dans le code de chaque champ retiré ou déprécié ne renvoie rien, il n'y a donc pas de casse connue - et la montée touche quand même ces 24 configurations et les versions épinglées de l'application elle-même.

L'étendue implicite. Le 30 septembre, notre contrôle des conditions de paiement exigeait à la fois read_payment_terms et write_payment_terms dans les étendues accordées. Shopify ne liste que l'étendue d'écriture quand les deux sont accordées, puisque l'écriture implique la lecture - les boutiques qui avaient accordé la permission étaient donc traitées comme si elles ne l'avaient pas fait, et convertir un devis avec des conditions de paiement était bloqué jusqu'à un correctif livré le jour même. Les données de test utilisaient un format d'étendue que Shopify n'envoie jamais.

Des erreurs de validation à la conversion. En juillet, draftOrderCalculate rejetait chaque devis d'entreprise bien formé avec « Cannot send both customer and purchasing_entity » jusqu'à ce que les deux soient rendus mutuellement exclusifs. L'erreur suivante était « An issue date is required with net payment terms » : les conditions à échéance exigent un échéancier de paiement, si bien que l'écran de conversion a dû demander une date d'émission au marchand.

Un avis de sécurité sur une bibliothèque. En août, un avis de sécurité visant la bibliothèque d'applications de Shopify (validation HMAC du proxy d'application) a imposé de passer à la version majeure corrigée. Notre propre contrôle du proxy n'était pas concerné, mais la mise à niveau exigeait un environnement Node.js plus récent et une modification du code pour une propriété supprimée.

Le budget en boutique. Le script de la boutique est plafonné à 108 Ko par un contrôle de taille du bundle. Il pèse aujourd'hui 105 050 octets, environ trois fois les 10 Ko compressés que suggère Shopify, et le plafond a été relevé dix fois en quatre semaines à mesure que des fonctionnalités sortaient à la mi-2026 (ce que cela coûte à une boutique).

Étendues et permissions. Entre mai et juillet 2026, les étendues demandées ont changé à plusieurs reprises :

• Une étendue qui n'existe pas a été rejetée par la validation du déploiement.
• Les étendues B2B ont été rendues obligatoires, puis remises en facultatif, parce que les exiger bloquait l'installation par un membre du personnel sans permission de voir les données d'entreprise.
• Une étendue restreinte liée au personnel a été rejetée faute d'approbation de Shopify.
• Deux étendues inutilisées ont été retirées avant la soumission à l'App Store.

Une custom app échappe à la moitié App Store de tout cela, pas au reste.

Le budget découle du journal : au minimum un audit d'API par trimestre, une revue des étendues et des permissions chaque fois qu'une fonctionnalité touche une nouvelle ressource, et une tâche de réconciliation dès le premier jour. La dette technique Shopify B2B réunit les surfaces datées dans un seul calendrier.

Ce qui fait le coût

Nous ne publions aucun chiffre de coût - aucun jeu de données ne soutiendrait ceux que nous pourrions donner. Les facteurs, eux, se comptent, et chacun est une obligation continue plutôt qu'une tâche de lancement :

• Les surfaces. Chaque type d'extension - boutique, compte client, admin, Flow, paiement - a ses propres limites et son propre chemin de mise à jour.
• Les dépendances à Plus. Les Functions, les extensions Flow dans une custom app et les extensions des étapes de paiement n'existent que sur les boutiques Plus.
• Les boutiques et les organisations. Une fiche d'application par boutique sans lien avec les autres ; la distribution ne peut pas changer plus tard.
• Le portail acheteur. Une extension de compte client plus un backend authentifié que vous hébergez.
• La conformité et les données. Des handlers d'effacement et des garde-fous pour les données protégées dans chaque table.
• Les intégrations. Chaque système externe ajoute une synchronisation, une réconciliation et un mode de défaillance.
• Le calendrier. Quatre versions d'API par an, chacune prise en charge au moins 12 mois, puis une bascule silencieuse vers la plus ancienne version prise en charge.
• L'exploitation. Hébergement, supervision et quelqu'un d'astreinte pour des endpoints dont Shopify attend une réponse en quelques secondes.

La grille : développer, acheter ou hybride

Copiez le tableau, une ligne par composant de l'inventaire ci-dessus, et remplissez-le avec le client :

Composant	Développer / acheter / hybride	Responsable	Surface Shopify	Obligation continue	Limité à Plus ?	Qui est alerté quand ça casse
Capture de la demande			Extension d'application de thème, proxy d'application	Compatibilité des thèmes, poids du script	Non
Conversion en commande provisoire			Admin API	Idempotence, écarts, audit d'API trimestriel	Non
Règle de paiement (par exemple un numéro de bon de commande obligatoire)			Functions	Versions de l'API Functions	Oui, dans une custom app
Validations et piste d'audit			Votre base de données, étendue liée au personnel	Application des règles, approbation de l'étendue	Étendue liée au personnel : Plus ou Advanced
…

Puis répondez à sept questions :

1. Le workflow est-il unique, ou un seul composant l'est-il ? Un seul composant, c'est l'hybride.
2. Qui finance l'audit d'API chaque trimestre pendant toute la vie de la boutique ?
3. La boutique est-elle sur Plus, et la conception a-t-elle besoin des Functions, des extensions Flow ou des extensions des étapes de paiement ?
4. Combien de boutiques, dans combien d'organisations ? La distribution personnalisée couvre une seule organisation Plus, et le choix est définitif.
5. Les acheteurs doivent-ils agir dans leur compte client ? C'est une extension plus un backend que vous hébergez.
6. Qui est responsable de la conformité - les webhooks d'effacement et le traitement des données protégées ?
7. Quelle est la sortie ? Qui détient le code, les données et les identifiants si la relation avec l'agence prend fin - sachant que le jeton d'une custom app n'expire pas de lui-même.

La voie hybride

Achetez une application pour le workflow standard et ne développez que la partie unique - une synchronisation ERP, une prise de demande headless, un service de tarification dont une personne applique ensuite le résultat. La condition est que l'application expose les événements et les endpoints dont la partie unique a besoin : vérifiez donc ce que son API ne peut pas faire avant de cadrer le projet.

L'API REST et les webhooks signés de QuotWay, à titre d'exemple énoncé précisément : disponibles sur le forfait Enterprise, y compris pendant l'essai gratuit de 14 jours. L'API lit les devis avec leurs lignes, leurs totaux et leurs événements, crée des demandes de devis, publie des messages, envoie une proposition qu'une personne a déjà chiffrée, liste les documents et lit les statistiques. Elle ne peut pas fixer ni modifier les prix, modifier les lignes, accepter ou refuser à la place de l'acheteur, ni convertir un devis en commande provisoire, et les charges utiles des webhooks ne contiennent aucune donnée personnelle de l'acheteur. Ce que vous pouvez construire avec l'API QuotWay détaille six intégrations ; la check-list d'évaluation est le test à appliquer à l'API de n'importe quel éditeur. Les forfaits sont sur la page des tarifs, et l'API elle-même est décrite sur la page API et webhooks.

Questions fréquentes

Qu'est-ce qu'une custom app Shopify ?

Une application créée pour une seule boutique, ou pour les boutiques d'une seule organisation Shopify Plus, dans le Dev Dashboard, et installée par un lien que vous générez. Elle n'a ni fiche sur l'App Store ni examen. Depuis le 1er janvier 2026, elle ne peut plus être créée dans l'admin Shopify.

Comment créer une custom app maintenant que l'option de l'admin a disparu ?

Créez l'application dans le Dev Dashboard - avec Shopify CLI si elle a une interface ou des extensions -, choisissez la distribution personnalisée, et générez le lien d'installation pour la boutique. Les applications créées dans l'admin avant 2026 continuent de fonctionner.

Quelle est la différence entre une custom app et une application publique ?

Une custom app s'installe sur une seule boutique ou une seule organisation Plus, échappe à l'examen, ne peut pas utiliser la Billing API, et ne peut utiliser les Functions et les extensions Flow que sur Plus. Une application publique s'installe sur n'importe quelle boutique via l'App Store, passe l'examen, peut facturer par Shopify et peut utiliser les Functions sur tous les forfaits. Le choix ne peut pas être changé plus tard.

Une custom app peut-elle utiliser les Shopify Functions ?

Oui, mais uniquement sur une boutique Shopify Plus, et il en va de même pour ses extensions Flow. Les extensions d'interface de paiement sur les étapes informations, livraison et paiement sont disponibles uniquement sur Shopify Plus, pour toutes les applications.

Les custom apps passent-elles un examen, et peuvent-elles être Built for Shopify ?

La distribution personnalisée n'a pas d'examen des applications. Built for Shopify est un programme de l'App Store, avec des prérequis d'installations et d'avis : il ne s'applique donc pas à une custom app.

Comment une custom app obtient-elle un jeton d'accès ?

Une application intégrée utilise l'échange de jetons ; une application non intégrée utilise l'octroi de code d'autorisation ; une intégration côté serveur sur les boutiques de votre propre organisation peut utiliser l'octroi par identifiants client, qui émet des jetons de 24 heures. Les custom apps sont exemptées de l'obligation de jetons expirants de 2027, mais y passer est plus sûr.

Qui héberge une custom app ?

Vous. Shopify n'héberge que le code des extensions - blocs de thème et extensions d'interface. Le backend, sa base de données et chaque endpoint que Shopify appelle tournent sur un hébergement que vous choisissez et entretenez.

Combien coûte une custom app Shopify de RFQ ?

Nous ne publions aucun chiffre. Le coût dépend des surfaces que vous développez, des dépendances à Plus, du nombre de boutiques, du portail acheteur, de la conformité, des intégrations et de l'hébergement - et de l'audit d'API de chaque trimestre, aussi longtemps que la boutique vend.

Peut-on acheter une application et ne développer que la partie unique ?

Oui, si l'application expose les événements et les endpoints dont la partie unique a besoin. Vérifiez d'abord ce que son API ne peut pas faire : l'API de QuotWay, par exemple, est réservée au forfait Enterprise et ne peut pas fixer les prix, modifier les lignes, accepter à la place de l'acheteur ni convertir.

Sources

Pages Shopify, lues le 7 octobre 2026 en version d'API 2026-10 :

• Custom apps - créées exclusivement pour une boutique ; données personnelles de niveau 2 et forfaits
• About app distribution et select a distribution method - distribution personnalisée ou publique, une seule organisation Plus, choix définitif, pas d'examen, pas de Billing API, applications créées dans l'admin et extensions, la phrase de Shopify sur « la plupart des applications créées pour un marchand précis »
• Changelog : legacy custom apps can't be created after 1 January 2026 - publié le 30 octobre 2025 ; les applications existantes continuent de fonctionner
• Shopify Functions - custom apps avec des Functions uniquement sur Plus
• Shopify Flow for apps - extensions Flow dans les custom apps uniquement sur Plus
• Checkout UI extensions - étapes informations, livraison et paiement sur Plus
• Customer account UI extensions - limites de taille ; « Shopify n'héberge que le code de votre extension »
• Authentication and authorization, client credentials grant et offline access tokens - échange de jetons, code d'autorisation, identifiants client à 24 heures, l'exemption des custom apps pour les jetons expirants
• Access scopes - l'écriture implique la lecture ; read_all_orders ; étendues soumises à approbation
• Protected customer data et privacy law compliance - disponibilité pour les custom apps ; webhooks de conformité
• API versioning et release notes 2026-10 - versions trimestrielles, durées de support, bascule vers l'avant, les changements de 2026-10
• Deploy your app - fournisseurs d'hébergement ; plusieurs fiches d'application sur une même base de code
• Built for Shopify requirements - un programme de l'App Store, avec des prérequis d'installations et d'avis

Notre propre historique : la revérification en 2026-10 de la référence Shopify B2B, et l'historique du dépôt de l'application QuotWay, lu le 7 octobre 2026 - décrit ici sans noms internes.