Lorsque les clients finalisent leurs achats, que les paiements sont traités et que les flux ou les courriels se déclenchent, il est facile de présumer que tout fonctionne comme prévu pour votre boutique en ligne.

Cependant, ce n'est qu'une partie de l'équation. Que se passe-t-il si la commande n'atteint jamais le système ERP? … Ou peut-être qu'elle l'atteint, mais qu'une nouvelle tentative la crée en double. Et si la mise à jour de l'inventaire s'est arrêtée il y a deux heures, de sorte que le site Web continue de vendre des articles qui ne sont plus en stock? … Ou qu'une expédition quitte l'entrepôt, mais que ses informations de suivi ne parviennent jamais au client?

C'est précisément le genre de problèmes que la surveillance des intégrations d'e-commerce est censée détecter.

La surveillance traditionnelle de l'e-commerce a tendance à se concentrer sur l'expérience visible par les clients : erreurs de page, temps de chargement lents, boutons inactifs, échecs au passage à la caisse et autres problèmes liés à la vitrine. Bien que ces éléments soient évidemment importants, les opérations d'e-commerce modernes dépendent également d'un réseau complexe d'API, de webhooks, de files d'attente, de middlewares (ou intergiciels), de systèmes ERP, de PIM, d'OMS, de WMS, de systèmes POS et d'applications tierces.

D'autre part, la surveillance des intégrations d'e-commerce vérifie que les commandes, l'inventaire, les produits, les mises à jour d'exécution (ou de traitement des commandes) et les autres données commerciales circulent avec succès entre les systèmes et produisent le résultat opérationnel attendu. Une bonne surveillance permet de repérer les enregistrements manquants, les données obsolètes, les opérations en double, les engorgements des files d'attente, les échecs de tentatives répétées et les incohérences entre les systèmes.

Dans ce billet de blogue, nous décortiquerons tout ce que vous devez savoir sur la surveillance de vos intégrations d'e-commerce afin de vous assurer que les erreurs sont interceptées avant qu'elles ne nuisent à votre boutique ou à vos revenus.

Ce que la surveillance des intégrations d'e-commerce doit démontrer

Les intégrations peuvent sembler saines sur le plan technique, tout en produisant des résultats erronés. Une requête d'API d'inventaire peut très bien avoir été exécutée avec succès, mais que se passe-t-il si Shopify n'affiche pas la même quantité vendable que celle indiquée dans le système d'inventaire?

De la même manière, le statut de synchronisation du flux de données d'Adobe Commerce (Data Feed Sync Status) peut indiquer que les données ont été exportées avec succès, bien que la plateforme précise elle-même que cela ne confirme pas la disponibilité de ces données dans le service connecté. La disponibilité en aval doit toujours être vérifiée.

Une observabilité utile des intégrations doit donc répondre à trois questions :

1. L'événement ou la synchronisation a-t-il démarré? Le webhook a-t-il été livré, le message publié dans la file d'attente, la tâche planifiée déclenchée ou la requête API envoyée?

2. Le traitement a-t-il réussi? La validation a-t-elle fonctionné? Le message a-t-il été consommé? Le système en aval l'a-t-il accepté?

3. L'état opérationnel attendu était-il présent par la suite? La commande figure-t-elle réellement dans le système ERP? L'inventaire sur Shopify est-il exact? L'expédition s'est-elle transformée en commande traitée? La mise à jour du produit a-t-elle bien été intégrée au catalogue?

La troisième question est particulièrement importante, car elle a le plus de chances de révéler des défaillances silencieuses.

Les défaillances d'intégration d'e-commerce qui ont tendance à passer inaperçues

La plupart des échecs d'intégration ne se traduisent pas par des pannes de système spectaculaires. Au contraire, certaines des défaillances les plus coûteuses sont généralement aussi les plus silencieuses. Pour cette raison, une stratégie efficace de surveillance des intégrations d'e-commerce devrait distinguer plusieurs types d'échecs :

Commandes manquantes

Un échec de synchronisation d’une commande Shopify peut entraîner un problème opérationnel particulièrement grave, notamment lorsque la commande a déjà été payée ou autorisée. Selon votre architecture, il se peut que cette commande doive encore atteindre un système ERP, un OMS, un WMS, une plateforme comptable, un partenaire d'exécution ou plusieurs systèmes simultanément.

