OpenClaw weekly : 3.12 et 3.13, correction de mémoire et changements en amont

Deux versions stables, une bêta, une régression mémoire corrigée en moins de 24 heures, et une semaine d'actualités upstream qui change la façon dont vous devriez envisager l'exécution de systèmes agentiques chez vous. Voici ce qui s'est passé entre le 13 et le 20 mars 2026, et ce qu'il faut en retenir.

OpenClaw 2026.3.12 : dashboard, sécurité et nouvelles primitives

Trois versions ont été publiées sur cette période. La 2026.3.12 est arrivée le 13 mars. La 2026.3.13-beta.1 a suivi le 14 mars, et la version stable 2026.3.13 a été publiée le même jour — sous le tag v2026.3.13-1 car GitHub ne permet pas de réutiliser un tag immuable après publication.

La version npm reste 2026.3.13. Si vous épinglez via les tags git, vous épinglez v2026.3.13-1. Vérifiez vos scripts de déploiement dès maintenant.

Dashboard v2 : la surface, pas l'essentiel

Le changement visible dans la 3.12 est une refonte de l'interface Control UI — vues modulaires (Overview, Chat, Config, Agent, Sessions), palette de commandes, commandes slash, recherche, export et messages épinglés. Si vous gérez votre gateway via le navigateur, vous le remarquerez immédiatement.

Mais le travail le plus important sur le plan opérationnel est ailleurs.

/fast devient un véritable contrat cross-provider

Le mode Fast fonctionne désormais comme un toggle cohérent dans le TUI, le Control UI et l'ACP. Sur les chemins OpenAI, il façonne les requêtes pour un comportement fast-tier. Sur les chemins Anthropic, il se mappe sur service_tier. Point crucial : l'interface vérifie si votre compte dispose réellement de l'accès au tier, au lieu de dégrader silencieusement.

Ce dernier détail compte. La « dégradation silencieuse », c'est comme ça que vous finissez par débugger des caractéristiques de latence bizarres pendant tout un après-midi avant de réaliser que le toggle ne faisait rien.

Pour un gateway auto-hébergé routant entre plusieurs providers, un seul modèle mental pour les compromis latence-coût vaut mieux qu'une douzaine de réglages spécifiques à chaque provider.

Les plugins provider deviennent modulaires

Ollama, vLLM et SGLang migrent vers une architecture provider-plugin avec des hooks d'onboarding et de découverte gérés par chaque provider. C'est un travail structurel. Le support day-one des futurs modèles sera moins fragile, car le cœur n'absorbe plus directement chaque cas particulier propre à un provider.

sessions_yield : une petite primitive aux conséquences réelles

Pour quiconque construit des workflows multi-agents, sessions_yield permet à un orchestrateur de terminer un tour immédiatement, de sauter le travail d'outils en file d'attente, et de transmettre un payload de suivi masqué au tour de session suivant.

Cela vous donne des patterns d'interruption et de préemption propres, sans hacks de prompt ni attente qu'une chaîne d'outils incontrôlée se termine. Trois patterns que vous pouvez construire ce week-end :

• Interruption prioritaire — arrêtez la chaîne d'outils en cours quand un événement de priorité supérieure arrive. Votre message « caméra de sonnette déclenchée » prend le dessus sur « range mes notes ».
• Guardrail fail-fast — si une vérification de politique échoue, yield immédiatement au lieu de laisser les outils s'exécuter puis tenter un rollback.
• Jobs longs découpés — décomposez les workflows coûteux en tours distincts (scan → plan → exécution → validation), en faisant un yield entre les étapes pour que le système puisse réévaluer le contexte et les budgets.

Vous n'avez pas besoin d'un scheduler pour en tirer profit. Un seul agent d'orchestration qui sait quand s'arrêter suffit.

Slack Block Kit : les messages comme interface

La 3.12 ajoute le support de channelData.slack.blocks dans le chemin standard de livraison des réponses. Les agents peuvent désormais émettre des payloads Block Kit via le mécanisme habituel. C'est la différence entre un chat bot et une interface de workflow — des messages structurés sur lesquels les utilisateurs peuvent cliquer, développer et router.

Un projet concret pour le week-end : un agent gérant une boucle opérationnelle récurrente — le statut d'un serveur domestique, par exemple — publiant un message Slack structuré avec des boutons « Voir les logs », « Redémarrer le service », « Désactiver les alertes pendant 2 heures », « Ouvrir une note d'incident ». Les utilisateurs restent dans un seul thread sans mémoriser de commandes.

