Tech • IA • Robotique • Jeu
Claude Code : les seules règles qui comptent encore (Opus 5.5 change tout)
7/10INTRO
Les workflows récents avec Claude privilégient des consignes de tâche claires, des garde-fous stricts, des instructions légères et une vérification rigoureuse plutôt que des modes de planification élaborés, des fichiers de règles tentaculaires et des changements constants de modèle.
POINTS CLÉS
Le mode planification a perdu son rôle central
Les premiers workflows d’agents commençaient souvent par une phase de planification dédiée avant tout travail. Cette approche est désormais jugée largement inutile, car les agents actuels peuvent planifier, exécuter, réfléchir et tester en une seule exécution. La priorité pratique est de définir la tâche, fixer les limites et préciser ce qui constitue un résultat terminé.
Un brief précis compte plus que les rituels de prompting
Les utilisateurs les plus performants traitent de plus en plus le modèle comme un travailleur autonome avec une mission définie. Ils précisent l’objectif, les limites et le critère de réussite, puis laissent l’agent effectuer le travail de bout en bout. Le but est moins de le guider manuellement que d’obtenir une autonomie fiable.
Mieux vaut utiliser un modèle principal plus puissant que changer sans cesse
Cette approche soutient que les passages fréquents entre Opus, Sonnet et des modèles plus légers ajoutent souvent de la complexité sans gain clair. Dans la comparaison citée, Opus avec des réglages faibles ou moyens était présenté comme égalant ou dépassant Sonnet à des réglages plus élevés, tout en restant proche en coût. La variable clé n’est pas seulement le nom du modèle, mais aussi le budget de réflexion attribué à la tâche.
Le coût dépend fortement du budget de réflexion
L’idée que Opus est toujours coûteux a été contestée par des exemples montrant qu’un usage à faible budget peut revenir en moyenne à environ 0,5 centime par tâche. Des budgets plus élevés peuvent faire monter les tâches dans une fourchette de 1 à 3 $, mais ces réglages ne sont pas nécessaires pour chaque travail. Un modèle plus intelligent peut aussi réduire le coût total s’il termine plus vite et avec moins de tentatives.
La vérification est l’habitude la plus importante
La recommandation la plus forte est d’amener l’agent à contrôler son propre travail de façon répétée. Cela exige un accès à un navigateur ou à un environnement de test afin qu’il puisse inspecter les sorties, se connecter à des services, reproduire des parcours utilisateur et corriger les erreurs sur plusieurs itérations. Au lieu de s’arrêter après un seul passage, les meilleurs workflows poussent l’agent à travers 2 à 9 cycles de test et de correction.
Les fichiers d’instructions doivent être plus courts, pas plus longs
Les gros fichiers de règles de type Claude.md ont été décrits comme une source croissante de mauvais résultats. L’idée est que des ensembles d’instructions trop volumineux embrouillent les modèles récents, surtout lorsque les équipes continuent d’ajouter avec le temps des avertissements, des priorités et des exigences de formatage. Une cible de moins de 200 lignes, et idéalement bien moins, a été présentée comme un meilleur réglage par défaut.
Les fichiers d’agent généraux remplacent ceux spécifiques à un outil
Plutôt que de maintenir un fichier conçu pour un seul assistant, la recommandation est d’évoluer vers un format agent.md plus large, compréhensible par plusieurs agents de code. L’avantage est une meilleure portabilité entre outils et moins de maintenance dans un écosystème qui change rapidement. En pratique, cela signifie conserver un seul manuel opératoire compact au lieu de multiples couches de prompts qui se chevauchent.
Trop de skills peuvent dégrader les performances
Beaucoup d’utilisateurs installent de grandes collections de skills, de plugins et de packs de prompts dans l’espoir de rendre l’agent plus intelligent. L’argument ici est inverse: les modèles modernes obtiennent souvent de meilleurs résultats sans skill supplémentaire, sauf si une faiblesse précise doit être corrigée. Les skills inutilisés consomment du contexte, ajoutent des instructions et peuvent rendre le comportement erratique.
Bloquez les mauvaises actions avec des outils, pas avec des avertissements
Lorsqu’un agent se comporte de manière dangereuse, ajouter davantage d’interdictions écrites est jugé moins efficace que des contrôles techniques stricts. Un exemple consiste à intercepter des commandes destructrices comme rm -rf et à les remplacer par une action plus sûre qui déplace les fichiers vers la corbeille. Des garde-fous déterministes réduisent la dépendance au fait que le modèle se souvienne de chaque règle.
Préférez les intégrations CLI aux connecteurs intégrés
Les connecteurs par défaut vers des services comme Notion peuvent enfermer les workflows dans une seule plateforme et se montrer moins fiables qu’un outillage direct. La voie privilégiée est la CLI officielle, que les agents gèrent bien parce qu’elle est textuelle et structurée. S’il n’existe pas de CLI, un petit script peut faire le lien entre l’API du service et un outil en ligne de commande que l’agent peut utiliser de manière cohérente.
Les plus grands gains viennent de l’automatisation
L’objectif final n’est pas de mieux converser, mais d’accomplir davantage de travail sans supervision. Des agents en arrière-plan exécutés sur un VPS ou une machine isolée peuvent auditer des données, faire des recherches, répondre aux e-mails et gérer des opérations de routine pendant que l’utilisateur est hors ligne. Cette approche transforme l’IA, d’un assistant utilisé occasionnellement, en une couche opérationnelle persistante.
CONCLUSION
Le nouveau mode d’emploi pour un usage avancé de Claude est plus simple que beaucoup de tendances antérieures en prompting: moins de rituels, moins de règles et moins d’ajouts, mais des modèles plus puissants, des garde-fous stricts et un auto-contrôle intensif. Le principal avantage compétitif vient de workflows qui permettent à l’agent d’exécuter et de vérifier un vrai travail de manière autonome.
Poser une question