La surveillance devrait donc permettre d'identifier les commandes qui n'ont pas atteint leur destination requise dans la fenêtre de synchronisation prévue. Par exemple :

1. Commande Shopify créée à 10:02:14

2. Création prévue dans le système ERP dans un délai de deux minutes

3. Commande ERP toujours manquante à 10:05:00

4. Alerte

Cela devrait vous aider à détecter et à corriger les erreurs avant qu'elles ne se multiplient et ne créent un problème majeur pour vos équipes techniques et de service à la clientèle.

Erreurs de synchronisation d'inventaire

Les erreurs de synchronisation de l'inventaire sont tout aussi dangereuses, car elles peuvent avoir un impact direct sur ce que les clients peuvent acheter. Voici quelques échecs fréquents :

• l'arrêt de l'exécution d'une tâche d'inventaire;

• une succursale ou un emplacement qui cesse de se synchroniser;

• des quantités désuètes causées par des retards dans les files d'attente;

• le mauvais système source qui écrase un inventaire plus récent;

• un échec de mappage des UGS (SKU);

• une synchronisation partielle à travers de multiples emplacements.

Pour le commerce multi-emplacements et les environnements POS de Shopify, l'inventaire global ne suffit pas. Un système peut très bien afficher le bon total alors que les quantités attribuées aux emplacements individuels sont erronées.

Échecs de synchronisation des produits

Les intégrations de PIM et de catalogues échouent souvent de manière beaucoup plus subtile que les autres. Un produit peut exister en aval tout en demeurant incomplet, parce que ses images, ses descriptions localisées, les attributs de ses variantes, ses catégories, ses méta-champs ou d'autres données n'ont pas été correctement synchronisés.

Cela signifie que votre processus de surveillance doit non seulement confirmer que tous vos produits ont bien été exportés, mais aussi que l'ensemble des données requises est arrivé à bon port et sans erreur.

Quels échecs d'intégration nécessitent des alertes immédiates?

Dans un monde idéal, les erreurs de synchronisation seraient enregistrées et corrigées sur-le-champ, mais ce n'est pas toujours réalisable. De plus, toutes les défaillances ne sont pas suffisamment critiques pour justifier de réveiller quelqu'un en pleine nuit pour les résoudre.

L'objectif des alertes de synchronisation de données est d'escalader les échecs en fonction de leur impact sur l'entreprise, plutôt que de traiter chaque avertissement avec le même degré d'urgence. Privilégiez plutôt une classification de tous les types d'erreurs (critiques, élevées, moyennes ou faibles) afin d'aborder les alertes et les correctifs en fonction de la gravité du problème.

Par exemple, des commandes payées qui n'atteignent pas un système ERP/OMS, une file d'attente de commandes non traitée alors que de nouvelles transactions continuent d'arriver, ou un échec d'authentification bloquant l'intégralité d'une intégration en production devraient être considérés comme critiques et nécessiter une alerte immédiate.

À l'inverse, un retard de quelques heures dans la synchronisation des produits pourrait constituer un enjeu de priorité moyenne susceptible de générer un billet ou une alerte pendant les heures de bureau. Quant à un attribut de produit non critique qui échoue à l'étape de validation, il pourrait relever d'une faible gravité et faire l'objet d'une alerte via un rapport regroupé.

Vos seuils d'alerte devraient toutefois refléter la réalité de votre entreprise. Un marchand traitant cinq commandes à l'heure n'utilisera pas (et ne devrait pas utiliser) les mêmes règles qu'un autre traitant des centaines de commandes par minute. De la même manière, une latence d'inventaire jugée acceptable pour des meubles fabriqués sur commande ne devrait probablement pas être la même pour une marque vendant des chaussures de sport en édition limitée.

Que se passe-t-il lorsqu'un webhook Shopify échoue?

Les webhooks Shopify sont souvent au cœur des intégrations d'e-commerce en temps réel; la surveillance des intégrations Shopify doit donc tenir compte de leur comportement réel en matière de livraison.

Actuellement, la plateforme accorde aux points de terminaison des webhooks un délai de connexion d'une seconde et de cinq secondes pour l'ensemble de la requête. Il faut accuser réception du webhook rapidement et placer le traitement réel en file d'attente de manière asynchrone, plutôt que de tenter d'exécuter une tâche d'intégration prolongée avant de répondre.

