OpenClaw 3.8 : ACP Provenance, recherche Brave et pourquoi la vitesse est un signal

OpenClaw 3.8 est une livraison plus modeste que la 3.7. Moins de lignes modifiées, moins de puces dans le changelog. Mais il y a une fonctionnalité ici dont l'importance dépasse largement la taille de son diff.

ACP Provenance : vos agents savent désormais qui leur parle

Quand les agents ne parlaient qu'à des humains, l'identité était simple — il y avait un utilisateur de l'autre côté d'une app de chat. Maintenant les agents parlent à d'autres agents. Une instance OpenClaw peut recevoir une tâche d'un pipeline CI, d'un agent d'orchestration ou d'un autre nœud OpenClaw dans un workflow multi-agents. La question « qui a envoyé ça ? » a cessé d'être triviale depuis un bon moment.

3.8 ajoute ACP Provenance — des métadonnées d'ingress optionnelles qui permettent à votre agent de vérifier l'origine des sessions ACP entrantes. Lancez openclaw acp --provenance meta et chaque session entrante portera un contexte d'origine signé avec un ID de trace. Passez à meta+receipt et l'agent injecte un reçu visible dans la conversation, créant une chaîne auditable de qui a déclenché quoi.

Trois modes : off, meta, meta+receipt. Désactivé par défaut — pas de rupture de compatibilité, pas de surcharge surprise. Activez-le quand vous en avez besoin.

Pourquoi c'est le titre

L'identité des agents est le problème non résolu du stack multi-agents. MCP gère l'accès aux outils — « que peut faire cet agent. » ACP/A2A gère la messagerie inter-agents — « comment les agents communiquent. » Mais aucun ne répond à « qui est cet agent, et dois-je lui faire confiance ? »

Le protocole ACP d'IBM et A2A de Google ont fusionné sous la Linux Foundation, avec plus de 100 entreprises derrière le standard unifié. DeepLearning.AI propose déjà un cours dédié. L'industrie converge vers l'interopérabilité des agents, et la vérification d'identité est la pièce manquante dont tout le monde a besoin.

ACP Provenance d'OpenClaw est un premier pas, pas la réponse finale. Le problème complet de l'identité n'est pas résolu — il n'existe pas encore d'autorité de certification pour les agents, ni de passeport universel. Mais c'est un outil pratique dès aujourd'hui : votre agent peut distinguer « requête de mon pipeline CI de confiance » de « requête d'origine inconnue » et agir en conséquence.

Pour les équipes qui font tourner des setups multi-agents, c'est la différence entre « ça marche en démo » et « ça marche en production. »

Brave LLMContext : des résultats de recherche conçus pour l'IA

La recherche web dans OpenClaw renvoyait du HTML brut ou des extraits basiques. Utile pour les humains, laborieux pour les agents. L'agent brûlait des tokens de sa fenêtre de contexte rien que pour parser la structure de la page et trouver la vraie réponse.

3.8 intègre le endpoint LLMContext de Brave. Une fois configuré, la recherche renvoie des fragments pré-extraits avec les métadonnées de source — du contenu structuré conçu pour être consommé par des modèles de langage. Moins de bruit, plus de signal, moins de tokens gaspillés.

Ce n'est pas un changement cosmétique. Pour les agents qui effectuent des recherches web dans le cadre de leur workflow, cela signifie une empreinte de contexte réduite et des résultats plus précis. L'agent obtient ce dont il a besoin sans devoir jouer les parsers HTML.

Podman + SELinux : Linux en entreprise, ça marche enfin tout seul

Si vous avez déjà essayé de faire tourner OpenClaw sur Fedora ou RHEL avec SELinux en mode enforcing, vous connaissez la chanson : erreurs de permission mystérieuses, ajout manuel des labels :Z, fils de forum remplis de conseils contradictoires.

3.8 détecte automatiquement si SELinux est en mode enforcing ou permissive et ajoute les labels :Z corrects aux volumes. Pas d'intervention manuelle. Pas de flags de configuration. Ça marche, tout simplement.

Petit changement. Gros gain de confort pour quiconque travaille dans un environnement Linux d'entreprise — et vu l'adoption croissante d'OpenClaw dans les secteurs réglementés, ça concerne pas mal de monde.

Image Docker : encore plus légère

Les dépendances de développement et les métadonnées de build ont été retirées de l'image de production. Résultat : un pull plus petit, des cold starts plus rapides et une surface d'attaque réduite.

Pas grand-chose à ajouter — c'est le genre de maintenance qui ne fait pas d'article palpitant mais qui s'accumule sur des milliers de déploiements.

La question de la vitesse

Certains disent qu'OpenClaw se met à jour trop vite. C'est une critique recevable si l'objectif est de se caler sur une version et de ne plus y toucher.

Mais prenez du recul et réfléchissez à ce que « trop vite » signifie vraiment pour un projet open source. Ça veut dire que les PR affluent. Que les maintainers passent en revue et mergent. Que le pipeline de contributeurs — ce qui fait réellement tourner l'open source — n'est pas un filet, c'est un torrent.

Un projet open source qui avance assez vite pour qu'on ait du mal à suivre, c'est un projet avec une communauté active derrière. Cette vélocité est un signal. Elle dit que la piste est chaude et que la direction est la bonne.

3.7 a posé les fondations avec ContextEngine. 3.8 commence à combler les trous — identité des agents, recherche plus intelligente, support de plateforme élargi. Le rythme ne ralentit pas. Tant mieux.

Ce qui a changé