---
title: "Quand le devis et la commande Shopify divergent : ce qui dérive après la conversion"
description: "Après conversion, devis, commande provisoire, commande et ERP divergent de 19 façons documentées : les détecter, les réparer, et qui possède quel champ."
url: "https://www.quotway.com/fr/blog/quote-to-order-out-of-sync"
type: "blog post"
category: "For Shopify agencies"
published: "2026-10-09"
verified: "2026-10-09"
shopify_api_version: "2026-10"
audience: "Agences et développeurs Shopify qui maintiennent l'accord entre une couche de devis, Shopify et un ERP ou un CRM après la conversion"
scope: "Après la conversion en API 2026-10 : modifications du brouillon et checkouts déliés, brouillons supprimés et purgés, factures impayées, webhooks de commande manqués, modifications de commande, modifications demandées par l'acheteur, annulations, remboursements et expédition, affaires fractionnées, devise, clés de liaison et tags écrasés, changements d'identité, propriété des champs, Events ou webhooks, et une tâche de réconciliation"
locale: "fr"
source: "QuotWay - B2B Quote & Negotiation App for Shopify"
---

# Quand le devis et la commande Shopify divergent : ce qui dérive après la conversion

Une fois un devis converti sur Shopify, quatre enregistrements décrivent la même affaire : le devis accepté, la commande provisoire, la commande, et ce que détient l'ERP ou le CRM. Ils cessent de concorder d'un petit nombre de façons documentées - un brouillon modifié après la conversion, un brouillon encore ouvert alors que sa commande existe, un brouillon supprimé ou purgé au bout d'un an, une commande modifiée, annulée ou remboursée, une modification demandée par l'acheteur, une liste de tags écrasée par un connecteur. Chaque dérive se détecte en comparant deux champs précis, et chaque champ a un seul propriétaire. Réconcilier, c'est choisir ces propriétaires et vérifier les paires à intervalles réguliers.

Cette page est le catalogue de ce qui dérive *après* que le brouillon existe, de la façon de détecter chaque cas, de le réparer, et de qui possède quel champ à partir de la conversion. Créer exactement une commande provisoire est traité dans [comment un devis accepté devient exactement une commande provisoire](/blog/idempotent-draft-order-creation) ; ce qui casse *au moment* de la conversion est dans [les 17 modes de défaillance](/blog/quote-to-draft-order-failure-modes) ; un prix faux dès le départ est diagnostiqué dans [pourquoi un devis se convertit au mauvais prix](/blog/quote-converts-at-wrong-price). La « réconciliation » désigne ici les données entre devis et commande, pas le rapprochement des versements ou le rapprochement bancaire.

Tout ce qui concerne Shopify ci-dessous a été vérifié sur les pages de Shopify le 9 octobre 2026, en version d'API 2026-10 ; les sources sont en fin de page.

## Les quatre comparaisons
> **Quatre enregistrements, quatre comparaisons**
>
> Quatre boîtes alignées : le devis accepté, la commande provisoire, la commande, et l'ERP ou le CRM. Entre chaque paire, la comparaison qui détecte la dérive : du devis au brouillon par les totaux stockés à la conversion ; du brouillon à la commande par le champ order du brouillon ; la commande avec elle-même par le total initial comparé au total actuel ; de la commande à l'ERP par l'attribut de conversion ou les tags et le montant en devise de présentation.
>
> Chaque dérive du tableau ci-dessous apparaît dans l'une de ces quatre comparaisons.

## Ce qui dérive, et comment le repérer
Classé selon le moment où cela se produit. La « source de vérité » est l'enregistrement qui l'emporte à partir de la conversion.