La 3.13 va plus loin avec des directives optionnelles de réponse interactive Slack.

Sécurité : lisez ceci avant tout le reste

La 3.12 inclut deux changements de sécurité qui devraient être une lecture obligatoire pour quiconque fait tourner un gateway partagé.

Tokens bootstrap pour l'appairage. /pair et openclaw qr émettent désormais des tokens bootstrap à durée de vie courte au lieu d'intégrer les identifiants partagés du gateway dans les payloads d'appairage. Un QR code capturé par screenshot dans un fil de discussion ne constitue plus un risque permanent de fuite d'identifiants.

Chargement automatique implicite des plugins désactivé (GHSA-99qw-6mr3-36qr). Les plugins de workspace ne s'exécutent plus automatiquement quand vous clonez un dépôt. Une décision de confiance explicite est désormais requise. C'est un breaking change si vous comptiez sur l'exécution automatique dans les workspaces fraîchement clonés.

Le modèle conceptuel est le bon : traitez les plugins d'agents comme des scripts CI. Un dépôt est un véhicule de livraison, et vous devez décider consciemment de ce qui s'exécute dans votre environnement.

Au-delà de ces deux points, la 3.12 intègre des durcissements autour du rendu d'approbation exec (normalisation Unicode et détection de caractères invisibles), du contrôle de scope pour les commandes réservées au propriétaire comme /config et /debug, des restrictions sur la gestion de profils navigateur persistants via browser.request, et des guardrails contre le contournement des frontières de workspace par des appelants externes.

Si vous faites tourner OpenClaw ailleurs que sur un laptop mono-utilisateur, traitez la liste complète des avis de sécurité comme une lecture obligatoire et priorisez cette mise à jour.

Corrections de longue traîne qui méritent d'être mentionnées

Plusieurs corrections qui semblent de niche sont exactement celles qui provoquent des sessions de yak-shaving le week-end :

• Améliorations de la persistance et de la validation du sélecteur de modèle Telegram
• Dédoublonnage de la livraison proactive Cron pour éviter les replays après redémarrage
• Corrections du routage main-session pour que les envois internes de l'UI n'héritent pas d'une route de livraison externe
• Windows : openclaw update ne plante plus prématurément en cas d'absence de git ou de configuration node-llama-cpp — il reproduit désormais le comportement de l'installateur via les flux npm update

OpenClaw 2026.3.13 : stabilisation et correction mémoire

La régression qui comptait

Le changement le plus important sur le plan opérationnel dans la 3.13 est la correction d'un problème de déduplication de chunks du plugin SDK introduit dans la 3.12, qui provoquait environ 2× la consommation mémoire. Le correctif déduplique les chunks plugin-sdk dans le pipeline de build.

Sur un VPS contraint ou un petit boîtier ARM, 2× la consommation mémoire n'est pas une métrique. C'est la différence entre un agent stable et la mort par swap. Si vous avez mis à jour vers la 3.12 et constaté une pression mémoire, voici votre explication et votre correctif.

Une approche de validation pratique : capturez le RSS de base et l'activité swap sur la 3.12 sous votre charge de travail la plus exigeante, mettez à jour vers la 3.13, rejouez le même scénario, comparez. Sur les appareils de type Raspberry Pi, cette mise à jour déterminera probablement si votre gateway survit aux pics de charge.

Compaction : continuité, pas seulement contrôle des coûts

La 3.13 ajoute une vérification de cohérence du nombre de tokens sur la session complète après compaction, préserve la continuité de persona et de langue à travers les résumés de compaction, conserve lastAccountId et lastThreadId lors du reset de session, et s'assure que les transcripts existent quand chat.inject s'exécute.

Si votre gateway tourne en continu, la compaction est une préservation d'identité, pas simplement de la gestion de coûts. Un agent qui dérive lentement en persona et en langue à travers les frontières de compaction est peu fiable d'une manière difficile à débugger. Ce travail adresse directement ce mode de défaillance.

OPENCLAW_TZ : corriger le cron Docker une bonne fois

La 3.13 ajoute une variable d'environnement OPENCLAW_TZ pour que les déploiements Docker puissent fixer un fuseau horaire IANA au lieu d'hériter du défaut du daemon.

services:
  openclaw:
    environment:
      - OPENCLAW_TZ=Europe/Zurich

