E-commerce
26 août 2026
Votre client jure que la page de paiement a planté et que sa carte n’a jamais été débitée. Vos sondes de disponibilité affichent du vert toute la journée, pourtant impossible de retrouver la trace de sa tentative. Le problème ? Une boutique en ligne ne produit pas un seul journal serveur mais six, chacun enregistrant une étape différente de la même requête. Sans identifiant partagé ni champs de timing précis, impossible de relier les morceaux et de dire à quelle couche la requête s’est arrêtée. Cet article détaille les six couches qui écrivent des logs dans une stack e-commerce, les champs indispensables pour reconstituer un parcours client après coup, et la question que chaque couche est la seule à pouvoir trancher. Pas de recommandation d’outil : ce qu’on enregistre se décide avant l’endroit où on l’envoie.
Sommaire
Les six couches de logs d’un site e-commerce
Un site marchand écrit des logs à six niveaux distincts, chaque couche capturant une tranche différente de la même requête client. D’abord le CDN ou l’edge, qui répond depuis le cache, bloque ou transmet vers l’origine. Ensuite le serveur web (Nginx, Apache) qui écrit une ligne d’accès. Puis l’application qui valide le panier et enregistre ses décisions métier. La base de données génère un slow query log si vous l’activez. L’application appelle ensuite des services tiers (passerelle de paiement, logistique) et ces réponses ne sont tracées que si vous choisissez de les enregistrer. Enfin, la recherche interne du site capture ce que les visiteurs ont tapé.
Chaque couche écrit son propre horodatage. Une requête qui échoue à un niveau peut donc être absente du suivant, ce qui complique la reconstitution. Les deux couches les plus souvent oubliées sont les logs applicatifs métier (création de commande, validation, refus de paiement) et les logs de recherche interne. Selon la plateforme hébergée, vous récupérez certains niveaux par défaut mais rarement la pile complète. Un tunnel de commande hébergé vous donne la réponse de la passerelle mais rien en dessous.
200+ ecommerçants accompagnés
Quelle question chaque couche est seule à trancher ?
Le CDN répond à la question : la requête nous est-elle même parvenue ? Il enregistre les réponses mises en cache, les blocages et les limitations de débit avant que le trafic n’atteigne l’origine. Le serveur web dit ce que le serveur a retourné et en combien de temps. L’application révèle quelle commande a échoué et sur quelle règle métier. La base de données indique si le délai venait de la couche data (requête lente, erreur de connexion, attente de verrou). Les appels sortants tiers montrent ce que la passerelle a vraiment répondu, et pas seulement ce que l’application a interprété.
Enfin, la recherche interne dévoile ce que les visiteurs ont cherché sans trouver, un signal clé pour détecter les ruptures de stock ou les problèmes de catalogue. Chaque couche détient une pièce du puzzle ; aucune ne peut reconstituer seule le parcours complet.
Les trois champs qui décident ce qu’on peut reconstituer
Trois champs déterminent votre capacité à diagnostiquer un paiement raté : la durée de la requête, le statut retourné par l’upstream, et un identifiant qui traverse toutes les couches. Le format Combined Log Format, par défaut sur la plupart des installations Nginx et Apache, n’en enregistre aucun. Il contient sept champs du Common Log Format plus le referrer et l’User-Agent, mais ignore le timing, le statut upstream et tout identifiant de corrélation.
Ajoutez explicitement la durée de requête et le temps de réponse upstream séparément, pour distinguer votre propre file d’attente d’une passerelle lente. Loguez le statut upstream à côté du statut envoyé au client : un edge peut transformer un 502 en page d’erreur personnalisée qui s’enregistre comme 200. Générez un X-Request-ID à l’edge et écrivez-le à chaque couche. Séparez bien les deux types d’identité : l’identifiant de session dit quel visiteur, l’identifiant de requête dit quelle tentative.
Adresses IP et horodatages : pièges courants
Derrière un CDN, l’adresse IP que votre serveur web voit par défaut est celle de votre propre edge, pas celle du client. Configurez le serveur pour lire X-Forwarded-For, mais ne faites confiance qu’à la portion ajoutée par votre edge : un client peut envoyer lui-même le reste de l’en-tête. Pour les horodatages, écrivez toujours en UTC au format ISO 8601 (année-mois-jour T heure:minute:seconde Z), de manière à ce que trier les événements entre couches devienne une opération arithmétique plutôt qu’une interprétation de fuseau horaire.
Un décalage horaire mal configuré peut faire apparaître une requête applicative avant la ligne d’accès correspondante dans le serveur web, rendant la corrélation impossible. Gardez le même format d’horodatage partout et synchronisez les horloges serveur via NTP.
Logs serveur et analytics JavaScript : deux questions différentes
Les analytics côté client comme GA4 enregistrent ce qu’un navigateur a réussi à exécuter. Les logs serveur enregistrent ce que le serveur a effectivement été sollicité de faire. Les requêtes qui comptent le plus pendant un incident sont précisément celles que les analytics ne voient jamais. La collecte côté client exige que la page se charge et que le script s’exécute. Une requête qui retourne un 5xx, qui timeout ou qui est coupée mi-réponse ne génère aucun événement GA4. Pas plus qu’un visiteur qui refuse le bandeau de consentement ou bloque le script.
Les logs capturent aussi le trafic qu’aucun navigateur n’a produit : robots, scrapers, clients API, applications mobiles, agents d’achat autonomes et webhooks entrants comme les callbacks de paiement. Les analytics lisent l’intention et la séquence (produits vus, étape abandonnée). Les logs lisent la livraison et l’échec (ce qui a été demandé, ce qui est revenu, combien de temps cela a pris). Un tableau de bord analytics peut sembler parfaitement normal alors que le tunnel de commande est cassé pour un sous-ensemble de clients qui n’ont jamais déclenché les événements qui auraient révélé la chute.
Quel niveau de détail pour les logs applicatifs ?
Les logs applicatifs enregistrent les événements métier plutôt que le trafic HTTP. Une boutique peut logger toutes les requêtes et ignorer encore quelle commande a échoué si l’application ne trace pas les validations, les refus de paiement ou les erreurs de stock. Enregistrez au minimum la création de commande (avec l’identifiant), les échecs de validation (règle métier concernée), les réponses de passerelle (montant, devise, code de refus) et les appels d’API de fulfillment (statut d’expédition, erreur d’adresse).
Évitez de logger les données sensibles (numéros de carte complets, CVV, mots de passe) même en développement. Masquez ou hachez les informations personnelles si votre juridiction l’exige. Structurez les logs en JSON pour faciliter le parsing : un message texte libre est difficile à requêter deux mois plus tard. Incluez toujours l’identifiant de requête et l’identifiant de session pour relier événement applicatif et ligne d’accès web.
Les logs de base de données qu’on oublie d’activer
Le slow query log de MySQL, PostgreSQL ou autre n’est souvent pas activé par défaut. Il enregistre les requêtes dont l’exécution dépasse un seuil configurable, les erreurs de connexion et les attentes de verrou. Sans lui, impossible de savoir si un tunnel de commande lent vient d’une jointure mal indexée ou d’un lock sur la table d’inventaire. Définissez un seuil réaliste (par exemple 500 ms) et ajustez-le selon votre charge : un seuil trop bas inonde les logs, un seuil trop haut masque les problèmes naissants.
Enregistrez aussi les connexions refusées (pool saturé) et les timeouts de transaction. Ces événements signalent souvent un pic de trafic ou une fuite de connexions dans le code applicatif. Si vous utilisez un cache Redis ou Memcached, activez ses propres logs pour tracer les évictions, les échecs de connexion et les taux de hit.
Pourquoi logger les appels sortants vers les passerelles ?
La passerelle de paiement peut retourner un refus, un timeout ou une erreur technique que votre application interprète et traduit en message utilisateur. Si vous ne loguez que le message final (« paiement refusé »), vous perdez le code exact renvoyé par la passerelle (fonds insuffisants, carte expirée, 3D Secure échoué, erreur réseau). Enregistrez la requête sortante (montant, devise, méthode) et la réponse complète (statut HTTP, code métier, message). Anonymisez les quatre derniers chiffres de la carte si la passerelle les renvoie, et masquez le reste.
Pour les appels d’API de fulfillment, tracez les erreurs d’adresse, les refus d’expédition et les timeouts. Ces données permettent de distinguer un problème chez le transporteur d’un bug dans votre intégration. Ajoutez l’identifiant de commande et l’identifiant de requête pour relier l’événement à la session client.
Les recherches internes à zéro résultat, signal invisible
La recherche interne du site capture ce que les visiteurs ont tapé, combien de résultats sont apparus et quelles recherches n’ont rien retourné. Une recherche à zéro résultat indique soit une rupture de stock, soit un problème de synonymes ou de catalogue. C’est un signal d’intention d’achat que vous manquez si vous ne le loguez pas. Enregistrez la chaîne de recherche, le nombre de résultats, la page de résultat consultée et si le visiteur a cliqué sur un produit.
Anonymisez les requêtes si elles contiennent des noms propres ou des adresses e-mail accidentellement collés. Agrégez les recherches fréquentes à zéro résultat pour détecter les produits manquants ou les variantes mal étiquetées. Un chatbot IA peut transformer ces recherches vides en recommandations de produits similaires ou en alerte pour le merchandising.
Combien de temps conserver les logs et où les stocker ?
La durée de rétention dépend de vos obligations réglementaires (RGPD, PCI-DSS) et de votre capacité de stockage. Gardez au minimum 30 jours en ligne pour diagnostiquer les incidents récents, puis archivez sur stockage froid (S3 Glacier, Azure Archive) pour les audits et les analyses à long terme. Les logs de paiement tombent sous PCI-DSS si vous gérez les données de carte vous-même ; la plupart des marchands délèguent cette responsabilité à la passerelle hébergée et ne conservent que les métadonnées (montant, statut, code de refus).
Centralisez les six couches dans un système de gestion de logs (ELK, Splunk, Datadog, Loki) pour corréler les événements par identifiant de requête. Sans centralisation, reconstituer un parcours exige de se connecter à six serveurs différents et de croiser manuellement les horodatages. Chiffrez les logs en transit et au repos si vous y stockez des informations personnelles. Définissez des alertes sur les taux d’erreur 5xx, les timeouts de passerelle et les pics de recherches à zéro résultat.
Qstomy et le monitoring : comprendre l’après-vente et la conversion
Qstomy est un agent IA Shopify qui guide les visiteurs vers l’achat (recommandations, upsell et cross-sell, panier, suivi de colis, SAV). Plus de cent marchands l’utilisent pour convertir, rassurer et fidéliser. Contrairement aux logs serveur qui diagnostiquent les pannes techniques, Qstomy enregistre les intentions client : questions sur les délais de livraison, demandes de politique de retour, comparaisons de produits. Ces interactions révèlent les frictions que les analytics ne capturent pas (visiteur hésitant sur la taille, inquiet du délai, cherchant une promo). En croisant les logs de conversation Qstomy avec les indicateurs techniques du site, vous distinguez les abandons dus à un bug de ceux dus à un doute non levé.
Qstomy répond aussi aux questions sur les offres disponibles uniquement en ligne ou uniquement en magasin, orientant le client vers le bon canal sans friction. Alors que le monitoring serveur vous dit si le tunnel de commande a répondu, Qstomy vous dit pourquoi le visiteur n’a pas cliqué sur Commander. Les deux sources se complètent : l’une pour la disponibilité technique, l’autre pour la disponibilité relationnelle.
Checklist, en bref et questions fréquentes
Checklist de démarrage :
Activez le slow query log de votre base de données avec un seuil de 500 ms.
Ajoutez request_time et upstream_response_time au format de log Nginx ou Apache.
Générez un X-Request-ID à l’edge et propagez-le à toutes les couches.
Loguez les réponses de passerelle (statut HTTP, code métier, message) dans l’application.
Enregistrez les recherches internes à zéro résultat pour détecter les produits manquants.
Centralisez les six couches dans un système de gestion de logs pour corréler par identifiant.
Définissez des alertes sur les taux d’erreur 5xx, timeouts de paiement et pics de recherches vides.
En bref : Une boutique en ligne écrit des logs à six niveaux (CDN, serveur web, application, base de données, appels tiers, recherche interne). Sans identifiant partagé, durée de requête et statut upstream, impossible de reconstituer un parcours client raté. Les logs serveur capturent ce qui a été demandé et livré ; les analytics JavaScript capturent ce qui a réussi à s’exécuter. Les deux répondent à des questions différentes et se complètent. Même un site construit gratuitement devrait activer le minimum : slow query log, request timing et logs applicatifs structurés.
Questions fréquentes :
Peut-on se contenter des logs du serveur web ?
Non. Le serveur web enregistre ce qu’il a retourné mais ignore pourquoi l’application a refusé la commande, pourquoi la base de données était lente ou ce que la passerelle a répondu. Vous saurez qu’une requête a pris trois secondes mais pas quelle couche a consommé ces trois secondes.
Comment corréler les logs si chaque couche a son propre horodatage ?
Générez un identifiant de requête unique (X-Request-ID) à l’entrée (CDN ou load balancer) et écrivez-le dans chaque log. Centralisez ensuite les six sources et requêtez par cet identifiant. Les horodatages servent à ordonner les événements au sein d’une même requête.
Les logs de recherche interne révèlent-ils des informations sensibles ?
Parfois. Un visiteur peut coller accidentellement une adresse e-mail ou un numéro de carte dans le champ de recherche. Anonymisez ou hachez les chaînes qui ressemblent à des données personnelles avant archivage, surtout si vous êtes soumis au RGPD.
Quelle différence entre identifier une session et identifier une requête ?
L’identifiant de session (cookie, JWT) dit quel visiteur ou compte fait plusieurs requêtes. L’identifiant de requête dit quelle tentative précise, utile quand un visiteur rafraîchit la page ou retente un paiement. Les deux sont nécessaires : session pour l’analyse de parcours, requête pour le débogage.
Faut-il un outil de monitoring payant dès le début ?
Non. Commencez par activer les logs natifs (access log, slow query log, logs applicatifs en JSON) et stockez-les localement. Même sur une plateforme gratuite, vous pouvez exporter vers un bucket S3 ou un dépôt Git. Passez à un outil centralisé quand corréler manuellement devient trop long, généralement après quelques milliers de commandes par mois.
Enzo
26 août 2026
