--- title: "Journal de relance : quelles traces demander avant d'automatiser ?" canonical: https://www.billabex.com/fr/blog/journal-relance-traces-automatisation/ lang: fr alternate: https://www.billabex.com/en/blog/collections-audit-trail-automation.md updated: 2026-09-22 index: https://www.billabex.com/llms.txt --- # Journal de relance : quelles traces demander avant d'automatiser ? Lors d'une démonstration, une frise affiche « relance effectuée » à côté d'une facture. La présentation paraît rassurante, mais elle ne répond pas encore aux questions utiles : quel message est parti, à quelle adresse, sur quel montant, après quelle décision et avec quel résultat ? Avant d'automatiser un portefeuille, demandez de reconstituer un dossier à partir des traces disponibles, sans faire intervenir la mémoire de la personne qui l'a traité. Un journal de relance doit permettre cette reconstruction. Il sert autant à comprendre une erreur qu'à reprendre une conversation correctement. Une longue liste de dates n'est pas suffisante si elle mélange les actions prévues, les envois tentés, les réponses et les changements de solde. Le critère d'achat est concret : une autre personne peut-elle expliquer ce qui s'est passé et ce qu'il reste à faire ? ## Distinguer les étapes derrière le mot « envoyé » Une action peut être planifiée, préparée, approuvée, transmise au prestataire, acceptée par le serveur destinataire, rejetée ou annulée. Toutes ces étapes ne sont pas nécessairement visibles dans chaque produit, mais leur signification doit être expliquée. Demandez ce qui déclenche chaque libellé de la frise et ce qui se passe lorsqu'une étape ultérieure échoue. Une coche sans définition ne constitue pas une preuve exploitable. La documentation de Twilio SendGrid illustre cette différence : un événement « processed » indique une prise en charge par le service, tandis que « delivered » correspond à la remise au serveur destinataire. Cette dernière étape ne démontre pas que le comptable a lu le message ou accepté la facture. L'exemple décrit ce fournisseur de messagerie ; il ne présume pas de la chaîne technique de Billabex. [Référence des événements SendGrid](https://www.twilio.com/docs/sendgrid/for-developers/tracking-events/event). Pendant la démonstration, faites apparaître un envoi rejeté, puis une action annulée après réception d'une réponse. Vous devez pouvoir les distinguer d'un message effectivement transmis. Si le [contact comptable a quitté l'entreprise](https://www.billabex.com/fr/blog/contact-comptable-parti-circuit-paiement/), le journal doit aider à repérer le problème de destinataire ; il ne doit pas vous laisser croire qu'une succession de tentatives sans réponse décrit un refus de payer. ## Relier l'action au dossier connu à cet instant Demandez la référence du client, les factures concernées, le montant utilisé et le destinataire au moment de l'action. Une adresse ou un solde actuellement corrects ne prouvent pas que le message ancien utilisait ces valeurs. Si un avoir a été ajouté après l'envoi, la reconstruction doit permettre de comprendre pourquoi le montant du courriel diffère du solde visible aujourd'hui. Pour une modification importante, recherchez l'auteur ou le processus responsable, la date et la nature du changement. Il peut s'agir d'une décision humaine, d'un import comptable ou d'une interprétation de réponse. Les trois ne donnent pas le même degré de confirmation. Un résumé produit automatiquement doit rester relié au message qui le motive, surtout lorsqu'il conduit à reporter une action ou à enregistrer une promesse. L'OWASP recommande de documenter l'auteur, le contexte, le moment et la nature d'un événement, avec des éléments permettant de relier les étapes d'une même interaction. Elle distingue aussi la date de l'événement de celle de son enregistrement. Ces principes techniques servent ici de grille de lecture pour l'acheteur : ils ne vous obligent pas à consulter des journaux informatiques bruts au quotidien. [Guide OWASP de journalisation](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html). ## Vérifier l'ordre des faits quand les informations arrivent en retard Prenons une chronologie fictive exprimée dans un même fuseau horaire. Le serveur destinataire accepte un message à 14 h 02. Le client répond à 14 h 03. La réponse est enregistrée immédiatement, mais l'information technique de remise arrive dans l'outil à 14 h 04. Une frise triée uniquement par heure d'enregistrement peut montrer la réponse avant la remise, sans que les faits réels soient contradictoires. L'outil doit permettre de retrouver cette différence quand elle explique le dossier. Vous n'avez pas besoin de deux horaires sur chaque écran, mais le support ou l'export autorisé doit pouvoir clarifier la séquence. Demandez également comment les fuseaux sont présentés lorsque votre équipe française travaille avec des clients européens. Des dates affichées sans indication peuvent devenir ambiguës autour d'un changement de journée. La même question se pose lorsqu'une comptabilité transmet tardivement un paiement. Le journal doit permettre de distinguer la date du mouvement de la date à laquelle le suivi en a eu connaissance. Notre article sur le [virement reçu mais non rapproché](https://www.billabex.com/fr/blog/virement-recu-facture-encore-ouverte-retrouver-un-paiement-non-rapproche/) explique pourquoi cette distinction compte : corriger l'information du dossier ne fait pas naître un nouvel encaissement. ## Compter des messages, pas toutes les lignes du journal Voici une simulation explicite. Douze actions sont planifiées, puis deux annulées avant transmission. Les dix autres sont transmises au prestataire. Neuf obtiennent une confirmation de remise au serveur destinataire et la dernière un rejet. Trois réponses sont ensuite enregistrées, dont une réponse automatique et deux messages humains. Supposons que chacune de ces étapes produise une ligne distincte dans le journal. Le total est de **37 événements** : 12 planifications + 2 annulations + 10 transmissions + 9 remises + 1 rejet + 3 réponses. Ce total ne représente ni 37 relances ni 37 clients contactés. Le nombre de transmissions est dix, et l'on dispose de neuf confirmations de remise au serveur dans les hypothèses retenues. Aucun des événements décrits n'est un paiement. Cette démonstration vérifie le vocabulaire du produit autant que son calcul. Un tableau qui additionne toutes les lignes comme de l'activité commerciale donne une lecture trompeuse. Demandez comment le journal rattache chaque retour au bon message et comment il traite deux notifications techniques relatives au même événement. La question porte sur la qualité de l'explication du dossier, sans imposer à l'acheteur une architecture particulière. ## Examiner la conservation avec la bonne finalité La CNIL recommande, pour les événements de journalisation visés par sa fiche de sécurité, une conservation glissante de **six mois à un an**, avec des exceptions à justifier selon le contexte. Cette indication ne fixe pas une durée universelle pour conserver toutes les factures ou toutes les conversations de recouvrement. Les pièces métier et les traces de sécurité peuvent répondre à des finalités différentes. [CNIL, Tracer les opérations, 14 mars 2024](https://www.cnil.fr/fr/securite-tracer-les-operations). Demandez donc quelles informations restent accessibles, à qui et pendant combien de temps. Faites préciser ce qui disparaît lorsqu'un accès utilisateur est retiré ou qu'un contrat se termine. Une conservation annoncée ne sert pas à grand-chose si votre équipe ne peut jamais récupérer les éléments nécessaires à la reprise d'un dossier. À l'inverse, tout garder sans limite n'est pas un objectif raisonnable de traçabilité. Évitez de transformer le journal en copie générale des données. Une référence peut relier un événement à une pièce conservée dans l'espace approprié, sans recopier tous les documents dans chaque trace. Les personnes chargées du suivi doivent accéder au contexte utile ; cela n'implique pas un accès libre aux journaux de sécurité ou aux informations de tous les autres comptes de l'entreprise. ## Tester une reprise réelle pendant le pilote Choisissez un dossier de démonstration comportant une modification de montant, une réponse et une action suspendue. Demandez à une personne qui ne l'a pas traité de retrouver la dernière décision et la prochaine étape. Elle doit pouvoir distinguer une promesse extraite d'une réponse d'une simple hypothèse de paiement. Le guide pour [rendre une promesse vérifiable](https://www.billabex.com/fr/blog/promesse-paiement-verifiable/) précise les références nécessaires à cette lecture. Intégrez ce contrôle à votre [portefeuille pilote comparable](https://www.billabex.com/fr/blog/automatisation-relances-portefeuille-pilote/) avant de généraliser l'usage. Notez les éléments disponibles directement, ceux que seul le support peut fournir et ceux qui ne sont pas conservés. Une limite documentée permet de décider ; une fonctionnalité supposée sur la seule base d'une frise ne le permet pas. La [vue client à 360° de Billabex](https://www.billabex.com/fr/produit/vue-client-360/) rassemble les factures et les conversations pour retrouver le contexte. Lors de votre démonstration, utilisez un cas précis pour examiner la profondeur des traces disponibles et les modalités d'accès qui répondent à votre besoin. Le bon résultat est une explication vérifiable du dossier, avec ses limites connues, qui permet à votre équipe de reprendre la main sans reconstruire toute l'histoire. ## Sources - Twilio SendGrid, documentation consultée le 7 septembre 2026 : [signification des événements de messagerie](https://www.twilio.com/docs/sendgrid/for-developers/tracking-events/event). - OWASP Cheat Sheet Series, consultée le 7 septembre 2026 : [attributs et finalités des journaux](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html). - CNIL, 14 mars 2024 : [sécurité et traçabilité des opérations](https://www.cnil.fr/fr/securite-tracer-les-operations).