Par Thales & Claude -- CEO & AI CTO, ZeroSuite, Inc.
Une experte-comptable à Abidjan demande à Deblo Pro de générer un rapport financier annuel complet conforme au SYSCOHADA -- avec bilan, compte de résultat, analyse des flux de trésorerie, notes annexes et commentaire de gestion. L'ensemble du processus prend 12 minutes.
Douze minutes est une éternité en temps d'application web. La connexion SSE du navigateur aura expiré après environ 180 secondes. Si la génération dépend d'une connexion HTTP active entre le navigateur et le serveur, ce rapport de 50 pages meurt à mi-chemin.
La solution : architecture queue-bridge
Nous avons implémenté une architecture queue-bridge avec des tâches asyncio détachées. Au lieu de lier la génération à la connexion HTTP, nous les découplons.
Le flux : l'utilisateur envoie un message avec background=true. Le backend crée un enregistrement GenerationJob dans PostgreSQL avec le statut pending. Le backend lance une asyncio.Task détachée. Le backend retourne immédiatement le job_id au frontend (HTTP 202 Accepted). Le frontend interroge GET /api/jobs/{job_id} toutes les 3 secondes pour vérifier la progression.
Suivi de progression dans Redis
Interroger PostgreSQL toutes les 3 secondes depuis chaque client connecté serait coûteux. Nous utilisons Redis comme cache de progression rapide avec un TTL d'une heure. Le endpoint de polling vérifie d'abord Redis. Si le job est terminé ou échoué, il se rabat sur PostgreSQL pour le résultat complet.
Annulation
Les jobs longue durée doivent être annulables. Le mécanisme d'annulation utilise Redis comme canal de signalisation : quand l'utilisateur clique « Annuler », le frontend envoie un POST qui positionne une clé Redis. La tâche de fond vérifie cette clé entre les itérations. C'est de l'annulation coopérative -- la tâche n'est pas tuée en pleine exécution.
Nettoyage des jobs obsolètes
Un redémarrage du serveur pendant un job actif crée un orphelin. Le nettoyage tourne au démarrage de l'application et marque tout job running ou pending comme failed avec le message « Le serveur a redémarré pendant la génération. »
Pourquoi pas Celery ?
Trois raisons : simplicité opérationnelle (Deblo est une opération à deux personnes), la charge de travail est limitée par le LLM (un seul event loop asyncio peut gérer des dizaines de tâches en attente concurrentes), et nous n'avons pas besoin d'exécution distribuée pour le moment.
Les chiffres
- Durée moyenne des jobs : 4,2 minutes
- Job réussi le plus long : 28 minutes
- Taux d'échec : 3,1 %
- Taux d'annulation : 8,7 %
La fonctionnalité a transformé Deblo Pro d'un outil conversationnel en une plateforme de génération de documents.
Ceci est l'article 11 de 20 dans la série « Comment nous avons construit Deblo.ai ».