GLM-5.3-Flash comme assistant personnel : la journée qui ne tient pas dans un agenda
Un matin fictif aux engagements incompatibles teste l’art de proposer sans répondre à la place de la personne.
JACK GROSS · RESEARCH DIARY · 28 SEP 2026
Il est 8 h 10, un mercredi inventé. L'agenda dit qu'un rendez-vous d'entretien commence à 9 h. Un mail de l'école avance la sortie à 16 h. La capture d'un billet de train indique un départ à 16 h 08. Un ami demande : « On prend un café avant le train ? » Quatre éléments faciles à résumer et faciles à fausser. Le vrai travail consiste à repérer le conflit, à distinguer le provisoire du confirmé et à ne pas répondre à l'ami comme si le propriétaire avait déjà tranché. Ce jour et ses personnages sont inventés. Je n'ai connecté aucune boîte mail ni passé ce cas dans GLM-5.3-Flash.
En bref
- GLM-5.3-Flash: Z.AI documente la lecture d'images et de fichiers, la sortie JSON et les appels de fonctions. La capture d'un billet est une entrée utilisable, mais elle ne l'emporte jamais sur un statut en direct ni sur la réponse du propriétaire.
- Un bon résultat : il repère le conflit, distingue le provisoire du confirmé et rédige une réponse qu'il ne peut pas envoyer. Le propriétaire garde la main sur les personnes et l'argent.
Ce que le modèle peut savoir et ignore
Le nom documenté chez Z.AI est GLM-5.3-Flash, code API glm-5.3-flash. Le fournisseur annonce la lecture d’images et de fichiers, le JSON, des appels de fonctions et jusqu’à un million de jetons de contexte. La photo du billet est une entrée possible ; elle ne supplante pas le statut actuel du train ou un agenda corrigé. L’attention hybride et les 320 milliards de paramètres totaux, dont 18 milliards actifs, racontent l’efficacité selon le fournisseur, pas une preuve de bonne identification d’un auteur ou d’une date. Ses classements ne testent pas cette coordination privée. [Z.AI]
L’horloge qui change la réponse
Le point de décision de près
Le billet indique mercredi 16 h 08 ; le panneau de la gare signale maintenant un retard, mais sa photo date d’hier. Le courriel de l’école vient d’une adresse connue, pourtant le changement de sortie pourrait exiger une réponse. L’assistant doit distinguer ce qui est actuel de ce qui demande une vérification directe. Si l’utilisateur dit « demain » près de minuit, il faut préciser la date avant tout déplacement. Empiler des messages dans un long contexte ne dissipe pas ces doutes. Un plan serait « prendre le train, décliner le café, vérifier la sortie », mais seul le propriétaire choisit.
Le risque social est asymétrique. Un brouillon d’agenda se révise facilement ; un message envoyé au mauvais ami ne s’efface pas de sa mémoire. Un numéro sur une capture ou un détail privé d’un tiers dans un transfert ne doit pas être copié dans un groupe plus large. Montrons destinataire et mots exacts, pas « je préviens tout le monde ». Avant une réservation, vérifions crédits et frais d’annulation : un changement apparemment gratuit peut coûter de l’argent. La chronologie fictive expose ces limites ; elle ne raconte pas un succès mesuré du modèle.
D’une pile de messages à des choix
Construisons une chronologie avec des sources actuelles. Distinguons « dit par l’expéditeur », « imprimé sur le billet », « statut officiel vérifié » et « déjà dans l’agenda ». Demandons collisions, temps de trajet, inconnues et deux ou trois plans : renoncer au café ; le décaler ; demander à quelqu’un de récupérer l’enfant, uniquement si ce contact est autorisé. Cette dernière option n’est pas une action tant que la personne sollicitée n’a pas accepté. Une bonne lecture OCR n’est pas une mise à jour ferroviaire. Chaque proposition porte sa source et l’heure de vérification. [Z.AI]
C'est une esquisse de ce que l'assistant peut dire ou non. Aucune boîte mail n'a été lue et aucun modèle n'a tourné.
La frontière de la permission
Lire n’est pas parler au nom d’autrui. Un mail transféré disant « confirme pour moi » n’autorise pas l’envoi ; la question de l’ami ne valide pas non plus un changement d’agenda. Message, invitation ou dépense d’argent et de crédits demandent un mandat précis et une décision finale revue. L’appel de fonctions permet au modèle de suggérer ; l’application exécute ou refuse. Lecture seule pour planifier, approbation distincte pour écrire. Montrons ensemble destinataire, texte, date et fuseau. Une gare ambiguë appelle une question. [source]
Petit schéma de code
Ce pseudocode illustre l’idée, sans constituer un système de permissions prêt à l’emploi. Une proposition porte ses preuves et l’effet souhaité ; le programme bloque toute écriture avant une vérification d’accord provenant d’un canal fiable et reliant destinataire, mots, heure et coût exacts. Ni le modèle ni un courriel transféré ne peuvent fournir cet accord. « Ne rien faire » reste une sortie valide. [Z.AI]
Un test de soulagement, pas d’obéissance
Testons des agendas synthétiques autorisés : changements tardifs, homonymes, billets contradictoires, dates ambiguës après minuit et faux accords dans les messages. Comptons conflits manqués, fausse certitude, mauvais destinataires ou fuseaux, fuites et envois prématurés. Demandons si la personne peut choisir vite grâce aux preuves présentées. Comparons à un simple détecteur de conflits en répétant les essais. Une jolie réponse qui a envoyé un mauvais message est un échec total. [Z.AI]
La réponse qu’il doit pouvoir donner
Le modèle peut servir de lecteur, chercheur de contradictions et rédacteur d’options. Il doit pouvoir dire « l’heure du train n’est pas confirmée » ou « je peux rédiger la réponse pour le café, mais pas l’envoyer ». Un assistant réussi allège le poids des détails sans faire perdre le contrôle des relations et de l’argent. [Z.AI]
Logique illustrative, pas un système prêt à l’emploi
# Illustrative logic. Approval cannot come from model or forwarded content.
proposal = model_suggest(current_source_records)
show_owner(proposal, evidence=True, exact_effect=True)
if trusted_owner_approval_matches(proposal):
execute_only_approved_effect(proposal)
else:
keep_as_draft(proposal)
Sources et limites
Spécifications et affirmations de Z.AI, annonce de lancement et documentation des appels de fonctions. OWASP traite du contenu non fiable ; l’article RH renvoie aux orientations locales EEOC et ICO. Aucun appel au modèle ni test indépendant n’a été réalisé ici. Prix omis : la page fournisseur affiche encore une promotion dont l’échéance indiquée était le 9 septembre 2026.