Pourquoi Bugzilla
Un tracker de bugs est l’exemple parfait d’un système où l’agent apporte de la valeur en lecture (retrouver le bug qui correspond à un ticket support, résumer les commentaires) et du risque en écriture (fermer, réassigner, commenter en masse). L’API REST de Bugzilla est simple, documentée, et l’instance publique de Mozilla permet de tester en lecture sans aucun compte.
Le lab fournit trois modes : un produit fictif « Lab Platform » cohérent avec les tickets CRM, des réponses réelles figées de bugzilla.mozilla.org, et une instance locale Docker pour ceux qui veulent écrire pour de vrai — dans leur bac à sable.
Le nœud Trieur
Dans le pipeline, un nœud optionnel extrait des mots-clés du sujet du ticket, interroge Bugzilla et propose des bugs liés. Le ticket « Erreur 401 app web » remonte le bug « SSO : 401 après redirection SAML ». Le résumé du bug 1007, piégé, est mis en quarantaine plutôt que recopié. Le commentaire de liaison est rédigé, mais en dry-run.
Le front qui décide
Une API FastAPI expose les runs ; un flux Server-Sent Events pousse chaque événement au navigateur : début et fin de chaque agent, appels d’outils avec durée et taille, alertes de sécurité, verdict. Quand le validateur exige un humain, le front affiche la raison et deux boutons. Approuver publie une note CRM (dry-run par défaut) et journalise la décision ; rejeter journalise aussi.
- Aucun innerHTML : un rapport piégé reste du texte
- Clé API en header, jamais dans l’URL ; CORS restreint
- Événements sans corps complet ni secret
- Front en HTML/JS natif pour rester lisible, portable en React / Next.js en TP
L’humain dans la boucle n’est pas un bouton de confort : c’est la condition pour laisser un agent approcher un système d’écriture.