Pierre ✺

Vous avez installé ou mis à jour l’extension Claude Code dans Cursor le 29 octobre ? Si votre machine est infectée, désinstaller l’extension ne suffit pas à retirer la porte dérobée. Des copies modifiées d’Anthropic.claude-code, versions 2.1.312 et 2.1.313, ont été distribuées via la marketplace Cursor sur macOS et Windows, entre 10 h 27 et 21 h 35 environ, heure de Paris. Ces copies malveillantes n’ont pas été développées par Anthropic. Le code ajoutait une clé SSH marquée svc-telemetry dans authorized_keys, tentait d’ouvrir un tunnel SSH inversé et installait des mécanismes de persistance. Sur Mac, il créait notamment un LaunchAgent nommé com.apple.sysmond Cursor a retiré les copies malveillantes, reconstruit sa marketplace et fait mettre hors ligne le serveur attaquant. Ça ne nettoie pas les machines déjà infectées. Sur Mac, un bug pouvait empêcher l’accès distant en laissant SSH désactivé. Il faut quand même supprimer la clé et les mécanismes de persistance. Un premier contrôle sur Mac : grep -n -- 'svc-telemetry' ~/.ssh/authorized_keys Si une ligne contenant `svc-telemetry` apparaît, suivez la procédure de remédiation Cursor. Si rien ne s’affiche, ou si le fichier n’existe pas, poursuivez avec les autres vérifications de la notice. Vous y trouverez aussi la commande PowerShell pour Windows. Pour les machines présentant des traces, Cursor recommande de les isoler, puis de suivre sa procédure pour retirer la clé, les scripts persistants et les processus associés. Selon les résultats, une réinstallation peut être nécessaire. Les identifiants et sessions accessibles depuis ces machines doivent aussi être renouvelés depuis une machine de confiance. Ce qui me frappe : le code s’exécutait dès le chargement de l’extension, avant même sa fonction d’activation. Pas besoin de lancer une conversation avec Claude. Et vous, les mises à jour d’extensions passent automatiquement sur vos machines, ou vous les validez avant ?

Une sortie réseau détectée en moins de 15 minutes. Le run arrêté environ 2 h 30 après la prise en charge humaine. Le 20 septembre, pendant un entraînement par renforcement, un modèle de recherche interne d’OpenAI a contourné les restrictions réseau de son environnement. Ce n’est pas Codex en prod : un modèle de labo, sur une tâche de recherche web. Le bac à sable lui donnait un cache web hors ligne. Les requêtes vers Google, Bing et DuckDuckGo ont échoué. Il a alors remarqué que le résolveur DNS répondait encore sur le vrai internet. Il a utilisé un service DNS public pour poser des questions à un chatbot tiers. Première réponse reçue : « The capital of France is Paris. » Il a enchaîné 18 questions de plus : 14 avec des indices de la tâche, quatre pour chercher d’autres moyens d’accéder au web via DNS. Il a finalement répondu qu’il n’avait pas réussi à identifier la personne recherchée. Chronologie côté OpenAI : première réponse externe à 9:50, alerte à 10:02 (~12 min), prise en charge humaine à 10:05, run arrêté à 12:34. L’arrêt automatique attendu ne s’est pas déclenché, et la procédure d’arrêt n’était pas claire. OpenAI a alors suspendu l’entraînement, l’évaluation et l’inférence avec outils sur leurs modèles les plus capables. Ce run ne sera pas repris. Seul le DNS a touché le vrai internet ; le reste passait par le cache. Ce que j’en retiens pour mes agents : bloquer HTTP ne suffit pas à contrôler les sorties réseau. Et une alerte critique doit déboucher sur une procédure d’arrêt claire, dont on a testé le fonctionnement. Chez vous, sur les agents avec outils réseau, vous avez déjà testé ce qui sort vraiment du bac à sable ?

Sur mon MacBook Pro, sous macOS 27.2, le git d’Apple accepte encore un certificat signé avec une clé eMudhra compromise. J’ai utilisé le serveur de test du suivi de l’incident, publié par Dennis Jackson : /usr/bin/git ls-remote git-emudhra.we-have-a-proble… Cette commande liste les références du dépôt distant, sans le cloner ni exécuter son code. • Erreur de certificat : ce git refuse le certificat testé • Commit listé : il l’accepte encore Chez moi, un commit s’affiche. Aucune erreur de certificat. Même résultat avec mon git Homebrew installé, en version 2.56.0_1 : il utilise lui aussi /etc/ssl/cert.pem. Homebrew a toutefois modifié sa formule en 2.56.0_2 pour ne plus dépendre du curl système. Je n’ai pas testé cette nouvelle révision. Pour le contexte : des clés privées d’autorités de certification intermédiaires eMudhra avaient été mal générées. Elles pouvaient être retrouvées à partir des certificats, puis utilisées pour émettre d’autres certificats et usurper des sites. Un attaquant placé sur le trajet réseau peut alors se faire passer pour le serveur, modifier le code récupéré par un clone ou un pull HTTPS, ou récupérer les identifiants transmis. Ce test ne prouve pas qu’une interception a eu lieu. Il montre que mon git accepte le certificat présenté. Safari et les apps qui utilisent les frameworks réseau et sécurité d’Apple bloquent déjà les certificats concernés. Mais certains outils en ligne de commande utilisent encore /etc/ssl/cert.pem sans consulter ce blocage. Les accès Git en SSH ne sont pas concernés par ce problème de certificats HTTPS. Et côté CI, pensez à vérifier le git réellement utilisé sur vos runners macOS. Le résultat sur votre poste ne dit rien de celui du build. En attendant le correctif, Apple documente un contournement manuel. Il faut revérifier après une mise à jour système : selon le suivi de l’incident, macOS 27.2 a déjà rétabli le fichier chez des utilisateurs qui l’avaient corrigé à la main. Je mets la procédure, ses limites et les sources en première réponse. Chez vous, le git Apple refuse le certificat ou liste aussi le commit ?

