--- title: "Un import rejoué ne doit pas relancer deux fois : tester les doublons" canonical: https://www.billabex.com/fr/blog/import-rejoue-doublons-relances/ lang: fr alternate: https://www.billabex.com/en/blog/replayed-import-duplicate-reminders.md updated: 2026-10-24 index: https://www.billabex.com/llms.txt --- # Un import rejoué ne doit pas relancer deux fois : tester les doublons La synchronisation comptable s'interrompt. Le support propose de rejouer le dernier import, puis confirme que les factures sont à nouveau visibles. Une heure plus tard, plusieurs clients reçoivent une deuxième relance identique. Le nombre de factures n'a pourtant pas augmenté dans l'outil. Cet incident révèle deux sujets distincts : reconnaître une donnée déjà reçue et reconnaître une action déjà effectuée. Un logiciel peut éviter les doublons de dossiers tout en répétant un message. Pour évaluer une intégration de recouvrement, le test doit donc aller jusqu'au résultat visible par le client, dans un environnement prévu pour les essais. ## Définir ce que « rejouer sans effet supplémentaire » signifie Les équipes techniques parlent d'idempotence lorsqu'une répétition de la même opération n'ajoute pas un nouvel effet métier. Ce principe doit être traduit dans votre cas : une facture reste une seule facture, un paiement n'est pas compté deux fois et la même décision de relance ne produit pas plusieurs envois. AWS explique que deux demandes identiques en apparence peuvent pourtant exprimer deux intentions différentes. Sa bibliothèque technique recommande de rendre l'intention identifiable plutôt que de déduire systématiquement le doublon du seul contenu. [AWS Builders' Library, reprises et API idempotentes](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/). Dans le recouvrement, cela évite une autre erreur : bloquer à tort une relance légitime plus tard parce que son texte ressemble à une ancienne. Le test doit distinguer la reprise de la même action et une nouvelle action autorisée à une autre date. Il ne demande pas qu'un client ne soit jamais recontacté. ## Garder l'identité stable au-delà du nom du fichier Renommer un fichier ne crée pas de nouvelles factures. Modifier l'ordre des lignes non plus. Pour identifier une pièce, le système doit retrouver son origine et son identifiant dans le périmètre concerné, notamment la société émettrice. Une simple comparaison du numéro visible peut confondre deux entités. Odoo 18 documente l'usage d'identifiants externes constants pour mettre à jour des enregistrements par import. Il avertit qu'un identifiant supprimé ou modifié peut provoquer une création en double. Cette règle d'importation illustre l'importance de l'identité persistante, sans prouver le comportement d'une autre intégration. [Odoo 18, import et mise à jour des données](https://raw.githubusercontent.com/odoo/documentation/18.0/content/applications/essentials/export_import_data.rst). Préparez donc une version identique du fichier, une version renommée et une version dont les lignes sont triées autrement. Le résultat attendu doit rester stable. La distinction entre [numéro de facture et entité juridique](https://www.billabex.com/fr/blog/factures-meme-numero-entites/) aide à choisir les références qui rendent cette vérification fiable. ## Construire un cas où les totaux ne masquent pas le problème Prenons une simulation avec dix clients et quarante factures de 2 000 €, soit 80 000 € ouverts au départ. L'import est transmis trois fois. Cela représente 120 lignes traitées au fil des transmissions, mais toujours quarante factures métier et dix clients. Un encours de 240 000 € révélerait une duplication manifeste. Vérifier uniquement les 80 000 € ne suffit pas. Le logiciel pourrait avoir créé quatre-vingts factures supplémentaires puis les avoir exclues du total affiché. Demandez le nombre de pièces actives, leurs références et les liens avec les conversations. Une trace d'import répétée est normale ; une seconde dette pour la même pièce ne l'est pas. Pour une vague de test distincte, choisissez six de ces clients, avec deux factures de 2 000 € chacun, soit douze factures et 24 000 €. La règle de l'essai prévoit un message groupé par client pour cette même décision : six messages attendus, pas douze. Ce regroupement est une hypothèse de test, pas une règle universelle de cadence. Si le même import est rejoué trois fois et que dix-huit messages partent pour cette seule vague, il y a douze envois supplémentaires. La multiplication est de trois, même si les factures et le solde restent corrects. Le compte rendu doit signaler l'écart au niveau des communications, pas seulement déclarer « import sans doublon ». ## Tester la reprise après un résultat incertain Le cas le plus instructif survient quand le service a effectué l'opération, mais que sa confirmation n'est pas revenue au demandeur. Une reprise peut alors répéter une action qui avait déjà réussi. Demandez une démonstration contrôlée de cette situation avec des destinataires de test et des envois isolés de la production. Stripe documente des retransmissions automatiques d'événements pouvant durer jusqu'à trois jours en mode réel. Il précise également que les événements peuvent arriver plusieurs fois et dans un ordre différent de leur génération. Ces comportements montrent pourquoi une intégration doit prévoir les reprises ; ils ne décrivent pas la cadence de vos relances. [Stripe, livraison des événements et doublons](https://docs.stripe.com/webhooks). Le rapport d'essai doit distinguer tentative, action acceptée par le service d'envoi et résultat connu. Si la confirmation manque, le système doit rendre l'incertitude visible et la résoudre avant une répétition susceptible de toucher le client. Une ligne « erreur » ne prouve pas que rien n'a été envoyé. ## Vérifier qu'une ancienne donnée ne rouvre pas une facture payée Reprenons les six clients de la vague simulée. Avant l'envoi, l'un d'eux règle ses deux factures, soit 4 000 €. Le paiement est vérifié et affecté. Le périmètre à relancer pour cette vague devient cinq clients, dix factures et 20 000 €. Rejouez alors l'extraction ancienne qui montrait encore 24 000 €. Le dossier doit conserver l'effet du paiement récent ou demander une résolution explicite du conflit de données. Un ancien import ne doit pas être pris pour une nouvelle preuve d'impayé. Répéter mécaniquement « la dernière donnée reçue gagne » peut inverser la chronologie des faits. Ce scénario complète le sujet des [factures modifiées après une relance](https://www.billabex.com/fr/blog/facture-modifiee-apres-relance-versions/). Dans les deux cas, la date de réception d'une information et la date de l'événement qu'elle décrit ne sont pas interchangeables. Le test doit aussi observer les messages déjà préparés avant l'arrivée du paiement. ## Inclure la nouvelle action légitime dans le contrôle Une protection trop large peut supprimer le doublon et toutes les relances suivantes. Ajoutez donc un scénario où, après examen du dossier, une nouvelle action est réellement décidée. Elle doit pouvoir être distinguée de la reprise précédente, tout en tenant compte des paiements, réponses et accords intervenus depuis. AWS souligne aussi que la durée pendant laquelle une demande reste reconnue dépend du service et de son contrat. Demandez jusqu'où remonte une reprise prise en charge et ce qui se passe au-delà. Un essai réussi à cinq minutes ne démontre pas automatiquement le comportement après plusieurs jours. ## Demander une preuve que la finance peut relire Le livrable utile contient les fichiers utilisés, les montants attendus, les pièces retrouvées et les messages effectivement produits. Le [journal de relance](https://www.billabex.com/fr/blog/journal-relance-traces-automatisation/) aide à réunir ces éléments sans confondre les étapes techniques avec une communication client. Pour évaluer votre circuit, examinez les [intégrations Billabex](https://www.billabex.com/fr/produit/integrations/) avec ces scénarios de reprise. Faites préciser les résultats observables et les limites du connecteur concerné. Aucun slogan sur la fiabilité ne remplace la vérification de trois choses : le même dossier, le bon solde actuel et uniquement l'action réellement autorisée. ## Sources - AWS Builders' Library, Making retries safe with idempotent APIs. - Odoo 18, Export and import data, identifiants et réimportation. - Stripe, Receive Stripe events, livraison et doublons. Sources consultées le 7 septembre 2026.