Parce qu'en cas de problème avec un partenaire, le journal est votre SEULE preuve de ce qui a été envoyé et reçu, à quel moment — sans lui, vous ne pouvez ni diagnostiquer, ni démontrer votre bonne foi, et vous en êtes réduit aux suppositions. Les situations où le journal sauve : (1) LITIGE avec un partenaire : « nous n'avons jamais reçu votre commande », « vos données étaient erronées ». Sans journal, c'est parole contre parole. Avec le journal, vous montrez exactement ce qui a été transmis, quand, et quelle réponse a été reçue. (2) DIAGNOSTIC d'un dysfonctionnement : des données arrivent fausses ou incomplètes — vient-il de l'envoi, de la réception, du traitement chez eux ou chez vous ? Le journal tranche immédiatement. (3) PANNES intermittentes : un échange échoue une fois sur cent. Impossible à reproduire à la demande, mais le journal en garde la trace et révèle le motif. (4) ÉVOLUTIONS non annoncées : le partenaire modifie son format ou son comportement sans prévenir (cela arrive souvent). Le journal montre à partir de quand les réponses ont changé. (5) REPRISE après incident : savoir précisément ce qui est passé et ce qui ne l'est pas permet de rejouer uniquement ce qui manque, sans doublon. (6) Contrôles internes ou audit : justifier ce qui a été transmis. Ce qu'il faut journaliser : (1) La DATE et l'HEURE précises. (2) Le SENS (envoi ou réception) et le service concerné. (3) Les DONNÉES échangées (ou un résumé si le volume est trop important). (4) Le CODE de retour et le message d'erreur éventuel. (5) La DURÉE de l'échange (utile pour repérer une dégradation de performance). (6) Un IDENTIFIANT permettant de relier l'échange à l'opération métier concernée (numéro de commande, de facture). C'est ce qui rend le journal réellement exploitable. Les précautions : (1) ⚠️ DONNÉES PERSONNELLES et SECRETS : ne journalisez jamais de mots de passe, de clés d'API ni de données sensibles inutiles. La journalisation ne doit pas devenir une faille de sécurité ni un manquement à la réglementation (⚠️ variable selon les pays). (2) VOLUME : prévoyez une rotation et une purge, sinon le journal saturera le disque. (3) PERFORMANCE : la journalisation ne doit pas ralentir significativement les échanges. (4) ACCESSIBILITÉ : un journal illisible ou introuvable ne sert à rien. Prévoyez une consultation simple, avec recherche par date ou par identifiant. (5) Protection : le journal contient des informations métier — protégez-en l'accès. Le principe général : (1) Tout ce qui sort de votre maîtrise (un système tiers) doit être TRACÉ. (2) Vous ne contrôlez ni la disponibilité, ni le comportement, ni les évolutions du partenaire : la traçabilité est votre seule protection. (3) C'est un investissement modeste qui se révèle décisif le jour d'un incident — et ce jour arrive toujours. En résumé : journalisez les échanges parce que, face à un partenaire, le journal constitue votre SEULE preuve de ce qui a été envoyé et reçu, et à quel moment. Il tranche les litiges (« nous n'avons jamais reçu votre commande »), permet de localiser l'origine d'une anomalie (envoi, réception ou traitement), garde la trace des pannes intermittentes impossibles à reproduire, révèle les évolutions non annoncées du partenaire — un grand classique — et rend possible une REPRISE propre après incident en distinguant ce qui est réellement passé de ce qui ne l'est pas. Journalisez la date et l'heure, le sens de l'échange, les données (ou un résumé), le code de retour et le message d'erreur, la durée, et surtout un IDENTIFIANT reliant l'échange à l'opération métier (numéro de commande ou de facture), sans quoi le journal reste inexploitable. Prenez trois précautions : ne jamais y consigner de secrets (clés, jetons) ni de données personnelles superflues, prévoir rotation et purge pour ne pas saturer le disque, et rendre le journal réellement consultable (recherche par date ou identifiant) tout en en protégeant l'accès. Le principe est simple : tout ce qui échappe à votre maîtrise doit être tracé — vous ne contrôlez ni la disponibilité ni les évolutions d'un système tiers.

