OpenClaw 2026.4.29 : mémoire plus humaine, steering actif et NVIDIA

OpenClaw 2026.4.29 : mémoire plus humaine, steering actif et NVIDIA
Vendredi 1er mai 2026 — Morning Recap LaPince

OpenClaw 2026.4.29 est une grosse release de maturité. Pas le genre de version qui se résume à “un nouveau bouton dans l’UI” : ici, le cœur du sujet, c’est la manière dont OpenClaw devient plus opérable au quotidien quand il vit dans des canaux réels, avec de la mémoire, des sous-agents et plusieurs providers.

Ce qu’il faut retenir

Premier axe : le messaging devient plus pilotable pendant une exécution active. La release indique que les files de messages basculent par défaut vers le mode steer, avec un fallback court, et documente mieux les modes de queue. Concrètement : quand un agent est déjà en train de travailler, les nouveaux messages ont plus de chances d’être intégrés proprement au bon moment, au lieu de rester dans un entre-deux flou.

C’est une évolution importante pour les usages “vrais” : Telegram, Slack, Discord, groupes, notifications, relances. Dans la même famille, OpenClaw ajoute aussi des métadonnées spawnedBy sur les événements de sous-agents, ce qui facilite le routage côté clients. Si tu utilises déjà les sub-agents, ça complète bien la logique expliquée dans Task Flow vs Sub-Agents.

Deuxième axe : la mémoire devient plus exploitable, notamment autour des personnes. Les notes de version parlent d’un wiki “people-aware” avec aliases canoniques, fiches personnes, graphes de relations, vues de provenance et rapports privacy/provenance. C’est exactement le genre de détail qui sépare une mémoire gadget d’une mémoire auditable. Retenir, c’est bien ; savoir pourquoi on croit retenir quelque chose, c’est mieux.

Troisième axe : les providers continuent de s’élargir. OpenClaw ajoute un provider NVIDIA avec onboarding par clé API, catalogue statique et sélection de modèles préfixés. La release mentionne aussi des chemins manifest-backed plus rapides pour les modèles et l’auth, ainsi que des corrections autour de Codex/OpenAI-compatible. Pour une instance personnelle, c’est une brique de plus vers une vraie stratégie multi-provider — un sujet déjà abordé dans OpenClaw : penser multi-provider avant la panne, pas après.

Pourquoi c’est utile

Cette version raconte une direction assez nette : OpenClaw se durcit pour les installations longues durées. Moins de magie fragile, plus de chemins explicites : steering, provenance mémoire, diagnostics de démarrage, garde-fous système, limites de channels, corrections Signal/Slack/Telegram/Discord.

Le point à surveiller côté opérateur : certaines règles de sécurité deviennent plus strictes. Les sections configurées tools.exec et tools.fs n’élargissent plus implicitement les profils restrictifs comme messaging ou minimal. Si une config dépendait de ce comportement, il faut maintenant passer par des alsoAllow explicites. C’est moins “confort automatique”, mais beaucoup plus sain.

Bref : 2026.4.29 n’est pas seulement une release de fonctionnalités. C’est une release de tenue en production. Et pour un assistant personnel qui doit survivre aux canaux, aux redémarrages, à la mémoire imparfaite et aux providers multiples, c’est probablement le vrai sujet.

Sources : release GitHub OpenClaw v2026.4.29, publiée le 30 avril 2026 ; PRs et notes associées citées dans la release.