Si Shopify ne reçoit aucune réponse ou reçoit une erreur, le système effectue actuellement huit nouvelles tentatives pour le webhook au cours des quatre heures suivantes. Pour les abonnements créés via l'API Admin, huit échecs consécutifs peuvent entraîner la suppression automatique de l'abonnement.

Shopify ne garantit pas non plus l'ordre d'arrivée des webhooks. Un événement de mise à jour peut survenir avant un autre événement que vous devez traiter en premier. 

Shopify recommande d'utiliser les horodatages des événements lorsque la séquence est importante. Les livraisons en double sont également possibles. Shopify fournit l'en-tête X-Shopify-Webhook-Id précisément pour que les intégrations puissent identifier et ignorer les webhooks envoyés en double.

Vous devriez également configurer des tâches de réconciliation qui récupèrent périodiquement les données de Shopify afin de repérer tout élément manquant ou mal traité, plutôt que de vous fier uniquement aux webhooks. Il est par ailleurs important de distinguer une livraison de webhook réussie d'un traitement en aval réussi.

Un statut « 200 OK » confirme que le point de terminaison a accusé réception de la requête de Shopify, et non qu'une opération d'ERP, d'inventaire ou d'exécution mise en file d'attente s'est terminée avec succès par la suite. Ce travail en aval nécessite sa propre logique de surveillance, de nouvelles tentatives et de réconciliation.

Comment prévenir les doublons de commande lors de nouvelles tentatives?

Les nouvelles tentatives (retries) sont d'une importance capitale pour des intégrations résilientes, mais elles peuvent aussi générer des commandes en double si elles ne sont pas correctement gérées. Prenez ce scénario, par exemple :

1. Shopify envoie une commande à l'intergiciel.

2. L'intergiciel demande au système ERP de créer la commande.

3. L'ERP la crée avec succès.

4. La connexion réseau échoue avant que l'intergiciel ne reçoive la réponse.

5. L'intergiciel présume que l'opération a échoué.

6. Il lance une nouvelle tentative pour « créer la commande ».

7. L'ERP en crée une autre.

La solution réside dans l'idempotence (le fait d'appliquer une opération plusieurs fois a le même effet final que de l'appliquer une seule fois). En résumé, une opération idempotente peut être répétée sans produire de résultats indésirables supplémentaires. Au lieu de traiter chaque nouvelle tentative comme une opération commerciale entièrement nouvelle, les systèmes sont capables de reconnaître qu'ils l'ont déjà vue.

Les API actuelles de Shopify prennent en charge l'idempotence pour les opérations concernées. Les nouvelles tentatives devraient réutiliser la même clé d'idempotence, tandis qu'une opération réellement nouvelle devrait en utiliser une autre. Pour les mutations de l'API GraphQL Admin utilisant la directive @idempotent de Shopify, la plateforme suit les clés d'idempotence pendant 24 heures.

Après cette fenêtre, la même clé n'est plus reconnue comme un doublon. Le comportement en matière d'idempotence peut différer pour d'autres opérations d'API; il est donc impératif que les intégrations respectent les exigences de la mutation spécifique ou du point de terminaison utilisé.

Cela dépend toutefois de l'opération. Certaines sont naturellement idempotentes, tandis que d'autres acceptent ou exigent une protection explicite contre l'idempotence. Ce même principe devrait également s'appliquer à tout intergiciel personnalisé.

Les nouvelles tentatives doivent également distinguer les problèmes temporaires des problèmes persistants. Un délai d'attente dépassé ou une erreur temporaire du serveur pourrait justifier un nouvel essai. En revanche, des erreurs déterministes telles que des charges utiles mal formées, des mappages invalides ou des échecs de permissions ne seront généralement pas résolues en envoyant à nouveau la même requête. Ce type d'échec devrait plutôt être corrigé ou faire l'objet d'une intervention humaine avant toute nouvelle tentative.

Pour les opérations pouvant faire l'objet d'une nouvelle tentative, le recours à un délai d'attente exponentiel avec une variation aléatoire (exponential backoff with jitter) est courant. Le délai augmente entre les tentatives, tandis qu'une légère part d'aléatoire empêche des milliers d'opérations échouées d'être relancées simultanément, ce qui surchargerait un système en cours de rétablissement. Utilisez cette méthode lorsque la réponse et les caractéristiques d'idempotence de l'opération justifient une nouvelle tentative.

