Refondre un site avec un assistant de code, sans livrer du brouillon

Ce qui accélère réellement

Un assistant de code change le rythme sur trois choses précises, et pas sur les autres.

L'échafaudage. Mettre en place un projet, sa configuration de tests, son système de composants et ses conventions : ce qui prenait deux jours en prend deux heures. C'est du travail connu, répétitif et vérifiable — exactement le terrain où ces outils excellent.

La déclinaison. Une fois qu'un gabarit de page existe et qu'il est bon, en produire dix autres sur le même modèle est presque gratuit.

La migration mécanique. Réécrire une table de redirections, convertir un jeu de contenus, adapter une API : tâches ingrates, parfaitement cadrées, sans jugement à porter.

Ce qui n'accélère pas

Les décisions. Quelle architecture d'information, quel positionnement, quelles pages supprimer. Un assistant vous donnera un avis plausible sur tout, ce qui est précisément le danger.

La direction artistique. Un assistant produit sans effort un site propre et générique. Le parti pris, lui, ne s'obtient pas en demandant « fais quelque chose de beau ».

La compréhension du métier. Les pages qui convertissent sont celles qui traitent les objections réelles de vos clients. Ces objections, seul vous les connaissez.

Le piège principal : le code qui a l'air juste

C'est le risque spécifique de ces outils, et il n'existait pas avant. Un assistant produit du code qui compile, passe le typage, s'affiche correctement — et se trompe.

Trois exemples rencontrés sur une refonte réelle :

Une classe utilitaire mal formée. text-[var(--fs-h4)] en Tailwind v4 : le framework interprète la valeur comme une couleur et la taille de police n'est jamais appliquée. Aucune erreur, aucun avertissement. Le texte s'affiche simplement dans la mauvaise taille, sur tout le site.

Une expression régulière échappée une fois de trop. Un caractère d'échappement en trop dans le filtre de routage, et le middleware ne s'exécute plus du tout. Le site fonctionne en apparence, mais la moitié de sa logique est morte.

Une animation qui dégrade le contraste. Des entrées au défilement partant d'une opacité réduite : l'effet est joli, et le contraste réel du texte tombe sous le seuil d'accessibilité. Un audit automatisé le voit, l'œil non.

Ces trois erreurs ont en commun de ne provoquer aucun échec visible. C'est ce qui les rend coûteuses.

La réponse : des garde-fous exécutables

Une revue de code humaine ne rattrape pas ces erreurs de façon fiable — elles sont invisibles à la lecture. Ce qui fonctionne, ce sont des tests qui échouent.

Sur une refonte, six garde-fous rapportent plus que tout le reste :

1. Les métadonnées sont contraintes au build. Une fonction qui lève une erreur si un titre sort de ses bornes. Une page sans description devient impossible à livrer.

2. Les redirections sont testées. Un test qui vérifie qu'aucune règle ne pointe vers une route inexistante. C'est le genre d'erreur qui coûte des mois de référencement et qu'on découvre trop tard.

3. L'accessibilité est automatisée. axe-core sur chaque gabarit, en intégration continue. Contraste, structure de titres, cibles tactiles : autant de choses qu'une relecture visuelle laisse passer.

4. Le rendu sans JavaScript est vérifié. Un test qui charge les pages sans JS et vérifie qu'aucun bloc n'est masqué.

5. Les budgets de performance échouent la PR. Nombre de requêtes, poids du JavaScript et du CSS, mesurés à chaque exécution.

6. Les conventions du design system sont testées. Aucune couleur en dur, aucune URL de route en dur, un seul h1 par page. Trois lignes de test qui préviennent une dérive lente.

Ces six garde-fous prennent une demi-journée à écrire. Sur une refonte, ils rattrapent plus d'erreurs que n'importe quelle relecture.

Comment travailler concrètement

Donnez le contexte avant la tâche. Un assistant qui connaît vos conventions, votre design system et vos contraintes produit du code cohérent. Un assistant sans contexte produit du code générique qu'il faudra réécrire.

Faites-vous expliquer avant d'accepter. Si l'explication ne tient pas, le code non plus.

Découpez. « Refais le site » ne donne rien d'exploitable. « Écris le composant de navigation, avec ces états et ces contraintes d'accessibilité » donne du code utilisable.

Écrivez le test d'abord, y compris avec un assistant. C'est la discipline qui résiste le mieux à l'accélération : un test écrit avant est un test qui décrit l'intention, pas le code produit.

Le calcul réel

Sur une refonte de site d'une vingtaine de pages, avec un design system sur mesure :

Le gain est réel — autour de 40 % — mais il ne porte que sur la production. Les décisions coûtent exactement le même temps qu'avant, et une ligne nouvelle apparaît : la correction d'erreurs qui n'existaient pas.

C'est une accélération, pas une transformation. La différence compte quand on budgète.