### Avant que la commande existe
| # | Ce qui dérive | Cause dans Shopify | Détecter | Réparer | Source de vérité |
| --- | --- | --- | --- | --- | --- |
| 1 | Les lignes ou les totaux du brouillon par rapport à ce qui a été accepté | Le personnel modifie le brouillon après la conversion ; mettre à jour `tags` écrase toute la liste | Les totaux du payload `draft_orders/update` comparés aux totaux stockés à la conversion ; `DraftOrder.tags` comparé aux tags que vous avez écrits | Un changement commercial passe par une nouvelle proposition ou une contre-proposition et un nouveau brouillon, l'ancien brouillon étant supprimé ; un changement logistique est consigné | La version acceptée, jusqu'au paiement |
| 2 | Le brouillon est encore ouvert alors que sa commande existe | Une mise à jour pendant un checkout en cours a délié ce checkout : la commande est créée, et « la commande provisoire restera ouverte même après la création de la commande » | Une commande porte votre attribut de conversion, mais `DraftOrder.order` est null ou le statut n'est pas `COMPLETED` | Lier la commande par l'attribut ; une personne supprime le brouillon obsolète | La commande |
| 3 | Le devis pointe vers un brouillon qui n'existe plus | Le personnel l'a supprimé | `draft_orders/delete` ; en filet de sécurité, `draftOrder(id)` ne renvoie rien | Marquer le brouillon comme perdu ; vérifier qu'aucune commande ne porte l'attribut ; recréer ou clore | Shopify |
| 4 | La même chose, au bout d'un an | Les brouillons créés à partir du 1er avril 2025 sont supprimés après un an sans modification | `draftOrder(id)` ne renvoie rien - Shopify ne documente pas si la purge envoie un webhook de suppression | Décider bien avant l'échéance si l'affaire est perdue ou fait l'objet d'un nouveau devis | Shopify |
| 5 | La facture est partie et n'a jamais été payée | Une commande n'existe qu'une fois le brouillon payé ou finalisé | `draftOrders(query: "tag:… status:invoice_sent")` plus l'ancienneté | Relancer, prolonger, ou supprimer le brouillon et clore le devis - les deux ensemble | Le statut du brouillon |
| 6 | Le devis a expiré, le brouillon est toujours payable | Un brouillon n'a pas d'autre échéance que la purge | Le devis est expiré alors que `DraftOrder.status` vaut `OPEN` ou `INVOICE_SENT` | Supprimer le brouillon quand le devis expire, ou ne plus faire expirer les devis après la facture | Au choix - mais un seul |
| 7 | Une commande payée que la couche de devis ou l'ERP ne connaît pas | La livraison des webhooks n'est pas garantie | `draftOrder.order` est renseigné mais aucun identifiant de commande n'est stocké ; ou `orders(query: "tag:… updated_at:>…")` comparé aux identifiants stockés | Rejouer par le même handler de webhook ([le balayage](/blog/idempotent-draft-order-creation#sweep)) | La commande |

### Après que la commande existe
| # | Ce qui dérive | Cause dans Shopify | Détecter | Réparer | Source de vérité |
| --- | --- | --- | --- | --- | --- |
| 8 | Les lignes ou le total de la commande par rapport à la version acceptée | Le marchand ou une autre application modifie la commande : selon Shopify, la commande issue d'un brouillon créé par une application « peut être modifiée dans votre admin Shopify, et par d'autres applications » | `orders/edited` ; `Order.edited` ; `originalTotalPriceSet` comparé à `currentTotalPriceSet` | Consigner le motif sur la commande ; ne pas réécrire le devis ; l'ERP suit la commande | La commande pour l'expédition et la facturation ; le devis pour ce qui a été convenu |
| 9 | Une modification demandée par l'acheteur, en attente, que l'ERP ou l'entrepôt ne voit pas | Depuis 2026-10, un acheteur peut demander le retrait de lignes non expédiées | Webhooks `requested_order_edit/*` ; `Order.requestedOrderEdits` | Suspendre l'expédition tant que la demande est en attente ; l'accepter ou la refuser ; une demande acceptée arrive comme une modification de commande | La commande |
| 10 | Le devis montre une affaire en cours, la commande est annulée | L'annulation est « irréversible » | `orders/cancelled` ; `cancelledAt` | La consigner par commande ; le devis reste la trace ; un nouveau devis est une nouvelle affaire | La commande |
| 11 | Les montants après remboursements et retours | Remboursements par ligne ou sur les frais de livraison ; retours | `refunds/create` ; `returns/*` ; `currentSubtotalPriceSet` | L'avoir de l'ERP vient du remboursement, pas du devis | Les remboursements de la commande |
| 12 | L'état d'expédition recopié à plusieurs endroits | Un entrepôt ou un ERP écrit les expéditions dans Shopify | `fulfillments/*` ; `displayFulfillmentStatus` | Ne pas recopier l'expédition dans la couche de devis | L'entrepôt ou l'ERP, via Shopify |

