Le vibe coding a profondément transformé les habitudes des développeurs : en quelques instructions en langage naturel, des outils d’IA produisent désormais des volumes de code considérables en un temps record. Gain de productivité indéniable, mais aussi source de nouveaux risques — bogues discrets, failles de sécurité, logique opaque. Pour y répondre, Anthropic a lancé ... Lire plus
L'article Claude Code se dote d’un outil de relecture pour maîtriser l’avalanche de code généré par l’IA est apparu en premier sur Fredzone.
Anthropic muscle encore son offre pour les développeurs. Son assistant de programmation Claude Code accueille une nouvelle fonction baptisée Claude Code Review, conçue pour analyser automatiquement les pull requests, détecter les bugs potentiels et remonter des retours exploitables avant la fusion du code. Selon Anthropic, le système déploie plusieurs agents en parallèle pour repérer les […]
L’article Claude Code Review : Anthropic lance une IA capable de relire votre code est apparu en premier sur BlogNT : le Blog des Nouvelles Technologies.
Claude Code tourne en local et c'est son gros avantage car ça permet par exemple d'agir sur votre machine, de lancer des scripts...etc. Mais c'est aussi sa grosse limite car à cause de ça, vous êtes cloué devant votre terminal. J'étais en quête depuis un moment d'une solution et je vous avais déjà parlé de Vibe Companion y'a pas longtemps mais tous ces outils vont disparaitre puisque Anthropic vient de sortir Remote Control, une feature qui transforme claude.ai ou l'app mobile en télécommande pour votre session locale. Comme ça, vos fichiers restent chez vous et seule l'interface voyage.
Votre ordi fait tourner Claude Code normalement, et vous, vous pouvez continuer à lui parler depuis votre iPhone, votre Android, votre iPad ou n'importe quel navigateur Chrome, Firefox, Safari... Pas de serveur exposé, pas de port ouvert, que du HTTPS sortant. C'est plutôt bien foutu vous allez voir !
Bon déjà, un abonnement Pro (Édit : ? on me dit que c'est pas encore actif pour les pro ?) ou Max (pas le choix, les clés API ne marchent pas et les plans Team/Enterprise sont exclus pour le moment). Ensuite, vérifiez que Claude Code est installé et que vous êtes connecté via /login. Acceptez ensuite le "workspace trust" dans votre projet et hop, c'est tout côté prérequis.
Deux options s'offrent à vous ensuite... Soit vous démarrez une nouvelle session dédiée :
Connexionclaude remote-control
Soit vous êtes déjà en train de bosser dans Claude Code et vous tapez /rc (alias de /remote-control). Avec claude remote-control, seule l'URL apparaît... donc appuyez sur espace pour afficher le joli QR code.
3 flags utiles (uniquement avec claude remote-control, pas /rc) : --verbose pour voir ce qui transite, --sandbox pour forcer le mode bac à sable (désactivé par défaut) et --no-sandbox pour le couper si vous l'avez activé dans votre config.
Ensuite, la méthode la plus rapide c'est de scanner le QR code avec votre téléphone. Sinon, copiez l'URL affichée et collez-la dans n'importe quel navigateur. Dernière option, allez sur claude.ai/code et votre session apparaît dans la liste (les sessions actives ont un petit point vert).
Une fois connecté, vous récupérez votre conversation en cours, vos fichiers, votre contexte... tout. Vous pouvez envoyer des messages, voir les résultats, approuver les modifications de fichiers. Bref, comme si vous étiez devant votre terminal, sauf que vous êtes dans votre canapé, votre lit ou en train de pousser le caddie chez Auchan !
Maintenant, si vous voulez que CHAQUE session Claude Code soit automatiquement accessible à distance, tapez /config dans une session Claude Code, puis activez l'option "Enable Remote Control for all sessions". Et voilà, plus besoin d'y réfléchir ! Chaque claude lancé dans un terminal sera pilotable depuis votre navigateur ou l'app mobile.
Vos sessions prennent le nom de votre dernier message (ou "Remote Control session" par défaut), donc utilisez /rename mon-projet-cool pour les retrouver facilement dans la liste sur claude.ai/code.
Sinon, dans Claude Code avec /mobile vous pouvez aussi afficher directement le QR code pour télécharger l'app Claude sur iOS ou Android.
Bon, après c'est pas non plus parfait car déjà, c'est cappé à UNE SEULE session à distance par instance de Claude Code (si vous en lancez une deuxième, la première se déconnecte). Par contre, plusieurs instances dans des terminaux différents peuvent chacune avoir leur session remote. Le terminal doit également rester ouvert (si vous le fermez, c'est fini). Mais bonne nouvelle quand même, si le laptop passe en veille ou que le réseau saute, ça se reconnectera tout seul au réveil. Le piège, c'est si la machine reste sans réseau plus de 10 minutes... là, la session expire et il faudra relancer claude remote-control.
Soyez rassurés quand même côté sécurité c'est propre (uniquement du HTTPS sortant sur le port 443, zéro port entrant et des identifiants éphémères), mais gardez en tête que
Claude Code a accès à votre terminal
donc sauf si vous activez --sandbox, il peut de ce fait exécuter n'importe quelle commande... donc les mêmes précautions qu'en local s'appliquent !
Du coup si vous en avez marre de rester scotché devant votre terminal, maintenant vous savez quoi faire.
Merci à Lorenper !
Claude Code, c'est super puissant... mais faut avouer que dans un terminal, quand l'IA commence à enchaîner les appels d'outils dans tous les sens, on se retrouve vite à lire de la Matrice sans les lunettes de Neo. Surtout si vous tentez le coup depuis un iPad ou un mobile, ça pique.
Mais c'était sans compter sur Companion , un projet open source qui vous colle une interface web par-dessus Claude Code. En gros, au lieu de scroller frénétiquement dans votre terminal comme un hamster sous caféine, vous avez une vraie UI avec des blocs rétractables, de la coloration syntaxique et une vue claire de ce que l'agent fabrique. Ça tourne sur desktop, mobile, tablette... bref, partout où y'a un navigateur. D'ailleurs, si vous préférez une app desktop native , y'a aussi Opcode qui fait le taf.
Le truc trop cool c'est que ça peut gérer plusieurs sessions en parallèle. Vous pouvez donc jongler entre différentes instances de Claude Code, chacune avec ses propres permissions. D'ailleurs, y'a 4 modes de permission : du "je valide tout à la main" au "YOLO bypass all" pour ceux qui aiment vivre dangereusement... et qui n'ont pas installé de plugin de sécurité (on vous aura prévenus).
Chaque appel d'outil (Bash, Read, Write, WebSearch...) est affiché et vous pouvez approuver, refuser ou même éditer les commandes avant exécution. Si vous utilisez des sub-agents, Companion affiche les tâches imbriquées sous le parent. C'est propre.
Et puis y'a ce petit détail qui fait plaisir à savoir une barre de progression colorée qui montre l'occupation de votre fenêtre de contexte avec une estimation du coût en temps réel. Parce que bon, savoir que votre session de debug à 3h du mat' vient de vous coûter l'équivalent d'un kebab, c'est quand même pratique. Mais est ce que ça vous coûte vraiment de l'argent ??? Hé bien le projet utilise le flag un peu caché --sdk-url de Claude Code pour communiquer via WebSocket sur le port 3456.
Et au cas où vous vous demanderiez, pas besoin de clé API supplémentaire puisque ça se branche directement sur votre abo Claude Pro ou Team (même si Anthropic vient d' ouvrir pas mal d'outils aux gratuits ).
Pour l'installer, c'est pas la mer à boire. Faut juste avoir Bun sur votre bécane, et ensuite :
bunx the-vibe-companion
Ensuite vous ouvrez http://localhost:3456 et c'est parti. Pour les bidouilleurs, tout le code est sur GitHub, un bun install dans le dossier companion/web et vous avez votre instance de dev. Après y'a plus qu'à installer
Tailscale
(ou votre propre VPN local) et vous avez accès à votre Claude Code depuis n'importe où.
Attention quand même, le protocole WebSocket est reverse-engineeré, donc si Anthropic change un truc demain... bon, vous voyez le délire, ça peut casser. Et si vous voulez en savoir plus sur les coulisses du protocole MCP d'Anthropic, j'en avais parlé il y a quelque temps. Mais en attendant, ça marche nickel et ça rend Claude Code nettement plus digeste qu'un terminal brut.
Allez jeter un œil !
On nous parle d'agents IA à toutes les sauces depuis deeeees mois mais au final, on se retrouve la plupart du temps avec des outils "stateless" qui perdent le fil dès qu'une session se termine. Heureusement, le projet Personal AI Infrastructure (ou PAI pour les intimes) de Daniel Miessler propose justement de régler ce problème en classant les systèmes IA en 3 niveaux.
Le niveau 1, c'est le chatbot de base type ChatGPT... vous posez une question, il répond, il oublie tout. Le niveau 2, c'est l'agent (genre Claude Code ou Cursor) qui peut exécuter des trucs mais qui ne vous connait pas vraiment. Et le niveau 3, c'est PAI, une infrastructure complète qui observe, planifie, exécute et surtout... apprend de vous.
Concrètement, PAI c'est pas juste une énième surcouche pour votre LLM préféré. C'est un framework (TypeScript, Python, Bash) qui tourne sur Bun et qui structure tout autour de VOUS. Le cœur du truc, c'est ce qu'il appelle "TELOS"... en fait c'est 10 fichiers Markdown (genre MISSION.md, GOALS.md, BELIEFS.md planqués dans votre dossier ~/.claude/) qui définissent qui vous êtes et ce que vous voulez accomplir. Du coup, l'IA ne se contente plus de répondre bêtement, elle comprend pourquoi vous posez la question par rapport à vos projets en cours.
Et y'a un deuxième concept sympa, qui est la séparation propre entre vos fichiers perso (dossier USER/) et l'infrastructure du système (dossier SYSTEM/). Ça veut dire que vous pouvez faire un git pull pour mettre à jour PAI sans écraser ce fichier USER/PREFERENCES.md que vous avez mis 2 heures à peaufiner. Ça parait con dit comme ça, mais quand vous avez passé du temps à peaufiner vos préférences... c'est PAS la même.
Côté mémoire, le système fonctionne sur 3 niveaux (chaud, tiède, froid) pour stocker intelligemment vos infos en fonction de leur fraîcheur. En gros, ce qui est frais et pertinent reste accessible immédiatement, le reste descend progressivement dans les couches inférieures. Attention par contre, faut pas confondre avec un simple fichier de notes... là je vous parle d'un truc qui se met à jour TOUT SEUL à chaque interaction. Et tout ça nourrit l'IA pour qu'elle s'affine au fil du temps sans que vous ayez à tout réexpliquer (parce que soyons honnêtes, c'est CHIANT de re-contextualiser à chaque nouvelle session).
L'architecture est modulaire avec des "Packs" et des "Bundles". Y'a 23 Packs disponibles qui couvrent la génération de code, la recherche d'infos, la gestion de la mémoire... Hop, vous installez le pack voice-system et vous avez un système qui cause façon Jarvis (via ElevenLabs). Et si vous avez besoin de notifications push sur votre téléphone (coucou Clawbot de merde ^^) quand une tâche longue se termine, y'a un pack pour ça aussi, avec ntfy ou Discord.
Le truc qui m'a bien plu dans la philosophie du projet, c'est la hiérarchie stricte : CODE d'abord, puis CLI, puis Prompt, puis Skill. En gros, si un problème peut se résoudre avec un grep ou un script bash de 10 lignes, on ne sort pas l'artillerie lourde. Et si on peut en faire un outil CLI, on ne reste pas sur un prompt de base. Perso, j'aime bien cette approche... ça évite d'utiliser un LLM comme un marteau pour enfoncer tous les clous (sauf que dans la vraie vie, on le fait tous quand même, avouez...).
D'ailleurs, PAI n'est pas réservé qu'aux devs puisque le projet vise aussi les artistes, les managers (pour du suivi d'équipe par exemple), les petits patrons (facturation, marketing...etc) et même monsieur / madame tout-le-monde pour gérer ses finances ou son planning sportif. La v2.5 est sortie il y a quelques jours avec l'exécution parallèle par défaut et des outils de "thinking" améliorés.
Pour installer le bouzin, c'est pas sorcier :
git clone https://github.com/danielmiessler/PAI.git
cd PAI/Releases/v2.5
cp -r .claude ~/
cd ~/.claude && bun run INSTALL.ts
Comptez 5 minutes montre en main (sauf si vous n'avez pas Bun, là faudra l'installer avant avec curl -fsSL https://bun.sh/install | bash). Ça a été développé avec
Claude Code
mais c'est platform-agnostic, ça marche aussi avec Cursor, Windsurf ou OpenCode et le support de modèles locaux accessible via
Ollama
ou llama.cpp est sur la roadmap (vivement que ça tourne 100% en local, perso).
Bref, si vous en avez marre des assistants qui ont la mémoire d'un poisson rouge, PAI est une piste sérieuse. C'est du terminal-first, open source (MIT) et largement plus ambitieux que les wrappers habituels. Bon, faut quand même être à l'aise avec le terminal hein... si vous êtes plutôt team GUI, passez votre chemin.
Merci à Pascal pour l'info !
« Tu es un ingénieur très expérimenté qui effectue une revue de code. Ta tâche est de comprendre si les changements proposés suivent les instructions. »
Ainsi débute un des prompts système que Spotify a définis dans le cadre de son architecture de codage agentique.
L’entreprise avait amorcé sa réflexion à ce sujet en février 2025. Son système Fleet Management automatisait alors déjà une grande partie de la maintenance logicielle. À partir d’extraits de code, il exécutait les transformations à l’échelle dans un environnement GKE et ouvrait les PR sur les dépôts cibles.
Ce mécanisme facilitait des opérations telles que la mise à niveau des dépendances dans les fichiers de build, la mise à jour des fichiers de configuration et le refactoring simple (par exemple, supprimer ou remplacer un appel de méthode). La moitié des PR poussés depuis mi-2024 l’avaient été par ce biais.
Fleet Management était moins adapté aux changements complexes nécessitant de manipuler l’arbre de la syntaxe abstraite d’un programme ou d’utiliser des expressions régulières. Illustration avec le gestionnaire de dépendances Maven. Autant sa fonction principale est simple (identifier les fichiers pom.xml et mettre à niveau les dépendances Java), autant les cas particuliers avaient fait grossir à plus de 20 000 lignes le script de transformation associé. Plus globalement, peu d’équipes avaient l’expertise et le temps adéquats.
La mise en place de l’approche agentique s’est d’abord portée sur la déclaration du code de transformation. Objectif : permettre la définition et l’exécution de changements en langage naturel, en remplacement des scripts de migration déterministes.
Plutôt que de choisir un agent sur étagère, Spofity a conçu un CLI. Celui-ci peut déléguer l’exécution d’un prompt à divers modèles d’IA. Mais aussi exécuter des tâches de formatage et de linting en utilisant MCP, évaluer une diff par LLM as a judge, uploader des logs vers GCP et capturer des traces dans MLflow.
Début novembre 2025, quelque 1500 PR fusionnés étaient passés par ce système. Spotify s’attaquait alors à des opérations telles que :
Spotify disait alors avoir gagné, sur ces tâches de migration, 60 à 90 % de temps par rapport à l’écriture du code à la main. Il se projetait sur l’amélioration du ROI avec la perspective de l’élargissement à d’autres codebases.
En complément à cette démarche sur la migration, les travaux se sont orientés sur un système plus généraliste, capable de remplir des tâches ad hoc. On en est arrivé à une architecture multiagent qui planifie, génère et révise des PR.
Au premier niveau, il y a des agents associés à différentes applications (Slack, Jira, GitHub Enterprise…). L’interaction avec eux, éventuellement additionnée de contexte récupéré sur des serveurs MCP, produit un prompt. Ce dernier part vers l’agent de codage, lui aussi exposé par MCP. Ses actions sont vérifiées par un autre groupe d’agents.
Entre autres usages « satisfaisants », Spotify mentionne la capture de décisions d’architecture depuis des threads Slack et la possibilité, pour les product managers, de proposer des changements simples sans avoir à cloner de dépôts sur leur machine.
Les premiers essais se sont faits avec des agents open source comme Goose et Aider. Appliqués à la migration, ils n’ont cependant pas produit de PR fiables. Spotify a donc construit sa propre boucle agentique superposée aux API de LLM. Principe : l’utilisateur fournit un prompt et une liste des fichiers que l’agent édite en incorporant à chaque étape le feed-back du système de build. La tâche s’achève quand elle réussit les tests ou qu’elle dépasse certaines limites (10 tours par session ; 3 retries).
Cette approche a convenu à de « petits » changements : éditer une ligne de code, modifier un manifeste, remplacer un flag… Mais l’agent restait difficile à utiliser. Le chargement des fichiers dans la fenêtre de contexte reposait sur une commande git-grep. En fonction de pattern de recherche, on pouvait saturer la fenêtre ou au contraire ne pas fournir assez de contexte. L’agent avait de plus du mal avant l’édition de multiples fichiers. Souvent, la boucle atteignait la limite de tours. Et lorsque la fenêtre de contexte se remplissait, l’agent finissait par oublier la tâche.
Dans ce contexte, Spotify a basculé vers Claude Code. Lequel a permis des « prompts plus naturels » tout en apportant sa capacité native de gestion de to-do lists et de création de sous-agents. Il couvre désormais la majorité des PR fusionnés en production.
L’agent initial fonctionnait au mieux avec des prompts stricts structurés étape par étape. Claude Code se débrouille mieux avec des prompts qui décrivent l’état final et laissent de la latitude sur le chemin à suivre.
Spotify constate qu’il peut être utile de dire clairement à l’agent quand il ne doit pas agir. Cela évite des tâches impossibles à réaliser, notamment au cas où on réutilise des prompts entre repos qui n’utilisent pas forcément les mêmes versions de langages.
Fournir des exemples de code influence par ailleurs beaucoup le résultat. Idéalement, on définira l’état souhaité sous forme de tests, l’agent ayant besoin d’un objectif vérifiable pour pouvoir itérer. On s’assurera de surcroît de ne demander qu’un changement à la fois pour éviter l’épuisement de la fenêtre de contexte. Et on n’hésitera pas à demander à l’agent un retour d’expérience à la fin de la session.
Spotify a privilégié les longs prompts statiques, sur lesquels les modèles raisonnement plus simplement.
Une approche alternative consiste à commencer avec un prompt plus court, mais à donner à l’agent l’accès à des outils MCP. Le contexte qu’il peut ainsi récupérer lui permet théoriquement de traiter des tâches plus complexes. Mais il rend aussi son comportement moins vérifiable et moins prévisible.
Pour le moment, Spotify permet à son agent d’accéder à un vérificateur (formatage, linting, tests), à une sélection de sous-commandes Git (pas de push ou de change origin, par exemple) et à un ensemble de commandes Bash (comme riggrep).
Encoder la méthode d’invocation des systèmes de build dans un MCP a été jugé plus simple que de s’appuyer sur des fichiers AGENTS.md. La raison : les configurations de build peuvent être très différents à travers les milliers de repos sur lesquels travaille l’agent. Cela permet aussi de réduire le bruit dans les outputs des outils en les résumant avant transmission à l’agent.
Il arrive que le système échoue à générer des PR. Parfois, il en produit, mais qui ne passent pas le CI ou s’avèrent fonctionnellement incorrects. Parfois, c’est lié à un problème de couverture des tests sur le composant cible. Dans d’autres cas, l’agent va au-delà des instructions ou ne comprend tout simplement pas comment bien exécuter build et tests.
Là interviennent des boucles de vérification qui guident l’agent vers le résultat désiré. Ce dernier ignore tout de leur fonctionnement : il sait simplement qu’il peut y faire appel.
La boucle comprend plusieurs vérificateurs indépendants, exposés – par MCP – en fonction du composant logiciel. Par exemple, le vérificateur Maven ne s’active qu’en présence d’un fichier pom.xml à la racine de la codebase.
L’ensemble permet de faire abstraction d’une grande partie du bruit qui remplirait sinon la fenêtre de contexte. L’agent n’a effectivement pas besoin de comprendre les spécificités de l’appel aux différents systèmes de build ou du parsing des résultats de tests.
Qu’ils aient été ou non déclenchés pendant l’exécution de la tâche, les vérificateurs pertinents s’activent avant toute ouverture d’un PR. Avec Claude Code, cela passe par le hook stop.
Au-dessus de ces vérificateurs déterministes, Spotify a ajouté une couche LLM as a judge. Nécessaire face à la tendance de l’agent à sortir du cadre des instructions.
Le LLM juge évalue la diff du changement proposé et le prompt d’origine. Il s’exécute après les autres vérificateurs. Les métriques internes indiquent qu’il rejette environ un quart des sessions. Pour la moitié d’entre elles, l’agent finit par se corriger.
Spécialisé (il ne pousse pas de code, ne rédige pas de prompts, n’interagit pas avec les utilisateurs), l’agent en est aussi plus prévisible. Et potentiellement plus sécurisé.
Début décembre, Spotify déclarait vouloir étendre son infrastructure de vérification à davantage de plates-formes (au-delà de Linux-x86). Nombre de ses systèmes ont en effet des besoins spécifiques. Entre autres ses applications iOS, qui exigent des hôtes macOS pour une exécution correcte des vérificateurs. L’entreprise a de surcroît des back-ends Arm. Elle compte aussi intégrer son agent plus profondément dans son systèmes de déploiement continu, en lui permettant d’agir sur les CI checks dans les PR. Et développer des évaluations plus structurées favorisant l’exploration de nouvelles architectures agentiques.
Illustration générée par IA
The post Codage agentique : le retour d’expérience de Spotify appeared first on Silicon.fr.