Si vous avez déjà programmé des « rappels matinaux en semaine » pour découvrir que votre conteneur tourne en UTC alors que vous raisonnez en heure locale, voici le correctif. Cela aligne aussi les timestamps des logs avec votre modèle mental, ce qui compte quand vous débuggez quelque chose à 23h.

La 3.13 met aussi à jour les Dockerfiles pour exécuter apt-get upgrade pendant le build. Pas glamour. Mais c'est un durcissement de base important.

Mobile : une vraie maintenance

La 3.13 inclut une refonte de l'interface des paramètres de chat Android, un onboarding QR amélioré utilisant Google Code Scanner, une correction de fuite HttpURLConnection sur Android, et un pager de bienvenue pour l'onboarding iOS.

Cela compte pour les configurations « gateway de poche toujours actif » — un vieux téléphone dans un tiroir, toujours branché, toujours connecté. Moins fragile est le seul mode toujours-actif qui tient dans la durée.

Fiabilité des agents : petites corrections, effet cumulatif

Plusieurs changements dans la 3.13 corrigent des défaillances silencieuses dans les sessions longues :

• Blocs de réflexion supprimés au replay pour les sessions Anthropic
• Fichiers mémoire qui ne sont plus injectés deux fois sur les montages insensibles à la casse
• Overrides de compatibilité utilisateur explicites respectés de manière plus cohérente
• Résolution de workspace cross-agent corrigée

Chaque élément est mineur. Ensemble, ils réduisent le gaspillage de tokens, la pollution de contexte, et ce genre de comportement « mon agent agit bizarrement » difficile à reproduire et encore plus difficile à expliquer.

Problèmes connus à suivre

Faux « missing scope » de openclaw status sur la 3.13. Un ticket GitHub ouvert le 16 mars signale que openclaw status peut indiquer que le gateway loopback est injoignable à cause d'un « missing scope: operator.read » même quand il est accessible. Un correctif est déjà sur main. En attendant qu'il atteigne la version stable, utilisez openclaw gateway status ou openclaw health comme chemin de vérification.

Dépendance optionnelle peer node-llama-cpp. Signalé le 17 mars : node-llama-cpp est marqué comme optionnel, donc npm peut ne pas l'installer automatiquement, ce qui fait tourner les workloads d'embedding local memorySearch en CPU-only. Si vous dépendez de modèles d'embedding locaux et attendez une accélération GPU, vérifiez explicitement l'installation de cette dépendance.

Procédure de mise à jour

Le chemin recommandé :

openclaw update
openclaw health

openclaw update détecte le type d'installation, récupère la dernière version, exécute openclaw doctor et redémarre le gateway. Cela rend les mises à jour routinières plutôt qu'exceptionnelles.

Une note de version pour la 3.13 : la version minimale supportée de Node.js est désormais alignée sur 22.16.0 dans la garde du runtime. Si vous gérez Node manuellement ou faites des installations depuis les sources, vérifiez votre version de Node avant de mettre à jour le gateway. La documentation recommande Node 24.

Veille écosystème

OpenAI : le monitoring des agents est désormais une discipline opérationnelle

Le 19 mars, OpenAI a publié un article détaillé sur la façon dont ils surveillent leurs agents de codage internes à l'aide d'un système à faible latence alimenté par GPT-5.4 Thinking — examinant les chaînes de raisonnement et produisant des alertes étiquetées par niveau de sévérité. L'article présente explicitement le monitoring comme une couche dans une stratégie de défense en profondeur et aborde le virage vers le blocage synchrone dans les contextes à haut risque.

Si vous faites tourner un gateway qui peut toucher à vos fichiers, votre navigateur, vos systèmes de chat et votre domotique, vous êtes déjà en territoire de système agentique. La direction est claire : traitez les sessions d'agents longue durée comme des systèmes de production. Conservez des logs structurés pour les appels d'outils et les approbations. Traitez une utilisation inattendue d'outil comme un incident méritant investigation, pas comme une curiosité.

Le durcissement sécurité dans les versions 3.12 et 3.13 — contrôle de scope, confiance des plugins, vérifications de cohérence de la compaction, prévention des fuites de tokens — reflète la même vision du monde. Des outils comme UptimeRobot, qui offre du monitoring de disponibilité externe avec un tier gratuit couvrant 50 moniteurs, deviennent pertinents dès que votre gateway est quelque chose dont vous dépendez au quotidien.

