Jeudi 16 avril 2026, Anthropic publie Opus 4.7. La release s’accompagne d’un billet sur les bonnes pratiques dans Claude Code. Un mot revient, qui n’était pas là sur Opus 4.6 : “délégué”. Anthropic invite à cesser de voir Claude comme un copilote assis à côté de soi, et à le traiter comme un ingénieur à qui on confie un objectif. Le vocabulaire change. Les conséquences pour une équipe tech aussi.
Du copilote au délégué : pourquoi maintenant
Le pair programming, c’est deux développeurs qui se passent le clavier. Quand Opus 4.6 jouait ce rôle, on validait ligne par ligne, on reprenait la main sur les décisions, on suivait le flow. Pour une majorité de cas, ce cadrage allait bien.
Ce qui change avec 4.7 : plusieurs évolutions techniques tirent le modèle vers plus d’autonomie.
L’adaptive thinking devient le seul mode de reasoning. Plus besoin de réserver manuellement un budget de thinking : le modèle ajuste à la volée selon la complexité. C’est moins une feature, plus un parti pris produit : Anthropic déclare en retirer la télécommande humaine.
Le niveau d’effort xhigh devient le défaut dans Claude Code. Il est calibré pour les tâches longues et complexes, celles où l’utilisateur ne surveille pas en temps réel. Anthropic ne cache pas sa cible : les workflows où la supervision humaine était le goulot.
La commande /ultrareview offre une revue multi-passes sur un diff. Implicite dans cette commande : c’est le modèle qui fait le travail de fond, et tu interviens sur sa conclusion, pas sur son process.
Pris ensemble, ces trois changements dessinent un ingénieur autonome à qui on confie un ticket. Pas un copilote.
4 réflexes de délégation qui marchent en pratique
J’ai fait la transition progressivement sur Opus 4.6 ces derniers mois, et les patterns ci-dessous se sont imposés. Ils restent valides sur 4.7, avec un retour sur investissement encore meilleur.
Brief complet en un seul message
L’habitude de découper ses demandes en plusieurs tours coûte cher en reasoning. Au lieu de “dis-moi d’abord ce que tu proposes puis code-le”, je donne tout en un bloc : l’intention, les contraintes, les critères d’acceptation, les fichiers concernés. Sur 4.7 avec xhigh en défaut, ce gain est encore plus net que sur 4.6.
Critères d’acceptation explicites
“Nettoie ce module” ne veut rien dire pour un délégué. “Je veux que ce fichier passe des tests unitaires à 80 % de couverture, sans changement d’API publique, avec des temps de réponse P95 sous 200 ms” est exploitable. L’écart de précision se retrouve directement dans la qualité de sortie.
Auto mode pour les phases de confiance
Dans Claude Code, Shift+Tab bascule en auto mode. Tu n’as plus à valider chaque commande. Pour les tâches où tu as bien cadré les critères, cette bascule te libère. Sur Opus 4.7, la fiabilité des décisions autonomes s’améliore encore, donc l’auto mode devient un vrai gain de temps plutôt qu’une source d’angoisse.
Notification sonore en fin de tâche
Astuce mentionnée par l’équipe Anthropic dans son billet : demander à Claude de jouer un son système en fin de tâche longue. Sur macOS, afplay /System/Library/Sounds/Glass.aiff dans le dernier tool call. Tu pars bosser sur autre chose, tu reviens quand ça sonne.
Ce qui ne marche pas bien en mode délégation
La posture n’est pas universelle. Trois cas où elle échoue.
Tâches courtes à faible enjeu. Renommer, corriger une typo, un one-liner : le coût de cadrage dépasse le gain. Reste en interactif avec effort low ou medium.
Tâches pédagogiques. Si tu veux apprendre une techno, la délégation te prive de l’observation du raisonnement. Demande explicitement un mode “explique chaque étape” si c’est ce que tu cherches.
Décisions d’architecture critiques. Le délégué est bon dans un cadre. Si la décision impacte plusieurs équipes ou plusieurs mois de travail, tu restes maître d’œuvre. Claude devient un assistant exploratoire, pas un décideur.
L’impact organisationnel
Pour une équipe tech, la posture de délégation combinée à 4.7 change plusieurs choses.
Les seniors glissent de “coder et reviewer” vers “cadrer le travail délégué et valider les outputs”. Les juniors prennent plus de levier, à condition d’être encadrés, sinon ils produisent vite du code qu’ils ne maîtrisent pas. La revue de code évolue : on valide la cohérence avec les critères plutôt que de relire ligne par ligne. Les outils comme /ultrareview deviennent des compléments naturels.
Le suivi de consommation devient un sujet de management. Une équipe de 5 devs sur xhigh par défaut peut voir sa facture API bondir de 30 à 40 % sur un mois. Il faut des dashboards internes ou des budgets par projet pour éviter les surprises.
FAQ
Faut-il former toute l’équipe à cette posture ? Un atelier d’une demi-journée suffit pour bâtir les réflexes. Les habitudes de pair programming sont tenaces, sans cadrage explicite les développeurs continuent comme avant.
Cette posture marche-t-elle sur d’autres modèles ?
Le principe, oui. Les réglages précis (xhigh, adaptive thinking, /ultrareview) sont spécifiques à Claude Code, à adapter sur les autres stacks.
Combien ça coûte en pratique ? Plage observée entre 80 et 300 euros par mois et par développeur en usage API intensif. Les plans abonnement lissent la facture.
Je pilote Linkuma, plateforme de netlinking low cost, 40 000 sites au catalogue, 15 000 clients accompagnés. Retours terrain sur linkuma.com, promos hebdo sur deals.linkuma.com.
