Quand on regarde des démos d'outils d'IA, il suffit de cliquer sur quelques boutons et de taper deux ou trois phrases pour obtenir une UI à couper le souffle. Le problème, c'est la réalité. Dès que l'on importe le code craché par l'IA dans un projet existant, les styles sautent tous et la gestion d'état devient un vrai plat de spaghettis. On a tous déjà fait l'expérience de passer deux fois plus de temps à corriger et à bricoler ce code qu'à le développer nous-mêmes.

En fin de compte, pour pouvoir utiliser le code de l'IA tel quel, il faut lier l'analyse statique, la structuration de l'état et la vérification visuelle au sein de garde-fous automatisés. Voici une configuration concrète pour importer ce code dans un état directement utilisable, sans y passer la nuit.

Éliminer les classes Tailwind arbitraires et les styles inline

L'IA a beau bien comprendre le contexte, elle se met soudainement à ignorer les tokens du projet. Elle va insérer à sa guise des valeurs arbitraires entre crochets comme w-[327px] ou des styles inline contenant des codes hexadécimaux. Le système de design s'effondre d'un coup et la priorité des règles CSS s'emmêle.

Si c'est un humain qui doit repérer et corriger cela à l'œil nu, c'est déjà trop tard. Il faut bloquer l'accès en amont avec un linter.

1. Installez les packages nécessaires dans le projet.
   `bash
   npm install -D eslint-plugin-tailwindcss @html-eslint/eslint-plugin

`

1. Dans le fichier eslint.config.mjs, ajoutez des règles pour traiter les valeurs arbitraires entre crochets et les styles inline comme des erreurs.
2. Enregistrez npx eslint --fix dans les scripts du package et exécutez-le juste après la réception du code.

Grâce à cette configuration, dès qu'une valeur entre crochets ou un style inline apparaît, le linter la rejette sous forme d'erreur et la remplace de force par la classe utilitaire standard la plus proche. La disparition de ces tâches ingrates permet d'économiser plus de 5 heures par semaine auparavant consacrées à l'ajustement des styles.

`javascript
// eslint.config.mjs
import eslintPluginTailwindcss from "eslint-plugin-tailwindcss";
import { defineConfig } from "eslint/config";

export default defineConfig([
{
plugins: {
tailwindcss: eslintPluginTailwindcss,
},
settings: {
tailwindcss: {
cssConfigPath: "./styles/tailwind.css",
},
},
rules: {
"tailwindcss/no-arbitrary-value": "error",
"tailwindcss/no-custom-classname": [
"error",
{ whitelist: ["custom\-*"] },
],
"tailwindcss/classnames-order": "warn",
},
},
]);

`

Nettoyer les useState qui s'accumulent au sein des composants

Si vous demandez à une IA de créer un composant React, neuf fois sur dix, elle va éparpiller trois ou quatre useState dans un seul fichier. Si des appels d'API asymptotiques et de la gestion d'erreurs viennent s'y mêler, c'est l'explosion du rendu garantie.

L'état de l'UI côté client doit être centralisé avec Zustand, tandis que les données du serveur doivent être séparées avec React Query. Les formulaires de saisie, quant à eux, doivent voir leur structure verrouillée grâce à l'association de Zod et react-hook-form.

1. Installez les bibliothèques de dépendances.
   `bash
   npm install @tanstack/react-query zod react-hook-form @hookform/resolvers

`

1. Dans le schéma de prompt de l'IA, interdisez l'utilisation directe de fetch et exigez que les types soient d'abord définis avec un schéma Zod.
2. Associez zodResolver à react-hook-form pour automatiser la validation, et structurez le tout pour appeler useMutation lors de la soumission.

Les re-rendus inutiles disparaissent complètement. Les échecs de validation des valeurs saisies ne parviennent même plus à l'intérieur du composant.

