Claude Code a cinq niveaux et 90% des gens ne dépassent jamais le premier. Le niveau cinq, je ne vais même pas vous dire ce que c’est tout de suite. Sachez juste que quand vous y arrivez, vous jouez un jeu complètement différent.
Le niveau un, c’est écrire des prompts. Vous débarquez, vous tapez ce que vous voulez, et vous espérez que ça marche. Pas de plan, pas de contexte, pas de processus. Ça fonctionne jusqu’au moment où ça ne fonctionne plus.
Le niveau deux, c’est l’ingénierie de contexte. Claude a une fenêtre de contexte de 200 000 tokens, et passé environ 100 000, les performances chutent d’un coup. Si vous n’êtes pas technique, la fenêtre de contexte, c’est la mémoire à court terme de Claude. Vous lui refilez trop d’infos d’un coup et il commence à moins bien réfléchir. Le niveau deux, c’est construire un deuxième cerveau pour Claude : savoir quoi lui donner, quoi laisser de côté, et quand repartir de zéro.
Le niveau trois, c’est l’appel d’outils. C’est là que vous donnez à Claude la capacité d’utiliser vos vrais outils, Jira, Slack, GitHub, Forcell, via des MCP. Un MCP, c’est ni plus ni moins qu’un port USB pour l’IA. Ça permet à Claude de cliquer sur des boutons dans vos applications réelles, pas juste d’écrire du code qui reste dans un dossier.
Le niveau quatre, c’est le développement piloté par spec, en utilisant des frameworks comme Superpowers. Au lieu de nourrir Claude un prompt à la fois, vous écrivez une spec d’abord. Ce que vous construisez, comment ça doit se comporter, et à quoi ressemble le résultat final. Mais voilà la partie que la plupart des gens sautent. Avant que Claude n’exécute quoi que ce soit, il doit vous poser des questions de clarification. Parce que l’IA ne sera jamais sur la même longueur d’onde que vous tant qu’elle ne pose pas de questions. Un vrai workflow de spec force Claude à combler cet écart d’abord. Que fait ce bouton ? Que se passe-t-il en cas d’erreur ? Sur quelle stack on travaille ? C’est seulement après avoir répondu à tout ça qu’il commence à construire. C’est ça, la différence entre le vibe coding et vraiment livrer du logiciel.
Mais même au niveau quatre, vous restez une personne, une session, à tout pousser vous-même. Le niveau cinq, c’est l’OS Agentique. Vous écrivez vos tâches sur un tableau. Littéralement, vous les déposez dans la colonne planning, et vous lancez /superboard run. C’est tout. Ça commence à exécuter ces tâches une par une, en continu, en arrière-plan. Vous n’avez pas à vous en préoccuper.
Voilà comment ça s’enchaîne. Un agent builder récupère la tâche et écrit le code. Quand c’est fini, la carte passe en QA. Un agent QA la teste. Si ça passe, la carte va chez le reviewer. Si le QA attrape un bug, ça revient dans la colonne précédente pour que le builder puisse le corriger. Et cette boucle continue de tourner, tâche après tâche, pendant que vous faites littéralement autre chose. Vous n’écrivez plus de code. Vous ne faites même plus de prompting. Vous dirigez une équipe qui construit des applis entières pendant que vous dormez.
Pourquoi 90% des utilisateurs restent bloqués au niveau un
La raison est simple : le niveau un donne l’illusion de la productivité. Vous tapez un prompt, Claude répond, vous avez l’impression d’avancer vite. Sauf que cette vitesse est un mirage dès que le projet prend de l’ampleur.
Le problème du prompting brut, c’est qu’il n’y a aucune structure. Vous écrivez une instruction, Claude génère du code, vous testez, ça casse, vous revenez avec un autre prompt, Claude régénère autre chose, et vous recommencez. C’est une boucle réactive où vous passez votre temps à corriger des trucs que l’IA aurait pu anticiper si elle avait eu le bon contexte dès le départ.
Ce qui manque au niveau un, c’est la mémoire. Claude ne se souvient pas de ce que vous avez fait il y a trois sessions. Il ne sait pas pourquoi vous avez pris telle décision d’architecture la semaine dernière. Chaque nouveau prompt repart quasiment de zéro. Les gens qui codent comme ça finissent par accumuler de la dette technique à une vitesse absurde, et au bout d’un moment, le projet devient tellement bordélique que Claude lui-même n’arrive plus à s’y retrouver.
Passer au niveau deux change déjà radicalement la donne, parce que vous arrêtez de jeter du contexte en vrac dans la fenêtre et vous commencez à être stratégique sur ce que Claude voit et ne voit pas.
La fenêtre de contexte : le goulot d’étranglement que personne ne voit venir
200 000 tokens, c’est énorme sur le papier. Ça fait environ 150 000 mots, l’équivalent d’un roman de taille moyenne. Mais la performance n’est pas linéaire.
Passé 100 000 tokens, Claude commence à perdre le fil. Pas d’un coup sec, non, c’est plus insidieux que ça. Il oublie des détails au milieu du contexte, il mélange des instructions qui étaient claires au début, il priorise mal ce qui compte vraiment. C’est comme si vous lisiez un roman de 500 pages et qu’on vous demandait de résumer précisément ce qui se passe page 237. Vous vous souvenez des grandes lignes, mais les détails, vous les inventez à moitié.
L’ingénierie de contexte, c’est traiter la mémoire de Claude comme une ressource rare. Vous ne balancez pas toute votre codebase, toute votre doc, toutes vos notes de réunion dans le prompt. Vous faites le tri. Vous gardez ce qui est pertinent pour la tâche en cours et vous laissez tomber le reste. Et surtout, vous savez quand reset. Parfois, repartir d’une fenêtre propre avec un résumé bien ficelé de l’état actuel du projet est plus efficace que de continuer à empiler du contexte dégradé.
C’est un skill qui s’apprend. Au début, on a tous le réflexe de vouloir tout donner à Claude pour être sûr qu’il ne rate rien. Mais plus d’infos ne veut pas dire de meilleures réponses. Ça veut juste dire plus de bruit.
Les MCP : quand Claude clique sur vos boutons
Le niveau trois marque un vrai changement de paradigme. Jusque-là, Claude vit dans un bac à sable. Il écrit du code, il vous le donne, et c’est vous qui faites le boulot de l’intégrer dans le monde réel.
Avec les MCP, le Model Context Protocol, Claude sort du bac à sable. Il peut interagir directement avec vos outils. Créer un ticket Jira. Pousser une branche sur GitHub. Envoyer un message Slack. Lire la doc de votre API interne.
L’analogie du port USB est parfaite. Vous branchez un outil, Claude le reconnaît, et il peut l’utiliser. Pas besoin de réinventer une intégration à chaque fois. Le protocole est standardisé. Ça veut dire que Claude ne se contente plus de générer du code que vous allez copier-coller dans votre IDE. Il agit directement sur votre environnement de travail.
Pour les développeurs qui bossent en équipe, c’est un accélérateur massif. Imaginez : vous discutez d’un bug dans Slack, Claude lit le fil, crée le ticket Jira avec le bon contexte, écrit le fix, et pousse la PR sur GitHub. Tout ça pendant que vous êtes en réunion. Vous revenez, et le boulot est fait, ou du moins bien avancé.
Le piège du niveau trois, c’est de croire que donner des outils à Claude suffit à le rendre autonome. Ça lui donne des bras, mais pas encore de cerveau stratégique. Pour ça, il faut monter au niveau quatre.
Spec driven development : faire réfléchir Claude avant de coder
Le niveau quatre, c’est là où on arrête de traiter Claude comme un exécutant et on commence à le traiter comme un ingénieur. La différence tient en une phrase : poser des questions avant d’écrire du code.
Le workflow classique de vibe coding, c’est : vous avez une idée, vous la décrivez en trois phrases, Claude pond 400 lignes de code, vous testez, ça fait à peu près ce que vous vouliez, mais pas exactement, vous ajustez le prompt, Claude regénère, et ainsi de suite. C’est rapide au début, mais chaque itération vous éloigne un peu plus d’un truc propre.
Le spec driven development renverse la logique. Avant d’écrire une seule ligne, Claude doit clarifier ce que vous voulez vraiment. Il pose des questions. Que doit faire ce bouton exactement ? Quel comportement en cas d’erreur ? On est sur quelle stack ? Quelles sont les contraintes de performance ?
Ces questions ne sont pas du temps perdu. Elles sont la seule façon de s’assurer que ce que Claude va construire correspond à ce que vous avez en tête. Parce que vous croyez avoir été clair, mais vous ne l’êtes jamais autant que vous le pensez. Il y a toujours des implicites, des suppositions, des détails que vous avez oublié de mentionner parce qu’ils vous semblent évidents. Sauf qu’ils ne le sont pas pour Claude.
Le framework Superpowers dont parle la vidéo structure ce processus. Vous écrivez une spec : ce que vous construisez, comment ça doit se comporter, à quoi ressemble le résultat final. Claude lit la spec, pose ses questions, vous répondez, et seulement après il commence à coder. Le résultat, c’est du code qui fait exactement ce qui est prévu, pas une approximation qui nécessite six allers-retours pour être corrigée.
C’est la différence entre shipper un produit fini et accumuler des prototypes cassés.
L’OS Agentique : votre équipe de dev qui tourne toute seule
Le niveau cinq, c’est le saut conceptuel. Vous n’êtes plus un développeur qui utilise Claude. Vous êtes un chef de projet qui supervise une équipe d’agents IA.
Le setup est simple : un tableau avec des colonnes. Planning, Build, QA, Review, Done. Vous balancez vos tâches dans la colonne planning. Vous lancez /superboard run. Et vous partez faire autre chose.
Ce qui se passe ensuite, c’est une chaîne de production automatisée. Un agent builder récupère la première tâche et écrit le code. Quand il a fini, la carte passe automatiquement en QA. Un agent QA prend le relais et teste le code. Si les tests passent, la carte avance vers le reviewer. Si le QA trouve un bug, la carte repart en arrière, le builder corrige, et le cycle recommence.
Pas d’intervention humaine. Pas de prompting manuel. Pas de session à relancer. Le système tourne en continu, tâche après tâche, jusqu’à ce que le tableau soit vide.
Ce qui est fondamental ici, c’est que le rôle du développeur change complètement. Vous n’écrivez plus de code. Vous ne faites même plus de prompting. Vous définissez ce qui doit être fait, vous le mettez dans le pipeline, et l’OS Agentique exécute. Vous gérez une équipe, pas un outil.
La boucle builder-QA-reviewer reproduit exactement le workflow d’une équipe de dev humaine, sauf qu’elle tourne 24 heures sur 24, sans pause, sans réunion, sans friction. Vous pouvez littéralement lancer le board le soir et vous réveiller avec des fonctionnalités terminées le lendemain matin.
Pourquoi la plupart des gens n’atteindront jamais le niveau cinq
Ce n’est pas une question de compétence technique. C’est une question de mindset.
Le niveau un est confortable parce qu’il donne l’impression de contrôle. Vous tapez, Claude répond, vous gardez la main. Monter dans les niveaux, c’est accepter de lâcher ce contrôle progressivement. Au niveau trois, vous laissez Claude toucher à vos vrais outils. Au niveau quatre, vous acceptez qu’il vous pose des questions au lieu d’exécuter bêtement. Au niveau cinq, vous lui confiez entièrement la chaîne de production.
Chaque étape demande de faire confiance au système. Et la plupart des développeurs ne sont pas prêts à faire ce saut. Ils préfèrent rester dans la boucle, garder le contrôle, vérifier chaque ligne. C’est rassurant, mais c’est aussi ce qui les plafonne.
L’autre frein, c’est que les niveaux supérieurs demandent de la rigueur en amont. Écrire une bonne spec, configurer correctement ses MCP, structurer son board agentique, tout ça prend du temps au début. Les gens veulent aller vite, donc ils sautent ces étapes. Et ils restent coincés au niveau un, à écrire des prompts et espérer que ça passe.
Points clés à retenir
- Le niveau un, le prompting brut, donne une illusion de vitesse mais ne scale pas. Passé une certaine complexité, ça casse.
- La fenêtre de contexte de Claude fait 200 000 tokens, mais les performances chutent après 100 000. L’ingénierie de contexte consiste à savoir quoi lui donner, quoi laisser de côté, et quand repartir de zéro.
- Les MCP sont comme des ports USB pour l’IA. Ils permettent à Claude d’interagir directement avec Jira, Slack, GitHub et vos autres outils, au lieu de juste générer du code dans le vide.
- Le spec driven development force Claude à poser des questions de clarification avant de coder. C’est ce qui fait la différence entre du vibe coding approximatif et du logiciel qui ship vraiment.
- L’OS Agentique transforme Claude en une équipe complète : un builder écrit le code, un QA le teste, un reviewer valide, et la boucle tourne en continu sans intervention humaine.
- Passer les niveaux, c’est accepter de lâcher le contrôle progressif. La plupart des gens restent au niveau un parce qu’ils ne sont pas prêts à faire confiance au système.
Le truc avec ces cinq niveaux, c’est qu’ils ne sont pas juste une classification théorique. Ils décrivent une trajectoire réelle. Chaque niveau débloque un nouveau rapport au code : d’abord vous utilisez Claude comme un assistant, puis comme un outil intégré, puis comme un ingénieur qui réfléchit avec vous, et enfin comme une équipe entière que vous dirigez.
La question n’est pas de savoir si c’est techniquement possible. La vidéo le montre, et le créateur a déjà documenté étape par étape comment construire cet OS Agentique. La vraie question, c’est de savoir si vous êtes prêt à arrêter de tout faire vous-même.