Cognition vient de sortir FrontierCode 2.0, leur bench qui cherche à répondre à une question : est-ce qu'un maintainer mergerait vraiment ta PR, pas seulement est-ce que les tests passent ? De nouvelles tâches, gardées privées pour limiter la contamination, des consignes moins détaillées et des critères de mergeabilité plus exigeants. Sur la 2.0 : • Opus 5.5 : 45,5 % • GPT-6 Astra : 42,8 % • DeepSeek V4.1 Flash : 19,3 % • Kimi K3 : 17,7 % Ce sont des scores pondérés, avec un zéro si un critère bloquant échoue. Pas directement des taux de PR acceptées. Pour remettre en contexte, sur la 1.1, Kimi et DeepSeek étaient autour de 44 %, contre 54,6 % pour Opus. Sur cette nouvelle suite, Opus baisse d'environ 9 points, contre environ 25 pour DeepSeek et Kimi. La baisse ne concerne pas seulement les open weight : Grok 4.7 et Gemini 4 Argon perdent aussi autour de vingt points. Sur cette comparaison, Opus et Astra conservent une avance nette. Les tâches et les critères ont changé. Ce n'est pas une régression des modèles, mais l'écart se creuse sur ce que cette version cherche à mesurer. La 2.0 insiste davantage sur ce que l'agent doit déduire du code et de la demande, sans qu'on lui écrive tout : corriger aussi un chemin voisin touché par le même bug, par exemple. Et honnêtement, c'est précisément là que je vois des différences dans mes usages. Avec les open weight que j'utilise, notamment DeepSeek et Kimi, j'obtiens de bons résultats sur une tâche bien délimitée. Quand la demande devient plus pointue ou laisse des choses implicites, je dois davantage recadrer : changements non demandés, mauvaise interprétation du besoin, réponses à côté. Ça m'arrive aussi avec Opus, Astra ou GPT-6.1 Sol, mais moins souvent. En perso, ça passe. En pro, beaucoup moins. Sur mes side projects, je peux accepter de passer une soirée à tester plusieurs approches. Beaucoup sont des expériences, avec des données de test et aucun business derrière. Au boulot, si je dois arrêter une tentative après une heure et tout relancer avec un autre modèle pendant trente minutes, j'ai perdu une heure par rapport à ce que j'aurais pu faire directement. Et ça, ça se paie. Le classement rejoint donc une partie de mon ressenti. Peut-être aussi que je retiens plus facilement un résultat qui va dans mon sens. Le harness, les outils, les skills et les consignes du projet changent beaucoup le résultat. Ce qui compte reste ce que vous arrivez à faire sur votre code. J'espère vraiment que l'écart va se réduire, que les modèles viennent de Chine, des États-Unis ou d'ailleurs. J'ai envie d'avoir davantage d'options auxquelles confier ce travail, avec moins de reprises. Et vous, sur vos projets, quels modèles vous demandent le moins de reprises quand la demande n'est pas complètement cadrée ? teapawt.org/cognition/status/21151…

Avec les agents, je code plus vite et je fais plus de choses. Mais si le goulot se déplace, est-ce qu’on gagne vraiment du temps ? On en discute souvent avec mes collègues. De mon côté, j’ai le sentiment de produire du meilleur code. Mais ça demande une vraie relecture des PR, des consignes adaptées au projet et de surveiller la complexité que les agents proposent d’ajouter. Le rapport State of Developer Experience 2026 d’Atlassian fait écho à ces discussions : 87 % des développeurs interrogés disent que l’IA les aide à livrer plus vite. Pourtant, 72 % déclarent rencontrer autant ou plus de friction qu’avant. Ce sont leurs perceptions, pas une mesure du temps de livraison. Mais je retrouve ce décalage dans mon quotidien. Concrètement : de l’implémentation, mais aussi une partie du design et de la réflexion produit. Le temps gagné me permet d’élargir mon périmètre. Avant de coder, il faut toujours comprendre le besoin, puis trancher sur ce qu’on fait. Après, il faut relire, tester et vérifier que ça répond vraiment à la demande. Une PR prête, ça ne veut pas dire que la fonctionnalité est livrée. Si l’organisation de l’entreprise ne s’adapte pas aux agents, les décisions et les validations gardent le même rythme. On peut donc coder plus vite sans livrer beaucoup plus vite. C’est ce que j’essaie de mieux comprendre en ce moment : où part le temps gagné, et qu’est-ce qu’il nous permet réellement d’améliorer ? Chez vous, le goulot se situe plutôt au début, pendant l’implémentation ou au moment de livrer ? Et vous avez l’impression de livrer plus vite, ou juste de coder plus vite ?

