Mozilla a dévoilé le 23 mars « cq », un projet présenté comme une base de connaissances partagée et un espace de questions-réponses conçu pour des agents d’IA, avec une promesse simple : arrêter de « réinventer la roue » à chaque intégration d’API ou correction de bug, et permettre aux modèles de capitaliser sur les solutions déjà trouvées par d’autres.
Un Stack Overflow pour agents, pensé pour l’exécution
Mozilla vise deux angles morts récurrents. D’abord, la dette d’actualité des modèles, qui les amène à appeler des API obsolètes ou à opérer sur des informations périmées, faute d’un accès fiable et structuré au contexte d’exécution. Les approches de type RAG aident, mais restent fragmentaires et ne révèlent pas les angles morts du modèle.
Ensuite, l’isolement des agents : confrontés aux mêmes blocages, ils brûlent chacun des tokens et de l’énergie pour résoudre des problèmes déjà réglés ailleurs. Une fois une panne comprise et documentée par un agent, cq doit permettre aux autres d’en réutiliser directement la réponse opérationnelle, avant même d’écrire la première ligne de code.
Boucle de retour automatique plutôt que fichiers “claude.md” locaux
Dans l’état actuel, nombre de développeurs corrigent la dérive des modèles à la main via des fichiers locaux du type « claude.md » ou « agents.md ». Mozilla veut remplacer ce bricolage par une boucle de connaissance partagée et itérative : l’agent interroge d’abord la bibliothèque publique cq pour un cas donné (nouvelle API, framework inconnu, message d’erreur spécifique), applique une stratégie validée si elle existe, puis publie en retour toute découverte utile.
L’objectif est d’industrialiser la transmission d’expertise entre agents, de stabiliser les décisions de code dans des environnements mouvants et de réduire la latence expérimentale. En filigrane, cq s’attaque à un coût invisible mais massif de l’IA appliquée au développement : la répétition sans partage structuré.
Si Mozilla parvient à faire émerger un format de connaissances exploitable à chaud par des agents hétérogènes, l’impact pourrait être double : une baisse nette du coût d’inférence sur les tâches d’intégration logicielle et une amélioration de la fiabilité perçue des assistants de code, qui peinent aujourd’hui à détecter leurs propres zones d’ignorance. Le succès dépendra toutefois de la qualité du schéma de contribution, de la désambiguïsation des contextes d’exécution et des garde-fous contre le contenu périmé.
Source : ITHome
