Pierre ✺

Ton agent tourne sur un serveur, mais il peut utiliser le navigateur de ton Mac avec tes sessions déjà ouvertes. C’est ce que propose OpenCode Browse : l’agent et le navigateur n’ont pas besoin d’être sur la même machine. Prenons un exemple : un agent corrige un formulaire sur un serveur de développement. Tu lui demandes ensuite de vérifier le résultat sur un environnement de test accessible depuis ton navigateur. Il peut ouvrir la page, remplir les champs, cliquer sur le bouton et regarder le résultat, en utilisant ta session existante. Tu n’as pas à recréer une connexion dans un navigateur séparé juste pour ce test. Pour faire le lien : • côté agent, un serveur MCP fournit les outils et un relais transmet les commandes • côté navigateur, une extension reçoit ces commandes et les exécute MCP permet de connecter cet outil à différents agents, dont OpenCode, Claude Code, Codex et Cursor. L’extension est prévue pour les navigateurs basés sur Chromium, notamment Chrome, Edge et Brave. L’agent peut ouvrir ses propres onglets en arrière-plan. Tu peux aussi lui confier un onglet déjà ouvert depuis le bouton de l’extension, puis le reprendre quand tu veux. Si une étape demande ton intervention, une connexion, une double authentification ou un paiement par exemple, un mécanisme permet à l’agent de te rendre la main. Tu fais l’étape, puis tu cliques sur Continue pour qu’il reprenne. Si l’agent tourne sur un serveur distant, il faut appairer le navigateur avec le relais qui tourne à côté de l’agent. La documentation recommande de passer par un réseau chiffré, comme Tailscale ou WireGuard : Browse ne chiffre pas lui-même cette liaison. Le navigateur reste sur ton ordinateur, mais les informations que l’agent lit peuvent être envoyées au fournisseur de son modèle. On lui donne aussi accès à une session déjà connectée. Une page malveillante peut tenter de le détourner en lui donnant d’autres instructions. Browse permet de limiter les domaines vers lesquels les onglets d’une session peuvent naviguer. Cela réduit le périmètre, sans empêcher une tentative d’injection sur un site autorisé. Ce qui m’intéresse ici, c’est de pouvoir garder le travail de l’agent sur un serveur tout en reprenant facilement la main dans mon navigateur quand il en a besoin. Vous utilisez quoi pour donner un navigateur à vos agents ?

Plusieurs agents, une seule mémoire, et 28 % des infos qui disparaissent. Anthropic a testé ça : des agents remplissaient en même temps une table de contrats. Ils résumaient mal certaines clauses et écrasaient le boulot des autres. Au final, le rapport ne contenait que 41 faits sur 57. Ils ont changé les consignes : une page par contrat, un seul agent par page, et les clauses copiées telles quelles. Là, les 57 faits y étaient. C'est un problème assez concret quand on commence à partager une mémoire entre plusieurs agents : qui peut écrire où, et qu'est-ce qui se perd au passage ? Anthropic appelle ça le « dreaming » : entre deux sessions, l’agent reprend l’historique pour vérifier ses notes, corriger les erreurs et faire du tri dans sa mémoire, sans modifier le modèle lui-même. Sur les documents internes de Stainless, une entreprise rachetée par Anthropic, la recherche seule atteint 53 % des critères évalués. Avec le wiki enrichi au fil de 128 sessions, le score monte à 61 %, en économisant environ 20 000 tokens par question. Ça reste une évaluation de 25 questions. Et les économies à la consultation doivent être mises en face du coût de construction et d'entretien du wiki. Sur une tâche juridique où l'information se trouvait surtout dans un seul document, le wiki n'apportait aucun gain clair. Dans un autre cas, il devenait même plus gros que les documents d'origine. Pour mon Second Brain en Markdown, j'aimerais tester une passe d'entretien : • retrouver la source derrière une règle • distinguer une hypothèse d'un fait vérifié • corriger ou retirer les notes périmées • éviter que plusieurs agents réécrivent le même document en parallèle • garder un petit index et aller chercher les détails au besoin Je garderais de la souplesse dans ces consignes : Anthropic observe aussi que trop contraindre ce qu'un agent doit mémoriser peut dégrader ses résultats. Je veux pouvoir savoir d'où vient une note et pourquoi l'agent la croit encore vraie. Et vous, comment vous faites le tri dans la mémoire de vos agents ?