GPT-5.4 mini et nano renforcent le pattern de sous-agents avec petits modèles

Le 17 mars, OpenAI a annoncé GPT-5.4 mini et GPT-5.4 nano. Mini est positionné comme plus de 2× plus rapide que GPT-5 mini. Nano cible la classification, l'extraction, le ranking et le travail de sous-agents.

L'architecture émergente vers laquelle cela pointe : un modèle de haute qualité pour la coordination, les politiques et la sortie finale ; de petits modèles rapides pour les tâches parallèles — grep de logs, scan d'une arborescence de config, résumé de docs, ébauche d'une carte Slack Block Kit.

La direction prise par OpenClaw cette semaine (sessions_yield, cohérence du mode fast, continuité de session améliorée) soutient directement cette conception. La 3.13 met aussi à jour les valeurs par défaut des tests Codex de GPT-5.3 à GPT-5.4, signalant que le projet suit le paysage des providers et affine les réglages pour les configurations multi-modèles.

Anthropic : le contexte 1M devient standard

Le 13 mars, Anthropic a annoncé que le contexte 1M est en disponibilité générale pour Opus 4.6 et Sonnet 4.6, au tarif standard sans surcoût pour le contexte long, et étend les limites média à 600 images ou pages PDF.

La bonne stratégie de compaction dépend désormais de votre routage :

• Routage vers un modèle à contexte 1M — la compaction est moins fréquente, mais le coût d'une mauvaise compaction quand elle survient est plus élevé. La préservation de la continuité compte davantage à chaque événement.
• Routage vers des fenêtres de contexte plus petites — la compaction est routinière, le travail de continuité est obligatoire à chaque cycle.

L'investissement d'OpenClaw pour rendre la compaction moins destructrice et moins cassante pour l'identité est la bonne direction dans les deux cas.

OpenAI Japan : un rappel concernant les déploiements partagés

OpenAI Japan a publié un Teen Safety Blueprint le 17 mars, couvrant les protections adaptées à l'âge, des politiques renforcées pour les utilisateurs de moins de 18 ans, et le contrôle parental.

L'implication pour l'auto-hébergement est directe : si plusieurs personnes accèdent à votre gateway — chat familial, Slack partagé, Discord partagé — vous avez besoin d'une politique délibérée et d'une posture de sécurité adaptée à cet environnement. Le contrôle de scope, la conception des tokens d'appairage et les surfaces réservées au propriétaire dans les versions 3.12 et 3.13 vont tous dans la bonne direction pour la réalité multi-utilisateurs.

Trois choses à faire ce week-end

Mettez à jour vers la 2026.3.13 si vous êtes sur la 3.12 et que la stabilité mémoire ou le polish opérationnel Docker vous importent. La correction de la régression mémoire du plugin SDK justifie à elle seule cette mise à jour.

Lisez les changements de sécurité et de confiance des plugins de la 3.12 si vous faites tourner un déploiement partagé. Intégrez les décisions de confiance explicites dans votre processus d'onboarding pour les nouveaux workspaces. Mettez à jour votre documentation pour vos coéquipiers.

Construisez quelque chose avec les nouvelles primitives. Une boucle d'agent sensible à la latence utilisant /fast, un orchestrateur interruptible avec sessions_yield, un message de workflow Slack structuré si Slack est votre base. Le travail de plateforme de cette semaine est exactement le type qui fait que les expériences du week-end tiennent dans l'usage quotidien.

La prochaine édition couvrira la semaine se terminant le vendredi 27 mars 2026.

Où faire tourner tout ça

Nous faisons tourner notre gateway OpenClaw sur Hetzner — un CX23 à 4,85 €/mois avec 10 € de crédit à l'inscription. La correction mémoire de la 3.13 rend ce tier à nouveau viable si la 3.12 vous avait poussé dans le swap. Pour un gateway qui reste en ligne, le rapport prix/RAM est difficile à battre.

Si vous préférez ne pas maintenir la stack vous-même, xCloud propose de l'hébergement OpenClaw managé — passez directement à la construction d'agents sans vous battre avec Docker.

Pour les automatisations qui ne nécessitent pas un gateway auto-hébergé complet — ou si vous voulez prototyper des workflows multi-agents avant de vous engager sur l'infrastructure — ClawTrust est une plateforme d'automatisation IA qui mérite le coup d'œil.

(Liens affiliés — nous percevons une petite commission si vous vous inscrivez, sans surcoût pour vous.)