L'heure de gloire d'Opus dans le monde de l'open source : GLM-5 peut-il reprendre le flambeau du codage agentique ?

Si vous demandez à un développeur quel est le moment le plus frustrant du codage avec l'IA,

la réponse sera probablement la phrase mécanique « Désolé, je n'ai pas compris » face à une erreur, suivie de la répétition d'un code tout aussi erroné.

Au cours de l'année écoulée, les progrès des grands modèles de codage se sont davantage manifestés dans la « capacité de génération » : générer une page web, des composants, des petits jeux en une phrase – créer une page web pixelisée, une icône SVG cool ou un jeu de serpent fonctionnel en 15 secondes. Ces démos sont suffisamment étonnantes, mais aussi suffisamment « légères », elles ressemblent un peu à des jouets sophistiqués produits à l'ère du Vibe Coding (programmation d'ambiance). Mais lorsqu'il s'agit d'architectures à forte concurrence, d'adaptation de pilotes de bas niveau ou de restructurations de systèmes complexes, elles deviennent des « fleurs de serre ».

C'est pourquoi, récemment, la tendance a changé dans la Silicon Valley.

Que ce soit Claude Opus 4.6 ou GPT-5.3, ces modèles de pointe commencent à mettre l'accent sur le codage agentique : ne pas chercher à « obtenir des résultats en quelques secondes », mais plutôt à accomplir des tâches au niveau du système par la planification, le démantèlement et l'exécution répétée.

Ce passage d'une approche « esthétique frontale » à une approche « ingénierie système » était autrefois considéré comme le domaine réservé des géants propriétaires. Ce n'est qu'après avoir testé GLM-5 que j'ai réalisé que « l'ère des architectes » de la communauté open source avait commencé plus tôt que prévu.

01

Du « front-end » à « l'ingénierie système »

Auparavant, lorsqu'on parlait de codage avec l'IA, on pensait surtout à un récit familier : générer une page web en une phrase, créer un petit jeu en une minute, réaliser un effet dynamique cool en dix secondes. L'accent était mis sur le « plaisir visuel » : des boutons qui bougent, des pages attrayantes, des effets spéciaux riches.

Mais ceux qui sont réellement sur le terrain savent que la capacité de générer une démo ne signifie pas la capacité de soutenir un système.

La difficulté des tâches complexes ne réside pas dans « l'écriture du code », mais dans la manière dont les modules sont divisés, dont les états sont gérés, dont les exceptions sont gérées, dont les performances sont optimisées et, lorsque le système devient complexe, dans la capacité à maintenir la stabilité de la structure.

C'est pourquoi nous avons choisi des tâches complexes comme objets de test.

Le positionnement de GLM-5 est différent de celui de nombreux produits concurrents.

Si la plupart des modèles ressemblent davantage à un « excellent front-end » – capable de générer rapidement des interfaces interactives et des effets visuels – GLM-5 est plus orienté vers un « rôle d'ingénierie système ». Il met l'accent sur la collaboration entre plusieurs modules, les tâches à longue chaîne et la stabilité structurelle exécutable dans un environnement de production.

Pour vérifier cela, nous avons conçu deux cas de test de dimensions complètement différentes.

Le premier test, une tâche apparemment simple mais en réalité hautement systématisée : créer un jeu interactif sur le thème du Nouvel An, basé sur un navigateur et une caméra, pour « contrôler à distance des feux d'artifice avec la vision de l'IA ».

Dans la vidéo de test, on peut voir l'utilisateur debout devant la caméra, contrôlant la direction et le rythme du lancement des feux d'artifice par des gestes ; les feux d'artifice s'épanouissent dans le ciel, accompagnés d'effets de particules et de rétroactions d'effets de lumière dynamiques, l'interaction globale est fluide et naturelle.

Mais il ne s'agit pas d'un simple projet d'effets dynamiques front-end. Il comprend au moins les modules principaux suivants : reconnaissance des gestes et traitement de l'entrée visuelle ; mappage des coordonnées des gestes à la logique de lancement ; système de particules de feux d'artifice et effets d'épanouissement ; rendu en temps réel et contrôle de la fréquence d'images ; compatibilité du navigateur et gestion des exceptions d'autorisation de la caméra ; gestion de l'état de l'interaction et rétroaction de l'utilisateur.

On peut dire qu'il s'agit d'un petit système interactif avec une structure complète et une expérience fluide. D'après le processus de test, GLM-5 n'est pas entré directement dans le codage, mais a d'abord planifié l'architecture globale : comment séparer les modules d'entrée visuelle, la couche de logique de contrôle, la couche de rendu et la couche d'effets spéciaux ; comment transmettre le flux de données ; quelles parties pourraient devenir des goulots d'étranglement en termes de performances.

Ensuite, il a implémenté la logique couche par couche, en commençant par le traitement des données de la reconnaissance des gestes, en passant par le calcul de la trajectoire de lancement, jusqu'à l'optimisation des paramètres de l'effet d'explosion des particules.

Lorsque le rendu est devenu lent, il a activement suggéré de réduire le nombre de particules et d'optimiser la structure de la boucle ; lorsque la reconnaissance des gestes a été mal interprétée, il a ajusté les seuils et les stratégies de filtrage.

L'effet présenté dans la vidéo est une « interaction qui semble très naturelle ». Mais derrière cela, il y a une chaîne d'ingénierie complète : planification → écriture → débogage → optimisation des performances → correction de l'interaction.

Le code généré final peut être exécuté directement, l'interaction est stable, la fréquence d'images est fluide et les situations anormales peuvent être gérées. Plus important encore, sa façon de travailler présente une pensée systémique claire : les limites des modules sont claires, la stratification logique est raisonnable, au lieu d'empiler toutes les fonctions dans un seul fichier.

Le deuxième cas testé est la capacité du système de structure. Ce scénario peut être considéré comme le quotidien du travail médiatique : importer une transcription d'interview, résumer le contenu, produire des angles et des idées de sujets.

Dans le test, on peut voir que le processus d'opération est très direct : j'ai collé une transcription d'interview d'il y a quelque temps, le modèle a commencé à analyser, puis a produit un résumé du contenu et des angles de sujets. D'après les résultats, les angles de sujets qu'il a générés sont toujours très opérationnels.

Comparé au système d'interaction visuelle, le tri des enregistrements semble simple, mais il teste en fait la « capacité d'abstraction structurelle » du modèle. Un enregistrement d'interview réel est souvent très peu structuré : les points de vue sautent, les informations se répètent, la ligne principale et les lignes secondaires s'entrecroisent. Donc, dans ce cas, la capacité démontrée par GLM-5 se situe au niveau du système.

Tout d'abord, la capacité d'identification du thème et d'extraction de la ligne principale. Le modèle n'a pas généré de résumé dans l'ordre du texte original, mais a d'abord déterminé quel était le sujet principal, puis a réorganisé le contenu autour de ce sujet. Cela signifie qu'il a effectué un balayage interne pour identifier quelles informations appartiennent à la ligne principale et lesquelles sont des compléments ou du bruit. Cette capacité est essentiellement une capacité de planification, c'est-à-dire qu'avant de produire, il faut d'abord établir un cadre de structure abstraite.

Deuxièmement, la capacité de réassemblage modulaire. Il classera les points de vue pertinents dispersés dans différents paragraphes dans le même module. Cette capacité d'intégration inter-paragraphes montre que le modèle a une cohérence globale lors du traitement de longs textes.

Troisièmement, la capacité d'ajustement actif de l'ordre logique. Le plan produit réel est souvent différent de l'ordre d'enregistrement original. On peut voir que GLM-5 a réorganisé les niveaux en fonction des relations de cause à effet ou de la logique de l'argumentation. Cela reflète un jugement de « priorité à la logique par rapport à l'ordre d'entrée original ». Ce modèle de « structure d'abord, sortie ensuite » est au cœur de la pensée d'ingénierie système.

Ces deux cas, un système d'interaction visuelle en temps réel et un système de traitement de l'information médiatique structurée, semblent complètement différents. Mais ils vérifient la même chose : GLM-5 a une capacité de boucle fermée de tâche complète : planification → exécution → débogage → optimisation.

Dans le jeu de feux d'artifice, cela se reflète dans la stratification des modules, l'optimisation des performances et la gestion des exceptions ; dans le processeur d'enregistrement, cela se reflète dans le jugement du thème, le démantèlement de la structure et la réorganisation logique. Leur point commun est que le modèle ne s'arrête pas à la « génération de résultats », mais maintient une structure durable et évolutive.

J'ai continué à essayer une tâche relativement complexe, « construire un noyau de système d'exploitation minimaliste ». Dans ce test, ce qui mérite vraiment d'être noté, ce n'est pas le fait que le code de la vidéo finit par fonctionner, mais la façon dont GLM-5 se comporte tout au long du processus.

Il n'est pas entré immédiatement dans un état de génération après avoir reçu la tâche, mais a d'abord clarifié les limites de la tâche, a activement décomposé les modules, a planifié la structure du système, puis est entré dans la phase de réalisation. Cette voie de « structure d'abord » est essentiellement la pensée d'ingénierie dont nous avons parlé précédemment : définir d'abord comment le système est composé, puis discuter des détails de la réalisation, au lieu d'écrire et d'assembler en même temps.

Dans le cycle de plusieurs tours d'écriture, d'exécution, d'erreurs et de corrections, GLM-5 n'a pas non plus montré d'effondrement de la structure. Chaque modification est effectuée autour de l'architecture établie, au lieu de renverser et de recommencer ou d'appliquer des correctifs locaux. Cela montre qu'il maintient en interne un modèle de système complet, capable de maintenir la cohérence dans les tâches à longue chaîne. De nombreux modèles ont tendance à être incohérents après que le contexte a été étendu, tandis que la performance dans la vidéo reflète précisément sa capacité de mémoire continue de la structure globale.

Il y a aussi sa façon de traiter les erreurs. Lorsque des erreurs se produisent, il ne s'arrête pas à la conjecture superficielle selon laquelle « il pourrait y avoir un problème avec une ligne de code », mais juge d'abord le type d'erreur, distingue les problèmes de logique, les problèmes d'environnement ou les conflits de dépendances, puis planifie le chemin de dépannage. Il s'agit d'un débogage au niveau de la stratégie, visant à réparer le chemin du problème.

Si l'on combine cela avec l'appel d'outils, cette capacité deviendra plus évidente. Il ne se contente pas de donner des suggestions de commandes, mais combine également la planification active de l'exécution du terminal, l'analyse des journaux, la réparation de l'environnement, puis continue de faire avancer la tâche. Ce comportement se rapproche déjà d'une progression d'ingénierie de type « conduite autonome ». Si l'objectif n'est pas atteint, il continue d'itérer.

Planifier d'abord puis exécuter, maintenir la stabilité de la structure dans les longues chaînes, dépanner les problèmes de manière stratégique et faire progresser continuellement autour de l'objectif – c'est la superposition des quatre capacités de base requises par l'ingénierie système qui permet à GLM-5 de commencer à présenter un mode de comportement proche de celui d'un ingénieur.

Pourquoi GLM-5 peut-il reprendre le flambeau de « l'architecte » ?

Si la première partie du test prouve que GLM-5 « peut faire un travail complexe », la question suivante est : comment peut-il le faire ? La réponse réside dans tout un ensemble de « modes de comportement de niveau ingénierie » cachés derrière la sortie.

Un point clé est que GLM-5 a manifestement introduit un mécanisme d'auto-vérification de la chaîne de pensée similaire à celui de Claude Opus 4.6.

Dans l'utilisation réelle, on peut sentir qu'il ne commence pas immédiatement à « remplir le code » après avoir reçu une tâche, mais effectue plusieurs tours de déduction logique en arrière-plan : prédire la relation de couplage entre les modules, éviter activement les chemins de boucle infinie, découvrir à l'avance les conflits de ressources et les problèmes de conditions limites. Le changement direct apporté par ce comportement est que, pour s'assurer que le plan est viable sur le plan de l'ingénierie, il est prêt à ralentir et à réfléchir complètement au problème.

Dans les tâches complexes, GLM-5 donnera d'abord une décomposition claire des modules : de quels sous-modules le système est-il composé, quelles sont les entrées et les sorties de chaque module, quelles parties peuvent être avancées en parallèle et lesquelles doivent être effectuées en série. Ensuite, il les surmonte un par un, au lieu d'écrire et de penser en même temps. Cela rend sa façon de travailler plus semblable à celle d'un véritable ingénieur : dessiner d'abord le schéma d'architecture, puis écrire les détails de la réalisation. On sent clairement qu'il a une sorte de « ténacité à ne pas s'arrêter tant que le problème n'est pas complètement résolu », au lieu de terminer à la hâte après avoir terminé une partie qui semble correcte.

Cette différence est particulièrement évidente dans la comparaison avec les modèles de codage traditionnels. Dans le passé, de nombreux modèles, lorsqu'ils rencontraient des erreurs, glissaient rapidement dans un mode familier : s'excuser, répéter les informations d'erreur, donner une suggestion de correction non vérifiée ; si cela échouait à nouveau, ils commençaient à produire en boucle des réponses approximatives. La façon dont GLM-5 traite les choses est plus proche de celle d'un architecte chevronné. Dans le test, lorsque le projet ne pouvait pas fonctionner en raison de problèmes de dépendances environnementales, il ne s'est pas arrêté aux informations d'erreur superficielles, mais a activement analysé l'arbre de dépendances (Dependency Tree), a jugé la source du conflit et a ensuite ordonné à OpenClaw de réparer l'environnement.

L'ensemble du processus ressemble davantage à un déploiement de type « conduite autonome » : le modèle ne répond pas passivement, mais lit, corrige le chemin et vérifie les résultats en continu.

Une autre capacité souvent négligée, mais extrêmement importante dans l'ingénierie système, est l'intégrité du contexte.

La fenêtre de jetons de niveau million de GLM-5 lui permet de comprendre la structure du code, les modifications historiques, les fichiers de configuration et les journaux d'exécution de l'ensemble du projet dans le même contexte. Cela signifie qu'il est déjà capable de juger du point de vue global quelles modules une modification aura des réactions en chaîne. Dans les tâches à longue chaîne, cette capacité détermine directement si le modèle est « intelligent mais myope » ou « stable et contrôlable ».

Dans l'ensemble, GLM-5 reprend vraiment le rôle de « l'architecte » principalement parce qu'il commence à penser aux problèmes comme un architecte : planifier d'abord, puis exécuter ; vérifier continuellement, corriger constamment ; se concentrer sur l'ensemble du système, plutôt que sur un succès ponctuel.

C'est aussi la raison fondamentale pour laquelle il est capable d'accomplir les tâches de test au niveau du système dans la première partie.

03

L'Opus du monde open source ?

Si l'on considère l'écosystème des grands modèles en 2026, la valeur de GLM-5 réside davantage dans le fait qu'il a brisé une chose qui était auparavant presque acceptée par défaut : l'intelligence au niveau du système ne semble pouvoir exister que dans les modèles propriétaires.

Auparavant, Claude Opus 4.6 et GPT-5.3 avaient en effet ouvert la voie du « codage agentique » : le modèle ne cherche plus à obtenir un retour d'information immédiat, mais effectue des tâches d'ingénierie vraiment complexes par la planification, le démantèlement et l'exécution répétée. Mais le coût est également très élevé : la consommation de jetons des tâches à forte intensité est extrêmement élevée, et une tentative complète au niveau du système signifie souvent un coût d'appel important.

GLM-5 offre ici une solution différente. En tant que modèle open source, il a ramené « l'IA de niveau architecte système » du cloud et des factures dans l'environnement des développeurs. Vous pouvez le déployer localement et le laisser passer du temps à ronger les travaux sales, les travaux pénibles et les gros travaux : ajuster les journaux, vérifier les dépendances, modifier l'ancien code, compléter les conditions limites.

Cela peut être considéré comme un changement structurel rentable : l'intelligence de niveau architecte n'est plus le privilège de quelques équipes.

Si l'on comprend cette différence par une métaphore professionnelle, elle sera plus intuitive. Les modèles comme Kimi 2.5 ressemblent davantage à d'excellents ingénieurs front-end avec une esthétique en ligne et un sens de l'interaction extrêmement fort, spécialisés dans la génération en un seul coup, la présentation visuelle et le retour d'information rapide ; tandis que le style de GLM-5 est manifestement différent, il ressemble davantage à un architecte système chevronné qui respecte les règles et met l'accent sur la logique : se concentrer sur les relations entre les modules, les chemins d'exception, la maintenabilité et le fonctionnement stable à long terme.

Derrière cela, il y a en fait une progression professionnelle claire de l'IA de programmation : passer de la poursuite du « Vibe Coding qui a l'air cool » à la mise en évidence de la robustesse et de la discipline d'ingénierie de l'ingénierie.

Plus important encore, l'émergence de GLM-5 rend le concept d'entreprise individuelle plus réalisable.Quand un développeur peut avoir localement un partenaire IA qui comprend la conception de systèmes, qui fonctionne à long terme et qui peut s'auto-corriger, de nombreux travaux d'ingénierie qui nécessitaient auparavant une équipe peuvent être réduits à une portée contrôlable par une seule personne. Ensuite, GLM-5 a le potentiel de devenir ce « partenaire numérique » responsable de la mise en œuvre de l'ingénierie de base dans une entreprise individuelle.