### La forme de l'affaire et ses clés
| # | Ce qui dérive | Cause | Détecter | Réparer | Source de vérité |
| --- | --- | --- | --- | --- | --- |
| 13 | « Le devis a une commande, il devrait en avoir deux » | L'acceptation partielle ou la conversion fractionnée crée un brouillon par groupe ; les lignes laissées pour plus tard sont encore ouvertes, pas refusées | Les groupes convertis comparés aux identifiants de commande stockés ; le sous-total de chaque commande comparé à ses lignes acceptées | Réconcilier par groupe ; les lignes encore ouvertes ne manquent pas | La couche de devis pour les lignes encore ouvertes ; les commandes pour ce qui a été acheté |
| 14 | Le total du devis ne correspond pas au montant de l'ERP | Le brouillon et la commande sont dans la devise de présentation ; `shopMoney` est converti | Comparer le devis uniquement avec `presentmentMoney` | Comptabiliser délibérément depuis un seul côté | Le montant en devise de présentation |
| 15 | La commande n'est plus reconnaissable comme issue du devis | Tags écrasés par une écriture de la liste complète ; attribut ou note modifiés | `orders(query: "tag:…")` comparé aux identifiants stockés ; déclencheurs Events sur `order.tags` et `order.customAttributes` | Restaurer depuis l'enregistrement du devis ; les intégrations ajoutent des tags avec `tagsAdd`, jamais en réécrivant la liste | La couche de devis, qui a écrit les clés une seule fois |
| 16 | L'identité de l'acheteur a changé après la conversion | Un contact retiré, un site supprimé ou modifié, des clients fusionnés | `company_contacts/delete`, `company_locations/delete`, `customers/merge` comparés aux identifiants stockés | Avant le paiement, recréer le brouillon pour le bon site ; après, corriger le fichier clients, pas la commande | Le fichier clients de l'ERP, ou Shopify - l'un des deux |
| 17 | Un connecteur réécrit des champs que possède la couche de devis | Deux écrivains sur un même champ | Déclencheurs Events par champ ; écart avec ce que la couche de devis a écrit | Limiter le connecteur à ses propres champs | Un écrivain par champ |
| 18 | Une intégration a manqué des événements de la couche de devis | Livraison au moins une fois, dans le désordre ; un endpoint en panne | Des trous dans la séquence d'événements ; des livraisons que l'émetteur a abandonnées | Rejouer depuis le flux d'événements, puis depuis l'API | Le journal d'événements de la couche de devis |
| 19 | Une tâche de réconciliation annonce « tout va bien » sur d'anciennes commandes | Les applications ne voient que les 60 derniers jours de commandes, sauf avec `read_all_orders` | Le périmètre de la tâche comparé à l'âge de la commande | Demander `read_all_orders`, ou réconcilier dans la fenêtre | - |

