Terminal d’abord · postes worktree · boucles supervisées · agents.md + MCP · Mac distant
En 2026, la première fenêtre qui s’allume sur votre poste n’est plus l’IDE. Ce sont trois terminaux : Claude Code, Codex CLI et Antigravity CLI, chacun avec sa propre session. Cet article ne fait pas de chronologie ni d’actualité. Il répond à une seule question : à quoi ressemble vraiment la journée d’un développeur aujourd’hui ? Et lorsque les worktrees parallèles, les boucles longues /goal et MCP + agents.md poussent l’ordinateur portable jusqu’à ses limites, pourquoi un Mac distant haute performance devient-il le nouveau poste principal ? À lire en complément : Mac Mesh × collaboration AI Agent et Git Worktree, branches parallèles.
L’ordre de démarrage du matin s’est inversé en 2026. Le terminal s’ouvre en premier, l’IDE ensuite. Dans le terminal, claude, codex et antigravity tournent en sessions distinctes, chacune épinglée à un dépôt. Dans le navigateur, un onglet PR GitHub et une URL de staging. L’IDE occupe le second écran et sert de surface pour le diff et les retouches d’interface.
La raison n’est pas une affection pour la console. La scène principale est passée de l’écriture du code à la direction des agents qui écrivent le code. Les agents vivent nativement dans le shell : ils lisent le dépôt, exécutent les commandes, éditent les fichiers, lancent les tests, sans pont logiciel. L’IDE n’est pas mort ; il est devenu un acteur secondaire pour la visualisation et la revue.
La répartition de la journée bouge en conséquence. Hier : 80 % de frappe, 20 % d’exécution. Aujourd’hui : environ 30 % d’écriture d’intention, 30 % de revue de diffs, 30 % d’exécution et lecture de tests, 10 % de code à la main pour les rares points qui nécessitent encore un humain. Le développeur devient reviewer et tech lead ; les agents jouent le rôle d’une équipe junior réactive.
Terminal d’abord : lancer Claude Code, Codex et Antigravity CLI ; épingler chaque session au cwd du dépôt. L’IDE va sur le second écran pour le diff et la revue.
Une session, un poste : chaque session vise un seul objectif (refactor, bug, tests, migration). Mélanger deux tâches pollue le contexte.
Aligner l’intention en premier : la première consigne du jour est souvent « lis le README, le modèle de PR et les changements des deux dernières semaines, puis résume l’objectif ».
L’IDE pour ce que l’œil fait mieux : lire un long diff, ajuster une UI, poser un point d’arrêt. Le clavier principal n’est plus là-bas.
Ne plus empiler les plugins : les capacités arrivent dans l’agent via agents.md et les serveurs MCP. La configuration de l’IDE devient plus légère, pas plus lourde.
En 2026, le développeur n’écrit pas du code dans un terminal ; il y dirige ceux qui écrivent le code.
Une session ne fait qu’une chose à la fois. C’est là que le premier goulot apparaît. La solution existe déjà dans git : les worktrees. Un même dépôt peut extraire plusieurs branches dans des répertoires distincts, en partageant un seul .git. Chaque worktree appartient à un agent. Refactor, tests, migration, documentation, expérimentation : tout avance en parallèle. Les conflits ne se produisent plus pendant l’édition ; ils attendent le merge.
| Dimension | IDE traditionnel, un seul poste | Agents AI + worktrees, plusieurs postes |
|---|---|---|
| Tâches en parallèle | 1 | 3 à 5 (refactor, tests, migration, documentation, expérimentation) |
| Action principale | Éditer, sauvegarder, exécuter | Envoyer l’intention, lire le diff, approuver, fusionner |
| Apparition des conflits | Pendant l’édition d’un même fichier | Au merge, exposés par git |
| Boucle de retour | Humain → code → tests → humain | Humain → agent → code → tests → agent → diff → humain |
| Charge locale | Faible (un processus) | Forte (plusieurs builds et tests parallèles) |
| Goulot réel | Frappe et réflexion | CPU, RAM, IO disque du poste |
L’intérêt va au-delà de la vitesse brute. Ce qui compte, c’est l’endroit où va l’attention. Au lieu de fixer un curseur, on circule entre cinq worktrees comme un tech lead qui supervise cinq ingénieurs. Quand un agent cale, dérive ou en fait trop, un message court suffit. On reprend rarement le clavier à sa place.
Astuce : les worktrees sont aussi le bon moyen d’isoler les artefacts de build (iOS DerivedData, caches Gradle). Sans eux, les agents en parallèle polluent le même cache. Retours d’expérience : Git Worktree, branches parallèles.
Ce qui change vraiment le rythme, ce n’est pas « l’agent écrit plus », c’est « l’agent sait quand il a fini ». La commande /goal de Claude Code et son équivalent côté Codex attachent à une session une condition d’achèvement vérifiable. Après chaque tour, un petit modèle évaluateur vérifie la condition. Si elle n’est pas remplie, l’agent continue ; si elle l’est, la main vous revient.
Cas réel : avant le déjeuner, vous tapez « objectif : npm run test:e2e tout vert ; diff PR < 500 lignes ». Vous quittez le poste. En revenant, le diff est prêt pour PR. L’agent a fait six tours, corrigé trois cas flaky et reverté un changement d’API inutile. Voici une boucle supervisée minimale en six étapes, qui fonctionne avec la plupart des agents CLI :
Rédiger la condition en une phrase : quelle commande, quel output, quel seuil. Exemple : « pnpm test vert et lint zéro avertissement ».
Poser les limites : répertoires modifiables et fichiers intouchables (migrations/, .env, secrets de production).
Lancer la boucle : émettre /goal "..." ou la commande équivalente. L’agent lit, modifie, exécute, regarde l’output et itère.
Prévoir un checkpoint : tous les N tours ou X minutes, l’agent ajoute un résumé « fait / à faire » dans un Markdown que vous parcourrez d’un coup d’œil.
Intervenir avec parcimonie : en cas de blocage, de dérive ou de tentative de franchir une limite. Un message recalibre, la boucle continue. Ne reprenez pas le clavier.
Une revue avant merge : relisez le diff PR d’un seul tenant, laissez vos commentaires, faites tourner un dernier passage et fusionnez.
git worktree add ../proj-fix-flaky fix/flaky-e2e
cd ../proj-fix-flaky
claude
> /goal "pnpm test:e2e tout vert ; ne pas toucher migrations/ ;
diff < 500 lignes ; ajouter le progres a PROGRESS.md tous les 3 tours"
# Quittez le poste pour le dejeuner ou une reunion.
# Revenez, lisez PROGRESS.md et git diff main, validez ou recadrez.
Le vrai déplacement concerne l’attention. Avant, il fallait rester au poste. Aujourd’hui, on peut confier une tâche de 30 à 60 minutes à un agent et utiliser ce temps pour ce qui a du levier : lire une spec, dessiner une architecture, s’aligner avec le produit. On revient au checkpoint. Le temps du développeur devient, pour la première fois, une ressource planifiable.
Le socle réel du nouveau workflow n’est pas une échiquier d’extensions IDE, mais un dossier de Markdown et un protocole. CLAUDE.md, agents.md et .cursorrules sont des manuels de projet destinés aux agents : conventions d’équipe, commandes de build, frontières de répertoires, garde-fous de sécurité, pièges récurrents. Écrits une fois, tous les agents en profitent. MCP (Model Context Protocol) fait la même chose pour les outils — bases de données, navigateurs, API internes, suivi de tickets — en les transformant en capacités appelables directement par l’agent et réutilisables entre outils.
| Fichier ou protocole | Public principal | Contenu typique |
|---|---|---|
| CLAUDE.md | Claude Code | Contexte du dépôt, commandes de build, points d’entrée des tests, répertoires à ne pas toucher |
| agents.md | Convention transverse adoptée par de nombreux agents CLI | Le point d’entrée standard pour présenter le dépôt à un nouvel agent |
| .cursorrules | Cursor / Cursor cockpit | Style d’édition, conventions de nommage, limites de répertoires |
| Répertoire skills / commands | Chaque agent CLI (commandes personnalisées) | Flux récurrents emballés en /deploy, /release |
| Serveur MCP | Tout client compatible MCP | Requêtes BDD, automatisation navigateur, API internes, systèmes de tickets |
Cette couche bien construite offre à l’équipe un « cerveau partagé ». La première tâche d’un nouveau collaborateur n’est plus de lire le wiki ; c’est de demander à un agent qui a lu agents.md de présenter le dépôt. Changer une convention de nommage ne demande plus de courrier interne ; une ligne dans .cursorrules ferme la boucle dès le lendemain. Brancher une nouvelle base de données ne réclame plus un nouveau script ; un serveur MCP suffit. Les règles de l’équipe passent de la mémoire humaine à la mémoire machine.
Attention : ne mettez jamais de secrets ni de chaînes de connexion de production dans CLAUDE.md ou agents.md. Ces fichiers entrent intégralement dans le contexte de l’agent, ce qui équivaut à les publier. Les secrets passent par injection à l’exécution via un serveur MCP, ou restent dans .env avec une consigne explicite « ne pas lire ».
Le workflow paraît élégant. La facture matérielle, elle, ne l’est pas. Worktrees parallèles, longues boucles /goal, QA navigateur headless et inférence locale sollicitent en même temps CPU, GPU/ANE, RAM et IO disque. Un portable ordinaire passe vite en plein ventilateur, batterie faible et SSD plein. Voici quelques repères pour savoir si votre poste tient le coup :
node_modules, DerivedData ou caches Gradle pour 10 à 40 Go. Avec les images Docker et les poids de modèles locaux (4 à 20 Go pièce), 1 To de SSD est le plancher. En dessous, c’est plein en une semaine./goal longues durent 30 minutes à plusieurs heures. Fermer le capot, couper l’alimentation ou déclencher une mise à jour OS casse la boucle. L’atout « pas d’interruption » d’un nœud toujours en ligne est doux mais très important.Une fois la facture posée, la conclusion est nette : le maillon faible n’est ni le modèle ni l’outillage, c’est la machine qui porte la charge. Le portable reste pertinent comme « client léger » pour écrire l’intention, lire les diffs et approuver les merges. Les charges lourdes — worktrees parallèles, boucles longues, QA headless, caches et builds — gagnent à vivre sur un Mac haute performance distant doté de RAM généreuse, de stockage rapide et d’un refroidissement soutenu. Forcer le portable à tout porter, c’est cumuler throttling, bruit et runs perdus. Pour des workflows iOS CI/CD et des agents AI tournant en continu en production, la location de Mac Mini dans le cloud VpsMesh est souvent le meilleur choix — nœuds dédiés, ressources prévisibles, accès SSH ou bureau distant immédiat, sans amortissement ni entretien matériel. Spécifications et tarifs sur la page des tarifs, mise en place dans le centre d’aide.
Non. L’IDE reste la meilleure surface pour le design UI, le débogage par points d’arrêt et la revue visuelle des diffs. Ce qui a changé, c’est qu’il est passé du lieu où l’on écrit le code à un volet secondaire pour la revue ; la scène principale s’est déplacée vers les agents AI dans le terminal. Le tableau d’ensemble : Mac Mesh × collaboration AI Agent.
Les worktrees parallèles, les longues boucles /goal, le QA navigateur headless et l’inférence locale sollicitent en même temps CPU, GPU/ANE, RAM et IO disque. Les portables limitent leur fréquence et leurs ventilateurs hurlent. Un Mac distant M4 Pro ou Max, avec plus de RAM, du stockage rapide et un refroidissement soutenu, absorbe la charge ; le portable reste un client léger pour les diffs et les décisions. Tarifs : page des tarifs.
Les trois sont des manuels de projet pour agents. CLAUDE.md vise Claude Code, .cursorrules cible Cursor, agents.md est une convention transverse adoptée par un nombre croissant d’agents CLI. Ils peuvent coexister, chaque outil lit ce dont il a besoin. Commencez par un seul agents.md comme point d’entrée universel, puis ajoutez un fichier spécifique pour l’outil principal. Mise en place dans le centre d’aide.