z.ai GLM-5.1 gagne une vision locale : un modèle 8B comble 70 % de l'écart avec la frontière

Un développeur montre comment corriger l'une des principales faiblesses des modèles de code bon marché : leur cécité face à leur propre UI. Pour z.ai GLM-5.1, il a construit un vision-sidecar local qui lit les captures d'écran, renvoie la structure de l'interface en JSON et permet à l'agent de vérifier lui-même le résultat après avoir généré le code.

En quoi consistait le problème

Le problème est familier à presque tous ceux qui ont essayé des modèles économiques à la place de systèmes frontier coûteux. L'agent sait écrire du HTML, lancer une page, exécuter Playwright et enregistrer une capture d'écran, mais il bute ensuite sur un mur : l'image existe, la compréhension non. Si un bouton se décale, si un tableau est tronqué, si du texte déborde sur une carte ou si la grille mobile s'effondre, le modèle ne le remarque pas. Résultat : l'humain revérifie l'interface à la main et, au lieu de piloter les tâches, devient un QA permanent entre deux itérations.

L'auteur est parti d'une hypothèse simple : ce type de retour ne nécessite pas le système multimodal le plus puissant du marché. Sur des captures d'interface web, l'enjeu n'est généralement pas le raisonnement abstrait, mais l'extraction de faits : OCR, liste des boutons, structure des blocs, présence de troncatures et exactitude des tableaux. Si c'est vrai, un modèle de vision ouvert et compact peut servir de couche sensorielle peu coûteuse à un agent de code et boucler le cycle « écrire -> regarder -> corriger » sans API cloud.

Comment le pipeline a été construit

La vision repose sur qwen3-vl:8b, déployé localement via Ollama. Par-dessus, l'auteur a développé un serveur MCP, vision-sidecar-mcp, qui reçoit les captures d'écran et renvoie une description structurée de l'écran. Cette couche ne fait pas de GLM-5.1 un modèle multimodal à part entière, mais lui apporte ce qui lui manquait en développement concret : la capacité de lire le résultat visuel de son travail via une interface textuelle. Sur un GPU classique ou sur Apple Silicon, l'ensemble se met en place en 20 minutes environ, selon l'auteur.

• qwen3-vl:8b comme modèle de vision local
• Ollama pour un déploiement rapide
• un serveur MCP avec les méthodes analyze_image, analyze_structured et extract_table
• des réponses JSON transmissibles directement à l'agent de code

L'essentiel du travail d'ingénierie n'a pas porté sur le réentraînement des poids, mais sur le réglage de l'inférence. L'auteur a fixé le seed, resserré le sampling avec top_p=0.9 et top_k=20, et contraint les réponses à un schéma JSON strict. Un champ dédié aux symboles et aux icônes a permis d'éliminer des erreurs de reconnaissance typiques, où des glyphs décoratifs étaient mal lus. La leçon compte : quand la tâche se résume à extraire une structure, un bon prompt, un schéma et une génération disciplinée apportent parfois plus qu'un passage direct au fine-tuning.

Quels chiffres ont été obtenus

Le test a porté sur dix captures d'écran d'une application web réelle, du petit écran mobile 320×568 au desktop 1440×900. Trois configurations ont été comparées : qwen3-vl:8b de base, le même modèle après optimisation, et Claude Opus 4.7 comme référence haute.

Le score moyen est passé de 3,99 à 4,70 sur 5, et l'écart avec la frontière est tombé de 1,01 à 0,30. Autrement dit, le modèle local 8B a rattrapé environ 70 % de son retard sans fine-tuning ni données supplémentaires.

« La boucle de test est bouclée.

Le modèle n'est plus aveugle. »

Après optimisation, le duo atteint quasiment la parité là où la vérification pratique de l'interface compte pour l'agent :

• OCR et extraction exacte du texte
• détection des éléments d'UI et des CTA
• compréhension de la structure du layout
• extraction des tableaux et exploitabilité pour un traitement automatique ultérieur

Le principal écart non résolu concerne les hallucinations et les nuances visuelles. Le modèle local pouvait confondre des teintes, mal interpréter de petits éléments décoratifs et saisissait moins bien l'intent du designer, surtout lorsque la couleur porte elle-même un statut ou une priorité. Mais pour des tâches comme la détection de clipping, la présence de CTA, l'exactitude des tableaux et la structure des sections, cela ne semble pas bloquant : il repère déjà les erreurs d'interface critiques de façon suffisamment fiable et prévisible.

Ce que cela signifie

La conclusion pratique est simple : les modèles frontier coûteux restent utiles comme couche de vérification pour les cas complexes, mais l'essentiel des itérations d'UI peut déjà être confié à un duo local associant modèle de code, captures d'écran et modèle de vision compact. L'étape logique suivante est le routing : les écrans simples sont traités localement, les cas litigieux partent automatiquement vers un modèle plus puissant ou vers un humain. Pour les équipes qui surveillent leur budget d'inference et veulent plus d'autonomie en développement frontend, cela ressemble déjà moins à une expérimentation qu'à un schéma opérationnel.