Entrée Telegram — workflow n8n

Statut : workflow Telegram actif, correctif de réponse publié. La logique de journal et de rappel reste dans Agent Tracker. Code et modèle n8n expurgé.

Le workflow

flowchart LR
    U[Message utilisateur] --> T[Telegram Trigger]
    T --> H[Requête vers Agent Tracker]
    H --> V{Réponse exploitable ?}
    V -->|Oui| R[Message de confirmation]
    V -->|Non| E[Erreur courte et actionnable]

La version expérimentée utilise trois nœuds principaux :

Telegram Trigger reçoit les messages texte.
HTTP Request transmet le message et son identifiant au Tracker.
Send Message renvoie la propriété reply produite par l’API.

Ce qui fonctionne

La saisie reste accessible depuis un téléphone sans ouvrir le vault.
Le workflow sert de passerelle et ne duplique pas la logique Python.
La réponse confirme immédiatement si la donnée a été enregistrée ou si une précision manque.

Fiabilité et limites

L’expression du chat_id a été corrigée dans la requête n8n. Si l’API est indisponible, le bot répond que le message n’a pas été enregistré, sans exposer le détail technique. L’API renvoie HTTP 503 lorsqu’elle ne peut pas écrire le journal. La déduplication par identifiant de mise à jour Telegram et un test réel de bout en bout restent à faire ; un événement rejoué peut encore ajouter une seconde ligne.

Workflow public

Le modèle bot_telegram.template.json est nettoyé : aucun token, credential, identifiant de chat ni nom de réseau privé. Il faut renseigner ses propres credentials et l’URL locale avant import. Le README détaille les variables et les tests.

Critères d’acceptation

Un événement Telegram valide reçoit un accusé de réception.
À faire : dédupliquer les événements Telegram rejoués avant l’écriture.
Une panne du Tracker produit un message clair et une trace technique minimale.
Un message invalide ne déclenche pas une boucle de nouvelles tentatives.
La passerelle peut être remplacée par une autre interface sans modifier le cœur du Tracker.

ORIORIS