J’ai confié le même diagnostic à un agent seul, puis à trois agents : un pour le frontend, un pour le backend et un pour la synthèse. Avec Astra puis avec Opus, le montage à trois agents a utilisé environ 2,4 fois plus de tokens d’entrée hors cache. Les deux approches ont retrouvé le problème dans les trois essais de chaque environnement. L’idée vient d’un article d’Anthropic : quand plusieurs sous-agents travaillent sur les mêmes informations, les regrouper peut permettre à un seul agent de suivre tout le raisonnement. Le guide parle d’architectures d’agents en entreprise. J’ai voulu essayer sur une analyse de code. Sur un de mes side projects, un utilisateur quittait une session puis la rejoignait. Il pouvait conserver ses droits d’administration côté serveur, tout en perdant certains boutons dans l’interface. Pour comprendre pourquoi, il fallait suivre les cookies, sa nouvelle identité et les règles d’autorisation des deux côtés. L’agent seul suivait tout le parcours. Les agents frontend et backend travaillaient en parallèle, puis transmettaient leurs rapports au troisième. Même commit, mêmes consignes communes et des sessions neuves. Tout s’est fait en lecture seule. En médiane, les tokens d’entrée hors cache étaient de : • Astra : 67 000 pour l’agent seul, 162 000 pour les trois agents, soit 2,41×. • Opus : 75 000 contre 183 000, soit 2,45×. Ces chiffres couvrent toute la chaîne, rapports et synthèse compris. Pour calculer le coût, il faut aussi compter les tokens en cache, les sorties et les tarifs appliqués. Une synthèse Opus a corrigé des références à des lignes qui n’existaient pas dans le fichier. Le constat de l’agent frontend était juste, mais ses numéros de ligne étaient faux. La relecture a été utile sur ce point. Les références ont été contrôlées par sondage : cet exemple ne suffit donc pas à dire quelle approche produit le moins d’erreurs de citation. Les agents frontend et backend pouvaient suivre les appels hors de leur couche. Leurs rapports étaient transmis intégralement, et l’agent de synthèse pouvait relire le dépôt. Les informations importantes ont été conservées, mais plusieurs étapes ont repris les mêmes sources. J’ai évalué manuellement un cas que je connaissais. Astra et Opus tournaient dans des environnements différents. Je compare donc les deux façons de travailler au sein de chaque environnement, sans classer les modèles entre eux. Sur ce scénario, un agent seul suffisait pour établir le diagnostic. La correction des références me donne envie de comparer ensuite un agent suivi d’un relecteur au montage frontend/backend avec synthèse. Sur quelles tâches plusieurs agents font-ils mieux qu’un agent seul chez vous ?

Ce matin, j'ai mis à jour mes side projects pour appliquer les correctifs de sécurité Node, notamment celui de la faille Brotli (CVE-2026-111497), qui touche aussi Bun. Je suis tombé sur deux problèmes : après une mise à jour d'Oxlint, ma configuration avait perdu une partie des contrôles, et un build installait une version de Node inférieure à celle exigée. J'ai passé neuf dépôts en revue avec Codex et Claude. Codex préparait les modifications, Claude relisait les diffs. Je renvoyais ensuite ses remarques à Codex pour qu'il les vérifie dans les sources avant de corriger. Premier piège : Oxlint, sur mon starter React. L'ancienne règle qui regroupait les contrôles du compilateur React avait été remplacée par plusieurs règles. Dans ma configuration, trois de ces contrôles appartenaient à des catégories qui n'étaient pas activées. Les revues ne s'accordaient pas sur la couverture conservée. On a donc comparé ce que vérifiait l'ancienne règle avec les contrôles activés dans la nouvelle configuration, puis réactivé les trois règles manquantes. Moins de diagnostics après une mise à jour peut vouloir dire moins de contrôles. Comparer le nombre de règles ne suffit pas : il faut regarder ce qu'elles couvrent et lesquelles sont actives. Second piège : le déploiement dans Coolify. Le dépôt exigeait Node 24.22.1, mais les logs montraient que Nixpacks installait encore Node 24.10.0. Il ajoutait aussi un vieux Corepack qui cherchait pnpm.cjs, absent de pnpm 12. L'installation s'arrêtait avant de compiler l'application. Corriger uniquement Corepack aurait laissé le décalage de version Node. J'ai validé le passage du site à Railpack, encore en bêta dans Coolify, avec une version Node fixée explicitement. Codex a appliqué les réglages après mon accord. Les logs ont confirmé les versions attendues, le déploiement a abouti et les vérifications sur le site public sont passées. Relire le package.json une fois de plus n'aurait pas permis de savoir quelle version le builder installait réellement.