Un message confirmé.
Une reprise sans nouvel envoi.
Une veille doit distinguer la publication nouvelle, l’envoi confirmé et la réponse incertaine. Voici ce qui arrive quand le flux change ou que le service de messagerie répond mal.
La reprise respecte ce qui a réellement été reçu.
| Cas éprouvé | Résultat observé | Décision |
|---|---|---|
| Premier flux valide | Historique enregistré | Aucun ancien contenu envoyé |
| Nouvelle publication | Identifiant de message valide | Confirmation conservée dans SQLite |
| Relecture après redémarrage | Zéro nouvelle requête | Aucun doublon créé |
| HTTP 200 sans identifiant | Réponse ambiguë | Revue manuelle avant toute relance |
| HTTP 429 | Limitation du service | Aucun message déclaré livré |
| Désabonnement | Attente annulée | Aucun nouvel envoi |
| Flux vide ou invalide | Erreur explicite | Historique conservé |
Sur mobile, faites défiler le tableau horizontalement.
Le code et les refus sont consultables.
Le prototype reconnaît un article RSS par son identifiant et suit les changements de contenu. Une tentative interrompue reste incertaine : elle ne disparaît pas du journal et n’est pas relancée automatiquement.
Ce que cet exemple ne démontre pas
Les commandes Telegram, la planification, le déploiement et une source réelle restent à brancher et à vérifier. Le prototype couvre RSS, pas Atom ni toute page web. Il repère des changements dans les articles du flux, pas tous les changements du document lié.
Il réduit les relances aveugles ; il ne garantit pas une livraison exactement une fois. Le consentement de l’utilisateur est simulé par un appel direct au prototype.
Exécution locale du 2 octobre à20:27:45 Paris. Documentation : API Telegram, RSS2.0.