Six Niveaux de Maîtrise de Claude Code que J'aurais Aimé Connaître Plus Tôt

Six Niveaux de Maîtrise de Claude Code que J'aurais Aimé Connaître Plus Tôt

Il y a trois mois, j'ai regardé l'une de mes sessions Claude Code produire une sortie tellement générique qu'elle aurait pu venir de n'importe quel chatbot gratuit sur internet. J'utilisais l'outil quotidiennement depuis presque un an. J'avais construit des projets clients avec, livré du code en production à travers, même écrit à son sujet sur ce blog. Et pourtant, j'étais là, à fixer du code boilerplate qu'un étudiant de première année en informatique aurait eu honte de rendre.

Ce moment m'a forcé à confronter quelque chose d'inconfortable : j'utilisais Claude Code de la mauvaise façon. Pas cassé-mauvais. Pas crash-le-terminal mauvais. Mauvais de la manière dont quelqu'un qui conduit une Ferrari en première vitesse est mauvais -- techniquement en train d'opérer la machine, mais passant à côté de tout ce qui la rend extraordinaire.

Ce qui a suivi fut une plongée de trois mois pour comprendre la véritable progression de compétences dans la maîtrise de Claude Code. Pas la version marketing où tout se met en place dès le premier jour. La vraie version, où chaque niveau exige de désapprendre les habitudes du précédent, et où les pièges à chaque étape sont plus dangereux que les défis.

J'ai identifié six niveaux distincts. J'ai personnellement rampé à travers chacun d'eux, passant parfois des semaines bloqué sur un plateau avant de comprendre ce qui me retenait. L'écart entre le Niveau 1 et le Niveau 6 n'est pas juste une différence de productivité -- c'est une relation fondamentalement différente avec l'IA en tant que partenaire de développement.

Voici ce que personne ne m'a dit quand j'ai commencé : la transition la plus difficile n'est pas d'apprendre de nouvelles commandes. C'est d'abandonner l'état d'esprit qui vous a amené au niveau actuel.

Niveau 1 : L'Ingénieur de Prompts (Où Tout le Monde Commence et Où la Plupart Restent)

Je me souviens de ma première semaine avec Claude Code très clairement. Je l'ai traité comme je traite tout outil en ligne de commande : taper une instruction, recevoir un résultat, répéter. "Construis-moi une API REST pour l'authentification des utilisateurs." "Écris des tests pour ce composant." "Refactorise cette fonction pour utiliser async/await."

Et ça a fonctionné. Plus ou moins. Claude générait du code, je le collais dans mon projet, je corrigeais quelques trucs et je passais à la suite. Le workflow semblait productif parce que je comparais avec tout écrire à la main. Toute accélération semblait être une victoire.

Le problème était invisible au début. Chaque sortie avait la même qualité -- adéquate mais sans éclat. L'API d'authentification fonctionnait, mais elle utilisait des patterns qui ne correspondaient pas au reste de ma base de code. Les tests couvraient les chemins heureux mais rataient les cas limites que j'aurais attrapés manuellement. La fonction refactorisée était plus propre, certes, mais elle a introduit un changement subtil dans la gestion des erreurs que je n'ai pas remarqué jusqu'à la production.

C'est le Niveau 1 : l'Ingénieur de Prompts. Vous écrivez des commandes et recevez des réponses. Communication à sens unique. Vous parlez, l'IA écoute, l'IA produit. Il n'y a pas de dialogue, pas d'itération au sein de la session, pas de collaboration.

Le piège à ce niveau a un nom qui le décrit parfaitement : la bouillie d'IA. Une sortie générique, techniquement-correcte-mais-sans-caractère qui se lit comme si elle avait été assemblée à partir de fragments de documentation. Vous la repérez immédiatement -- elle utilise des noms de variables comme data et result, structure le code de la manière la plus conventionnelle possible, et ajoute des commentaires qui expliquent ce que le code fait plutôt que pourquoi.

J'ai passé environ six semaines au Niveau 1. Ma production était plus rapide que le codage manuel mais nécessitait tellement d'édition que le gain de temps était marginal. La percée est venue quand j'ai réalisé que je traitais Claude Code comme une machine à écrire alors qu'il était conçu pour être un partenaire de conversation.

Ce qui m'a finalement poussé au-delà de ce niveau fut un mardi après-midi frustrant. J'avais demandé à Claude Code de construire un handler de webhooks, et il a produit quelque chose de fonctionnel mais complètement déconnecté des patterns de ma base de code existante. Au lieu de réécrire le prompt avec plus de détails, j'ai essayé quelque chose de différent. J'ai commencé à poser des questions en retour.

