Mon workflow Claude Code pour refondre un site existant en 1 semaine

Quand un client me confie la refonte d'un site qui tourne déjà, je lui dis toujours la même chose : le plus dur, ce n'est jamais le nouveau site. C'est l'ancien. Comprendre ce qui existe, ce qui marche, ce qui est cassé, ce que personne n'ose plus toucher depuis des années. Avant, ce travail me prenait 4 à 6 semaines pour une refonte complète. Aujourd'hui, avec Claude Code et une méthode que j'ai fini par stabiliser à force d'essais, je boucle la même refonte en une semaine. Voici exactement comment je m'y prends, et surtout où ça coince encore.

Pourquoi une refonte traîne autant

Une refonte n'est pas un projet neuf. Sur un projet neuf, tu pars d'une page blanche, tu décides de tout, tu n'as de comptes à rendre à personne. Sur une refonte, tu hérites de décisions prises par d'autres, parfois il y a longtemps, sans documentation. La base de données a été bricolée au fil des ans. Des colonnes portent des noms qui ne veulent plus rien dire. Des bouts de code sont là « au cas où ». Et personne dans l'équipe ne sait te dire pourquoi telle page existe encore.

Le temps ne part donc pas dans le développement. Il part dans l'archéologie. Avant Claude Code, je passais l'essentiel de ces 4 à 6 semaines à reconstituer mentalement un système que je n'avais pas conçu. Le code venait après, presque vite. C'est ce déséquilibre que mon workflow attaque en priorité : raccourcir la phase de compréhension, pas la phase de code.

Mon workflow en quatre étapes

Tout tient dans un enchaînement simple : audit de l'existant, reconstruction du schema.sql, blueprint, puis vibe-coding. Chaque étape produit un artefact concret qui nourrit la suivante. Rien de magique, mais l'ordre compte énormément. Sauter une étape, c'est reporter le problème sur la suivante.

1. Auditer l'existant

Je commence par donner à Claude Code accès au code source actuel et je lui demande de cartographier ce qu'il voit. Pas de le réécrire, pas de le juger : juste de le décrire. Quelles pages, quels points d'entrée, quelles dépendances, quels appels à la base. En quelques heures, j'obtiens une vue d'ensemble qui me prenait avant des jours à reconstruire à la main, fichier après fichier.

L'intérêt n'est pas que l'outil comprenne tout, tout seul. C'est qu'il me rende le terrain lisible assez vite pour que, moi, je prenne les décisions. Je reste celui qui tranche ce qu'on garde et ce qu'on jette. Claude Code défriche, je décide.

2. Reconstruire le schema.sql

C'est l'étape que je ne saute jamais, et de loin la plus rentable. Avant d'écrire la moindre ligne du nouveau site, je reconstruis un schema.sql propre et complet de la base existante. La structure réelle des tables, les colonnes, les types, les relations telles qu'elles sont vraiment, pas telles qu'on les imagine.

Pourquoi tant insister ? Parce que sans ce fichier, l'outil invente. Il devine des noms de tables, suppose des colonnes, et tu te retrouves avec du code qui a l'air juste mais qui casse au premier vrai appel. Avec un schema.sql sous les yeux, Claude Code arrête de deviner. Chaque requête qu'il écrit s'appuie sur la structure réelle. C'est devenu pour moi une règle absolue : pas de SQL sans le schéma sous la main.

3. Le blueprint

Une fois l'existant compris et la base cartographiée, je rédige un blueprint : le plan de ce que sera le nouveau site. Les pages, les parcours, ce qui change par rapport à l'ancien, ce qui reste. Ce document, je le construis avec Claude Code, mais c'est moi qui le valide ligne par ligne. C'est mon garde-fou contre la dérive.

Le blueprint sert à deux choses. D'abord, à aligner le client : il voit noir sur blanc ce qu'il va recevoir avant qu'une seule page soit codée. Ensuite, à cadrer l'outil. Quand je lance la phase de code, Claude Code ne part pas dans tous les sens : il a un plan, un schéma de données et une carte de l'existant. Le contexte est posé.

4. Le vibe-coding

C'est seulement là que j'écris du code, et c'est la partie la plus rapide. J'avance par itérations courtes, en dialogue avec Claude Code, page par page, fonctionnalité par fonctionnalité. Comme l'audit, le schéma et le blueprint existent déjà, l'outil produit du code cohérent avec l'ensemble au lieu de réinventer à chaque prompt.

Le vibe-coding sans préparation, c'est ce que je vois faire partout, et c'est exactement ce qui ne marche pas sur une refonte. Tu obtiens des bouts qui fonctionnent isolément mais qui ne tiennent pas ensemble. Mes trois premières étapes ne sont rien d'autre que la préparation qui rend le vibe-coding fiable. L'ordre fait tout.

Les outils que j'utilise

Côté code, Claude Code fait tout le travail lourd, du premier audit jusqu'à la dernière itération. C'est le cœur du workflow, et c'est lui qui encaisse le gros de la charge.

Côté design, je travaille avec Figma et Pencil. Figma pour poser les maquettes, l'organisation des pages, le rendu visuel ; Pencil pour les croquis rapides en amont, quand je veux juste fixer une idée d'écran sans entrer dans le détail. Ces deux-là vivent en parallèle de Claude Code, ils ne le remplacent pas. Le design reste un travail humain ; l'outil exécute une fois que la direction est claire.

Là où ça coince

Je serais malhonnête de vendre ça comme une recette qui marche partout. La méthode tient parce que je l'applique sur des stacks simples. Sur du PHP procédural, par exemple, ça fonctionne très bien : le code est direct, la logique se lit de haut en bas, et Claude Code suit le fil sans se perdre.

Dès que la stack se complique, l'affaire devient plus délicate. Sur des frameworks lourds, avec des couches d'abstraction, des conventions implicites et des fichiers de configuration éparpillés, l'outil a beaucoup plus de mal. Le contexte à tenir explose, les liens entre fichiers deviennent moins évidents, et je passe plus de temps à corriger qu'à avancer. Le gain de 4-6 semaines à 1 semaine, je le tiens sur du simple. Sur du complexe, l'écart se réduit, et parfois la préparation coûte presque aussi cher que ce qu'elle fait gagner.

C'est ma limite honnête. Je n'ai pas trouvé de formule miracle pour les architectures lourdes. Mon workflow brille sur les sites où la logique reste lisible, et je préfère le dire plutôt que de promettre la lune.

Mon verdict

Passer de 4 à 6 semaines à une seule semaine sur une refonte complète, ce n'est pas un détail. C'est la différence entre un projet qui pèse sur l'agenda et un projet qu'on traite dans la semaine. Mais ce gain ne vient pas de l'outil seul. Il vient de la discipline : auditer avant de coder, reconstruire le schéma avant de toucher à la base, écrire le blueprint avant la première page. Claude Code accélère chacune de ces étapes ; il ne les remplace pas.

Si tu ne retiens qu'une chose : ne lance jamais le vibe-coding directement sur un site existant. Fais l'audit, fais le schema.sql, fais le blueprint. C'est ennuyeux, ça ne ressemble pas à du « vrai » travail, et c'est précisément ce qui fait toute la différence. Sur une stack simple, ce workflow a changé ma façon de travailler. Sur une stack lourde, garde tes attentes basses. Et dans tous les cas, c'est toi qui décides — l'outil ne fait qu'aller plus vite là où tu sais déjà où tu vas.