## Qui possède quel champ après la conversion
[Les patterns d'intégration ERP, CRM et PIM](/blog/shopify-b2b-erp-crm-pim-integration-patterns#ownership) donnent le tableau de propriété pour toute la vie d'une intégration. Celui-ci commence au moment où le brouillon existe :

| Champ | Propriétaire après la conversion | Tous les autres | Pourquoi |
| --- | --- | --- | --- |
| Lignes, quantités, prix unitaires, conditions et version convenus | La couche de devis - la version scellée acceptée, jamais modifiée | Lecture pour l'audit | C'est la trace de l'accord ; une proposition envoyée est verrouillée |
| Les lignes encore ouvertes | La couche de devis | Le CRM la lit comme pipeline | Pas converties, et pas perdues |
| Le contenu du brouillon jusqu'au paiement | La couche de devis l'a écrit une fois ; les modifications du personnel sont des exceptions à consigner | L'ERP ignore les brouillons | Le brouillon est payable - le changer, c'est changer l'affaire |
| Les lignes, quantités et totaux de la commande | La commande Shopify | L'ERP et l'entrepôt la lisent ; la couche de devis ne la recopie pas | Modifications, remboursements et retours se font sur la commande |
| Paiement et remboursements | Shopify | L'ERP comptabilise depuis les remboursements ; la couche de devis ne consigne que les états finaux | L'argent circule sur la commande |
| Expédition | L'entrepôt ou l'ERP, qui écrit dans Shopify | La couche de devis : rien | Un seul écrivain |
| Facture, grand livre, avoirs | L'ERP ou le système comptable | - | Shopify n'est pas le grand livre |
| Clés de liaison - les tags du devis, l'attribut de conversion, la ligne de note | La couche de devis les écrit une fois | Les autres ajoutent avec `tagsAdd` | Mettre à jour `tags` écrase la liste |
| Entreprise, site, contact | Le fichier clients de l'ERP ou Shopify - l'un des deux | La couche de devis lit | Un seul écrivain |
| Statut du devis après la conversion | La couche de devis, déduit des événements de commande de Shopify | Les intégrations lisent | Déduit, jamais l'inverse |

La règle qui en découle : ne jamais réécrire les changements de la commande dans le devis. Le devis est ce qui a été convenu ; la commande est ce qui est expédié et payé. Quand ils diffèrent, consignez pourquoi sur la commande.

## Events ou webhooks pour ce travail
Events de Shopify est devenu disponible pour tous avec l'API 2026-10, en successeur des webhooks classiques, et les webhooks classiques continuent de fonctionner. Events a des topics pour les commandes, les remboursements, les retours, les ordres d'expédition, les entreprises et les clients, avec des déclencheurs sur des champs individuels - `order.tags`, `order.customAttributes`, `order.lineItems.quantity` entre autres - ce qui convient aux lignes 8, 15 et 17. Il n'a **aucun topic pour les commandes provisoires**, donc les lignes 1 à 6 ont toujours besoin des webhooks classiques `draft_orders/*`. Shopify ne documente pas les garanties de livraison d'Events : gardez la tâche de réconciliation ci-dessous, quel que soit votre choix.

## Une tâche de réconciliation à reprendre telle quelle
Exécutez-la à intervalles réguliers, sur les identifiants stockés, à l'intérieur de la fenêtre d'accès aux commandes :

1. **Les brouillons que vous avez créés et dont vous n'avez pas vu le paiement :** `draftOrders(query: "tag:<your-tag> updated_at:>…")`. Pour chacun, `status` et `order` : une commande sans identifiant stocké, c'est la ligne 7 ; un brouillon manquant, la ligne 3 ou 4 ; un vieux brouillon `INVOICE_SENT`, la ligne 5 ou 6.
2. **Les commandes qui portent votre clé :** `orders(query: "tag:<your-tag> updated_at:>…")`. Comparez `originalTotalPriceSet` et `currentTotalPriceSet` (ligne 8), vérifiez `cancelledAt` et le statut financier (lignes 10 et 11), `requestedOrderEdits` (ligne 9), et que les tags et l'attribut de conversion sont toujours là (ligne 15).
3. **Les systèmes extérieurs :** pour chaque commande, le montant de l'ERP comparé à `presentmentMoney` (ligne 14), le nombre de commandes comparé aux groupes convertis (ligne 13).
4. **Le périmètre :** sans `read_all_orders`, seuls les 60 derniers jours de commandes sont visibles (ligne 19).

Le côté création - le balayage qui retrouve une conversion dont l'issue est inconnue - est dans [l'article sur la conversion idempotente](/blog/idempotent-draft-order-creation#sweep).

## Comment QuotWay se comporte
Une implémentation, décrite telle qu'elle fonctionne aujourd'hui :

- **Ce sur quoi il fait la correspondance.** Chaque brouillon créé par QuotWay porte les tags `quotway` et `quotway-<quote reference>`, une note visible du seul marchand avec la référence et la version du devis, et un attribut de conversion qui relie la commande à son groupe de conversion. QuotWay ne modifie, ne finalise ni ne supprime jamais un brouillon après l'avoir créé, et ne modifie jamais les commandes.
- **Ce qu'il consigne.** Un changement des totaux d'un brouillon converti est consigné dans le journal d'activité du devis, avec les montants avant et après. Une fois un devis à l'état **Commande terminée**, QuotWay consigne sur le devis l'annulation ou le remboursement total de sa commande. Les remboursements partiels, les retours, les modifications de commande et l'expédition restent sur la commande Shopify - vérifiez-les sur la commande ([convertir en commande provisoire](/docs/converting-to-orders/convert-a-quote-to-a-draft-order)).
- **Conversions fractionnées et partielles.** Chaque groupe accepté devient son propre brouillon et sa propre commande ; les lignes que l'acheteur a laissées pour plus tard restent encore ouvertes sur le devis et peuvent être converties plus tard ([acceptation partielle et conversion fractionnée](/docs/converting-to-orders/partial-acceptance-and-split-conversion)).
- **Webhooks de commande manqués.** Un balayage vérifie les devis facturés depuis sept jours sans commande et, si Shopify en montre une, la rejoue par le même handler.
- **Pour les intégrations.** Sur le forfait Enterprise - y compris pendant l'essai gratuit de 14 jours - l'objet devis de l'API liste les identifiants de commande provisoire et de commande Shopify du devis, et un flux d'événements de 30 jours est la voie de rattrapage des webhooks manqués ([le flux d'événements](/docs/api/events)). Les forfaits sont sur la [page des tarifs](/pricing) ; la conversion est décrite sur [convertir les devis en commandes](/features/convert-to-orders).

## Questions fréquentes

### Pourquoi une commande provisoire Shopify reste-t-elle ouverte après le paiement du client ?

Le brouillon a été mis à jour pendant que son checkout était en cours, ce qui délie le checkout : la commande est créée, mais « la commande provisoire restera ouverte même après la création de la commande ». Vérifiez `DraftOrder.order`, liez la commande par votre propre clé, et supprimez le brouillon obsolète.

### Existe-t-il un webhook pour le paiement d'une commande provisoire ?

Pas de topic « payé » pour les commandes provisoires. Le paiement crée une commande : écoutez donc `orders/create` et rattachez-la au brouillon par votre propre attribut ou tag ; le `status` du brouillon passe à `COMPLETED` et son champ `order` est renseigné. `draft_orders/update` couvre les changements du brouillon, et Events de Shopify n'a aucun topic pour les commandes provisoires en 2026-10.

### Le devis doit-il changer quand la commande est modifiée ?

Non. Le devis est la trace de ce qui a été convenu ; la commande est ce qui est expédié et payé. Consignez le motif d'une modification sur la commande et laissez l'ERP suivre la commande.

### Comment détecter les modifications de commande pour mon ERP ?

Le webhook `orders/edited`, le champ `edited` de la commande, et un écart entre `originalTotalPriceSet` et `currentTotalPriceSet`. Avec Events, un déclencheur sur `order.lineItems.quantity` fait la même chose pour les quantités.

### Que sont les modifications de commande demandées par l'acheteur ?

Depuis l'API 2026-10, un acheteur peut demander le retrait de lignes non expédiées d'une commande. La demande arrive par les webhooks `requested_order_edit/*` et est visible sur `Order.requestedOrderEdits` ; suspendez l'expédition tant qu'elle est en attente, et une demande acceptée devient une modification de commande ordinaire.

### Les commandes provisoires impayées expirent-elles ?

Les brouillons créés à partir du 1er avril 2025 sont supprimés après un an sans modification. Rien d'autre ne les fait expirer : un devis qui expire plus tôt laisse son brouillon payable, sauf si vous le supprimez.

### Shopify Events remplace-t-il les webhooks pour la réconciliation ?

Events est le successeur des webhooks classiques et les webhooks classiques continuent de fonctionner, mais il n'a aucun topic pour les commandes provisoires, donc les brouillons ont toujours besoin de `draft_orders/*`. Shopify ne documente pas les garanties de livraison d'Events : gardez une tâche de réconciliation dans les deux cas.

### Pourquoi le total de l'ERP ne correspond-il pas au devis ?

Le devis, le brouillon et la commande sont dans la devise de présentation de l'acheteur ; `shopMoney` est converti. Les remboursements et les modifications de commande changent le total actuel de la commande. Comparez le devis avec le montant en devise de présentation de la commande et avec son total initial.

## Sources

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

- [draftOrderUpdate](https://shopify.dev/docs/api/admin-graphql/2026-10/mutations/draftOrderUpdate) - une mise à jour délie un checkout en cours et le brouillon reste ouvert
- [DraftOrder](https://shopify.dev/docs/api/admin-graphql/2026-10/objects/DraftOrder) et [DraftOrderInput](https://shopify.dev/docs/api/admin-graphql/2026-10/input-objects/DraftOrderInput) - statut, `order`, tags
- [Commandes provisoires](https://help.shopify.com/en/manual/fulfillment/managing-orders/create-orders) - suppression après un an sans modification pour les brouillons créés à partir du 1er avril 2025 ; le paiement crée la commande
- [Order](https://shopify.dev/docs/api/admin-graphql/2026-10/objects/Order) - totaux initial et actuel, `edited`, `cancelledAt`, `requestedOrderEdits`
- [Modifier des commandes existantes](https://shopify.dev/docs/apps/build/orders-fulfillment/order-management-apps/edit-orders) - les commandes créées par une application peuvent être modifiées dans l'admin et par d'autres applications ; la fenêtre de 60 jours sur les commandes
- [orderCancel](https://shopify.dev/docs/api/admin-graphql/2026-10/mutations/orderCancel) - l'annulation est irréversible
- [tagsAdd](https://shopify.dev/docs/api/admin-graphql/2026-10/mutations/tagsAdd) - ajouter des tags sans écraser la liste
- [Topics de webhook](https://shopify.dev/docs/api/admin-graphql/2026-10/enums/WebhookSubscriptionTopic) et [livraison des webhooks HTTPS](https://shopify.dev/docs/apps/build/webhooks/subscribe/https) - topics ; la livraison n'est pas garantie
- [Events est désormais disponible pour tous](https://shopify.dev/changelog/next-generation-events-are-now-generally-available) et [events et webhooks](https://shopify.dev/docs/apps/build/events-webhooks) - topics, déclencheurs par champ, les webhooks classiques continuent
- [Notes de version 2026-10](https://shopify.dev/changelog/release-notes/2026-10) - modifications de commande demandées par l'acheteur

Le comportement de QuotWay est décrit d'après sa documentation publique et le code source de l'application, lus le 9 octobre 2026.