À partir d’aujourd’hui, plusieurs modèles Grok sur l’API ajoutent un watermark par défaut. Le marquage s’applique aussi aux réponses JSON et aux paramètres générés pour appeler des outils. Le détail utile pour les devs : le header HTTP `x-watermark` indique si la réponse a été générée avec ce marquage. `true` signifie oui ; une autre valeur ou l’absence du header signifie non, d’après la documentation. Ce marquage ne consiste pas à ajouter des caractères invisibles. Il influence légèrement le choix des tokens pendant la génération. La détection est statistique : elle peut conclure « watermarké », « non watermarké » ou « incertain ». Les textes longs donnent un signal plus fort. L’accès au détecteur se demande séparément : lire le header d’une réponse et analyser un texte quelconque sont deux opérations différentes. Les admins peuvent désactiver le watermark modèle par modèle, pour toute l’équipe. Certains modèles peuvent être verrouillés. La désactivation demande de confirmer qu’une exception juridique s’applique. SpaceXSI présente ce dispositif comme une mesure de conformité à l’AI Act européen. Vous conservez déjà les headers utiles de vos appels LLM, ou seulement le texte et le nombre de tokens ?

290,2 Mo de RAM, avec deux comptes connectés. C’est ce qu’affiche une capture partagée par le CTO de Discord pour Discord Phoenix, la version en développement. Discord reconstruit ses apps en Rust pour remplacer Electron sur desktop et React Native sur mobile. Et c’est surtout la façon de partager le code entre les plateformes qui me parle. Discord construit une couche UI commune, avec GPUI sur desktop, des vues natives sur mobile et du HTML dans le navigateur. La logique web sera compilée en WebAssembly. Les webviews restent utilisées pour les contenus embarqués, comme YouTube ou les Activities. GPUI est le framework accéléré par GPU développé par l’équipe de Zed. Discord y ajoute ses propres patchs. Sur mobile, l’API s’en inspire, mais le fonctionnement se rapproche de React Native : le code Rust pilote les vues natives d’iOS et d’Android. Discord a aussi partagé des comparaisons côte à côte sur Windows et Android. La capture mémoire n’est pas une comparaison avec le client actuel dans les mêmes conditions, et les vidéos restent des démos. Les tests utilisateurs sont annoncés sans date précise. Moi qui travaille surtout en TypeScript, c’est ce compromis qui me fait réfléchir. Partager du code via JavaScript, c’est pratique, mais les apps desktop et mobile gardent un runtime JS, et Electron embarque aussi Chromium. Discord conserve le partage de code, mais passe par Rust et construit ses propres couches UI. Le prix : maintenir ces outils et retrouver toutes les fonctionnalités de l’app actuelle. D’après son CTO, l’équipe utilise déjà Rust depuis 2018 pour son infrastructure, sa technologie vocale et certaines parties du client. Ça compte avant de se lancer dans une réécriture pareille. Vous partageriez seulement la logique entre desktop, mobile et web, ou aussi une couche UI commune ?