Une fois les nouvelles tentatives épuisées, le message devrait basculer vers un état d'échec contrôlé, souvent dans une file d'attente de messages non distribués (dead-letter queue), plutôt que de tourner en boucle indéfiniment.

Comment la synchronisation d'inventaire devrait-elle être réconciliée?

Une tâche de réconciliation d'e-commerce compare les données de deux ou plusieurs systèmes pour cibler les enregistrements manquants, dupliqués, obsolètes ou incohérents.

Shopify recommande la réconciliation car les webhooks peuvent être manqués ou mal gérés. Akeneo donne essentiellement le même conseil pour sa plateforme d'événements (Event Platform), en recommandant aux intégrations de ne pas dépendre exclusivement de la réception d'événements et de récupérer périodiquement les données du PIM.

Réconciliation quotidienne des commandes

Pour les commandes, comparez l'ensemble des commandes Shopify figurant dans la fenêtre de réconciliation avec celles de l'ERP ou de l'OMS, à l'aide d'un identifiant partagé et stable. Signalez des situations telles que :

• une commande manquante dans l'ERP;

• une commande ERP en double;

• un écart dans le total de la commande;

• un article de ligne manquant;

• un statut d'exécution ou de traitement incorrect;

• une commande non synchronisée inhabituellement ancienne.

Certaines entreprises pourraient devoir réconcilier leurs flux plus d'une fois par jour. Il ne s'agit là que d'une base de référence pour les processus qui ne nécessitent pas de vérification en temps réel.

Réconciliation de l'inventaire

Lorsqu'il s'agit de la réconciliation d'inventaire, vous devrez déterminer quel système est la source de vérité. Selon l'architecture, l'autorité en matière d'inventaire peut résider dans un système ERP, un OMS, un WMS, Shopify ou une autre plateforme de gestion des stocks. Une fois cela établi, la réconciliation peut comparer la quantité faisant autorité à celle de Shopify, à l'échelle de l'UGS (SKU) et de l'emplacement.

Parmi les vérifications utiles, on retrouve les écarts de quantité, les emplacements manquants, une variance anormalement importante ou la modification du stock Shopify sans le changement anticipé en amont. Si vous possédez de multiples points de vente au détail, intégrez des vérifications à l'échelle de chaque emplacement. Une entreprise qui utilise Shopify POS, l'expédition depuis le magasin (ship-from-store), le ramassage en magasin ou l'exécution des commandes depuis une succursale peut très bien afficher un inventaire global exact alors que les données des emplacements individuels sont erronées.

Réconciliation des expéditions

Les flux de travail liés au traitement des commandes devraient comparer les commandes expédiées dans l'ERP, l'OMS, le WMS ou la plateforme du partenaire 3PL aux données d'exécution de Shopify. Gardez l'œil ouvert sur :

• une expédition qui existe en aval, mais dont l'exécution est manquante dans Shopify;

• un numéro de suivi qui n'a pas été synchronisé;

• un statut d'exécution obsolète;

• une expédition partielle représentée de manière incorrecte;

• une expédition annulée qui apparaît toujours comme active.

Il est crucial de surveiller ces éléments, car les clients remarquent ce type de problème immédiatement, ce qui peut entraîner des répercussions sur la réputation et alourdir la charge de travail de votre équipe de service à la clientèle.

Réconciliation des produits et du PIM

Pour une synchronisation d'Akeneo vers Shopify ou d'Akeneo vers Adobe Commerce, la réconciliation pourrait vérifier que :

• les UGS (SKU) attendues existent;

• les variantes attendues sont bien là;

• les attributs requis sont remplis;

• les valeurs localisées sont présentes;

• les actifs et les images sont bien arrivés;

• les affectations de catégories ou de taxonomie sont exactes;

• les produits récemment modifiés ont bel et bien été mis à jour en aval.

Cela est devenu particulièrement pertinent pour les intégrations Akeneo en 2026. L'ancienne API Events d'Akeneo doit être retirée le 31 décembre 2026 et sera remplacée par la nouvelle plateforme Event Platform. Akeneo précise que cette plateforme offre une livraison garantie au moins une fois et la possibilité de nouvelles tentatives, mais recommande tout de même la réconciliation.