Ce seul changement -- de commander à converser -- a tout changé.

Niveau 2 : Le Planificateur (Où le Dialogue Remplace la Dictée)

Le Plan Mode a été la fonctionnalité qui m'a débloqué le Niveau 2. Si vous ne l'avez pas utilisé, le concept est simple : au lieu que Claude Code exécute immédiatement votre demande, il propose d'abord un plan, pose des questions clarificatrices, et attend votre avis avant d'écrire une seule ligne de code.

La première fois que j'ai activé le Plan Mode pour une tâche complexe, la différence était saisissante. J'ai demandé à Claude de construire un système de notifications pour un projet client. Au lieu de générer du code immédiatement, il est revenu avec des questions que je n'avais pas considérées : "Les notifications doivent-elles être persistées en base de données ou gérées comme des événements éphémères ? Quelle est la priorité de livraison -- le système doit-il garantir la livraison ou le meilleur effort est-il acceptable ? Prévoyez-vous de supporter plusieurs canaux de notification au-delà de l'email ?"

Ce n'étaient pas des questions génériques. C'étaient exactement les décisions architecturales que j'aurais dû prendre de toute façon -- mais que j'aurais probablement prises implicitement, sans les réfléchir en profondeur, résultant en du retravail ensuite.

Le Plan Mode change fondamentalement votre relation avec Claude Code. Vous cessez d'être un commandant pour devenir un collaborateur. L'IA résiste, suggère des alternatives, identifie les lacunes dans votre spécification. C'est la différence entre donner un plan à quelqu'un et s'asseoir avec un architecte pour concevoir ensemble.

Voici mon workflow réel au Niveau 2. Je commence chaque tâche non triviale avec le Plan Mode activé. Je décris ce que je veux à un haut niveau. Claude propose une approche et pose des questions. Je réponds aux questions et ajoute des contraintes. Claude affine le plan. J'approuve ou j'ajuste. Ce n'est qu'alors que la génération de code commence. Toute la phase de planification prend cinq à dix minutes, mais elle économise des heures de retravail.

Le piège du Niveau 2 est plus subtil que celui du Niveau 1. Au Niveau 1, le piège est évident -- mauvaise sortie. Au Niveau 2, le piège est la passivité. Vous vous habituez à ce que Claude pose de bonnes questions, alors vous arrêtez d'apporter votre propre expertise à la table. Vous devenez un répondeur de questions au lieu d'un co-penseur.

Je me suis surpris à faire cela sur un projet de migration de base de données. Le plan de Claude était techniquement solide, mais il proposait une stratégie de migration qui aurait causé une interruption de service pendant le déploiement. J'ai failli l'approuver parce que le plan "avait l'air bien". Les questions que Claude a posées étaient intelligentes, mais il n'a pas posé la seule question qui importait le plus parce qu'il ne connaissait pas notre exigence de déploiement sans interruption. C'était un savoir que je devais apporter volontairement.

La leçon : le Plan Mode fait de Claude un meilleur collaborateur, mais ne rend pas Claude omniscient. Vous devez toujours injecter du contexte que l'IA ne peut pas inférer. Et savoir quel contexte injecter -- c'est la compétence qui définit le Niveau 3.

Niveau 3 : L'Ingénieur de Contexte (Où le Vrai Écart de Compétence S'Ouvre)

C'est le niveau où les utilisateurs occasionnels de Claude Code et les praticiens sérieux divergent. L'ingénierie de contexte semble académique, mais c'est la compétence la plus pratique de toute la progression. C'est l'art de donner à Claude exactement la bonne information au bon moment -- ni plus, ni moins.

J'ai appris cela à mes dépens pendant un grand projet de refactoring. J'avais une application monolithique Express qui devait être découpée en microservices. Mon approche a été de charger toute la base de code dans le contexte de Claude, d'expliquer l'objectif, et de le laisser travailler. Ça semblait logique. Donnez-lui un maximum d'information, obtenez un maximum de qualité de sortie.

Les résultats étaient terribles. Pas immédiatement -- les premiers fichiers que Claude a refactorisés étaient excellents. Mais à la troisième heure, les suggestions devenaient bizarres. Des signatures de fonction qui ne correspondaient pas aux patterns existants. Des chemins d'import pointant vers des fichiers dans l'ancienne structure. Du nommage de variables qui passait de camelCase à snake_case en milieu de session. C'était comme regarder quelqu'un perdre sa concentration lentement pendant une réunion marathon.

C'était ma première rencontre avec la dégradation du contexte, et la comprendre a tout changé dans ma façon d'utiliser Claude Code.

