Relances programmées — workflow n8n

Statut : rappels Telegram actifs après consentement ; Twilio historique et désactivé. Les appels ont été testés pendant l’essai Twilio. Le dépôt public documente cette option sans publier de credentials.

Fonctionnement actuel

Le nouveau workflow Telegram_Tracker_Relances vérifie l’état deux fois par jour. L’API réserve au plus un envoi quotidien dans SQLite, uniquement après /rappel_on, pendant sept jours et entre 08 h et 21 h. Un log du jour, /rappel_fait, /rappel_pause ou /rappel_off bloque la relance. Le canal utilisé est une notification Telegram ; le son dépend des réglages du téléphone. Une panne d’envoi après réservation n’est pas retentée automatiquement le même jour.

Option d’appel Twilio si elle est financée

L’appel vocal reste intéressant lorsque la notification Telegram ne suffit pas : l’essai a montré qu’un signal externe plus insistant pouvait aider à reprendre le journal. C’est une option payante possible, pas un service actif aujourd’hui. La remettre en place demanderait un consentement distinct, un plafond d’appels et de dépenses, des horaires, un arrêt immédiat et une règle pour choisir entre appel et Telegram sans doubler la relance. L’ancien workflow ne peut pas être simplement réactivé : la route API héritée refuse désormais les appels. Les tarifs doivent être vérifiés au moment d’un éventuel choix. Voir la documentation technique.

Le workflow expérimenté

flowchart LR
    S[Deux contrôles planifiés] --> H[Lire l'état du Tracker]
    H --> I{Relance demandée ?}
    I -->|Non| X[Silence]
    I -->|Oui| G[Garde-fous]
    G --> C[Canal de relance]

La version testée exécutait deux contrôles quotidiens. Le nœud conditionnel faisait son travail : lorsque l’API renvoyait besoin_relance: true, la branche d’appel était utilisée. Le défaut se trouvait dans l’état trop pauvre fourni au workflow et dans l’absence de mémoire des rappels.

Résultat réel

Les appels ont aidé à remplir les journaux pendant environ une semaine.
Ils ont ensuite continué, parfois deux fois par jour, pendant approximativement trois semaines.
L’expérience démontre donc à la fois la force d’un signal externe et le coût d’un automate incapable de reconnaître qu’il doit s’arrêter.

Cause confirmée

Le Tracker demandait une relance chaque fois qu’il ne trouvait pas le repère attendu dans le journal du jour. Le workflow ne conservait ni dernier appel, ni acquittement, ni date de fin. Deux contrôles quotidiens pouvaient donc produire deux appels quotidiens.

Une remise à zéro rendait également le repère introuvable et pouvait réarmer la branche de relance.

Garde-fous obligatoires

Garde-fou	Règle
Acquittement	« Fait », « reçu », « reporter » ou « arrêter » ferme ou modifie l’épisode.
Plafond	Jamais plus d’une relance dans la période configurée.
Temporisation	Un délai minimal empêche deux actions rapprochées.
Expiration	Toute campagne possède une date de fin automatique.
Horaires calmes	Aucun canal intrusif hors de la plage consentie.
Quota financier	Le dépassement du crédit ou du budget bloque l’appel.
Interrupteur	Une commande coupe les relances sans arrêter Agent Tracker.
Canal de repli	Une notification non urgente remplace la voix si le fournisseur est indisponible.

Code et traçabilité

Le modèle de workflow Telegram est publié sans identifiants privés. La note Twilio historique conserve l’option testée. Le workflow Twilio de l’installation auditée a été dépublié et l’ancienne route API ne peut plus autoriser un appel.

Critères d’acceptation

Un journal complété ferme immédiatement l’épisode.
Deux exécutions rapprochées ne produisent jamais deux relances.
Une campagne expirée ne peut pas se réactiver seule le lendemain.
L’arrêt manuel est prioritaire sur toute autre règle.
La perte du fournisseur ne bloque pas le Tracker.
Chaque décision est expliquée par un état lisible, pas seulement un booléen.

ORIORIS