Comment les agents QA enrichissent eux-mêmes la base de connaissances et réduisent la recherche de la cause d'un bug de 2 heures à 10 minutes

Imaginez : un QA passe deux heures à comprendre pourquoi la vitrine est vide pour le retrait en magasin. Il s'avère que ce n'est pas un bug. Le cache de disponibilité se met à jour toutes les quelques minutes, et le mock des stocks écrasait le proxy réel avec une priorité erronée. Le savoir est acquis, mais il reste dans la tête d'une seule personne ou dans un chat que personne ne retrouvera une semaine plus tard. Un mois après, un autre QA perd les deux mêmes heures sur le même problème. Quant à l'agent IA, il n'a aucune mémoire entre les sessions : il refait donc ce chemin à chaque fois.

L'équipe de test de « TekhVill » a résolu ce problème avec une plateforme dédiée, MKP (Multi knowledge platform). Voyons ci-dessous comment elle est conçue et ce que l'on peut en retenir.

Qu'est-ce que MKP et comment fonctionne sa recherche

MKP est une plateforme interne dotée de bases de connaissances et d'une recherche intelligente. Il existe deux types de bases : evawiki, intégrée et contenant la documentation d'entreprise (via MKP, on ne peut que la lire), et les bases markdown des équipes, où l'on peut créer, mettre à jour, supprimer des documents et les rechercher par le sens. On y accède via l'interface web, l'API REST et un serveur MCP pour les agents dans Cursor, Claude Code, Codex. MCP ne propose que cinq outils : liste des bases, requête sémantique, récupération d'un document par son numéro, création ou mise à jour, suppression douce.

Sous le capot, il y a du RAG, mais pas le plus naïf. Le hybrid dense/sparse retrieval combine recherche sémantique et recherche par mots-clés. C'est crucial pour le QA : des identifiants comme GetExists, is_pickup ou CMA-14699 sont souvent perdus par une recherche purement vectorielle. Viennent ensuite le multi-query (le modèle reformule la question), le reranking et le parent-child retrieve : on cherche sur de petits fragments, mais on fournit le contexte de la section entière. La réponse contient toujours le texte, les sources avec score et snippet, ainsi qu'un trace_id pour le diagnostic.

L'agent écrit lui-même dans la base

L'idée centrale est que personne n'y dépose les documents à la main : sinon, six mois plus tard, on se retrouve avec un énième wiki abandonné. À la place, MKP est intégrée au QA-kit, un dépôt de règles et de skills pour Cursor et Claude Code. L'agent agit comme un éditeur : il sélectionne dans la session le savoir vérifié au lieu de déverser toute la conversation dans la base.

Pour chaque domaine (catalogue, recherche, recommandations, etc.), quatre bases sont créées :

• wiki — connaissances stables : architecture, environnements, mocks, « comment bien vérifier » ;
• outputs — textes complets des plans de test, résultats et commentaires dans le Tracker ;
• daily — notes par jour et sommaire index ;
• artifacts — preuves brutes : curl, SQL, JSON, mocks.

Avant de présenter un plan de test, l'agent doit effectuer quatre recherches : y a-t-il eu un retest sur les numéros exacts de documents, ce qui a été détecté sur des cas similaires dans outputs, ce que l'équipe sait du service dans wiki et ce que dit le produit dans eva-wiki. Après les tests, il enregistre le plan, le résultat et le commentaire dans outputs, la journée dans daily, et le nouveau fait stable dans wiki.

Ce que cela donne en pratique

Vitrine vide : désormais, une question à catalog-wiki renvoie en 24 secondes une checklist de neuf points. On y trouve le cache de disponibilité, les précommandes, la priorité du mock dans WireMock, le 403 du proxy de recherche. Le QA la parcourt en dix minutes au lieu de deux heures. Personne n'a rédigé cette checklist comme un article : elle est issue d'analyses de tâches auxquelles l'agent a ajouté des faits un à un.

Tâche sur les analogues de produits : l'agent remonte en amont les résultats de deux exécutions précédentes. Le nouveau QA sait quelles fixtures préparer, ne crée pas de faux DEFECT sur un chemin legacy inatteignable (un collègue l'a déjà marqué QUESTION) et ajoute aussitôt une vérification pour savoir si l'environnement n'héberge pas encore un ancien code sans filtre. Le lead voit dans le sommaire daily ce que l'équipe a fait, sans réunion de statut séparée.

Droits et discipline

L'accès est strictement encadré. Il y a deux rôles : admin et user, et les droits read et write sont accordés séparément pour chaque base. Chaque agent a son propre utilisateur avec un minimum de droits, et l'utilisateur technique peut se voir retirer l'accès à l'UI. L'agent lit les bases de son domaine et eva-wiki, mais n'écrit que dans ses quatre bases. L'auteur d'un document est déterminé par la clé API, et l'équipe apparaît dans les métadonnées. Le registre des accès est stocké dans git.

Limites et conclusion

L'article n'évalue ni la qualité des notes ni la manière dont est écarté un savoir erroné entré dans le wiki, alors que l'agent y écrit lui-même. Les chiffres d'économie de temps sont internes et donnés sur des exemples isolés. De plus, un nouveau document n'est pas immédiatement trouvable : il passe d'abord par le statut processing.

Conclusion pratique pour les équipes qui travaillent avec des agents : il ne faut pas un énième wiki, mais un cycle « se souvenir, travailler, consigner ». Le kit minimal : séparer les connaissances stables des résultats d'exécution, obliger l'agent à chercher avant de travailler, lui donner des droits restreints et conserver les sources à côté de la réponse. Ainsi, chaque tâche rend la suivante moins coûteuse.