J'ai teste le Ultra Plan de Claude Code — Voici la verite
J'etais en plein milieu d'une migration de dependances — remplacement de tRPC v10 par v11 dans un monorepo avec 47 definitions de routes — quand un ami a laisse un message dans notre Discord : "Tu as essaye /ultraplan ?"
Ma premiere reaction honnete ? Du scepticisme. J'utilisais le mode de planification local de Claude Code religieusement depuis des mois. Shift+Tab, examiner le plan, passer en mode edition, executer. Le rythme etait devenu une seconde nature. Pourquoi deleguerais-je ce processus a une session de planification dans le cloud quand mon workflow terminal etait deja rapide ?
Puis j'ai execute /ultraplan migrate all tRPC v10 routes to v11 with backward-compatible type exports et j'ai vu quelque chose que je n'attendais pas. En quelques secondes, mon terminal m'a fourni une URL. Je l'ai ouverte dans le navigateur. Et la se trouvait un plan d'implementation structure qui ne se contentait pas de lister les fichiers a modifier — il cartographiait les chaines de dependances entre les routes, signalait trois signatures de type incompatibles auxquelles je n'avais pas pense, et generait un diagramme Mermaid montrant l'ordre de migration qui minimiserait les echecs de tests en cours de route.
Mon mode de planification local n'avait jamais fait ca. Pas une seule fois.
C'etait il y a deux semaines. Depuis, j'ai utilise Ultra Plan sur dix prompts differents — des echanges de modeles simples, des refactorisations complexes, du scaffolding greenfield, des audits de securite — le testant contre le mode de planification local a chaque fois. Ce que j'ai decouvert etait plus nuance que "Ultra Plan est meilleur." La verite implique trois modes de planification caches, un systeme d'AB testing que la plupart des utilisateurs ignorent, et un ensemble tres specifique de scenarios ou Ultra Plan est veritablement transformateur par rapport aux cas ou ce n'est qu'une interface plus jolie pour le meme resultat.
Voici tout ce que j'ai appris.
Ce qu'est reellement Ultra Plan (et pourquoi il existe)
Avant d'entrer dans les resultats des tests, il vous faut le bon modele mental. Car Ultra Plan n'est pas simplement "le mode planification mais dans le cloud." L'architecture est fondamentalement differente, et comprendre cette difference change la facon dont on l'utilise.
Quand vous executez le mode de planification local avec Shift+Tab dans Claude Code, la planification se deroule au sein de votre session terminal. Meme fenetre de contexte. Meme instance du modele. Memes contraintes. L'IA lit votre codebase, reflechit aux modifications et presente un plan — le tout dans les limites de votre conversation actuelle.
Ultra Plan casse completement ce modele. Quand vous tapez /ultraplan suivi de votre prompt, Claude Code lance une session de planification dediee dans le Cloud Container Runtime d'Anthropic — ce qu'ils appellent CCR. Cette session distante obtient Opus 4.6, jusqu'a 30 minutes de temps de calcul dedie et un acces a votre depot via un instantane synchronise dans le cloud. La planification se deroule en dehors de votre machine, dans un environnement specialement concu pour l'analyse approfondie.
La difference pratique ? Votre terminal reste libre. Pendant que Ultra Plan elabore votre strategie de migration dans le cloud, vous pouvez continuer a coder, lancer des tests ou demarrer une autre session Ultra Plan pour une tache completement differente. J'ai eu trois sessions Ultra Plan en cours simultanement pendant que je deboguais un probleme CSS en local. Essayez de faire ca avec le mode de planification local.
Une fois le plan pret, vous recevez une URL de session qui s'ouvre dans votre navigateur. Et c'est la que l'experience diverge nettement de tout ce qui existe dans le terminal.
L'interface web qui change la facon dont vous examinez les plans
Je serai direct : l'interface web est la plus grande amelioration de qualite de vie qu'apporte Ultra Plan. Et je dis ca en tant que quelqu'un qui vit dans le terminal.
Quand un plan apparait dans votre navigateur, vous regardez un document enrichi — pas un mur de markdown qui defile dans votre terminal. Des en-tetes. Des sections repliables. Des blocs de code en ligne avec coloration syntaxique. Et de maniere cruciale, deux fonctionnalites qui rendent la planification collaborative veritablement fonctionnelle : des commentaires en ligne sur des parties specifiques du plan, et des reactions emoji pour une signalisation rapide.
Ca semble anodin. Ca ne l'est pas.
Voici pourquoi. Quand j'examine un plan dans le terminal, ma boucle de retour ressemble a ceci : lire le plan, remonter jusqu'a la partie avec laquelle je ne suis pas d'accord, taper "en fait, pour l'etape 3, je prefererais utiliser le patron repository plutot que des requetes directes," attendre que l'IA regenere l'integralite du plan, tout relire. Avec l'interface web, je clique sur l'etape 3, je tape mon commentaire en ligne et je demande une revision ciblee. L'IA met a jour cette section sans toucher au reste. La vitesse d'iteration est considerablement plus rapide.
Les diagrammes Mermaid sont inconsistants — parfois ils apparaissent, parfois non (j'y reviendrai). Mais quand ils sont la, ils sont veritablement utiles. Pour la migration tRPC, Ultra Plan a genere un diagramme de flux de dependances montrant quelles routes dependaient de definitions de types partagees, ce qui signifiait que je pouvais voir d'un coup d'oeil que migrer userRouter avant authRouter casserait trois consommateurs en aval. Cette visualisation m'aurait pris vingt minutes a etablir manuellement.
Apres avoir approuve un plan — avec ou sans revisions — vous obtenez trois options :
- Executer dans le cloud — le plan s'execute a distance et peut ouvrir un PR directement
- Implementer ici — teleporter le plan vers votre session terminal actuelle
- Demarrer une nouvelle session — effacer votre conversation actuelle et repartir de zero avec le plan comme contexte
J'utilise l'option 2 environ 80% du temps. Le plan arrive dans mon terminal comme contexte structure, et je continue l'execution en local ou j'ai un controle total sur les operations de fichiers, l'execution des tests et le workflow Git. L'option 1 est tentante pour les taches simples, mais j'ai constate que l'execution beneficie toujours d'une supervision locale — surtout quand le plan concerne des fichiers qui ont change depuis la prise de l'instantane cloud.
Cela dit, le chemin d'execution cloud est la direction que prend Ultra Plan. Et pour les equipes qui veulent un pipeline planification-vers-PR avec une intervention humaine minimale, c'est deja presque au point.
Dix prompts, deux modes, une comparaison honnete
Parler de fonctionnalites, c'est facile. Ce qui compte, c'est la performance. J'ai donc soumis les memes dix prompts a la fois a Ultra Plan et au mode de planification local, en comparant les resultats selon quatre dimensions : vitesse, qualite du plan, detection des risques et exploitabilite.
Voici ce que j'ai teste :
Taches simples :
- Remplacer Qwen 3.5 par Gemma 4 comme modele d'inference local
- Ajouter un bouton bascule mode sombre a un composant React existant
- Renommer une colonne de base de donnees avec une migration
Complexite moyenne : 4. Refactoriser le middleware d'authentification de session vers JWT 5. Ajouter une limitation de debit a tous les endpoints API avec des seuils configurables 6. Migrer un schema Prisma de PostgreSQL vers MySQL
Haute complexite : 7. Mettre a jour tRPC v10 vers v11 dans un monorepo 8. Implementer une couche d'isolation de donnees multi-tenant 9. Ajouter le chiffrement de bout en bout pour les messages utilisateurs 10. Auditer un codebase pour les vulnerabilites OWASP Top 10
Les resultats se sont clairement repartis selon les lignes de complexite — mais pas de la facon que j'attendais.
La ou Ultra Plan a egale le mode local (et rien de plus)
Pour les prompts 1 a 3 — les taches simples — Ultra Plan n'a offert aucun avantage significatif par rapport au mode de planification local. Les plans etaient structurellement similaires. Les memes fichiers ont ete identifies. Les memes etapes ont ete proposees. La seule difference etait la presentation : la sortie d'Ultra Plan etait plus jolie dans le navigateur.
Le remplacement de Qwen 3.5 par Gemma 4 a genere des plans quasi identiques dans les deux modes. Plan local : modifier la configuration du modele, mettre a jour l'endpoint d'inference, ajuster les parametres du tokeniseur, tester. Ultra Plan : memes etapes, descriptions legerement plus detaillees, une note sur la verification de compatibilite — mais rien que je n'aurais pas remarque moi-meme.
Pour les taches simples, l'aller-retour supplementaire vers le cloud ajoute de la latence sans ajouter de perspicacite. Le mode de planification local les a traitees en 15-30 secondes. Ultra Plan a mis 45-90 secondes pour le meme resultat, car la session cloud doit demarrer, synchroniser l'instantane du depot et rendre l'interface web.
Ma recommandation : si vous pouvez decrire le changement en une phrase et que vous savez deja quels fichiers doivent etre modifies, restez en mode de planification local. L'avantage de vitesse est reel.
La ou Ultra Plan a pris l'avantage — et de combien
Les prompts 4 a 6 — complexite moyenne — ont montre le premier ecart significatif. Ultra Plan a commence a reperer des choses que le mode de planification local avait manquees.
La migration JWT (prompt 4) est un bon exemple. Le mode de planification local m'a donne un plan raisonnable : creer l'utilitaire JWT, mettre a jour le middleware d'authentification, modifier l'endpoint de connexion pour emettre des tokens, ajouter la logique de rafraichissement des tokens. Solide. Correct. Mais il a manque le probleme de nettoyage des sessions — les utilisateurs existants avaient des sessions actives qui devaient etre invalidees pendant la fenetre de migration. Il n'a pas non plus mentionne la necessite de mettre a jour la configuration CORS pour le nouveau modele d'en-tete Authorization.
Ultra Plan a detecte les deux. Le plan incluait une etape de migration dediee pour les sessions actives, une strategie de retour en arriere si la verification JWT echouait pour un seuil d'utilisateurs, et une section de mise a jour CORS. La detection des risques etait nettement plus approfondie.
Pour la migration Prisma (prompt 6), le mode de planification local a propose une reecriture directe du schema. Ultra Plan a signale quatre pieges specifiques a MySQL : la difference du type @db.Text, l'absence de support natif des tableaux necessitant une table de jointure, la difference de sensibilite a la casse dans les comparaisons de chaines, et une limitation de longueur d'index qui aurait casse l'un de mes index composites. Trois de ces quatre auraient provoque des erreurs d'execution que j'aurais passe des heures a deboguer.
L'ecart s'est encore creuse avec la haute complexite. La migration de tRPC v10 a v11 (prompt 7) est la ou Ultra Plan a vraiment prouve sa valeur. Le mode de planification local a produit un guide de migration raisonnable. Ultra Plan a produit ce que je ne peux decrire que comme un document d'ingenierie — complet avec l'ordonnancement des dependances, l'analyse de compatibilite des types, une liste des API obsoletes que j'utilisais avec leurs remplacants v11, et une strategie de deploiement progressif me permettant de migrer route par route au lieu de tout d'un coup.
L'audit de securite (prompt 10) a montre la difference la plus spectaculaire. Le mode de planification local a identifie des problemes superficiels : validation d'entree manquante, quelques vecteurs d'injection SQL, des secrets codes en dur. Ultra Plan a trouve ceux-la plus trois problemes plus profonds : une reference directe a un objet non securisee dans l'endpoint de profil utilisateur, une condition de concurrence dans le flux de reinitialisation de mot de passe qui pourrait permettre la reutilisation de tokens, et un limite de debit manquante sur l'endpoint de connexion le rendant vulnerable au credential stuffing. Le plan local a signale 6 problemes. Ultra Plan en a signale 11.
Mais c'est la que l'histoire se complique.
Les trois modes caches dont personne ne vous parle
Apres avoir execute ces tests, l'inconsistance me derangeait. Pourquoi Ultra Plan generait-il des diagrammes Mermaid pour certains prompts mais pas d'autres ? Pourquoi l'audit de securite a-t-il produit une analyse multi-perspectives alors que le changement de modele a produit essentiellement la meme sortie que le mode local ?
J'ai fouille dans le code source de Claude Code — specifiquement les prompts systeme divulgues qui ont fait surface apres l'incident du source map npm en mars 2026 — et j'ai trouve quelque chose qui explique tout.
Ultra Plan n'execute pas un seul mode de planification. Il en execute trois. Et Anthropic les attribue dynamiquement, invisiblement, en fonction de la configuration cote serveur.
Simple Plan est la base. Il est structurellement similaire au mode de planification local — une analyse directe qui identifie les fichiers, propose des etapes et produit un plan propre. Pas de diagrammes. Pas d'analyse multi-perspectives. Quand vous obtenez un Simple Plan, vous recevez essentiellement le mode de planification local avec une interface plus jolie et une execution cloud. C'est ce que j'obtenais pour les taches simples.
Visual Plan ajoute des diagrammes. Meme profondeur analytique que le Simple Plan, mais avec la generation de diagrammes Mermaid et Asy en couche supplementaire. Le diagramme de flux de dependances que j'ai obtenu pour la migration tRPC ? C'etait un Visual Plan. Les diagrammes ne sont pas decoratifs — ils encodent des relations structurelles que le texte brut peine a communiquer. Mais l'analyse elle-meme n'est pas plus profonde que le Simple Plan.
Deep Plan est celui qui change la donne. Et c'est celui qui a explique mes resultats d'audit de securite.
Deep Plan active un systeme multi-agents. Pas un seul modele reflechissant a votre probleme — plusieurs sous-agents specialises, chacun concentre sur une dimension differente :
- Un agent analyse le code et l'architecture — examinant les implications structurelles du changement
- Un agent localise tous les fichiers necessitant une modification — pas seulement les cibles evidentes, mais les consommateurs en aval et les fichiers de test
- Un agent identifie les risques, les cas limites et les conflits de dependances — le specialiste du "qu'est-ce qui pourrait mal tourner"
- Un agent examine le plan complet pour la coherence logique, les attentuations manquantes et l'ordre d'execution
Ces agents s'executent en parallele, contribuent leurs decouvertes a un contexte partage, et le systeme synthetise leurs sorties en un plan unifie. L'audit de securite qui a trouve 11 problemes au lieu de 6 ? C'etait Deep Plan. L'agent de risque a specifiquement signale la condition de concurrence dans le flux de reinitialisation de mot de passe — quelque chose qu'une analyse en un seul passage manque systematiquement parce qu'elle necessite de raisonner sur des etats concurrents.
Voici la partie qui m'a frustre : vous ne pouvez pas choisir quel mode vous recevez.
Vous faites partie d'un test AB (et Anthropic le sait)
L'attribution du mode n'est pas aleatoire au sens du pile ou face. Anthropic la controle via des configurations cote serveur — essentiellement un systeme de feature flags qui determine quelle variante de planification chaque utilisateur recoit pour chaque session. Le code source divulgue confirme qu'il s'agit d'un framework d'AB testing delibere.
Anthropic mesure plusieurs choses a travers ce systeme :
- Les taux d'acceptation des utilisateurs pour chaque variante de planification — les utilisateurs approuvent-ils et executent-ils les Simple Plans au meme taux que les Deep Plans ?
- L'efficacite des prompts de planification — quels prompts systeme produisent des plans que les utilisateurs suivent effectivement ?
- Les performances du modele — l'infrastructure pourrait etre utilisee pour tester de prochaines versions du modele les unes contre les autres dans des scenarios de planification en direct
Cela explique pourquoi mon experience etait inconsistante d'une execution a l'autre. Certaines de mes sessions Ultra Plan tombaient sur Simple Plan (quasi identique au mode local), tandis que d'autres tombaient sur Deep Plan (considerablement meilleur). Je ne comparais pas "Ultra Plan vs Plan Local" de maniere controlee. Je comparais "la variante que le systeme AB d'Anthropic m'avait attribuee" contre le plan local.
Une fois que j'ai realise cela, je suis revenu en arriere et j'ai reexecute les prompts de haute complexite plusieurs fois. La migration tRPC a produit des plans sensiblement differents sur trois executions — un avec des diagrammes, un sans, un avec l'analyse de risques multi-agents. Meme prompt. Meme etat du depot. Differentes variantes de planification.
Pour les utilisateurs qui se soucient de la coherence — et si vous construisez du logiciel de production, vous devriez — c'est la chose la plus importante a comprendre sur Ultra Plan en ce moment. Le plafond de qualite est authentiquement eleve. Le plancher de qualite est essentiellement le mode de planification local avec une latence supplementaire. Et vous n'avez aucun controle sur lequel vous obtenez.
Cette incertitude est la raison pour laquelle, pour l'instant, j'ai adopte un workflow specifique qui me donne le meilleur des deux mondes. Mais avant de le partager, il y a encore un detail technique qui merite d'etre compris.
Comment Ultra Plan lit votre codebase (et ou il echoue)
Quand vous declenchez /ultraplan, Claude Code ne telecharge pas l'integralite de votre depot vers le cloud d'Anthropic. Il cree un instantane — une copie a un instant donne synchronisee vers l'environnement CCR ou la session de planification s'execute. L'agent de planification lit ensuite depuis cet instantane comme s'il s'agissait d'un codebase local.
Cela cree une limitation subtile mais importante : la session cloud ne voit pas les modifications que vous effectuez apres avoir lance Ultra Plan. Si vous declenchez un Ultra Plan pour une migration de base de donnees, puis modifiez le schema en local pendant que le plan est genere, le plan sera base sur l'ancien schema. Ca m'est arrive une fois — j'ai approuve un plan qui faisait reference a une colonne que j'avais deja renommee pendant la fenetre de planification.
La fenetre de calcul de 30 minutes est genereuse pour la plupart des taches. Ma session Ultra Plan la plus longue — l'audit OWASP complet — s'est terminee en environ 8 minutes. Mais la fenetre compte pour les depots extremement volumineux ou l'analyse initiale du codebase prend un temps considerable. Anthropic n'a pas publie de limites de taille de depot pour le CCR, mais dans mes tests, les depots de moins de 500 Mo de code source (excluant node_modules et les artefacts de build) ont ete planifies sans probleme.
Encore une chose sur l'approche par instantane : Ultra Plan fonctionne mieux avec les depots heberges sur GitHub. La synchronisation repose sur le remote de votre depot, ce qui signifie que les depots uniquement locaux ou les depots avec d'importants changements non commites peuvent produire des plans bases sur un contexte incomplet. J'ai appris a toujours commiter et pousser avant d'executer /ultraplan pour quoi que ce soit d'important.
Si vous preferiez que quelqu'un mette en place un workflow Claude Code optimise de A a Z — avec integration Ultra Plan, skills personnalises et orchestration d'agents — j'accepte ce type de missions. Vous pouvez voir ce que j'ai construit sur fiverr.com/s/EgxYmWD.
Mon workflow reel — Comment j'utilise Ultra Plan aujourd'hui
Apres deux semaines de tests, voici le workflow sur lequel je me suis arrete. Ce n'est pas "toujours utiliser Ultra Plan" ni "l'ignorer completement." C'est conditionnel, et les conditions sont specifiques.
Pour les taches que je peux decrire en une phrase et ou je connais deja les fichiers concernes : Mode de planification local. Pas d'aller-retour cloud necessaire. Shift+Tab, examiner, executer. Rapide.
Pour les taches impliquant plus de 5 fichiers, des chaines de dependances ou des changements incompatibles : Ultra Plan. L'analyse multi-agents (quand on obtient Deep Plan) detecte des risques que la planification en un seul passage manque systematiquement. L'interface web rend l'iteration plus rapide. Meme quand j'obtiens Simple Plan, l'examen dans le navigateur est plus confortable pour les plans complexes.
Pour les audits de securite et les revues d'architecture : Ultra Plan, toujours. La variante Deep Plan est considerablement meilleure pour trouver les vulnerabilites non evidentes. Et puisque ce sont des evaluations a enjeux eleves ou manquer un cas limite a des consequences reelles, je prefere accepter le cout en latence pour la chance d'une analyse plus approfondie.
Pour les changements urgents ou chaque seconde compte : Mode de planification local. L'aller-retour cloud d'Ultra Plan ajoute 30-90 secondes avant meme de voir le plan. Quand la production est en panne et que j'ai besoin d'un correctif rapide, cette latence est inacceptable.
Pour le multitache : Ultra Plan est imbattable. Je lance regulierement deux ou trois sessions Ultra Plan pour differentes taches, puis je les examine et les approuve au fur et a mesure qu'elles se terminent. Ce workflow de planification parallele est quelque chose que le mode local ne peut tout simplement pas faire — chaque plan local bloque votre terminal jusqu'a ce qu'il soit termine.
L'astuce du Skill Deep Plan
Voici le point le plus tactique de tout cet article.
Puisqu'Anthropic ne vous laisse pas choisir quelle variante de planification vous recevez, et que Deep Plan produit les meilleurs resultats de loin, j'ai extrait la structure du prompt systeme de Deep Plan et l'ai transformee en un skill personnalise Claude Code.
L'approche : creer un skill qui reproduit le schema d'analyse multi-agents de Deep Plan localement. Le skill indique a Claude Code d'analyser le prompt a travers quatre lentilles sequentielles — impact architectural, identification des fichiers, evaluation des risques et revision du plan — avant de synthetiser un plan unifie. Ce n'est pas identique au vrai Deep Plan (qui execute de vrais agents paralleles dans CCR), mais ca reproduit environ 80% de l'amelioration de qualite dans mes tests.
Voici le squelette :
---
name: deep-plan
description: >
Multi-perspective planning for complex code changes.
Trigger when user asks for a detailed plan, migration
strategy, or architecture review.
---
## Deep Plan — Multi-Agent Analysis Skill
### Phase 1: Architecture Analysis
Analyze the requested change from a structural perspective.
Identify affected modules, data flows, and integration points.
Map dependencies between components.
### Phase 2: File Discovery
Locate ALL files that need modification — not just the obvious
targets. Include test files, type definitions, configuration
files, and downstream consumers.
### Phase 3: Risk Assessment
For each proposed change, identify:
- Edge cases that could cause runtime failures
- Breaking changes for existing consumers
- Race conditions or state management issues
- Security implications
- Rollback complexity
### Phase 4: Plan Synthesis & Review
Combine findings from all phases into a unified implementation
plan. Order steps by dependency chain. Flag any phase where
findings conflict. Include rollback procedures for each step.
### Output Format
Use numbered steps with sub-items. Include file paths.
Generate a Mermaid dependency diagram if more than 5 files
are affected. End with a risk summary table.
Cela me donne une analyse de qualite Deep Plan a la demande, sans la loterie de l'AB testing. Le compromis est la vitesse — l'execution locale prend plus de temps qu'un plan en un seul passage car ce sont quatre passes d'analyse sequentielles. Mais pour les taches complexes, les deux minutes supplementaires de planification font economiser des heures de debogage.
J'utilise toujours la commande /ultraplan reelle pour les scenarios de multitache et quand je veux l'experience de revision via l'interface web. Mais pour mes planifications les plus critiques — celles ou j'ai besoin d'une profondeur garantie — le skill personnalise me donne un controle qu'Ultra Plan n'offre pas actuellement.
Ce que cela revele sur la direction de Claude Code
Prenez un moment de recul par rapport aux details tactiques et observez ce qu'Ultra Plan revele sur la feuille de route d'Anthropic.
L'infrastructure CCR n'est pas uniquement destinee a la planification. C'est un environnement d'execution cloud polyvalent. Aujourd'hui, il execute des sessions de planification. Demain — et c'est de la speculation basee sur l'architecture, pas des informations privilegiees — il pourrait executer des sessions d'implementation completes, des suites de tests, voire des pipelines d'integration continue alimentes par des agents Claude Code.
Le framework d'AB testing est tout aussi revelateur. Anthropic utilise des sessions Ultra Plan en direct pour optimiser les prompts de planification et mesurer quelles approches produisent des plans que les utilisateurs executent reellement. C'est une boucle de retour en direct pour ameliorer les capacites de planification du modele. Chaque fois que vous approuvez ou rejetez un Ultra Plan, vous contribuez des donnees a ce processus d'optimisation.
L'architecture multi-agents de Deep Plan est la piece la plus visionnaire. Aujourd'hui, elle fait tourner trois a quatre sous-agents specialises pour la planification. Le schema se generalise a toute tache complexe : agents d'implementation, agents de test, agents de documentation, agents de revue de securite — chacun avec des prompts systeme specialises, s'executant en parallele, synthetisant leurs sorties. La fonctionnalite d'equipes d'agents de Claude Code fait deja une partie de cela en local. L'infrastructure d'Ultra Plan suggere qu'Anthropic construit l'epine dorsale cloud pour l'executer a grande echelle.
J'anticipe trois choses dans les six prochains mois :
- Des modes de planification selectionnables par l'utilisateur — la phase d'AB testing prendra fin et nous pourrons choisir entre Simple, Visual ou Deep Plan explicitement
- Des ameliorations de l'execution cloud — executer des plans dans CCR avec creation directe de PR deviendra le chemin par defaut pour les equipes
- Des sessions de planification persistantes — la possibilite de sauvegarder, partager et revenir a des sessions Ultra Plan entre les membres de l'equipe
Que ces predictions se realisent ou non, la direction est claire : Claude Code devient un outil de planification d'abord ou l'execution est la partie facile.
Les compromis honnetes que vous devez connaitre
Ultra Plan n'est pas une amelioration pure. Voici les limitations que j'ai rencontrees en utilisation reelle, et aucun des materiels promotionnels ne les mentionne.
Le decalage de l'instantane est reel. Votre session cloud planifie contre une copie figee de votre depot. Si vous developpez activement pendant que le plan est genere, vous recevrez des recommandations basees sur du code obsolete. Faites toujours un commit et un push avant de lancer Ultra Plan pour des taches critiques.
Vous ne pouvez pas controler la variante de planification. C'est ma plus grande frustration. Deep Plan est nettement meilleur que Simple Plan, mais le systeme decide lequel vous obtenez. Pour une fonctionnalite censee aider a la planification a enjeux eleves, l'aleatoire ressemble a un defaut de conception — meme si la justification de l'AB testing a du sens du point de vue d'Anthropic.
L'interface web impose un changement de contexte. Passer du terminal au navigateur pour examiner un plan rompt le flux. Je suis un developpeur dirige par le clavier. Chaque fois que j'attrape la souris pour cliquer sur une section du plan dans le navigateur, une petite partie de moi meurt. Les commentaires en ligne sont super une fois qu'on y est, mais la transition du terminal au navigateur est brutale.
La latence compte pour le travail iteratif. Quand je suis dans un cycle serre construction-test-debogage, le temps de reponse de 15 secondes du mode de planification local bat les 45-90 secondes d'Ultra Plan a chaque fois. Ultra Plan est un outil de reflexion profonde, pas un outil de retour rapide.
La fenetre de 30 minutes est en grande partie theorique. Aucune de mes sessions Ultra Plan n'a depasse 10 minutes. Mais si vous travaillez avec un codebase exceptionnellement volumineux ou demandez une analyse qui necessite la lecture de milliers de fichiers, la fenetre pourrait devenir une contrainte. Je ne l'ai personnellement pas atteinte.
Necessite Claude Code sur le web. Ultra Plan a besoin d'un compte connecte et d'un depot heberge sur GitHub. Si vous travaillez avec des depots uniquement locaux, des instances GitLab privees ou dans un environnement isole, Ultra Plan n'est pas une option. Le mode de planification local est votre seul chemin.
Ce ne sont pas des arguments redhibitoires. Ce sont le genre de points de friction qui comptent quand vous decidez si vous adoptez un nouvel outil pour du travail de production versus simplement jouer avec sur des projets secondaires. Connaissez-les avant de vous lancer.
Alors, devriez-vous vraiment utiliser Ultra Plan ?
Il y a deux semaines, j'aurais donne une reponse simple. Maintenant elle est plus honnete.
Si vous faites des refactorisations complexes, des mises a jour de dependances, des audits de securite ou des modifications d'architecture — et que vous pouvez tolerer la loterie de l'AB testing — Ultra Plan vaut la peine d'etre ajoute a votre workflow. Le plafond de qualite quand vous tombez sur Deep Plan est significativement plus eleve que tout ce que produit le mode de planification local. L'interface web rend la revision et l'iteration des plans plus rapides pour les modifications non triviales. Et la capacite de planification parallele est veritablement unique.
Si la majeure partie de votre travail implique des modifications ciblees sur des fichiers connus, le mode de planification local reste plus rapide et plus previsible. N'ajoutez pas de latence cloud pour des taches qui n'ont pas besoin d'une analyse a l'echelle du cloud.
Si vous voulez une qualite Deep Plan garantie sans l'aleatoire, construisez le skill personnalise que j'ai decrit plus haut. Executez-le localement. Acceptez le compromis de vitesse pour la garantie de profondeur.
Et si vous etes le genre de developpeur qui suit de pres le comportement de ses outils — ce qui, si vous avez lu jusqu'ici, est probablement votre cas — continuez a surveiller les schemas d'AB testing. Executez le meme prompt plusieurs fois. Remarquez quand vous obtenez des diagrammes versus quand non. Remarquez quand l'analyse des risques est superficielle versus chirurgicale. Comprendre quelle variante vous recevez vous aide a calibrer votre confiance dans le resultat.
Ce que personne ne dit sur Ultra Plan, c'est ceci : ce n'est pas une fonctionnalite finalisee. C'est une preversion de recherche qui sert simultanement de plateforme d'optimisation en direct pour les capacites de planification d'Anthropic. Vous etes en train d'utiliser un outil et de l'entrainer en meme temps. Ce n'est pas une critique — c'est la realite de la construction a la frontiere du developpement assiste par IA. Mais cela signifie que l'Ultra Plan que vous utilisez aujourd'hui ne sera pas l'Ultra Plan que vous utiliserez dans trois mois. Et cette version future, alimentee par des millions de sessions de planification reelles, sera presque certainement meilleure que tout ce que l'un d'entre nous peut construire avec des skills personnalises.
Je garde /ultraplan dans ma rotation quotidienne. Je garde mon skill Deep Plan en reserve. Et j'execute les deux, compare les resultats et archive chaque difference comme un point de donnees.
Car les ingenieurs qui comprennent leurs outils en profondeur — pas seulement ce que les outils font, mais comment ils fonctionnent sous le capot — sont ceux qui en tirent le meilleur parti. C'est vrai depuis le premier compilateur, et ca l'est toujours.
Questions frequemment posees
Comment lancer Ultra Plan dans Claude Code ?
Tapez /ultraplan suivi de votre prompt de planification dans le terminal Claude Code. La session demarre dans le cloud d'Anthropic et vous recevez une URL dans le navigateur pour examiner le plan genere. Vous avez besoin d'un compte Claude Code on the web et d'un depot heberge sur GitHub.
Ultra Plan est-il plus rapide que le mode de planification local ?
Pour le calcul de planification, Ultra Plan s'execute jusqu'a 2 fois plus vite car il utilise des ressources cloud dediees avec Opus 4.6. Mais l'aller-retour total — incluant le demarrage cloud et l'examen dans le navigateur — ajoute 30-90 secondes par rapport aux 15-30 secondes de temps de reponse du mode de planification local pour les taches simples.
Puis-je choisir entre Simple Plan, Visual Plan et Deep Plan ?
Pas actuellement. Anthropic attribue les variantes de planification via une configuration cote serveur dans le cadre de son framework d'AB testing. Vous pouvez approximer la qualite de Deep Plan en construisant un skill personnalise qui reproduit son schema d'analyse multi-agents localement.
Ultra Plan fonctionne-t-il avec les depots prives ?
Ultra Plan necessite un depot GitHub accessible via votre compte Claude Code on the web. Les depots uniquement locaux, les depots heberges sur GitLab et les environnements isoles ne sont pas pris en charge. Pour ces configurations, le mode de planification local reste la seule option.
Que se passe-t-il avec mon code pendant les sessions Ultra Plan ?
Claude Code cree un instantane en lecture seule de votre depot synchronise vers le cloud. L'agent de planification analyse cet instantane — il ne peut pas modifier vos fichiers locaux. Les modifications ne se produisent qu'apres que vous avez approuve le plan et choisi un chemin d'execution (cloud ou local).
Travaillons ensemble
Vous cherchez a construire des systemes d'IA, automatiser des workflows ou faire evoluer votre infrastructure technologique ? Je serais ravi de vous aider.
- Fiverr (developpements sur mesure et integrations) : fiverr.com/s/EgxYmWD
- Portfolio : mejba.me
- Ramlit Limited (solutions entreprise) : ramlit.com
- ColorPark (design et branding) : colorpark.io
- xCyberSecurity (services de securite) : xcybersecurity.io
