[🛠] AI Orchestration #4: J’ai réduit de 22 à 9 minutes une tâche de suivi dans Telegram

✨ Résumé de GPT-5.6 Sol

Le récit d’un auto-blocage dans la même Session, de recherches répétées et de vérifications improvisées découverts lors d’un canary réel, puis d’un temps de retour des fichiers Telegram réduit de 57,6 % grâce aux générateurs, vérificateurs et reprises partielles existants.

Un auto-blocage provoqué par un canary dans la même Session

Lors du dogfooding de la veille, j’avais donné uniquement un objectif dans Telegram et reçu un PDF et un XLSX. La découverte du projet, la répartition des rôles, l’exécution parallèle, la reprise et le retour des fichiers avaient fonctionné, mais l’ensemble avait pris 22 minutes et 6 secondes. Si chaque petite tâche de suivi demandait autant de temps, l’usage quotidien resterait pénible.

Je n’ai pas construit de benchmark séparé. J’ai envoyé un nouvel objectif dans le même Topic Telegram : « conserve la qualité, mais réduis les 22 minutes ». Je voulais voir directement si l’AI Orchestrator pouvait trouver les vrais goulots d’étranglement, corriger le Workflow partagé et terminer seul la tâche de suivi sur les fichiers.

La première validation s’est immédiatement retrouvée bloquée. Pendant qu’il traitait la demande en cours, l’AI Orchestrator a envoyé un canary dans la même Session, puis a attendu sa réponse. La nouvelle demande ne pouvait commencer qu’après la fin du turn actuel, tandis que le parent ne pouvait pas se terminer puisqu’il attendait précisément cette nouvelle demande.

J’ai arrêté uniquement la CLI en attente et séparé le Topic consacré à la modification du produit de celui du canary. Le modèle n’était pas incapable de faire le travail. Le problème venait de la frontière d’exécution : un Orchestrator ne doit pas attendre la tâche suivante dans une Session qu’il occupe déjà.

Réutilisation des générateurs et vérificateurs pour une reprise partielle

Le premier canary lancé dans un Topic indépendant a renvoyé les fichiers en 17 minutes et 35 secondes. C’était plus rapide, mais le résultat indiquait à tort qu’un Pilot déjà approuvé attendait de nouveau une approbation. La réduction du temps ne suffisait pas pour valider le résultat.

En suivant l’exécution réelle, j’ai constaté des recherches répétées des mêmes éléments de preuve, du polling sur les tâches enfants et des vérifications de dependencies effectuées trop tard, une fois la génération des livrables déjà commencée. Il y avait aussi un coût important à recréer des chemins de vérification proches de ceux qui existaient déjà, au lieu de réutiliser les générateurs et verifiers PDF et XLSX déjà validés.

Je n’ai conservé que les règles suivantes dans le Workflow partagé :

• Figer les preuves nécessaires dans un unique snapshot borné.
• Récupérer les résultats enfants par des événements de fin, sans polling répété.
• Réutiliser un générateur ou un verifier existant au lieu de créer une nouvelle implémentation.
• N’appliquer que les écarts des décisions et mesures les plus récentes, puis ne reprendre que la zone défectueuse.
• Exécuter une seule validation finale du livrable complet et aligner son Source provenance.

J’ai corrigé uniquement l’état d’approbation et le texte erronés du premier résultat, puis relancé le rendu complet et la vérification indépendante d’ouverture et de réenregistrement. Le nouveau flux ne reconstruisait pas tout depuis zéro : il modifiait seulement ce qui était devenu sémantiquement obsolète, puis revérifiait l’intégrité de l’ensemble.

Retour des fichiers Telegram en 9 minutes et 23 secondes sans relâcher la qualité

Le canary de reprise a renvoyé le PDF et le XLSX dans Telegram en 9 minutes et 23 secondes, sans intervention de l’utilisateur. C’est 57,6 % de moins que les 22 minutes et 6 secondes initiales, et le nombre d’appels d’outils d’Orchestration est passé de 56 à 21.

Ce gain ne vient pas d’une suppression des contrôles. J’ai revérifié le rendu, la structure, le contenu, les formules et l’ouverture-réenregistrement indépendant du PDF de deux pages et du XLSX de quatre feuilles. Les fichiers retéléchargés depuis Telegram avaient aussi le même hash que les originaux générés. Enfin, le système a découvert que le Workflow provenance intégré aux fichiers pointait encore vers un ancien hash et n’a corrigé que cette valeur, sans toucher au contenu ni à la structure.

La décision la plus importante a été de ne pas compter le premier résultat de 17 minutes comme un succès. Si la dernière décision est fausse, réduire le temps revient seulement à produire plus vite un mauvais résultat. Cette amélioration a été validée parce que le temps de retour réel a diminué tout en conservant le même Gate de qualité.

Frontière entre la v0.1 mono-utilisateur et le Pilot multi-utilisateur

La v0.1 mono-utilisateur actuelle sait recevoir un objectif en langage naturel, trouver le projet, répartir le travail, vérifier les résultats et les renvoyer dans Telegram. Il est néanmoins trop tôt pour parler d’un fonctionnement entièrement sans surveillance. Dans le rôle du CEO, j’ai encore dû interrompre l’auto-blocage dans la même Session, signaler l’erreur sémantique du premier résultat et demander le commit local manquant.

La prochaine étape n’est pas un autre benchmark. Je dois continuer à confier des tâches réelles et non sensibles avec la même frontière de qualité, accumuler les temps de traitement et surveiller leur distribution et les régressions. Une fois la connexion d’un autre utilisateur approuvée, il faudra aussi vérifier que deux Cells peuvent s’exécuter en même temps sans mélanger leurs Sessions, leur Memory ou leurs fichiers. Un Task Flow controller complet n’est pas le goulot d’étranglement critique du parcours utilisateur actuel ; il reste donc une piste séparée à long terme.