2026-05-29 Rétrospective

Ce que j'ai fait aujourd'hui

En essayant d'améliorer le problème qui a commencé hier, j'ai trouvé aujourd'hui un outil MCP qui permet d'intégrer plus efficacement la recherche web.

L'outil que j'ai découvert était web-search-mcp, qui propose les recherches de navigateurs bing, brave, duckduckgo via MCP.

• https://github.com/mrkrsl/web-search-mcp

Je prévois de le forker plus tard et de le personnaliser pour l'adapter à mon flux de travail actuel.

Impressions sur l'utilisation de Qwen 3.6

Le modèle Qwen 3.6 était plus lent que prévu.

On m'a demandé de synchroniser et de pousser le workflow du répertoire .github présent dans qwen-code, mais en réalité il a essayé de copier seulement certains fichiers dans le répertoire .qwen. C'était le problème principal.

Finalement, j'ai dû cloner manuellement, aligner les répertoires .github et .qwen exactement comme l'original, puis poursuivre. C'était simplement une question de « reproduire la structure d'origine », mais le modèle a confondu les chemins et les objectifs, ce qui a entraîné des tâtonnements inutiles.

Réflexion sur Qwen lui‑même

Qwen n'est pas tant un modèle sans capacité, mais plutôt un modèle dont les capacités existent mais dont le contrôle est limité.

Il excelle dans la recherche d'informations, la modification de code, la manipulation de fichiers et l'exécution de longues tâches. Le problème réside dans sa faiblesse à maintenir fermement l'intention de l'utilisateur jusqu'au bout. Il a tendance à oublier ou à écraser des contraintes telles que « copier tel quel », « ne pas modifier », « ne pas inférer », « se baser uniquement sur les critères officiels », « ne pas toucher à ce chemin » au cours du travail, en les remplaçant par son propre jugement.

En d'autres termes, Qwen ne refuse pas le travail, il le réinterprète à sa façon.

Le problème initial de cette tâche était simple.

Copier tel quel le .github officiel  
Exclure .qwen  
Push  
Test

Cependant, Qwen a continuellement étendu cela à d'autres problèmes.

Est-ce un problème MCP ?
Est-ce un problème workflow_call ?
Faut‑il ajouter un déclencheur push ?
Faut‑il créer .qwen/commands ?
Est‑ce un problème JSON stderr ?
Est‑ce un problème de revue vide ?

Avant de résoudre le problème, on l’a en fait agrandi. Dans les LLM de type agent, ce point est fatal. Plus l’unité de travail devient grande, plus il commence à résoudre des sous‑problèmes qu’il a lui‑même créés au lieu de la demande initiale.

Même en ajoutant une recherche web, le problème n’a pas été complètement résolu. Un bon flux consiste d’abord à consulter la documentation officielle ou le code source, à en comprendre la structure, puis à comparer avec la demande de l’utilisateur pour n’exécuter que les tâches nécessaires. Cependant, Qwen a d’abord inféré, a formulé une hypothèse, a effectué une recherche pour vérifier cette hypothèse, puis a adapté les résultats de la recherche à son hypothèse.

Ainsi, la recherche web a été utilisée davantage comme un outil de renforcement d’hypothèses que comme un outil de travail basé sur des preuves. J’ai constaté que l’attitude face aux résultats de recherche est plus importante que la capacité de recherche elle‑même.

L’interprétation des états d’échec était également faible. Par exemple, si la commande git ls-files .qwen/ renvoie rien, on doit immédiatement conclure que .qwen n’est pas dans l’état suivi. Pourtant, la commande git rm -r --cached .qwen/ a été répétée plusieurs fois. Bien que la capacité d’exécuter des commandes soit présente, l’interprétation des résultats et la capacité à sortir de la boucle en ajustant le comportement étaient instables.

De plus, Qwen est faible dans les tâches de préservation « tel quel ». Il est proactif pour la création et la modification, mais il tente constamment d’améliorer les opérations qui consistent à préserver le contenu original et à le synchroniser tel quel. On peut se retrouver à proposer de créer un répertoire .qwen alors qu’il n’existe pas dans la documentation officielle, à ajouter un déclencheur qui n’existe pas, ou à forcer une exécution directe lors d’un push, ce qui finit par casser la structure originale.

Par conséquent, il est plus sûr de ne pas confier à Qwen la tâche « copier tel quel la documentation officielle », mais de la décomposer comme suit.

## Liste des fichiers officiels
## Liste de mes fichiers
## Affichage des différences
## Copier uniquement les fichiers approuvés par l'utilisateur

Donner trop d’autonomie à Qwen est également risqué. Des autorisations telles que la modification de fichiers, git add, le commit, le push, la modification du workflow, ou des corrections supplémentaires après les tests automatiques, peuvent pousser une mauvaise décision jusqu’à son exécution.

