SoPing
Des rappels persistants, une interface web et des outils MCP, avec un état explicite quand le résultat d’un envoi est incertain.
Interface réelle en mode démo · rappels fictifs et envois simulés
Problème et contexte
Un rappel doit rester programmé lorsque l’assistant ou son client se ferme. Une erreur réseau peut aussi laisser un doute : le fournisseur a peut-être accepté l’envoi sans confirmer sa réponse. Recommencer aveuglément risque alors de créer un doublon.
Ma contribution
Conçu un parcours de rappels avec interface web FR/EN et outils MCP partageant une file SQLite persistante. Développé les espaces isolés, la programmation, l’historique des tentatives et des règles alimentées par événements signés. Séparé les transports fournisseurs du simulateur utilisé pour examiner les parcours sans envoyer de vrais messages.
Choix et compromis
Confier les rappels au backend et conserver une même intention entre les tentatives.
Le worker traite une file persistante et l’idempotence limite les doublons. Le backend doit rester actif ; sur une machine en veille, le traitement attend son réveil.
Distinguer échec, nouvelle tentative autorisée et résultat incertain.
Les reprises sont bornées. Un résultat incertain reste visible sans nouvel envoi automatique ; une acceptation fournisseur ne prouve ni livraison ni lecture.
Résultat
Une application locale réunissant programmation, historique et contrôle des rappels. La démonstration présentée utilise exclusivement des données fictives et des envois simulés ; les parcours fournisseurs et les clients réels gardent leur validation distincte.