Dégradation du Contexte : Le Tueur de Performance Silencieux

Voici la réalité technique que la plupart des tutoriels survolent. La fenêtre de contexte de Claude Code a une capacité, et cette capacité ne concerne pas seulement faire rentrer de l'information -- il s'agit de maintenir la qualité d'attention à travers cette information. Une fois que votre fenêtre de contexte dépasse environ 50-60%, la qualité de sortie commence à se dégrader de manières follement subtiles.

J'ai testé cela systématiquement sur plusieurs projets. Mêmes tâches, mêmes prompts, différentes charges de contexte. À 20-30% d'utilisation du contexte, la sortie de Claude était précise, respectueuse des conventions et structurellement cohérente. À 50%, de petites incohérences commençaient à apparaître -- rien qui casserait le build, mais assez pour nécessiter un nettoyage manuel. À 70%+, la sortie devenait ce que je ne peux décrire que comme "faux avec assurance". Du code syntaxiquement correct qui prenait des décisions architecturalement discutables.

La commande /compact est devenue ma meilleure amie à ce stade. Exécuter /compact compresse le contexte de la conversation, éliminant les échanges terminés tout en préservant l'information essentielle dont Claude a besoin pour la continuité. Je l'exécute maintenant de manière proactive, pas réactive. Chaque fois que je termine une sous-tâche distincte, je compacte avant de passer à la suivante.

Et /clear ? C'est l'option nucléaire, mais parfois c'est le bon choix. Démarrer un contexte complètement frais pour une nouvelle tâche produit de meilleures sorties que continuer une session gonflée, même si on a l'impression de "gaspiller" la compréhension que Claude a construite. La compréhension au-delà de 60% de capacité est plus un fardeau qu'un atout.

Quoi Donner au Contexte (et Quoi Retenir)

L'autre moitié de l'ingénierie de contexte est la curation. Tous les fichiers ne sont pas pertinents. Toutes les pièces de contexte n'aident pas. Charger tout votre package.json, tous vos fichiers de configuration, et votre suite complète de tests "au cas où" est l'équivalent contextuel de faire votre valise avec toute votre garde-robe pour un week-end.

Mon approche maintenant est chirurgicale. Pour toute tâche donnée, j'identifie trois catégories de contexte :

Contexte essentiel -- fichiers qui seront directement modifiés ou qui définissent des interfaces auxquelles le code modifié doit se conformer. Ceux-ci entrent en premier.

Contexte de référence -- exemples de patterns similaires dans la base de code que Claude devrait suivre. Je charge typiquement un ou deux fichiers représentatifs, pas chaque instance.

Contexte périphérique -- choses qui pourraient être pertinentes. Celles-ci restent en dehors du contexte initial. Si Claude en a besoin, il demandera -- et cette question elle-même est un signal que je devrais évaluer si le contexte est vraiment nécessaire.

J'ai aussi commencé à fournir des captures d'écran de composants UI quand je travaille sur du code frontend. Ça semble évident, mais j'ai résisté pendant des semaines parce que ça semblait inefficace. Il s'avère qu'une capture d'écran de l'état actuel du composant donne à Claude plus de contexte utile que trois paragraphes de description. Le contexte visuel est sous-estimé.

Le fichier CLAUDE.md à la racine de votre projet est un autre outil de Niveau 3 que la plupart des gens sous-utilisent. Le mien contient les conventions de code, les décisions architecturales, et des règles explicites comme "toujours utiliser les retours anticipés" et "les réponses d'erreur doivent inclure à la fois un code lisible par machine et un message lisible par l'humain". Charger ces conventions automatiquement signifie que Claude commence chaque session déjà aligné sur mes patterns, sans brûler de contexte en explications.

Le piège du Niveau 3 est de trop réfléchir à la gestion du contexte au point de passer plus de temps à curer les entrées qu'à générer des sorties. J'ai heurté ce mur pendant environ deux semaines, mesurant obsessionnellement les pourcentages d'utilisation du contexte et remettant en question chaque fichier que je chargeais. Le point d'équilibre est plus proche de "bonne curation, rapidement" que de "curation parfaite, lentement".

Ce qui m'a finalement propulsé en avant était de réaliser que la qualité du contexte importait plus que la quantité du contexte -- et que certains outils pouvaient gérer les décisions de contexte pour moi automatiquement. Cette réalisation a ouvert la porte au Niveau 4.

Niveau 4 : L'Intégrateur d'Outils (Où Claude Code Obtient des Superpouvoirs)

Le Niveau 4 est celui où Claude Code cesse d'être juste un assistant de codage et commence à devenir une plateforme de développement extensible. C'est le niveau des serveurs MCP -- serveurs et frameworks du Model Context Protocol qui donnent à Claude des capacités au-delà de la génération de texte.

