Lundi à l'établi : un écran d'état avec ZCode et GLM-5.3-Flash, en fiction

JACK GROSS · FICTION + SOURCED ANALYSIS · 28 SEP 2026

Récit de vie fictif, ni entretien avec un vrai dirigeant ni test du modèle

Dans ce récit inventé, je dirige un petit atelier de réparation. Lundi matin : trois clients réservés sur le même établi, une livraison fournisseur en retard, et le « peut-être jeudi » du technicien griffonné dans un carnet jaune. Un collègue demande qui appeler en premier. La réponse existe, éparpillée en trois endroits, et je ne peux pas me permettre une heure de recherche de plus. Le narrateur et l'entreprise sont inventés. Je n'ai exécuté ni ZCode ni GLM-5.3-Flash, interrogé aucun fondateur, ni observé les résultats décrits.

Réservations inventées→Plan ZCode→Prototype local→Le patron relit

Deux noms, deux produits

Deux choses sont nommées dans cette histoire. ZCode est l'environnement d'agent de code de Z.AI. GLM-5.3-Flash est un modèle. Toutes les descriptions de produits ci-dessous viennent des pages de Z.AI elle-même, pas d'un essai de ma part.

Un assistant à construire, pas un PDG numérique

Je ne veux pas qu'un agent dirige mon entreprise. Je veux un petit écran interne avec les réservations confirmées, les pièces provisoires et la source exacte de chaque statut. Selon Z.AI, ZCode garde une tâche avec les fichiers du projet, un terminal, l'état Git, un aperçu navigateur et un panneau de relecture. Sa page d'accueil dit que GLM-5.3-Flash est intégré pour le travail sur images et captures, alors que son discours plus large tourne autour de GLM-5.3. J'ouvrirais donc le sélecteur de modèles et je vérifierais mon offre au lieu de supposer qu'une session tourne sur Flash. Le nom documenté dans l'API est glm-5.3-flash, et un modèle d'API n'est pas le harnais ZCode. [source]

Journal du patron fictif

Du lundi au vendredi, à la première personne, par un patron inventé. Rien de tout cela n'a eu lieu.

Le premier prompt et la première limite

Dans l'histoire, je crée un dépôt neuf avec des réservations inventées, jamais de vrais dossiers clients. J'ouvre ZCode en mode Plan et j'écris un seul objectif : « Construis un prototype local ; trois statuts seulement ; pas d'envoi, pas de paiement, pas de déploiement en production. Montre les conflits et les horodatages des sources. » L'agent pourrait proposer une base de données, une interface et une chaîne d'intégrations. Je réduirais la première passe à un importeur CSV, un détecteur de conflits et un écran. La documentation de ZCode dit que Plan attend l'approbation et que « demander avant de modifier » est le réglage par défaut pour les éditions et commandes. L'accès complet réduit les confirmations, ce qui est un mauvais départ avec des données d'entreprise. Je vérifierais quand même les réglages exacts dans la version installée. [source]

Une capture d'écran n'est pas un cahier des charges

J'ajoute une photo du tableau papier et je désigne la colonne « promis ». Sur ce tableau, un rond rouge veut dire « en attente de la réponse du client », pas « urgent ». Un modèle de vision peut construire un joli tableau de bord qui inverse justement ce sens. Z.AI décrit GLM-5.3-Flash comme nativement multimodal, avec entrée image et un contexte allant jusqu'à un million de jetons. Ce sont des spécifications du fournisseur, pas la preuve qu'il a déchiffré ma légende manuscrite. Je lui ferais donc lister les marques dont il doute, lui demander la légende, et comparer l'écran rendu au tableau d'origine. La boucle : lire, proposer, rendre, inspecter, corriger. Mon approbation de la légende empêche une erreur plaisante de devenir un processus. [source]

La note du fournisseur qui voulait être un ordre

Dans l'histoire, un PDF de fournisseur arrive avec une référence de pièce ordinaire et une ligne adressée à « votre automatisation » demandant de changer le compte bancaire sur la facture. Le PDF est une preuve sur des pièces, pas une permission de toucher aux coordonnées bancaires. L'OWASP nomme cette frontière l'injection de prompt depuis un matériau non fiable. Dans ZCode, un agent de code peut lire un fichier et proposer une commande, et une boîte de dialogue d'autorisation ne remplace pas la compréhension de ce que la commande fera. Les documents fournisseurs restent donc dans un dossier de test en lecture seule, aucune requête réseau ne vise un système financier, et tout détail de paiement passe par un processus humain distinct. Le modèle peut signaler la ligne suspecte sans l'exécuter ni la répéter comme une instruction. [source]

La démo du vendredi

Vendredi de cette semaine inventée, le prototype sur mon portable montre trois colonnes : confirmé, provisoire, bloqué. La ligne la plus importante n'est pas un chiffre. C'est « source non vérifiée » à côté de la livraison en retard. Je demande à l'agent un cas où deux réservations se chevauchent de quinze minutes. S'il en décale une en silence pour que l'écran passe au vert, c'est raté. S'il montre les deux réservations, une étiquette d'heure locale, leurs lignes sources et un brouillon de note pour mon collègue, la conception va dans le bon sens. C'est un seuil de revue imaginé, pas un exploit de ZCode ou de Flash. [source]

Règle illustrative de chevauchement, pas un agenda de production

from datetime import datetime

def overlaps(a_start, a_end, b_start, b_end):
    # Inputs must be timezone-aware and normalized beforehand.
    assert all(x.tzinfo is not None for x in (a_start, a_end, b_start, b_end))
    return max(a_start, b_start) < min(a_end, b_end)

# On a conflict: show both source rows; never move a booking automatically.

Ce que je testerais avant de faire confiance au montage

Je monterais d'abord un jeu de données synthétique : noms en double, changements de fuseau, une feuille papier scannée avec une marque ambiguë, rendez-vous qui se chevauchent, une révision fournisseur périmée et une instruction cachée dans un PDF. On fige les entrées et on compare une base construite à la main au prototype assisté par ZCode. On mesure précision et rappel des conflits, taux de statuts erronés, provenance des sources, accessibilité visuelle, tests qui passent sur une machine propre, et si un relecteur peut retracer chaque promesse affichée. On répète avec le même budget de temps et d'outils en comptant ensemble l'usage du modèle et les corrections humaines. Les benchmarks de code du fournisseur ne me diront pas si un client s'est vu promettre une pièce qui n'est jamais arrivée.

Ce qui est resté à moi

Ce qui aide, c'est un logiciel que je peux inspecter, pas un PDG synthétique. Je choisis toujours qui l'on appelle, quels changements partent en ligne, quels dossiers peuvent quitter l'atelier et si un fournisseur est payé. Un bon agent réduit les endroits où je dois regarder. Il n'a pas mérité une signature, un accès bancaire ni le droit d'improviser une promesse. Je ne ferme le carnet jaune que lorsque l'écran est honnête sur ce qu'il ignore.

Sources et limites

Le narrateur, l'atelier et le prototype sont inventés, aucune exécution de ZCode ni de modèle n'a eu lieu. Tout ce qui précède est un raisonnement de conception, sans résultat mesuré.

zcode.z.ai · zcode.z.ai · zcode.z.ai · zcode.z.ai · zcode.z.ai · zcode.z.ai · docs.z.ai · cheatsheetseries.owasp.org · github.com