Si elle manque, le contrôle porte d’abord sur ce que le site expose. Si elle est présente, il faut suivre sa récupération et son import. Cette séparation évite de modifier les réglages de publication sociale alors que le nouvel article n’est peut-être jamais arrivé jusque-là.
Pour transmettre l’incident, la rédaction peut réunir un article témoin, les adresses utilisées et quelques heures de contrôle. La personne qui maintient le site pourra alors comparer des réponses précises. Si l’article est déjà détecté mais que son texte manque en partie, la recherche est différente : le guide du contenu RSS incomplet traite ce cas.
Prendre un article témoin et conserver les heures
Une fiche d’incident peut commencer par l’URL de l’article et l’heure à laquelle sa version publique a été observée. Viennent ensuite l’URL du flux configuré et le dernier contrôle connu de l’outil. Pour comparer ces heures, il faut leur fuseau : un écran en heure locale et un journal en UTC peuvent sembler se contredire alors qu’ils décrivent le même moment.
La personne chargée du site peut ouvrir l’article sans session d’administration. Une prévisualisation dans le CMS ne prouve pas que le public reçoit déjà la page. Si la publication est programmée, la fiche doit distinguer l’heure prévue de l’heure où l’article a réellement été observé en ligne. Le diagnostic se fonde sur cette seconde observation.
Un ancien article corrigé est un témoin ambigu. Son absence d’une liste de nouveautés ne démontre pas une panne ; le lecteur peut déjà connaître son adresse. Une nouvelle publication attendue dans le flux permet de vérifier plus clairement l’arrivée d’une entrée. La correction d’un contenu existant demande, elle, de connaître la manière dont le système traite les mises à jour.
Dans un exemple fictif, la rédaction constate la page publique à 9 h 10 et un dernier contrôle du flux à 9 h 05. Rien ne permet encore de parler de panne. Si le contrôle suivant a lieu à 9 h 20, l’observation utile est celle faite après cette échéance. Ces horaires illustrent une méthode ; ils ne décrivent pas la cadence d’un outil particulier.
Vérifier le contenu du flux réellement connecté
Le test doit utiliser l’adresse enregistrée dans l’outil. En essayer une autre, trouvée sur le site, pourrait masquer une simple erreur de source : WordPress distingue notamment les flux d’articles de celui des commentaires. Son manuel des flux natifs documente ces sorties. Deux URL proches ne désignent donc pas nécessairement la même liste.
La comparaison se fait sur le corps de la réponse reçue, pas seulement sur l’apparence de la page dans le navigateur. Le responsable technique peut rechercher l’URL exacte de l’article et relever les dernières entrées présentes. Une page de connexion ou de protection peut s’afficher à la place du XML attendu ; un code de réussite HTTP ne suffit alors pas à montrer que le bon contenu a été fourni.
Quand l’article n’apparaît pas, sa rubrique et son type de contenu méritent un contrôle. Un flux spécialisé peut fonctionner tout en excluant ce nouvel article. Le guide des flux WordPress par rubrique détaille cette sélection. Ici, l’objectif est seulement d’établir si le témoin appartient bien au périmètre déjà configuré, avant de modifier ce périmètre pour résoudre une fausse panne.
La réponse conservée au moment du constat devient une pièce de comparaison, avec l’adresse demandée et l’adresse finale après redirection éventuelle. Si un collègue reçoit d’autres entrées, les deux relevés doivent rester datés : le contenu a pu évoluer entre les contrôles. Un écart simultané orienterait plutôt la recherche vers le trajet des requêtes ou les copies servies aux différents lecteurs.
Séparer la fréquence de lecture et les caches
Une ancienne copie peut encore être servie alors que le site a produit un flux récent. Mais le retard peut aussi venir du lecteur, qui n’a pas encore effectué son prochain passage. La distinction change le correctif : multiplier les lectures n’aide guère si elles récupèrent toujours la même copie. Les horaires relevés plus tôt permettent de commencer à séparer ces deux possibilités.
La spécification RSS 2.0 prévoit un champ facultatif ttl, exprimé en minutes, qui indique combien de temps un canal peut être conservé en cache avant actualisation. Elle distingue aussi les informations du canal de celles de chaque entrée. La date globale du flux ne suffit donc pas à prouver la présence d’un article précis. Spécification RSS 2.0.11.
La documentation WordPress peut prêter à confusion sur ce point. Sa fonction fetch_feed() met par défaut les flux qu’elle récupère en cache pendant douze heures. Cette documentation décrit WordPress comme lecteur d’un flux distant ; elle ne fixe pas un délai universel de publication des flux produits par un site WordPress. Référence de fetch_feed().
Pour savoir quel délai s’applique, la personne qui maintient le système doit identifier le composant qui conserve la copie. Elle peut comparer une réponse de l’origine avec celle reçue par le lecteur, dans un test maîtrisé, puis examiner les règles de cache. La rédaction n’a pas besoin d’en modifier les paramètres elle-même ; elle peut fournir l’article témoin et les heures qui rendent la comparaison possible.
Une purge ciblée peut servir au diagnostic si le responsable technique la juge adaptée. Mais sa réussite ponctuelle ne clôt pas l’incident. Le prochain article doit aussi apparaître sans intervention manuelle. Sinon, l’équipe a seulement trouvé une manière de contourner le retard, sans corriger la règle qui le provoque.
Comprendre une réponse « non modifié »
Les logiciels qui lisent un flux peuvent demander si leur copie est encore à jour. Ils indiquent la version connue dans des en-têtes de requête, notamment If-None-Match ou If-Modified-Since. Le serveur peut répondre 304 Not Modified, c’est-à-dire « non modifié », pour signaler que cette copie peut être réutilisée. Ce mécanisme de validation est documenté dans la norme HTTP sur les caches. RFC 9111, validation des réponses.
Une réponse 304 n’est donc pas, à elle seule, une erreur. Elle devient une piste lorsque l’on sait qu’un nouvel article appartient au flux mais que le lecteur continue de recevoir cette réponse. Le responsable technique peut alors comparer une récupération complète avec la requête conditionnelle, et vérifier les valeurs qui identifient la version. Le diagnostic porte sur leur cohérence avec le contenu reçu.
Dans EditoRelay, la lecture RSS utilise les valeurs ETag et Last-Modified conservées lorsqu’elles sont disponibles. Lors d’une réponse 304, le traitement enregistre le contrôle et prévoit le suivant, sans importer d’entrées depuis cette réponse. Ce comportement est vérifié dans le code ; il n’établit pas qu’un flux réel souffre aujourd’hui d’un problème de cache.
Le relevé à transmettre peut donc rester précis : à telle heure, le lecteur a reçu 304 ; à telle autre, une récupération complète contenait ou non l’URL témoin. L’équipe technique dispose ainsi d’une contradiction vérifiable. « Le RSS est cassé » donne beaucoup moins d’informations et pousse à tester plusieurs changements sans savoir lequel a un effet.
Quand le flux est récent mais que l’article n’arrive pas
Si l’URL témoin figure dans la réponse réellement récupérée, le contrôle se déplace vers l’import. Une entrée peut déjà exister, une tâche peut attendre ou une erreur peut empêcher la suite du traitement. L’état du flux et l’état de l’article doivent alors être examinés séparément. On ne résout pas un blocage d’extraction en changeant l’adresse d’un flux qui livre déjà la bonne entrée.
Dans EditoRelay, l’import évite de réinsérer une URL déjà connue au sein du même flux. Le traitement crée ensuite une tâche de récupération pour les nouveaux articles insérés. Une nouvelle lecture du flux ne transforme donc pas chaque entrée existante en nouvel article à diffuser. Ce fonctionnement protège le circuit contre certaines répétitions, mais ne constitue pas une garantie universelle de déduplication entre plusieurs sources.
Cette distinction explique pourquoi supprimer puis reconnecter une source n’est pas un bon premier test. L’opération peut modifier le périmètre de comparaison et rendre l’historique moins lisible. Avant de toucher aux sources, mieux vaut rechercher l’URL témoin dans les articles déjà détectés, puis relever son état et celui des opérations qui la concernent.
Retrouver l’article dans l’outil change la suite du diagnostic. Le flux a peut-être correctement livré cette entrée, alors que l’extraction ou la préparation attend encore. L’envoi au réseau dépend ensuite des règles éditoriales et de la connexion sociale. La page sur l’automatisation RSS situe ces étapes ; chacune appelle un contrôle différent, avec son propre résultat attendu.
Vérifier la reprise avant de rattraper les absences
Après un correctif, le contrôle le plus utile suit une nouvelle publication prévue par la rédaction. Il ne nécessite pas d’envoyer un faux article au public. L’équipe note quand la page devient accessible, quand l’entrée apparaît dans le flux et quand l’outil la détecte. Cette chronologie montre si la chaîne reprend réellement son fonctionnement ordinaire.
Les articles parus pendant l’incident demandent un examen séparé. Certains figurent peut-être encore dans le flux ; d’autres ont pu sortir de la fenêtre des dernières entrées. Le simple retour du service ne prouve pas qu’ils ont tous été récupérés. Comparer la liste des publications du CMS avec celle des articles détectés permet d’identifier les absences réelles.
Cette liste ne doit pas devenir automatiquement une file de posts à envoyer. Une brève urgente peut avoir perdu son intérêt ; un contenu a peut-être déjà été partagé manuellement. Le responsable de diffusion peut décider, article par article, ce qui mérite encore un relais et vérifier l’historique avant tout nouvel envoi. Le guide de prévention des doublons complète cette reprise.
Le compte rendu peut conclure que la diffusion a repris tout en laissant la cause ouverte. Après une purge, par exemple, l’arrivée d’un article prouve la reprise observée, sans expliquer à elle seule pourquoi la copie avait vieilli. Il reste à noter le changement effectué, les témoins vérifiés et la personne qui suivra les prochaines publications. Si l’incident revient, l’équipe disposera de cette comparaison au lieu de repartir de mémoire.
Sources officielles
Documents utilisés pour vérifier les points techniques de cet article.