Les serveurs MCP sont, en pratique, des plugins qui permettent à Claude d'interagir avec des systèmes externes. Requêtes de base de données. Appels API. Opérations sur le système de fichiers. Automatisation du navigateur. Intégration d'outils de design. Chaque serveur MCP étend ce que Claude peut faire sans que vous copiez manuellement des données entre outils.

J'ai intégré mon premier serveur MCP -- un connecteur PostgreSQL -- après avoir passé un après-midi entier à copier manuellement des résultats de requêtes depuis pgAdmin dans le contexte de Claude pour qu'il m'aide à optimiser des requêtes lentes. L'absurdité de ce workflow m'a frappé en plein copier-coller. J'étais le composant le plus lent dans mon propre pipeline, agissant comme un presse-papiers humain entre deux outils numériques.

Après avoir connecté le serveur MCP Postgres, je pouvais simplement dire "analyse les requêtes lentes dans la table des commandes et suggère des améliorations d'index". Claude interrogeait la base de données directement, examinait les plans d'exécution, et proposait des index optimisés avec le SQL réel pour les créer. Ce qui avait pris un après-midi de copier-coller est devenu une conversation de cinq minutes.

Mais voici où le Niveau 4 devient dangereux.

Le Piège de la Surcharge d'Outils

Ma collection de serveurs MCP a grandi rapidement après cette première intégration. Connecteur Postgres. Intégration GitHub. Slack pour les notifications. Notion pour la documentation. Automatisation du navigateur pour les tests. Linear pour la gestion de projet. Figma pour les spécifications de design.

En deux semaines, j'avais onze serveurs MCP configurés. Et les performances de Claude ont chuté.

Pas parce que les serveurs étaient buggés -- ils fonctionnaient bien individuellement. Le problème était la surcharge cognitive côté Claude. Avec onze outils différents disponibles, Claude atteignait parfois le mauvais, ou passait des tokens à évaluer quel outil utiliser avant de faire le travail réel. Pire, avoir trop de capacités rendait les réponses de Claude plus lentes et occasionnellement confuses sur quel outil pouvait gérer quelle tâche.

J'ai appris cette leçon pendant une session de revue de code. J'ai demandé à Claude de vérifier un pull request pour des problèmes de sécurité. Au lieu d'analyser le code directement, il a essayé d'utiliser le serveur MCP GitHub pour récupérer les métadonnées du PR, puis l'automatisation du navigateur pour rendre le diff, puis le connecteur Postgres pour vérifier les patterns d'injection SQL -- une machine de Rube Goldberg d'appels d'outils qui a produit une analyse pire que simplement lire le code.

La solution a été la sélection chirurgicale. J'ai réduit ma configuration MCP à cinq serveurs que j'utilisais réellement quotidiennement : GitHub, Postgres, un observateur de système de fichiers, Notion, et un outil personnalisé de test d'API que j'avais construit. Tout le reste a été supprimé.

Le principe que je suis maintenant : ajoutez un outil uniquement quand vous avez rencontré la même friction de workflow manuel au moins trois fois. Si vous n'êtes pas activement ennuyé par l'absence d'une capacité, vous n'avez pas besoin du plugin. Capacité et performance ne sont pas la même chose -- plus d'outils ne signifie pas meilleure sortie.

Le choix du framework compte aussi. J'ai essayé d'intégrer Claude Code avec plusieurs frameworks d'automatisation, et le pattern est constant : ceux qui fonctionnent le mieux sont ceux qui font une chose bien et ont des interfaces propres et prévisibles. Ceux qui essaient d'être tout -- des plateformes complètes de développement IA avec dix-sept fonctionnalités -- tendent à créer plus de confusion qu'ils n'en résolvent.

Aveu honnête : je me surprends encore occasionnellement à installer un nouveau serveur MCP brillant parce qu'il semble utile, pour le supprimer une semaine plus tard quand je réalise qu'il ajoute de la latence sans ajouter de valeur. L'instinct d'intégration d'outils est difficile à contrôler une fois activé.

Le vrai bénéfice du Niveau 4 n'est aucun outil individuel. C'est le changement de modèle mental de "Claude traite du texte" à "Claude orchestre des workflows". Une fois que vous voyez Claude comme un hub de workflow plutôt qu'un générateur de texte, vous commencez à penser à l'automatisation différemment. Et cette pensée mène directement au Niveau 5.

Niveau 5 : Le Développeur de Skills (Où la Répétition Meurt)