Ainsi, le rôle de Qwen doit être plus proche d’un générateur de candidats, d’un résumeur de journaux et d’un assistant d’interprétation des résultats de commandes, plutôt que celui d’un gestionnaire de tâches ou d’un exécuteur final.

Qwen = générateur de candidats / résumeur de journaux / assistant d'interprétation des résultats de commande  
Utilisateur ou script = exécuteur final

Structurez également la sortie avec prudence. Le fait que Qwen ne soit pas incapable de produire du JSON ne signifie pas qu’il ne peut pas le faire, mais confier la gestion de schémas complexes ou d’états de workflow à son rôle entraîne une perte de fiabilité globale. La rédaction de revues en Markdown, l’explication de code, le résumé de logs, la compilation de causes potentielles et la génération de brouillons de correctifs sont acceptables. En revanche, la production précise de schémas JSON, la gestion d’états de workflow complexes, l’orchestration de l’ordre d’appel des outils, les opérations via l’API GitHub, la préservation des chemins de fichiers, ainsi que les décisions de commit/push sont inappropriées.

En conclusion, Qwen convient comme générateur mais est instable en tant qu’orchestrateur.

L’essentiel se résume à cette phrase unique.

Qwen est un modèle génératif intelligent, mais il manque de contrôle, d’interprétation d’état et de conservation des instructions pour être utilisé comme gestionnaire de tâches fiable ou agent d’automatisation.

La conclusion pratique est la suivante.

Vous pouvez faire réfléchir Qwen.  
Vous pouvez confier le brouillon à Qwen.  
Vous ne devez pas confier la manipulation finale du dépôt à Qwen.

Si vous continuez à utiliser Qwen à l'avenir, il est préférable d'établir les principes de fonctionnement ainsi.

Interdiction du travail autonome  
Une commande à la fois  
Afficher le diff avant modification  
Interdiction de commit/push  
La conservation de la version officielle doit être approuvée par une personne  
La sortie LLM doit être utilisée uniquement en Markdown/texte

Impressions sur la recherche Web dans MCP

En ajoutant la recherche Web, les performances de recherche se sont nettement améliorées par rapport à la méthode de patch Web traditionnelle. La vitesse de localisation des informations nécessaires et la portée de la recherche se sont accrues, ce qui a aidé à rassembler des liens candidats.

Cependant, il y avait une tendance à interpréter de façon étrange les informations obtenues par la recherche Web. Le modèle était bon en recherche, mais sa capacité à juger les résultats de recherche dans le contexte du travail de codage était encore instable.

J’ai donc pensé qu’il pourrait être préférable de séparer le LLM de codage et le LLM de recherche. Confier la recherche à un modèle ou un outil spécialisé, et valider séparément les jugements de codage, semble plus fiable.

Réflexion

Certaines parties de mes tâtonnements d’aujourd’hui étaient en fait des problèmes simples dont je connaissais déjà la réponse.

Il suffisait d’aligner .github et .qwen avec les originaux, mais j’ai compliqué le problème en suivant les tentatives intermédiaires du modèle. À l’avenir, je vérifierai d’abord si le résultat produit par le modèle correspond à la structure requise, et je validerai les synchronisations de répertoires/fichiers dès le début avec un diff direct.

En particulier, il faut d’abord s’assurer que « la structure de la source et de la destination est identique » plutôt que de se demander « qu’est‑ce qui a été copié ».

Problème d’interruption du travail

Après 14 h aujourd’hui, la connexion Internet s’est rétablie, mais le serveur Qwen qui tournait sur RunPod s’est arrêté. Depuis, les appels au modèle étaient impossibles, ce qui a rendu la poursuite du travail difficile.

Le travail local et le nettoyage étaient possibles, mais le flux automatisé de revue/recherche/validation basé sur le serveur Qwen dépend fortement de l’état de la connexion Internet, comme je l’ai de nouveau constaté.

Prochaines actions

• Forker web-search-mcp et personnaliser le moteur de recherche ainsi que le format de sortie.
• Séparer l’étape de résumé des résultats de recherche de l’étape de jugement de codage afin de réduire les erreurs d’interprétation des résultats de recherche par Qwen.
• Pour les tâches où la synchronisation de la structure des répertoires (comme .github, .qwen) est cruciale, valider d’abord avec un diff.
• Ne pas accorder immédiatement à Qwen des droits de manipulation du dépôt ; l’utiliser commande par commande avec vérification du diff.
• Recevoir d’abord la sortie de Qwen sous forme de brouillon Markdown/texte, et laisser les schémas JSON ou l’orchestration via l’API GitHub à des scripts ou à une personne.
• Préparer un modèle de secours ou une procédure de vérification locale pour faire face à une éventuelle panne du serveur Qwen sur RunPod.