⬅️ Retour Accueil

♾️ Bot_Telegram

🎯 Objectif Principal (Focus)

Résumé

Relais passif et silencieux. Écoute les messages du bot Telegram et les pousse instantanément vers l’API Python locale pour traitement. Zéro logique cognitive dans n8n.

---

🏗️ Architecture Logique (VSL)

graph LR
    A[Trigger: Telegram Bot] --> B[HTTP Request: POST]
    B --> C[Réponse HTTP retournée à Telegram]

🧩 Composants Techniques (Stack)

1. Explication des Nœuds (La logique)

📡 Telegram Trigger Rôle : Écoute les nouveaux messages texte sur le bot. Propriétés clés : Connecté via Credentials Telegram. Déclenche le flux instantanément.

🌐 HTTP Request (POST) Rôle : Transférer la charge (payload) à l'agent Python. Propriétés clés :

• URL : http://agent_tracker_bunker:8000/webhook/telegram (Nom du conteneur Docker).

• Body parameters : Envoie la variable chat_id et le message brut.

🔑 Sécurité & Accès (Credentials)

Nœud / Outil	Type d’Auth	Variable / Clé
Telegram Bot	API Token	TELEGRAM_BOT_TOKEN

📦 Sauvegarde Technique (Le Code)

🗄️ JSON du Workflow

