cq — Stack Overflow pour agents : base de connaissances partagée inter-agents¶

Resume¶

Mozilla.ai propose cq, un serveur MCP + plugin Claude Code/OpenCode permettant à des agents IA de partager des connaissances entre eux. Avant une tâche inconnue, l'agent interroge cq ; si un autre agent l'a déjà résolue, il récupère la solution directement. Quand il découvre quelque chose de nouveau, il propose la connaissance pour validation par d'autres agents. Architecture : plugin Claude Code/OpenCode → serveur MCP local → API d'équipe (org-wide) → interface de validation humaine. Lancé en open source, PoC. Contexte : Stack Overflow est passé de 200K questions/mois en 2014 à 3 862 en décembre 2025 — les LLM ont absorbé le corpus puis asséché la source.

Analyse critique¶

Ce qui est juste :

L'ironie historique est documentée et réelle. Stack Overflow s'est effondré après avoir nourri les modèles qui l'ont rendu obsolète.

Le problème sous-jacent est concret : chaque agent repart de zéro sur les mêmes patterns d'erreurs. Des bugs récurrents (double-hash ECDSA, ALTER TYPE PostgreSQL, Math.random() Sonar) réapparaissent story après story faute de mécanisme d'injection pendant la génération, pas seulement au démarrage.

Ce qui est flou ou prématuré :

Le PoC est minimal. Plugin + MCP local + API d'équipe, c'est une intention, pas une implémentation prouvée. Aucun chiffre de réduction d'erreurs, aucun benchmark de pertinence des connaissances récupérées.

Le problème de qualité n'est pas résolu. Stack Overflow fonctionnait grâce au filtre humain (votes, acceptation). Ici "d'autres agents valident" — des agents validant le travail d'agents, c'est le même problème d'auto-évaluation que le papier Anthropic harness pointait (Art. II CONSTITUTIONAL). Sans humain dans la boucle de validation, la base peut se dégrader rapidement (garbage in, garbage out accéléré).

Le scope est vague : "connaissances acquises" = quoi ? Une config CI/CD ? Une règle ESLint ? Une architecture de service ? Le niveau de granularité optimal n'est pas défini.

Pertinence ProbatioVault¶

Impact modéré et direct — parce que le problème est réel dans le workflow actuel.

Le système de learnings (data/learnings.jsonl, scripts/index-learnings.py, injection step 0) est déjà un cq interne. La différence : c'est l'orchestrateur qui injecte manuellement via /gov-learnings-inject au step 0, pas les agents subprocess qui interrogent eux-mêmes pendant l'exécution.

Ce que cq apporterait concrètement : que les agents claude -p des étapes 6b puissent interroger les learnings pendant leur exécution. Le bug double-hash (PD-282) aurait pu être évité si l'agent crypto avait interrogé les learnings au moment de générer verify() — le learning createVerify vs raw ECDSA HSM était déjà documenté.

Frein actuel : le MCP est local ou org-wide, pas encore utilisable dans un subprocess claude -p isolé. La validation humaine reste nécessaire pour éviter la dégradation de la base — ce qu'on a déjà avec le workflow PMO.

À surveiller pour la v1 stable : si le MCP local fonctionne proprement dans un subprocess, c'est une brique pluggable dans le step 6b sans changer l'architecture.