En partant du principe que le service distant SERA indisponible, lent ou incohérent un jour : prévoyez les délais d'attente, les reprises, une file d'attente pour ne rien perdre, la validation de tout ce qui arrive, et une information claire des utilisateurs. Ce qui peut mal se passer (et se produira) : (1) Service INDISPONIBLE : panne, maintenance, coupure réseau de votre côté ou du leur. (2) LENTEUR : le service répond, mais au bout de trente secondes — votre application semble figée. (3) Réponse INATTENDUE : format modifié, champ manquant, valeur nulle imprévue, message d'erreur au lieu des données. (4) Réponse PARTIELLE ou tronquée. (5) Authentification expirée : jeton périmé, clé révoquée, mot de passe changé. (6) Limitation de débit : le partenaire refuse au-delà d'un certain nombre d'appels. (7) Double traitement : vous renvoyez une demande déjà prise en compte parce que la réponse s'est perdue. Les mécanismes de robustesse : (1) DÉLAI D'ATTENTE (timeout) : ne laissez jamais un appel bloquer indéfiniment. Fixez une durée maximale raisonnable. (2) REPRISES avec espacement progressif : réessayer immédiatement puis à intervalles croissants absorbe les pannes brèves. Mais limitez le nombre de tentatives pour ne pas boucler indéfiniment. (3) FILE D'ATTENTE : si l'envoi échoue, stockez la demande localement et rejouez-la plus tard. C'est ce qui garantit qu'aucune opération n'est perdue — essentiel pour les échanges métier (commandes, factures). (4) TRAITEMENT ASYNCHRONE : ne faites pas attendre l'utilisateur derrière un service externe. Enregistrez son action, informez-le, et effectuez l'échange en arrière-plan. (5) IDEMPOTENCE : concevez les échanges de sorte qu'un même envoi répété ne crée pas de doublon (identifiant unique d'opération). C'est indispensable dès qu'il y a des reprises. (6) VALIDATION systématique de ce qui arrive : ne faites jamais confiance au format ni au contenu. Une donnée externe non validée qui entre en base est une bombe à retardement. (7) DÉGRADATION contrôlée : si le service est indisponible, l'application doit continuer à fonctionner pour le reste, avec une fonctionnalité en moins plutôt qu'un blocage total. Côté utilisateur : (1) INFORMEZ clairement : « L'envoi au service de facturation n'a pas abouti, il sera automatiquement retenté. Votre facture est enregistrée. » L'utilisateur doit savoir ce qui est acquis et ce qui reste en attente. (2) Ne montrez jamais un message technique brut. (3) Prévoyez une visibilité sur les éléments en attente et, si pertinent, un moyen de relancer manuellement. La méthode : (1) TESTEZ les scénarios de panne : coupez le réseau, simulez une réponse invalide, un délai très long, une authentification refusée. Une gestion d'erreur jamais testée ne fonctionne généralement pas le jour venu. (2) JOURNALISEZ tout (voir question précédente). (3) SURVEILLEZ : alertez si les échecs se multiplient — mieux vaut le découvrir avant le partenaire. (4) Documentez le comportement attendu en cas de panne. En résumé : concevez vos échanges en partant du principe que le service externe SERA un jour indisponible, lent ou incohérent — car cela arrivera. Protégez-vous par un DÉLAI D'ATTENTE (jamais d'appel bloquant indéfiniment), des REPRISES espacées progressivement mais limitées en nombre, et surtout une FILE D'ATTENTE qui stocke localement les envois échoués pour les rejouer : c'est elle qui garantit qu'aucune opération métier n'est perdue. Traitez les échanges de façon ASYNCHRONE pour ne pas faire attendre l'utilisateur derrière un système tiers, et rendez-les IDEMPOTENTS (identifiant unique d'opération) afin qu'une reprise ne crée jamais de doublon. VALIDEZ systématiquement tout ce qui arrive — une donnée externe non contrôlée qui entre en base est une bombe à retardement — et prévoyez une DÉGRADATION contrôlée : l'indisponibilité d'un service doit priver d'une fonctionnalité, pas bloquer l'application entière. Côté utilisateur, informez clairement de ce qui est acquis et de ce qui reste en attente, sans jargon technique. Enfin, TESTEZ réellement les scénarios de panne (réseau coupé, réponse invalide, délai excessif, authentification refusée), journalisez tout et surveillez la multiplication des échecs : une gestion d'erreur jamais éprouvée ne fonctionne pas le jour où elle sert.