Je vais être honnête : le Niveau 5 est celui où j'ai passé le plus de temps à lutter, et c'est aussi celui où j'ai vu les plus grands gains de productivité soutenus. Le développement de skills dans Claude Code est la pratique de transformer des workflows de prompts répétitifs en automatisations réutilisables à commande unique.

Une skill, en termes Claude Code, est essentiellement un workflow basé sur du texte. Pensez-y comme une macro, mais plus intelligente -- c'est un ensemble d'instructions structurées que Claude suit quand elle est déclenchée, incluant quel contexte collecter, quelles étapes exécuter, et quel format de sortie produire.

Voici un exemple concret. Avant de créer des skills, mon workflow de revue de code ressemblait à ça : charger les fichiers modifiés, expliquer mes critères de revue, demander à Claude de vérifier les problèmes de sécurité, puis demander les préoccupations de performance, puis demander la conformité aux patterns, puis demander les lacunes de couverture de tests. Six prompts séparés, à chaque fois. Parfois j'oubliais une étape. Parfois je formulais les critères différemment et obtenais des résultats incohérents.

Ma skill de revue de code a compressé tout ça en un seul déclencheur. Elle charge automatiquement le diff, applique mes critères de revue dans un ordre cohérent, vérifie contre mes conventions CLAUDE.md, et produit un rapport structuré avec des niveaux de sévérité. Même qualité à chaque fois. Zéro prompt oublié.

Construire des Skills qui Fonctionnent Vraiment

L'outil Skill Creator dans Claude Code aide à démarrer de nouvelles skills, mais j'ai trouvé que les meilleures skills viennent de l'évolution organique plutôt que de la conception initiale. Mon processus :

D'abord, je fais un workflow manuellement trois ou quatre fois, notant quels prompts j'utilise et dans quel ordre. Ensuite, j'identifie quelles parties sont cohérentes entre les exécutions et lesquelles varient. Enfin, je construis une skill qui gère les parties cohérentes automatiquement et accepte les parties variables comme paramètres.

Mes skills les plus utilisées en ce moment :

Project Bootstrap -- prend une description de projet et génère la structure de fichiers, les fichiers de configuration, les conventions CLAUDE.md et le boilerplate initial. Économise environ 45 minutes par nouveau projet.

API Endpoint Builder -- prend une spécification d'endpoint (route, méthode, formes request/response) et génère le handler, la validation, la gestion d'erreurs, les tests et la documentation. En suivant précisément mes patterns établis parce que la skill référence mes conventions d'architecture.

Deployment Preflight -- parcourt une checklist de variables d'environnement, migrations de base de données, audits de dépendances et scans de sécurité avant que je pousse en production. Celle-ci a attrapé trois problèmes qui auraient été des incidents de production.

Bug Investigation -- prend un message d'erreur ou rapport de bug, rassemble les logs pertinents et le contexte de code, et produit une analyse structurée avec les causes racines probables classées par probabilité.

Chacune de ces skills a pris environ une heure à construire et affiner. Elles me font gagner cette heure dans la première semaine d'utilisation.

Le Piège de la Prolifération de Skills

Voici le piège du Niveau 5, et j'y suis tombé directement : créer trop de skills.

À mon maximum, j'avais vingt-trois skills personnalisées configurées. Vingt-trois. Certaines se chevauchaient en fonctionnalité. Certaines étaient tellement spécifiques qu'elles ne s'appliquaient qu'à exactement un projet. Quelques-unes se contredisaient de manières subtiles -- ma skill "endpoint API rapide" utilisait des conventions de gestion d'erreurs différentes de ma skill "endpoint API production", et je ne me souvenais plus laquelle était laquelle.

Claude lui-même était confus. Quand je déclenchais une tâche qui pouvait correspondre à plusieurs skills, la qualité de sortie baissait parce que le système essayait de réconcilier des instructions contradictoires. C'est le même principe que la surcharge MCP du Niveau 4 -- plus n'est pas mieux. Précis est mieux.

J'ai élagué jusqu'à huit skills. Huit workflows bien testés, fréquemment utilisés, sans chevauchement qui couvrent environ 80% de mes tâches répétitives. Les 20% restants, je les gère avec des prompts ad-hoc, et c'est très bien. Tout n'a pas besoin d'être automatisé.

Les critères d'élagage que j'utilise : si je n'ai pas déclenché une skill en deux semaines, elle est archivée. Si deux skills partagent plus de 50% de leurs étapes, elles sont fusionnées. Si une skill produit une sortie que j'ai régulièrement besoin d'éditer, elle est réécrite ou supprimée.

