Pourquoi 9 étapes et pas 1
La tentation pour un AI website builder est de tout faire en un seul prompt : on prend le brief, on appelle un LLM, on récupère du HTML. C'est rapide, et c'est généralement mauvais.
La raison est mécanique : un seul appel LLM doit décider en même temps de la structure, de la copy, du design, des images, de la performance, et de l'accessibilité. Chaque décision affecte les autres, et le modèle ne peut pas optimiser tout simultanément. Le résultat est un compromis moyen sur tous les axes.
La logique du pipeline en étapes : chaque étape a un seul objectif clair, optimisé indépendamment, avec un livrable validé avant de passer à la suivante. C'est plus lent (quelques minutes au lieu de quelques secondes), mais c'est radicalement plus solide. Et le surcoût en temps est négligeable face au surcoût d'itérations sur un mauvais premier jet.
Étape 1 : Brief structuré
Le pipeline commence par un brief structuré, pas un champ texte libre. L'utilisateur remplit cinq blocs : audience, problème/promesse, ton et références, structure attendue, success criteria. Le formulaire guide la réflexion et force la précision.
Un brief vague (« landing pour mon SaaS ») est rejeté ou complété par des questions de clarification. Un brief précis (avec audience nommée, problème mesurable, références d'inspiration) passe à l'étape suivante.
Cette étape coûte 15-30 minutes à l'utilisateur, et c'est sa part la plus importante. Le reste du pipeline travaille à partir de ce brief, donc sa qualité conditionne tout. Un brief approximatif produit un site approximatif, peu importe la qualité du pipeline en aval.
Étape 2 : Audit concurrents et secteur
Avant de générer quoi que ce soit, Eufya extrait des signaux du marché. Si l'utilisateur a fourni 2-3 URLs de concurrents, le pipeline les analyse : structure de sections, registres de copy, patterns visuels dominants, signaux de preuve utilisés.
Le rôle de cet audit : ne pas générer ce qui est déjà sur-fait dans le secteur. Si tous les concurrents ont un hero centré avec gradient violet, le pipeline va dévier intentionnellement vers une asymétrie ou une palette différente, pour produire de la différenciation.
Cet audit est aussi utilisé pour pondérer la rubrique de scoring des étapes suivantes. Pour un secteur conservateur (juridique, médical), les patterns trop audacieux sont pénalisés. Pour un secteur créatif (gaming, agence créative), c'est l'inverse.
Étape 3 : Section Plan macro
Avant de coder une seule ligne, le pipeline produit un Section Plan : la liste ordonnée des sections, avec pour chacune un titre, un objectif fonctionnel, un type de composition, et un état d'esprit éditorial.
Exemple : « Section 3 — Bénéfices. Objectif : adresser les 3 objections principales identifiées dans le brief. Composition : grille asymétrique 2+1, avec un bénéfice mis en avant. Ton : technique mais sans jargon. »
Le Section Plan est validé avant la génération du code. C'est l'étape où on rattrape les structures bancales (trop de sections, ordre illogique, redondances) à coût quasi-nul. Une fois le HTML généré, corriger la structure coûte 10x plus cher. Le Section Plan macro est l'équivalent d'un wireframe textuel : une discipline de pensée avant l'exécution.
Étape 4 : Hero Lab
Le hero est la section la plus critique et la plus difficile. Plutôt que de générer une seule version et de croiser les doigts, le Hero Lab génère quatre variantes simultanément, dans des registres distincts.
Les registres typiques : éditorial typographique (gros titre, peu d'éléments visuels, focus sur la copy), asymétrique avec capture produit (titre à gauche, screenshot à droite, hiérarchie visuelle forte), split layout (deux colonnes contrastées, ton manifeste), mosaïque bento (grille de blocs hétérogènes, ton produit dense).
Chaque variante est scorée sur une rubrique pondérée par le secteur : lisibilité, concrétude, asymétrie, preuve, différenciation. La variante avec le meilleur score passe à l'étape suivante. Les trois autres sont conservées comme alternatives consultables par l'utilisateur s'il veut explorer.
Étape 5 : Génération du reste du site
Avec le hero validé, le pipeline génère les autres sections selon le Section Plan. Chaque section est produite avec une contrainte stylistique dérivée du hero : palette, typo, rythme d'espacement, registre des compositions.
La contrainte est importante : sans elle, chaque section serait générée indépendamment et la cohérence stylistique s'effondrerait (le problème classique des sites IA dont le hero est bon mais la suite est générique). En propageant les choix stylistiques du hero validé, on garde une signature unifiée sur toute la page.
À cette étape, le HTML/CSS est généré avec une stack standardisée (Tailwind + composants React optionnels), pour faciliter l'export et l'édition ultérieure. Pas de framework exotique qui complique l'export.
Étape 6 : Quality Gate Playwright
Une fois le site généré, il est testé automatiquement via Playwright. Les vérifications : rendu sur trois breakpoints (320px, 768px, 1280px), score Lighthouse (perf, accessibility, SEO), absence d'erreurs console, validité du HTML sémantique (un seul h1, hiérarchie correcte des headings), contraste AA sur tous les textes, présence des meta tags essentiels (title, description, og), et présence d'un schema Organization ou WebSite minimum.
Si le Quality Gate échoue sur un critère bloquant, le pipeline boucle automatiquement : il identifie la cause probable et regénère la section concernée avec une contrainte de correction. Par exemple, si le contraste est insuffisant sur les CTAs, il regénère avec une contrainte de palette.
C'est cette étape qui empêche le « slop IA » de passer en production. Sans Quality Gate, on a un site qui paraît OK en preview mais qui casse en mobile, qui a un Lighthouse à 40, et qui n'est pas accessible.
Étape 7 : Optimisation copy
La copy générée initialement est un draft fonctionnel mais rarement le meilleur possible. À cette étape, le pipeline applique des heuristiques d'optimisation : raccourcissement des titres à 7-9 mots max, suppression des buzzwords (« innovant », « next-gen »), vérification que chaque section avance un argument et ne paraphrase pas l'intro.
Un LLM spécialisé en copy édite chaque bloc avec une cible de concision et de concret. Le titre vague « The modern platform for marketing teams » devient « Automatisez votre marketing email en 20 minutes » si le brief le permet. Le sous-titre paraphrasique devient un mécanisme explicite.
L'utilisateur peut intervenir à cette étape pour fournir des éléments concrets (chiffres réels, témoignages authentiques, logos clients) qui remplacent les placeholders. La règle absolue : pas de témoignage fabriqué, pas de chiffre inventé. Mieux vaut un placeholder marqué que de la preuve fictive.
Étape 8 : Export multi-format
Le site validé est exporté dans plusieurs formats au choix : HTML/CSS pur (déposable sur n'importe quel hébergeur statique), composants React + Tailwind (intégrable dans une stack Next.js existante), ou archive Figma (pour les équipes design qui veulent itérer en outil de design).
L'export HTML/CSS contient : un index.html sémantique, un styles.css avec les tokens en CSS variables, les assets optimisés (images en WebP, fonts subsettées), un sitemap.xml, un robots.txt, et les meta tags SEO/OG. Tout est immédiatement déployable.
L'export React contient : des composants typés, un tailwind.config avec les tokens personnalisés, et un layout Next.js prêt à intégrer. Pas de lock-in : l'utilisateur peut continuer le projet n'importe où.
Étape 9 : Déploiement et monitoring
Pour les utilisateurs qui ne veulent pas gérer leur propre déploiement, Eufya propose un déploiement one-click sur Vercel (ou équivalent) avec un domaine custom configuré, un certificat SSL, et un monitoring de base (uptime, erreurs, analytics minimum).
Le monitoring renvoie à l'utilisateur des métriques utiles : trafic, conversion sur le CTA principal, temps de chargement réel observé sur les visiteurs, erreurs JS éventuelles. Ces métriques alimentent une boucle d'amélioration : au bout de 30 jours, le pipeline peut proposer des optimisations basées sur le comportement réel.
Les étapes 8 et 9 sont disjointes pour préserver l'autonomie : l'utilisateur peut exporter et déployer ailleurs sans jamais utiliser le déploiement géré. C'est un choix de produit volontaire : pas de lock-in, pas de chantage à la migration.