Pour les destinations HTTPS, Akeneo effectue actuellement les meilleures tentatives possibles en cas d’échec transitoire admissible après 5, 10 et 20 minutes. Après ces trois essais, le message est abandonné. Les problèmes de livraison peuvent également contribuer à la suspension de l'abonnement, ce qui fait de l'état de santé des abonnements un autre signal de surveillance de premier plan.

Un cahier de procédures pour les incidents d'intégration d'e-commerce

Votre cahier de procédures (runbook) pour répondre aux incidents d'intégration n'a pas besoin d'être un document colossal, mais il devrait fournir à votre équipe une marche à suivre reproductible en cas de bris :

1. Détecter et classifier l'échec : Qu'est-ce qui est affecté par l'incident, et quelle est sa gravité selon l'impact commercial?

2. Éviter d'aggraver la situation : Si une intégration crée des données incorrectes, des commandes en double ou des mises à jour d'inventaire hasardeuses, mettez temporairement en pause le processus d'écriture ou la relance affectée, le cas échéant.

3. Définir la fenêtre temporelle concernée : Identifiez la première et la dernière défaillance connue, la boutique ou le marché touché, l'intégration, le type d'événement, l'emplacement, les ID de commande ou les UGS, ainsi que le nombre estimé d'enregistrements.

4. Vérifier la livraison des événements et de l'API : Inspectez les journaux (logs) de livraison des webhooks, les codes de réponse HTTP, les taux d'expiration, les signatures ou l'authentification, le statut d'abonnement aux webhooks, les erreurs d'API et les journaux de livraison du côté de la plateforme.