`typescript
import { useForm } from 'react-hook-form';
import { zodResolver } from '@hookform/resolvers/zod';
import { z } from 'zod';

export const userProfileSchema = z.object({
username: z.string().min(2, { message: '이름은 최소 2자 이상이어야 합니다.' }),
email: z.string().email({ message: '올바른 이메일 형식이 아닙니다.' }),
role: z.enum(['admin', 'user'], { required_error: '역할을 선택하세요.' }),
});

export type UserProfileInputs = z.infer;

export function ProfileForm() {
const {
register,
handleSubmit,
formState: { errors },
} = useForm({
resolver: zodResolver(userProfileSchema),
});

const onSubmit = (data: UserProfileInputs) => {
// React Query Mutation 실행
};

return (

`

Une boucle de test pour détecter visuellement les cassures d'affichage

Il arrive très souvent qu'on se dise « Oh, ça rend bien » en regardant uniquement un écran d'ordinateur de bureau, pour se rendre compte en l'ouvrant sur mobile que la mise en page est un vrai désastre. D'après le rapport 2025 de WebAIM sur l'accessibilité web, on compte en moyenne plus de 51 erreurs WCAG uniquement sur la page d'accueil des 1 million de sites les plus visités. Alors inutile de préciser à quel point le rendu réactif du code fraîchement généré par une IA peut être cassé.

En automatisant les tests de régression avec Playwright et Pixelmatch, plus besoin de réduire manuellement la fenêtre du navigateur pour tout vérifier un par un.

1. Installez les outils de test.
   `bash
   npm install -D @playwright/test @axe-core/playwright

`

1. Mettez en place un script qui prend des captures d'écran en parcourant les viewports mobile (375px), tablette (768px) et ordinateur de bureau (1440px).
2. Fixez le seuil maxDiffPixelRatio à 0,02. Si ce seuil est dépassé, l'image montrant la différence de pixels est renvoyée dans le prompt de l'IA pour lui faire réécrire les media queries.

Depuis la mise en place de cette boucle de test de rendu, le temps consacré à l'inspection visuelle manuelle de l'UI a diminué de plus de 80 %.

`typescript
import { test, expect } from '@playwright/test';

const viewports = [
{ name: 'mobile', width: 375, height: 667 },
{ name: 'tablet', width: 768, height: 1024 },
{ name: 'desktop', width: 1440, height: 900 },
];

for (const vp of viewports) {
test(Responsive layout test - ${vp.name}, async ({ page }) => {
await page.setViewportSize({ width: vp.width, height: vp.height });
await page.goto('/render-test-harness');

await expect(page.locator('#ai-component-root')).toHaveScreenshot(
  `component-${vp.name}.png`,
  {
    maxDiffPixelRatio: 0.02,
    threshold: 0.2,
    animations: 'disabled',
  }
);

});
}

`

Filtrer le code bizarre juste avant le commit

Même en rédigeant très bien les prompts, il arrive parfois que du code poubelle s'infiltre, un peu comme si la climatisation de l'IA sautait. Il faut bloquer le code qui fait planter les types ou qui ne passe pas le linter juste avant le commit, pour l'empêcher d'entrer dans l'espace de travail Git.

Configurez les hooks Git avec Lefthook.

1. Installez Lefthook dans le projet et créez un fichier lefthook.yml à la racine.
   `bash
   npm install -D lefthook

`

1. Associez les commandes de vérification ESLint, Prettier et TypeScript à l'étape de pre-commit.
2. Activez l'option stage_fixed: true pour que les modifications auto-corrigées soient directement prises en compte dans le commit.

S'il y a des erreurs de types corrigées ou des Props supprimées sans autorisation, le commit est immédiatement bloqué. C'est le moyen le plus sûr de mettre fin à l'inefficacité des développeurs devant faire la revue de code manuellement pour nettoyer les résidus laissés par l'IA.

`yaml

lefthook.yml

pre-commit:
commands:
eslint-autofix:
glob: ".{js,ts,jsx,tsx}"
run: npx eslint --fix {staged_files}
stage_fixed: true
prettier-format:
glob: ".{js,ts,jsx,tsx,css,json}"
run: npx prettier --write {staged_files}
stage_fixed: true
typescript-check:
glob: "*.{ts,tsx}"
run: npx tsc --noEmit

`