OpenAI a tendu un piège à son nouveau modèle de sécurité : à côté de la cible, des services faciles à compromettre. Le modèle avait le droit de s’en servir, pas de les exploiter. Sans le prompt de déploiement, GPT-5.6 Cyber les exploitait plus d’une fois sur 20. GPT-6 Cyber, environ une fois sur 1 400. C’est l’un des tests de GPT-6 Cyber, annoncé hier par OpenAI. Avec le prompt de déploiement, aucune exploitation hors périmètre n’a été observée pendant le test. À noter : aucune exploitation hors périmètre n’a été observée pour GPT-6 Astra, le modèle généraliste, même sans le prompt de déploiement. Pour moi, c’est le vrai sujet de l’annonce. Un agent qui cherche des failles doit aussi respecter les règles d’engagement. Ces résultats sont encourageants, mais ils ne dispensent pas de limiter ses accès et de surveiller ses actions. Côté capacités, OpenAI rapporte : • ExploitGym : 48,5 %, contre 32,1 % pour GPT-5.6 Cyber. • Noyau Linux : 1 724 vulnérabilités reproduites, des exploits fonctionnels pour 948, et 304 findings critiques transmis aux mainteneurs. • Firefox : 81 vulnérabilités inédites, classées haute sévérité par Mozilla. OpenAI le classe « Critical » en cybersécurité dans son Preparedness Framework, contre « High » pour GPT-5.6 Cyber. Côté garde-fous : liste d’IP autorisées par défaut sur l’API et surveillance des actions hors autorisation. A voir aussi ce que ça apporte à la review de code. CodeRabbit a comparé son pipeline avec et sans Cyber : 22 failles connues retrouvées sur 33, contre 19. Les rapports contiennent aussi 66 % de signalements high et medium supplémentaires. CodeRabbit précise lui-même qu’il reste à vérifier combien sont de vraies vulnérabilités. C’est une distinction importante : davantage d’alertes, ça peut aussi être davantage de travail pour l’équipe. Je veux surtout savoir combien de failles supplémentaires méritent réellement une correction. Pour l’instant, l’accès reste limité à une sélection de clients Daybreak Red. OpenAI annonce une ouverture progressive à tous les clients Red « bientôt », sans date précise. Mais la question du périmètre se pose déjà avec les agents qu’on utilise tous les jours. Vous donnez un périmètre écrit à vos agents, comme on le ferait pour un pentesteur ? Sources en réponse pour aller plus loin ↓

ChatGPT, Claude, Muse et Grok Bot peuvent maintenant écrire dans la même mémoire Notion et réutiliser les mêmes skills. L’idée : les préférences, les décisions et le contexte projet ne restent plus coincés dans un seul chat. Les agents connectés retrouvent une mémoire personnelle, éditable, et une bibliothèque partagée de skills. De mon côté, j’ai déjà un Second Brain : des fichiers Markdown versionnés sur Git, accessibles à mes différents agents. J’y conserve mes notes, le contexte de mes projets et mes journaux de travail pour retrouver ce qui a été fait et reprendre là où je m’étais arrêté. Notion propose de le faire via MCP. On connecte chaque agent au même compte et au même workspace, puis on lui donne les consignes pour consulter et alimenter cette mémoire. Les skills restent aussi récupérables avec leur fichier SKILL..md et leurs fichiers associés. Pas besoin de tout réécrire pour les utiliser ailleurs. Pour quelqu’un qui utilise déjà beaucoup Notion, cette intégration pourrait éviter de maintenir un dépôt séparé juste pour ce contexte. Les agents peuvent le consulter et l’enrichir directement dans Notion, et on peut le relire ou le corriger sans passer par Git. La mémoire aide l’agent à comprendre le projet, mais le code et la configuration du repo restent la référence sur son fonctionnement réel. Vous utilisez quoi pour partager le contexte entre vos agents ?

OpenAI rachète Pierre. Non, pas moi (malheureusement) 😅. OpenAI annonce le rachat de Pierre Computer Company. Si tu as déjà navigué des fichiers ou relu un diff dans l’app Codex, tu as déjà utilisé leurs libs Trees et Diffs. C’est la suite logique de Pando, le backend Git qu’ils ont présenté cette semaine pour encaisser le volume des agents. Là, ils récupèrent l’équipe qui soigne l’autre bout du workflow : lire, comparer et corriger le code produit en parallèle. Pierre, c’est aussi Code Storage, un service pour stocker du code et son historique via Git (déjà utilisé par Lovable, Bolt ou Amp), et Highlights, un syntax highlighter rapide. Le mode Edit de Diffs permet de corriger une ligne directement dans le diff. Une fois le rachat finalisé, l’ambition affichée est de faire évoluer la gestion du code pour le travail avec des agents. OpenAI promet de garder les projets open source et de continuer à y contribuer. Les clients pourront continuer à utiliser Code Storage après le rachat, pendant l’intégration de ses fonctionnalités dans Codex. L’opération reste soumise aux conditions habituelles et aux autorisations réglementaires. Avec Pando puis Pierre, OpenAI s’occupe aussi de tout ce qui vient après la génération : stocker, comparer et relire le code. Vous faites encore vos reviews dans GitHub/GitLab, ou de plus en plus directement dans votre outil de dev ?