Les skills sont le moment où Claude Code passe de "outil que j'utilise" à "système que j'ai construit". Elles sont personnalisées, opiniâtres, et façonnées par mes patterns de développement spécifiques. Les skills de personne d'autre ne fonctionneraient parfaitement pour moi, et les miennes ne fonctionneraient parfaitement pour personne d'autre. Cette personnalisation est le but.

Mais même avec d'excellentes skills, vous êtes toujours limité à une instance de Claude Code faisant une chose à la fois. Briser cette limitation, c'est le propos du Niveau 6 -- et honnêtement, c'est le niveau que je suis encore en train de découvrir activement.

Niveau 6 : L'Orchestrateur de Claude Code (Où Ça Devient Intense)

Je dois être franc sur quelque chose : le Niveau 6 est celui où ma confiance baisse et mon excitation monte en parts égales. Orchestrer plusieurs instances de Claude Code simultanément est la frontière de ce qui est possible, et c'est véritablement puissant, mais c'est aussi véritablement désordonné. J'ai eu des sessions où tout s'est mis en place et j'ai eu l'impression de diriger une équipe de développement depuis un seul terminal. J'ai aussi eu des sessions où trois agents ont produit des changements conflictuels et j'ai passé plus de temps à fusionner que je n'en aurais passé à coder seul.

Voici le concept. Au lieu d'une instance Claude Code gérant une tâche à la fois, le Niveau 6 implique d'exécuter plusieurs instances en parallèle, chacune travaillant sur une partie différente du projet. Un agent gère l'API backend. Un autre construit les composants frontend. Un troisième écrit les tests. Ils travaillent simultanément, dans des environnements isolés, et vous coordonnez les résultats.

L'élément technique clé, ce sont les Git worktrees. Si vous n'êtes pas familier, un Git worktree vous permet de faire le checkout de plusieurs branches du même dépôt dans des répertoires séparés simultanément. Chaque répertoire est une copie de travail pleinement indépendante. Les changements dans un worktree n'affectent pas les autres jusqu'à ce que vous les fusionniez explicitement.

Cela correspond parfaitement aux workflows multi-agents. Je crée un worktree pour chaque agent, j'assigne à chaque agent un périmètre de travail spécifique, et je les laisse tourner en parallèle. L'Agent A travaille sur l'API dans worktree-api/. L'Agent B travaille sur l'UI dans worktree-ui/. L'Agent C travaille sur les tests dans worktree-tests/. Pas de conflits pendant le développement parce qu'ils sont dans des répertoires séparés. Fusion quand c'est terminé.

Mon Workflow d'Orchestration (Avec Tous les Défauts)

Voici comment une session multi-agents fonctionne réellement pour moi. Je vais utiliser un projet récent comme exemple -- construire un dashboard en temps réel avec des mises à jour WebSocket.

Étape 1 : Je crée trois Git worktrees depuis la branche principale.

git worktree add ../dashboard-api feature/api
git worktree add ../dashboard-ui feature/ui
git worktree add ../dashboard-tests feature/tests

Étape 2 : J'ouvre trois sessions terminal, chacune pointant vers un worktree différent, chacune exécutant sa propre instance de Claude Code.

Étape 3 : Je donne à chaque instance un brief ciblé. L'agent API reçoit la spécification du serveur WebSocket, les modèles de données, et le schéma d'événements. L'agent UI reçoit les designs de composants, les exigences du client WebSocket, et l'approche de gestion d'état. L'agent tests reçoit le contrat API et les comportements attendus.

Étape 4 : Je les laisse tourner, vérifiant périodiquement. C'est la partie qui ressemble à la gestion d'une équipe. Vous n'écrivez pas de code -- vous révisez des plans, répondez à des questions, et prenez des décisions architecturales à travers trois flux parallèles.

Étape 5 : Quand les trois ont terminé, je fusionne. C'est là que la réalité devient désordonnée.

Le Problème de la Fusion (et Pourquoi Je Suis Honnête à ce Sujet)

Fusionner le travail d'agents parallèles est le plus grand défi individuel au Niveau 6. Même avec une séparation claire des périmètres, les agents font des suppositions. L'agent API pourrait structurer un payload de réponse différemment de ce que l'agent UI attend. L'agent tests pourrait écrire des assertions contre une interface qui a changé pendant le développement.

Mon taux de réussite de fusion -- c'est-à-dire les fusions qui n'ont nécessité aucune résolution manuelle de conflit -- est d'environ 60%. Quatre fois sur dix, je passe de trente minutes à une heure à corriger des problèmes d'intégration qui n'auraient pas existé si un seul agent avait tout fait séquentiellement.