5. Inspecter le traitement et les files d'attente : Vérifiez la profondeur de la file d'attente, l'âge du message le plus ancien, les consommateurs actifs, le nombre de tentatives, les tâches échouées, les tâches planifiées, les files de messages non distribués (dead-letter queues) et les exceptions d'application (pour Adobe Commerce, cela peut inclure les consommateurs de la file d'attente de messages et les tâches cron).

6. Vérifier l'état de destination : Vérifiez le résultat commercial, c'est-à-dire si Shopify a reçu le bon niveau d'inventaire, si la commande ERP existe bel et bien ou si le produit s'est réellement mis à jour.

7. Corriger la cause fondamentale : Selon l'incident, il peut s'agir d'identifiants expirés, de modifications d'API, de permissions manquantes, de changements de configuration, etc.

8. Relancer en toute sécurité : Ne relancez les opérations échouées qu'après avoir déterminé si elles n'ont pas déjà réussi. Utilisez les contrôles d'idempotence et de déduplication dans la mesure du possible.

9. Réconcilier l'intégralité de la fenêtre de l'incident : Une fois le traitement repris, comparez tous les enregistrements de la période affectée. Ne présumez pas que le fait de corriger l'erreur a également réparé tout ce qui s'est produit pendant l'incident ou la panne.

10. Fermer l'incident et améliorer la surveillance : Documentez la cause fondamentale, les enregistrements affectés, le processus de récupération, l'impact commercial, les alertes manquantes, ainsi que les tests ou mesures de protection destinés à prévenir le prochain incident.

Bien que l'idéal soit d'éviter tout incident futur, un tel cahier de procédures devrait faciliter la gestion de ceux qui pourraient survenir.

Surveillance de Shopify, Adobe Commerce, Akeneo, des systèmes POS et des flux de travail basés sur l'IA 

Les principes de surveillance et d'optimisation des incidents sont similaires d'une plateforme à l'autre, mais quelques différences méritent d'être soulignées.

Surveillance de l'intégration Shopify

Pour Shopify, surveillez la livraison des webhooks, le statut des abonnements, les doublons, le décalage des événements, les erreurs d'API, les files d'attente, les nouvelles tentatives, les enregistrements en aval et les écarts de réconciliation.

Les webhooks peuvent être dupliqués, livrés dans le désordre ou complètement manqués, ce qui fait de la réconciliation et du traitement idempotent des piliers fondamentaux pour une architecture d'intégration Shopify fiable.

Surveillance de l'intégration Adobe Commerce

Les environnements Adobe Commerce peuvent également dépendre fortement des tâches cron et des consommateurs de messages.

Adobe recommande de surveiller le traitement des files d'attente et fournit le statut de synchronisation du flux de données pour les exportations de catalogues concernées. Il est important de noter qu'une exportation de flux réussie ne confirme toujours pas que le service connecté a ingéré les données avec succès.

Pour les implémentations d'Adobe Commerce utilisant Adobe I/O Events, il y a une autre couche de livraison d'événements à surveiller. Actuellement, Adobe documente une livraison garantie au moins une fois, la possibilité d'événements en double et aucune garantie quant à l'ordre des événements. Les livraisons de webhooks échouées et admissibles peuvent faire l'objet d'une nouvelle tentative pendant un maximum de 24 heures, et l'API de journalisation d'Adobe (Journaling API) conserve des événements souscrits pendant 7 jours pour la récupération.

Surveillance de l'intégration Akeneo

Pour Akeneo, surveillez les événements liés aux produits, l'état des abonnements, la capacité de traitement, le décalage de synchronisation, l'exhaustivité des produits et la réconciliation en aval.

La plateforme Event Platform peut effectuer de nouvelles tentatives en cas d’erreurs transitoires, mais des événements en double et désordonnés sont possibles, ce qui signifie que les applications auront tout de même besoin de processus de réconciliation.

Shopify POS et opérations multi-emplacements

Les systèmes POS ajoutent une couche de complexité à la surveillance de l'inventaire. Lorsque le commerce en ligne, les magasins physiques, les points de ramassage et les entrepôts partagent le même inventaire, la surveillance devrait vérifier l'état par emplacement plutôt que de se contenter de comparer les totaux.

Le routage des commandes, les retours, l'expédition depuis le magasin (ship-from-store) et les flux de travail liés au ramassage peuvent également créer des dépendances inter-systèmes qui méritent leurs propres accords de niveau de service (SLA) de synchronisation.

Noibu et la surveillance orientée client

La surveillance de l'intégration en arrière-plan (backend) ne devrait pas remplacer celle de la vitrine.

Des outils comme Noibu peuvent contribuer à identifier les erreurs d'e-commerce et les problèmes de conversion auxquels les clients sont confrontés, tandis que l'observabilité de l'intégration vérifie que les données opérationnelles sous-jacentes à ces parcours clients circulent correctement.

Flux de travail basés sur l'IA

Les flux de travail d'e-commerce basés sur l'IA peuvent ajouter une autre couche aux opérations d'intégration en classant les anomalies, en corrélant les journaux, en résumant les incidents ou en suggérant des mesures correctives.

Un agent capable de relancer une commande, de modifier l'inventaire, d'émettre un remboursement ou de déclencher toute autre opération modifiant les activités de l'entreprise a tout de même besoin de permissions, d'idempotence, de pistes d'audit, de réconciliation et d'une approbation humaine appropriée.

Conclusion

Une surveillance efficace des intégrations d'e-commerce permet de détecter les défaillances avant que les clients ou les équipes internes n'aient à les signaler. Cela implique de surveiller les commandes manquantes, les inventaires obsolètes, les webhooks échoués, les engorgements des files d'attente, les tentatives en double répétées, les mises à jour incomplètes de produits et les divergences entre les systèmes, pour ensuite appuyer ces alertes par une logique de nouvelle tentative idempotente, des processus de réconciliation, une attribution claire des responsabilités et un plan de réponse aux incidents.

À mesure que les architectures d'e-commerce deviennent plus interconnectées, l'observabilité des intégrations ne fera que gagner en importance. Les entreprises capables de détecter, de diagnostiquer et de se remettre rapidement d'un échec de synchronisation sont mieux positionnées pour maintenir la fluidité de leurs opérations, protéger la confiance de leur clientèle et croître sans faire des problèmes d'intégration une composante du quotidien.

Si vos intégrations Shopify, Adobe Commerce, Akeneo, POS ou sur mesure sont devenues difficiles à surveiller ou à entretenir, notre équipe chez Blue Badger peut vous aider à repérer les points faibles, à améliorer l'observabilité et à bâtir des flux de travail d'e-commerce plus fiables. Communiquez avec nous dès aujourd'hui pour en savoir plus.