{
  "nodes": [
    {
      "parameters": {
        "updates": [
          "message"
        ],
        "additionalFields": {}
      },
      "type": "n8n-nodes-base.telegramTrigger",
      "typeVersion": 1.1,
      "position": [
        -192,
        -448
      ],
      "id": "e11fb115-ba59-45a3-9a55-07fc1cc2967e",
      "name": "Telegram Trigger1",
      "webhookId": "8b92c14b-9110-4bee-b421-e2c6999b073b",
      "credentials": {
        "telegramApi": {
          "id": "YaQazaLUd1OxuUTc",
          "name": "Telegram account"
        }
      }
    },
    {
      "parameters": {
        "chatId": "={{ $('Telegram Trigger1').item.json.message.chat.id }}",
        "text": "={{ $json.reply }}",
        "additionalFields": {}
      },
      "type": "n8n-nodes-base.telegram",
      "typeVersion": 1.2,
      "position": [
        80,
        -208
      ],
      "id": "9549f732-47ed-4928-bac6-0de6e012bd10",
      "name": "Send a text message1",
      "webhookId": "454be86a-567d-497d-bf4a-721a8b16e93f",
      "credentials": {
        "telegramApi": {
          "id": "YaQazaLUd1OxuUTc",
          "name": "Telegram account"
        }
      }
    },
    {
      "parameters": {
        "method": "POST",
        "url": "http://agent_tracker_bunker:8000/webhook/telegram",
        "sendBody": true,
        "bodyParameters": {
          "parameters": [
            {
              "name": "chat_id",
              "value": "{{ $json.message.chat.id }}"
            },
            {
              "name": "message",
              "value": "={{ $json.message.text }}"
            }
          ]
        },
        "options": {}
      },
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.4,
      "position": [
        32,
        -448
      ],
      "id": "9ad61874-70c4-444b-8e0f-b9cd82a90f91",
      "name": "HTTP Request"
    }
  ],
  "connections": {
    "Telegram Trigger1": {
      "main": [
        [
          {
            "node": "HTTP Request",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "HTTP Request": {
      "main": [
        [
          {
            "node": "Send a text message1",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  },
  "pinData": {},
  "meta": {
    "templateCredsSetupCompleted": true,
    "instanceId": "ae6456a6ab1abb9468e9e25a4065e8d75bf1b835a4dd18a7345c88e3618d9182"
  }
}

Rapport Tactique : Audit du Workflow ♾️ Bot_Telegram Russell 15/07/26

L’examen du JSON du workflow Bot_Telegram révèle une structure “passerelle” simple. Cependant, elle présente un risque de blocage synchrone et une faille de gestion d’erreurs qui pourrait paralyser le bot en cas de latence de votre API locale.

1. Analyse Technique

• Risque de Time-out (Synchrone) : Le nœud HTTP Request est configuré par défaut en mode synchrone (il attend une réponse de agent_tracker_bunker). Si votre script Python interne prend trop de temps à traiter le message, le nœud n8n “pend” et risque de faire expirer la connexion du webhook Telegram.
  • Conséquence : Telegram risque de réessayer d’envoyer le message, provoquant des doublons (traités plusieurs fois) ou un échec complet.
• Absence de Gestion d’Erreurs : Il manque un branchement “Error Trigger” ou une configuration “Continue on Fail”. Si agent_tracker_bunker est indisponible (restart du conteneur, crash Python), le workflow s’arrête net. Le message est perdu pour l’utilisateur sans aucun feedback.
• Configuration du Nœud “Send a text message1” : Vous utilisez {{ $json.reply }}. Cette variable n’est pas définie dans la sortie du nœud HTTP Request. Pour que cela fonctionne, votre API Python doit renvoyer un JSON contenant exactement une clé reply. Si ce n’est pas le cas, le bot Telegram enverra un message vide.

2. Risques Opérationnels

• Scalabilité : Utiliser n8n comme simple proxy est une bonne pratique, mais votre architecture dépend de la stabilité réseau du “pont” Docker (bunker_net).
• Sécurité : L’URL http://agent_tracker_bunker:8000 est en clair à l’intérieur du réseau Docker. C’est acceptable pour un réseau interne, mais assurez-vous qu’aucun autre conteneur sur ce réseau ne puisse intercepter ces payloads.

3. Plan d’Action (A, B ou C)

Priorité	Action	Impact
A (Urgent)	Gestion d’erreurs : Ajouter une règle “Continue on Fail” sur le nœud HTTP Request avec un nœud Switch pour envoyer un message d’erreur automatique à l’utilisateur si l’API est injoignable.	Garantit une expérience utilisateur fluide même en cas de crash interne.
B (Optimisation)	Async/Fire-and-forget : Si la réponse de l’API n’est pas nécessaire immédiatement, configurer le nœud HTTP pour ne pas attendre le retour (ou mettre un timeout court).	Évite le blocage du workflow.
C (Maintenance)	Validation des données : Ajouter un nœud “Set” ou “Code” après l’HTTP Request pour vérifier si reply existe dans la réponse avant d’envoyer le message Telegram.	Empêche l’envoi de messages Telegram vides.

---

Audit & Angles morts (Expertise Russell) : 27/07/2026

1. La faille de la synchronisation (L’effet “Retry Storm”) : Telegram attend une réponse du webhook. Si ton HTTP Request (l’agent Python) prend 5 secondes pour traiter ton message, Telegram ne reçoit rien, considère que le message n’est pas arrivé, et le renvoie. Résultat : tu reçois 2, 3, voire 5 fois le même message.
2. L’absence d’idempotence : Ton système actuel ne vérifie pas si le message_id provenant de Telegram a déjà été traité. C’est critique pour éviter des actions en double (ex: si le bot commande une action, tu ne veux pas qu’elle soit exécutée 3 fois).
3. L’UI (Utilisateur) : Envoyer une réponse synchrone via n8n est une solution pour les outils de messagerie rapides (comme Slack), mais Telegram est trop sensible aux délais de réponse.

Plan d’action (Russell) :

• Plan A (Async total) : Casser la chaîne synchrone. Le workflow Telegram doit juste recevoir le message, l’écrire dans une file d’attente (Redis ou fichier simple dans /reception), répondre “OK” à Telegram immédiatement pour éviter le retry, puis ton agent_tracker_bunker doit consommer cette file d’attente de manière asynchrone.
• Plan B (Idempotence) : Stocker les message_id traités dans une base de données locale (ou un fichier JSON indexé) pour ignorer tout message déjà arrivé.
• Plan C (Feedback) : Si tu veux que l’utilisateur sache que le bot “travaille”, ton workflow de traitement peut envoyer un message Telegram dédié de type “Je traite votre demande…” via l’API Telegram, indépendamment de la réponse initiale.

Conclusion : Ton workflow actuel est un “prototype” qui fonctionne en laboratoire, mais qui s’effondrera en conditions réelles. Je verrouille la modification de ce workflow pour passer à une architecture “Fire-and-Forget”.