La vitesse parallèle en vaut-elle la peine ? Pour les grosses fonctionnalités, oui. Le projet de dashboard que j'ai décrit ci-dessus aurait pris environ douze heures avec un seul agent. L'approche à trois agents s'est terminée en environ cinq heures de temps réel, incluant une heure de résolution de fusions. Économie nette de six heures. Pour ce projet, le calcul fonctionnait.

Pour les fonctionnalités plus petites ? Honnêtement, non. La surcharge de configuration des worktrees, d'écriture de briefs séparés, et de gestion des fusions ronge les gains de temps. Ma règle empirique : si la tâche prendrait moins de trois heures avec un seul agent, l'orchestration multi-agents ne vaut pas le coût de coordination.

Sous-Agents et Équipes d'Agents

Claude Code supporte aussi les sous-agents -- générer un agent secondaire depuis une session d'agent primaire pour gérer une sous-tâche. C'est moins de surcharge que l'orchestration complète avec worktrees mais plus limité en portée. J'utilise les sous-agents pour des tâches comme "va rechercher l'API de cette bibliothèque et reviens avec un résumé" ou "génère les types TypeScript pour ce schéma JSON pendant que je continue à travailler sur le handler".

Les équipes d'agents sont la partie la plus expérimentale du Niveau 6. Le concept est plusieurs agents avec des rôles définis -- un planificateur, un codeur, un réviseur -- travaillant dans un pipeline coordonné. J'ai testé cette configuration trois fois. Deux fois, elle a produit des résultats véritablement impressionnants, avec l'agent réviseur attrapant des problèmes que l'agent codeur avait ratés. Une fois, elle a produit une boucle de feedback infinie où le réviseur continuait à demander des changements et le codeur continuait à les faire, brûlant des tokens sans converger.

Je mentionne cela parce que je pense qu'il est important d'être honnête : les équipes d'agents sont puissantes en théorie et imprévisibles en pratique. L'outillage s'améliore rapidement. Mais à la date d'aujourd'hui, début 2026, je traite les équipes d'agents comme expérimentales. Je ne les utiliserais pas pour du travail client où la prévisibilité compte. Pour des projets personnels où je peux me permettre d'expérimenter et occasionnellement perdre un après-midi dans une boucle de feedback ? Absolument.

La Réalité des Tokens

L'orchestration multi-agents brûle des tokens. Vite. Trois agents en parallèle consomment trois fois les tokens d'un agent unique, évidemment, mais le vrai coût est moins évident. Chaque agent a besoin de sa propre configuration de contexte, de son propre chargement de CLAUDE.md, de sa propre orientation vers le projet. Cette initialisation de contexte dupliquée s'accumule.

Je suis mon utilisation de tokens par projet, et les sessions multi-agents coûtent typiquement 2,5-3x ce qu'une session à agent unique coûte pour la même fonctionnalité. Pas 1x (le rêve) et pas 3x (la supposition naïve). Les économies viennent des fichiers CLAUDE.md partagés et des contextes ciblés et plus petits par agent.

Si ce ratio coût-performance fonctionne dépend entièrement de votre économie de temps. Pour le travail client facturé à l'heure, l'amélioration de vitesse justifie facilement le coût en tokens. Pour les projets personnels avec un budget, je suis plus sélectif sur quand je lance plusieurs agents.

Le Changement d'État d'Esprit qui Connecte les Six Niveaux

En regardant en arrière ma progression, les compétences techniques à chaque niveau comptent moins que le changement d'état d'esprit qui les rend possibles. Et il y a un seul fil qui connecte les six transitions : passer de commander à collaborer.

Au Niveau 1, vous commandez Claude pour produire une sortie. Au Niveau 2, vous planifiez ensemble. Au Niveau 3, vous curez le contexte ensemble. Au Niveau 4, vous construisez des chaînes d'outils ensemble. Au Niveau 5, vous codifiez des workflows ensemble. Au Niveau 6, vous orchestrez des équipes ensemble.

Chaque niveau nécessite d'abandonner un peu plus de contrôle et de faire un peu plus confiance au système -- tout en devenant simultanément plus sophistiqué dans la façon dont vous le guidez. C'est le paradoxe. Vous faites simultanément moins de travail manuel et appliquez plus de réflexion stratégique.

Les développeurs que je vois bloqués aux Niveaux 1 ou 2 sont presque toujours bloqués à cause d'un problème de contrôle, pas de compétence. Ils ne veulent pas investir dans l'ingénierie de contexte parce que ça ressemble à de la surcharge. Ils ne veulent pas intégrer d'outils parce qu'ils veulent comprendre chaque étape. Ils ne veulent pas exécuter plusieurs agents parce qu'ils ne peuvent pas personnellement réviser chaque ligne de sortie.

