Comprendre le moment où le doublon se forme
Un service envoie une requête à une plateforme sociale. Celle-ci crée la publication, puis renvoie une réponse. Si la connexion coupe entre ces deux événements, le service voit une erreur alors que le contenu existe déjà. Une relance naïve produit une seconde publication.
Le même problème peut survenir plus tôt. Un flux change l’identifiant d’un article, une tâche est exécutée par deux travailleurs ou un utilisateur recharge une page après avoir validé. Les causes diffèrent, mais elles partagent un défaut : le système ne possède pas une identité stable pour l’opération.
La prévention commence donc avant l’appel au réseau. Il faut nommer l’article, le compte ciblé et l’intention de publication de manière reproductible. Deux tentatives portant sur la même combinaison doivent retrouver le même enregistrement.
Donner un identifiant stable à l’article
L’identifiant du flux est souvent le premier choix. Dans Atom, chaque entrée doit posséder un identifiant. En RSS, le champ guid peut jouer ce rôle, à condition que l’éditeur le garde stable. Une URL canonique constitue un bon second repère.
Le titre ne convient pas. Il peut être corrigé et plusieurs articles peuvent partager une formulation identique. La date seule ne convient pas non plus, car deux contenus peuvent être publiés pendant la même seconde ou recevoir une nouvelle date après une migration.
Lorsque la source change de CMS, conservez une table de correspondance si les identifiants sont remplacés. Sans cette précaution, le premier passage sur le nouveau flux peut donner l’impression que tout l’historique vient d’être publié.
Définir une clé pour chaque destination
Un même article peut légitimement produire une publication Facebook, une publication Instagram et un post LinkedIn. La clé doit donc inclure la destination. Elle peut combiner l’organisation, l’article, le compte social et le type d’envoi.
Cette clé reste la même lors d’une reprise technique. En revanche, une nouvelle campagne décidée par la rédaction peut créer une autre intention de publication. La différence doit venir d’une action explicite, pas d’un changement accidentel dans le texte.
Une contrainte d’unicité en base de données renforce cette règle. Deux travailleurs qui démarrent au même instant ne pourront pas créer deux opérations portant la même clé. Le premier gagne, le second récupère l’enregistrement existant.
Séparer les états préparé, envoyé et confirmé
Le statut « publié » ne devrait apparaître qu’après une confirmation exploitable de la plateforme. Avant cela, l’opération peut être préparée, en attente, en cours d’envoi ou incertaine. Cette dernière situation mérite un traitement particulier.
Lorsqu’une réponse se perd, le service ne sait pas encore si le réseau a créé le contenu. Il peut consulter l’API lorsque celle-ci permet de retrouver l’objet, ou demander une vérification humaine. Relancer immédiatement est la solution la plus simple techniquement, mais aussi celle qui crée le doublon visible.
L’historique doit conserver l’identifiant retourné par la plateforme. Cet identifiant sert ensuite à vérifier le contenu, construire son lien permanent ou éviter une nouvelle création.
Rendre les tâches rejouables sans répéter leurs effets
Une file de traitement rejoue parfois une tâche après un délai dépassé ou un redémarrage. Ce comportement est normal. La tâche doit donc vérifier son état avant chaque effet externe : génération, téléversement d’image et création de publication.
Si le brouillon existe déjà, la tâche le réutilise. Si l’image a été envoyée, elle conserve son identifiant. Si la publication est confirmée, elle s’arrête. Cette logique demande quelques contrôles, mais elle évite de multiplier les appels et les contenus.
Le verrouillage global n’est pas nécessaire pour commencer. Une contrainte d’unicité et des transitions d’état atomiques couvrent les collisions ordinaires. Un système plus complexe devient utile seulement si le volume montre des contentions réelles.
Traiter les clics répétés dans l’interface
Le bouton de validation doit devenir indisponible pendant l’envoi, mais ce contrôle visuel ne suffit pas. Deux onglets ouverts ou une connexion lente peuvent déclencher deux requêtes malgré tout. Le serveur doit reconnaître la même intention.
Après le clic, l’interface peut afficher l’état en cours sans annoncer trop tôt un succès. Si la requête dure, l’utilisateur doit pouvoir quitter la page et retrouver l’opération dans l’historique. Le forcer à attendre devant un bouton favorise les rechargements et les nouveaux clics.
Une réponse répétée du serveur devrait renvoyer l’état existant plutôt qu’une erreur incompréhensible. Pour l’utilisateur, valider deux fois par accident aboutit ainsi au même résultat qu’une seule validation.
Normaliser les adresses avant de comparer
Un article peut apparaître avec plusieurs adresses : version avec paramètres de suivi, redirection depuis une ancienne rubrique ou variation de protocole. La comparaison brute de chaînes considère ces liens comme différents.
La source canonique indique l’adresse préférée. Le service peut aussi retirer les paramètres connus pour le suivi et suivre les redirections sûres. Cette normalisation doit rester prudente, car deux paramètres peuvent parfois désigner des versions réellement distinctes.
Conservez l’adresse reçue et l’adresse normalisée. La première aide au diagnostic du flux. La seconde sert à la déduplication et au maillage interne. Effacer l’original rend les erreurs plus difficiles à comprendre.
Reprendre une erreur selon sa catégorie
Une erreur temporaire, comme un service indisponible, peut être rejouée après un délai. Une erreur de permission demande une reconnexion. Une image refusée exige souvent une correction du média. Ces cas ne devraient pas suivre la même boucle automatique.
Limitez le nombre de reprises et espacez-les. Une tâche qui échoue toutes les secondes encombre les journaux et risque d’atteindre les limites de l’API. Après plusieurs échecs identiques, elle passe dans un état qui demande une action.
Gardez le message reçu de la plateforme, puis traduisez-le en instruction lisible pour la rédaction. Le détail technique reste utile au support, tandis que l’utilisateur voit l’action à mener.
Tester avec des pannes volontaires
Un test heureux ne suffit pas pour vérifier les doublons. Interrompez la connexion après l’envoi, redémarrez le travailleur pendant une tâche et lancez deux validations presque simultanées. Le résultat attendu reste une seule publication par destination.
Vérifiez aussi le retour dans l’interface. L’état doit converger vers la réalité de la plateforme. Si l’envoi est incertain, le système ne doit ni afficher un succès inventé, ni créer automatiquement une seconde publication.
Répétez aussi le scénario avec deux réseaux. Une panne sur X ne doit pas remettre en cause la publication déjà confirmée sur LinkedIn. Les opérations partagent l’article mais gardent des états indépendants.
- Deux exécutions concurrentes créent une seule opération en base.
- Une réponse perdue ne provoque pas une relance aveugle.
- L’identifiant du réseau est conservé dès qu’il est reçu.
- Une correction de titre ne transforme pas l’article en nouveauté.
- Chaque destination peut reprendre sans toucher aux autres.
Détecter un doublon sans supprimer trop vite
Une publication peut sembler dupliquée alors qu’elle répond à une décision légitime de rediffusion. Avant toute suppression automatique, comparez l’article, le compte, l’heure, le texte et l’intention enregistrée. Deux posts proches ne sont pas forcément la même opération.
Lorsqu’un doublon technique est confirmé, gardez une trace des deux identifiants. La rédaction choisit lequel conserver selon les réactions déjà reçues et l’heure de publication. Effacer le plus récent par défaut peut supprimer celui que le public a commencé à partager.
Le service peut signaler une paire suspecte sans agir seul. Ce contrôle est particulièrement utile après une panne ou une reprise manuelle. Il doit rester rare pour ne pas transformer chaque campagne de rediffusion en alerte.
Analysez ensuite la cause dans la chaîne interne. Un double clic, deux travailleurs concurrents et une réponse réseau perdue demandent des corrections différentes. Le symptôme public est le même, mais le correctif se place à un autre endroit.
Une fois le problème réparé, rejouez le scénario exact dans un environnement contrôlé. La preuve attendue n’est pas seulement l’absence de doublon. L’historique doit aussi montrer qu’une seconde tentative a retrouvé l’opération existante.
Regardez enfin les publications déjà visibles avant de traiter une alerte. Une campagne préparée par une autre équipe peut utiliser le même lien avec un texte différent. Le registre interne reste la première source pour reconnaître une opération, mais la vérification sur le compte apporte le contexte que les seules clés techniques ne contiennent pas.
La suppression doit rester une action confirmée. Le système peut recommander le post probablement dupliqué et expliquer son rapprochement, puis laisser une personne choisir. Cette étape protège les réponses et partages déjà reçus. Elle produit aussi une trace de décision utile si le même cas revient lors d’une prochaine panne.
Ajoutez la date de détection et le compte concerné à cette trace. Ces deux repères permettent de regrouper les incidents liés à une même reprise et de vérifier si le défaut touche une seule destination. L’équipe corrige alors le bon parcours sans suspendre toutes les publications par précaution.
Après quelques semaines sans nouvelle alerte, conservez malgré tout le test de reprise. Il doit rester exécutable après une évolution du connecteur ou du système de tâches. Un doublon évité une fois peut revenir si la clé, l’ordre des états ou la stratégie de relance change.
Sources officielles
Documents utilisés pour vérifier les points techniques de cet article.