Beaucoup nous ont dit que c’était impossible - que c’était trop ambitieux, pas réaliste.
Je sais maintenant que cette décision était la bonne, c’était un pari, et il a été gagnant, et je peux l’affirmer avec certitude : le virage qu’on a pu prendre avec Zadig&Voltaire nous a permis de garantir beaucoup de choses essentielles pour le business.
Une refonte front-end, ce n’est pas rien. Souvent, on fait appel à une agence externe, les équipes sont dupliquées, et il y a un énorme chantier à gérer, on connaît tous les risques, les délais et les coûts que ça implique.
Ce qu’on sait maintenant, c’est qu’avec 1 Chef de projet technique, 2 PO et 3 développeurs, il est possible de faire une refonte complète en interne avec de l’IA.
On a commencé en juillet 2025. Aujourd’hui, on a terminé. Et on l’a fait en beauté.
J’ai même le luxe de pouvoir écrire ce blog pour décrire ce qui a été fait - avant même que le nouveau site ne sorte en production.
Eh oui, on a gagné du temps. Nous pensons qu’il est temps de partager cette expérience, car nous constatons que le secteur n’a pas encore compris les enjeux et les gains. Il y a de la crainte, de la frilosité, un manque d’audace.
Soyez audacieux. Franchissez le pas. Vous ne pourrez plus revenir en arrière.
C’est ça notre message, en février 2026.
Ce qu’on avait : la dette technique
Notre frontend historique tournait sur Vue Storefront, une solution qui avait fait ses preuves mais qui montrait ses limites.
Vue 2.7 avec un store Vuex monolithique : 104 lignes de wrapper pour orchestrer plus de 20 modules. Apollo Client v2 avec une gestion manuelle du cache qui ressemblait plus à de l’archéologie qu’à du code moderne.
Le point le plus douloureux ? Trois configurations Webpack séparées. Une pour le client, une pour le serveur SSR, une pour le service worker. Chacune avec son système d’overlays pour les thèmes. Modifier un alias de build, c’était toucher à trois fichiers en espérant ne rien casser.
La structure modulaire semblait organisée sur le papier : 20+ modules dans src/modules/, chacun avec sa propre arborescence graphql/, store/, helpers/. En pratique, c’était une duplication massive de patterns et une dette technique qui s’accumulait. Le tout saupoudré de mixins Vue 2 - cet antipattern qu’on traînait depuis des années.
La timeline : l’évolution de notre stack IA
C’est là que notre histoire diverge des migrations classiques. On n’a pas juste changé de framework - on a changé de méthode de travail.
On explore Cursor et Windsurf. Les deux outils promettent une assistance IA intégrée à l’IDE. On teste, on compare, on hésite. L’équipe est sceptique mais curieuse.
La décision est prise : on reconstruit proprement de zéro. Et on le fait avec l’IA comme copilote.
Démarrage de la migration avec l’équipe au complet. Tout le monde code avec l’assistance IA. Les premiers composables Nuxt 3 naissent. GraphQL Codegen est installé dès le premier jour - plus jamais de types manuels.
C’est dur, le code legacy sert de référentiel mais le passage à la Composition API est un changement de paradigme complet. L’équipe fait les choses bien et co-construit une architecture extensible.
On passe full Claude Code. Le changement est radical.
Là où Cursor et Windsurf nous permettaient de co-construire, Claude Code offre une compréhension contextuelle de toute la codebase. On ne parle plus de suggestions de code - on parle de conversations avec un développeur qui connaît l’intégralité du projet.
Les règles SSR qu’on découvrait à la dure ? Claude Code les connaît. Les patterns Nuxt 3 qu’on cherchait dans la doc ? Il les applique directement.
- L’explosion des MCPs nous aide dans notre build
- On intègre des agents spécialisés
- On migre du
.windsurf-rulesvers leCLAUDE.md
Opus 4.5 sort. L’accélération est immédiate.
Le modèle comprend mieux les intentions, génère du code plus propre, fait moins d’erreurs. Les code reviews IA deviennent fiables. Les refactorings complexes passent du premier coup.
On commence à déléguer des features entières, on passe d’un co-développement à un développement agentique.
Fin novembre on intègre les SKILLs : zv-commit, zv-code-review, zv-jira, zv-jira-qa…
Ainsi que des skills communautaires : skills.sh
La productivité de l’équipe explose. x2, x3 par rapport à nos estimations initiales.
Ce qui devait prendre une semaine se fait en deux jours. Les bugs sont détectés avant même d’être mergés.
On finit la migration avec de l’avance. On a le temps de peaufiner, d’optimiser, de documenter, d’ajouter des features initialement repoussées.
- Orientation agentique : les agents codent, les développeurs orchestrent
- Mutualisation globale dans un seul
workspace: back / front / microservice / infra
Les choix techniques
Nuxt 3 plutôt qu’un autre framework ? L’écosystème Vue était déjà maîtrisé par l’équipe, et Nuxt offrait le SSR natif. En plus c’est français 🇫🇷 (racheté par Vercel entre-temps)
GraphQL Codegen ? Non négociable. Après avoir maintenu des interfaces TypeScript manuelles pendant des années, l’auto-génération depuis le schema était une évidence.
MCP / SKILLs obligatoires si vous travaillez avec un agent aujourd’hui, le gain est réel et ouvre la voie vers l’automatisation de votre workflow.
Les règles SSR, on les a apprises à la dure :
useState()obligatoire, jamais deref()au niveau module. Sinon, état partagé entre les requêtes, bugs impossibles à reproduire en local.- Ne jamais appeler un composable dans un
watch(). Le contexte Nuxt n’est plus disponible, ça explose silencieusement. - Nettoyer les watchers dans
onBeforeUnmount(). Memory leaks garantis sinon. - Les plugins ne peuvent pas toucher
console.*ouwindow.*côté serveur.
Les résultats
Volume de code
| Métrique | Vue Storefront | Nuxt 3 |
|---|---|---|
| Lignes de code applicatif | ~72 000 | ~48 000 (-33%) |
| Stores | 1 monolithe Vuex | 8 Pinia |
| Types GraphQL manuels | ~20 fichiers | 0 (auto-générés) |
| Composables | 0 (mixins) | 75 |
| Couverture TypeScript | ~50% | ~96% |
Moins de code pour la même couverture fonctionnelle. La Composition API et les composables Nuxt 3 éliminent le boilerplate des mixins et du store Vuex monolithique.
Performance Lighthouse (mobile)
HP (Homepage)
| Métrique | VSF | Nuxt | Delta |
|---|---|---|---|
| LCP | 18.9s | 7.0s | -63% |
| TBT | 910ms | 200ms | -78% |
| CLS | 0.131 | 0.011 | -92% |
| FCP | 11.4s | 4.0s | -65% |
| Speed Index | 18.8s | 6.1s | -68% |
| TTI | 19.0s | 16.8s | -12% |
PLP (Page Liste Produits)
| Métrique | VSF | Nuxt | Delta |
|---|---|---|---|
| LCP | 19.4s | 8.1s | -58% |
| TBT | 1 620ms | 640ms | -60% |
| CLS | 0.074 | 0 | parfait |
| FCP | 9.4s | 1.8s | -81% |
| Speed Index | 9.4s | 5.3s | -44% |
| TTI | 19.4s | 8.3s | -57% |
PDP (Page Détail Produit)
| Métrique | VSF | Nuxt | Delta |
|---|---|---|---|
| LCP | 18.8s | 8.0s | -57% |
| TBT | 1 380ms | 330ms | -76% |
| CLS | 0.057 | 0.003 | -95% |
| FCP | 3.7s | 1.5s | -59% |
| Speed Index | 7.1s | 4.0s | -44% |
| TTI | 24.0s | 10.5s | -56% |
Productivité équipe
| Période | MRs mergées/semaine | Ratio IA-assisté |
|---|---|---|
| Juillet 2025 | ~7 | 30% |
| Novembre 2025 | ~15 | 70% |
| Janvier 2026 | ~27 | 90%+ |
x4 entre juillet et janvier.
Comparatif technique
| Aspect | Vue Storefront | Nuxt 3 |
|---|---|---|
| Framework | Vue 2.7 | Vue 3.5 |
| State Management | Vuex (104 lignes wrapper) | Pinia (8 stores) |
| Build | 3 configs Webpack | 1 config Vite |
| SSR | Express.js manuel | Natif Nuxt |
| Middleware | Express.js manuel | Natif Nuxt |
| Routing | Vue Router manuel | File-system automatique |
| Types GraphQL | Manuels | Auto-générés (Codegen) |
| Composables | 0 (mixins) | 75 |
Ce qu’on a appris
Sur la migration
- GraphQL Codegen dès le jour 1. Le ROI est immédiat.
- Ne pas migrer, reconstruire. Copier du code legacy, c’est copier sa dette, par contre l’intégrer dans la code-base comme référence documentaire est essentiel.
- Partager des insights et des ressources. Ça évite que chaque dev découvre les pièges seul.
Sur l’IA
- Adopter tôt, itérer vite. On a changé d’outil trois fois en 6 mois. Chaque pivot nous a fait gagner du temps.
- L’IA ne remplace pas l’expertise, elle l’amplifie. Il faut savoir quoi demander et valider ce qui sort.
- Le contexte est roi. Un outil qui comprend toute la code-base vaut dix fois un autocompléteur intelligent.
- Former l’équipe ensemble. L’adoption IA est un sport d’équipe, pas une initiative individuelle.
- Beaucoup de tâches secondaires intégrées. L’IA ne se fatigue jamais, il en résulte un code globalement qualitatif car on ne prend pas de raccourcis.
Sur le shift mental
On est entré dans une nouvelle ère, les développeurs ne codent plus, ils ont désormais toutes les casquettes.
On a le sentiment d’avoir des supers-pouvoirs, et c’est le cas, c’est comme si on avait développé un cheat-code qui nous permet de toute débloquer et de tout faire.
Plus aucun problème nous semble hors de portée, plus aucun sujet nous semble bloquant, en résumé, on exploite nos capacités de base et l’IA les décuple à un niveau qu’on a du mal à décrire.
Un développeur de l’équipe résume bien : “Maintenant je ne pourrais plus revenir en arrière.”
Le message
Six mois. Trois développeurs. Trois project managers.
On l’a fait quand tout le monde disait que c’était impossible.
L’IA n’est pas un gadget. C’est un multiplicateur de force. Et ceux qui attendent de voir “comment ça évolue” prennent du retard chaque jour.
Le secteur n’a pas encore shifté. Il y a de la crainte, de la frilosité, un manque d’audace.
Nous, on a fait le choix. On a pris le risque. Et aujourd’hui, on peut affirmer : ça marche.
Soyez audacieux. Franchissez le pas.
Vous ne pourrez plus revenir en arrière.
Le nouveau site sort bientôt, mais on ne spoil pas la date !
“On est passés de « comment on fait pour que ça marche » à « comment on fait pour que ce soit bien ». C’est toute la différence.” — L’équipe Tech Z&V