Ces instincts ne sont pas faux -- c'est de la discipline professionnelle qui vous sert bien quand vous écrivez du code à la main. Mais ils deviennent des limitations quand votre rôle passe de "personne qui écrit du code" à "personne qui orchestre des systèmes d'IA qui écrivent du code". L'ensemble de compétences est différent, et l'état d'esprit doit évoluer pour correspondre.

Ce qui a Réellement Changé dans Mon Quotidien

L'impact pratique du passage du Niveau 1 au Niveau 6 est difficile à surestimer. Les délais de livraison de mes projets se sont compressés d'environ 40%. Pas parce que chaque tâche individuelle est 40% plus rapide -- certaines sont plus rapides, certaines prennent le même temps -- mais parce que le temps mort entre les tâches a presque disparu. Les coûts de changement de contexte ont baissé quand j'ai commencé à utiliser les worktrees. Le retravail a baissé quand j'ai commencé à gérer correctement le contexte. Les tâches répétitives ont disparu quand j'ai construit des skills.

Mes fichiers CLAUDE.md sont devenus certains des fichiers les plus précieux dans mes projets. Ils représentent du savoir architectural cristallisé -- des décisions qui vivaient dans ma tête vivent maintenant dans un fichier que chaque session Claude Code absorbe automatiquement. Les nouveaux membres de l'équipe (humains ou IA) peuvent lire le CLAUDE.md et immédiatement comprendre les conventions du projet.

Les commandes /compact et /clear sont maintenant des réflexes. J'exécute /compact de la même façon que j'appuyais sur Cmd+S -- fréquemment, presque inconsciemment, comme un geste d'hygiène. La dégradation du contexte n'est plus quelque chose que j'expérimente parce que je la préviens de manière proactive plutôt que de réagir après que la qualité se dégrade.

Et ma relation avec Claude Code lui-même a changé. Je ne pense plus à lui comme un outil. Les outils sont des choses qu'on prend et qu'on pose. Claude Code est plus comme un environnement de développement -- quelque chose qu'on configure, personnalise et habite. L'investissement dans la personnalisation se compose avec le temps. Chaque skill que je construis, chaque convention CLAUDE.md que je documente, chaque serveur MCP que j'intègre rend chaque session future plus productive que la précédente.

Cet effet composé est le vrai bénéfice d'avoir traversé les six niveaux. La productivité du Niveau 1 est linéaire -- vous obtenez ce que vous investissez, à chaque fois. La productivité du Niveau 6 est exponentielle -- le travail passé amplifie le travail futur.

À Votre Tour

Je ne vais pas prétendre que cette progression est rapide ou facile. Il m'a fallu environ quatre mois pour passer du Niveau 1 au Niveau 6, et j'affine encore mes compétences d'orchestration chaque semaine. Certains niveaux ont pris des jours à franchir. Le Niveau 3 a pris trois semaines. Le Niveau 6 est sans doute en cours -- je ne pense pas que quiconque ait pleinement maîtrisé l'orchestration multi-agents encore, parce que l'outillage évolue plus vite que quiconque ne peut construire de l'expertise.

Mais vous n'avez pas besoin d'atteindre le Niveau 6 pour voir des améliorations massives. Passer du Niveau 1 au Niveau 3 -- des prompts basiques à l'ingénierie de contexte -- transformera votre expérience Claude Code plus que toute autre transition. Si vous ne faites rien d'autre après avoir lu ceci, faites ces trois choses dans votre prochaine session :

Activez le Plan Mode pour votre prochaine tâche non triviale. Remarquez comment la conversation change quand Claude planifie avec vous au lieu de simplement exécuter.

Créez un fichier CLAUDE.md à la racine de votre projet avec dix conventions de codage spécifiques. Observez comment la sortie de Claude s'aligne immédiatement sur vos patterns.

Exécutez /compact après chaque sous-tâche terminée. Faites attention à si la prochaine réponse semble plus précise que les réponses à la fin d'une longue session non compactée.

Ces trois changements prennent quinze minutes à implémenter. Ils vous feront gagner des heures dans la première semaine.

La question n'est pas si Claude Code peut opérer au Niveau 6. Il le peut -- la capacité est déjà là. La question est si vous êtes prêt à faire évoluer votre workflow pour le rencontrer. Et de la part de quelqu'un qui a fait cette ascension : la vue d'ici vaut chaque transition inconfortable en chemin.

Travaillons Ensemble

Vous cherchez à construire des systèmes d'IA, automatiser des workflows ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous aider.

• Fiverr (builds personnalisés et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io