J’ai un agent qui écrit et un agent qui relit. Mais est-ce qu’ajouter un agent améliore toujours le résultat ? @BHolmesDev teste une review déclenchée selon le risque : un second agent cherche les failles quand les effets du patch ne sont pas évidents à la lecture. Si le changement est simple, pas de second agent. Il reste à mesurer ce que ça apporte en qualité et en coût. Sur Reddit, un développeur rapporte 81 % de réussite pour Opus 5.5 seul, à 1,20 $ par tâche. Avec DeepSeek V4.1 Flash chargé d’écrire le code : 67 %, pour 1,29 $. Sur ce test, le montage « économique » coûte environ 30 % plus cher par tâche réussie. Test sur 12 tâches difficiles, trois passes par config. Il teste le fait de confier l’écriture à un autre modèle, pas l’apport d’un relecteur. Dans mon workflow, Codex prépare et Claude relit. Ça marche quand la revue a un vrai brief : le risque, les zones à examiner, ce qu’il faut essayer de casser. Un sous-agent moins cher peut coûter plus cher. Avant d’en ajouter un à la chaîne, je veux savoir ce qu’il améliore. Vous mesurez comment le gain de vos pipelines multi-agents ? Sources en réponse.

Comment prouver quel modèle répond derrière un routeur d’API ? Anthropic propose un prototype, testé sur Llama 4 Maverick : FlashProve. Le principe : le fournisseur publie une empreinte cryptographique qui l’engage sur des poids précis, puis fournit une preuve vérifiable sans dévoiler ces poids. Le routeur peut transmettre la preuve au client, qui la vérifie avec une empreinte de confiance pour le modèle annoncé. Les chiffres sur Llama 4 Maverick (MoE de 400 milliards de paramètres, quantifié en 4 bits) : • Environ 19 Mo par preuve dans le test de référence, qui vérifie le token suivant après 1 024 tokens de contexte. • Une vingtaine de secondes pour vérifier une preuve sur CPU. Pour situer le progrès : sur le même modèle, VerInf produisait des preuves de 93,6 Go, vérifiées en près d’une journée. VerInf et FlashProve n’ont pas été testés sur les mêmes machines ni avec les mêmes méthodes. Les temps de vérification ne sont donc pas directement comparables. Les limites : • Produire les preuves coûte environ 70 à 95 fois le temps GPU du prétraitement des prompts avec vLLM, dans les configurations comparées. • FlashProve vérifie une version du modèle qui calcule en nombres entiers et choisit toujours le token le plus probable. Une réponse issue d’une stack d’inférence classique peut différer et échouer à la vérification. Une intégration expérimentale avec un vLLM adapté est documentée. Vu le surcoût actuel, je regarderais d’abord cette approche pour des audits ponctuels ou des appels critiques. Vous avez déjà une méthode pour vérifier que votre routeur sert bien le modèle annoncé ? Sources en réponse.

Anthropic reconnaît, dans un dépôt à la SEC, avoir déjà détecté après coup une accélération importante de son rythme de développement. C’est dans son S-1/A du 2 novembre, le dossier préparant son introduction en Bourse. Dans le même passage, elle estime que ses futurs modèles pourraient très bientôt atteindre le seuil de sa Responsible Scaling Policy sur l’accélération des progrès de l’IA. Ce seuil vise une forte accélération des capacités, attribuable à l’automatisation de la recherche et de l’ingénierie. Anthropic rattache ce risque à ce qu’on appelle l’auto-amélioration récursive, ou RSI. Quelques précisions : → l’estimation porte sur ses futurs modèles, aucun modèle actuel n’est déclaré au-dessus du seuil → « très bientôt » reste une estimation interne, sans date précise → ces affirmations viennent de l’entreprise, dans un document destiné aux investisseurs Anthropic ne pense pas pouvoir laisser Claude concevoir et construire seul les générations suivantes en toute sécurité, sans supervision ou compréhension humaine réelle, même si l’automatisation complète devient techniquement possible. Elle envisage de modifier sa politique pour maintenir ce contrôle. Garder des humains dans la boucle suppose qu’ils aient l’information à temps pour intervenir. Quels signaux permettraient de ralentir ou de renforcer les contrôles avant de pouvoir confirmer l’accélération ? Sources en réponse 👇