Comment on a construit une landing page en moins de 24h avec Astro et l'IA

82 commits. 29 183 lignes de code. Trois langues. Accessible WCAG AA. Environ 10 heures de travail effectif, livré le lendemain matin. Un fondateur, un agent IA, zéro budget.

Ce n’est pas une démo. C’est hayka-pacha.io, le site que vous lisez en ce moment.

Voici exactement comment on a fait, ce qui a marché, ce qui a cassé, et si ce workflow est reproductible pour votre prochain projet.

Pourquoi construire une landing page en un jour ?

On avait besoin d’un vrai site marketing, pas d’un placeholder. Un truc qui fait dire aux partenaires potentiels “ces gens savent ce qu’ils font.” Voici ce qu’on devait livrer :

• Trilingue (anglais, français, espagnol) avec hreflang et routage i18n natif
• Rapide : temps de chargement sous les 2 secondes sur tout appareil
• Accessible : conforme WCAG AA dès le premier jour
• Prêt pour le SEO : données structurées, sitemaps, meta tags, images Open Graph
• Blog intégré : collections de contenu MDX, système de brouillons, publication programmée
• Capture de leads : formulaire de contact avec demandes catégorisées et emails personnalisés

Une agence classique facturerait 2 à 4 semaines et 5 000 à 15 000 $ pour ce périmètre. On a dépensé 0 $ et 17 heures.

La stack, et pourquoi chaque choix compte

On n’a pas choisi des outils parce qu’ils sont à la mode. Chaque dépendance est là parce qu’elle résout un problème sans en créer deux autres.

12 dépendances au total. C’est tout. Pas de bibliothèque de gestion d’état, pas de CSS-in-JS, pas de librairie de composants avec 47 peer dependencies. Moins de dépendances, c’est moins de surfaces d’attaque, des builds plus rapides, et moins de maintenance.

Qu’est-ce qu’Astro ? Astro est un framework web qui génère des pages en HTML statique au moment du build, sans envoyer de JavaScript au navigateur sauf si vous le demandez explicitement. Idéal pour les sites riches en contenu où la performance et le SEO priment sur l’interactivité côté client.

Le workflow assisté par IA, ce qui s’est vraiment passé

Soyons précis sur ce que “assisté par IA” veut dire. On n’a pas tapé “construis-moi un site” pour aller se coucher. Un humain a pris chaque décision. L’IA a écrit le code, vite.

Phase 1 : Architecture (~1 heure)

J’ai écrit une spec de 400 lignes : identité de marque, hiérarchie des audiences, exigences par section, palette de couleurs, choix typographiques. De l’étymologie quechua de notre nom de marque aux valeurs OKLCH exactes.

Claude Code a pris cette spec et généré le plan d’implémentation : 12 tâches avec dépendances, chemins de fichiers et critères d’acceptation. Scaffolding du projet Astro avec le bon adapter, configuration i18n, schéma des collections de contenu.

Décision clé : On a choisi le routage i18n natif d’Astro (préfixe /{lang}/ sur toutes les routes) plutôt qu’une librairie i18n tierce. Le routeur gère la détection de langue à l’edge, et les fichiers de traduction restent en JSON simple. Zéro surcharge à l’exécution.

// src/content.config.ts : le schéma que chaque article doit respecter
const blog = defineCollection({
  loader: glob({ pattern: '**/*.mdx', base: './src/content/blog' }),
  schema: z.object({
    title:       z.string(),
    description: z.string(),
    pubDate:     z.coerce.date(),
    lang:        z.enum(['en', 'fr', 'es']),
    category:    z.enum(['SEO', 'Infra', 'Automation', 'Business']),
    readTime:    z.number(),
    draft:       z.boolean().default(false),
  }),
});

Ce schéma est vérifié au moment du build. Si un article oublie un champ obligatoire ou utilise une catégorie invalide, le build échoue. Pas d’erreurs silencieuses, pas de pages cassées en production.

Phase 2 : Composants (~5h30)

C’est là où les agents IA brillent. Cette phase a été rapide. Je décrivais ce que je voulais, l’IA écrivait le composant, je corrigeais ce qui n’allait pas, l’IA ajustait. Huit fois de suite.

On a construit 8 composants en 5h30 :

6 composants sur 8 n’envoient aucun JavaScript. Le seul JS de la page est un IntersectionObserver léger pour les animations au scroll (moins de 1 Ko) et le handler de soumission du formulaire. Tout le reste est rendu en HTML statique au moment du build.

Phase 3 : Finitions et sécurisation (~6 heures)

La plupart des projets “build fast” sautent cette phase. Pas nous.

Création du design system : Chaque couleur, espacement et règle typo a fini dans .claude/skills/hayka-design-system/SKILL.md. Quand l’IA construit un nouveau composant, elle lit ce fichier d’abord. La cohérence de marque sans y penser.

Audit d’accessibilité : On a lancé AccessLint sur chaque composant et corrigé :

• Labels de formulaire manquants
• Contraste de couleur insuffisant (recalibrage complet de la palette OKLCH pour WCAG AA)
• Lien de navigation rapide manquant
• Styles de focus pour la navigation au clavier

Sécurisation :

• Vérification d’origine CSRF sur l’API du formulaire de contact
• Headers de sécurité via Cloudflare (CSP, X-Frame-Options, HSTS)
• Secrets d’environnement lus depuis le runtime Cloudflare Workers, pas intégrés au build

Complétude i18n : Chaque chaîne de chaque composant a été extraite dans les fichiers de traduction. On a détecté 14 chaînes anglaises codées en dur qui auraient été livrées non traduites.

Phase 4 : Déploiement et itérations (~4 heures)

Déploiement sur Cloudflare Workers, génération de l’image OG, configuration du robots.txt, génération du sitemap. Puis la boucle d’itération sur le copy : 23 commits de pur ajustement, reformulation du manifeste, correction d’anglicismes dans la traduction française, remplacement des guillemets.

Dernier commit juste avant le déjeuner.

Ce qui a cassé, et ce qu’on a appris

Des trucs ont cassé. Voici lesquels.

Le cauchemar CI multi-plateforme

Notre plus gros gouffre de temps : 5 commits pour résoudre des dépendances binaires natives. Tailwind CSS v4 utilise des binaires natifs spécifiques à la plateforme (@tailwindcss/oxide). Le package-lock.json généré sur macOS n’incluait pas les binaires Linux nécessaires à la CI. On a essayé npm ci, le vidage de cache et les dépendances optionnelles explicites avant de trouver une solution stable.

Leçon : Quand vous utilisez des outils avec des modules natifs spécifiques à la plateforme, testez votre pipeline CI tôt. Pas après avoir construit 8 composants.

La confusion Cloudflare Pages vs Workers

On avait initialement configuré pour Cloudflare Pages, mais l’adapter Astro Cloudflare génère un format Worker. Deux commits perdus sur le conflit de configuration wrangler.jsonc entre les modes de déploiement Pages et Workers.

Leçon : Lisez la documentation de l’adapter avant le premier déploiement, pas après que wrangler deploy échoue.

Le bug du contenu invisible

On avait ajouté une classe CSS qui masquait le contenu jusqu’au chargement du JavaScript (pour les animations d’apparition au scroll). Résultat : les crawlers et les outils de capture d’écran voyaient des sections vides. Un commit pour corriger, mais ça aurait pu tuer notre SEO si on était passés à côté.

Leçon : Ne masquez jamais du contenu derrière JavaScript sans fallback. Les moteurs de recherche n’attendent pas votre IntersectionObserver.

Les chiffres

32 % des commits étaient des corrections de bugs. C’est normal. Aller vite, ça casse des choses.

Ce workflow est-il reproductible ?

Oui, mais ça dépend de comment vous vous y prenez.

Ce qui a rendu ça possible : la spec de 400 lignes. Pas un luxe, une nécessité. L’IA a généré des composants corrects du premier coup parce qu’elle avait toutes les informations. Spec bancale, résultat bancal, peu importe le modèle.

La stack disciplinée a aussi aidé. 12 dépendances, chacune justifiée. Moins de pièces mobiles, c’est moins de choses que l’IA doit comprendre et moins de surfaces où les choses cassent. On n’a jamais ajouté une librairie “au cas où.”

Ce qui n’est pas automatiquement transposable : j’avais des années d’expérience avec Astro, Tailwind et Cloudflare. L’IA amplifie l’expertise, elle ne la remplace pas. Si vous ne savez pas évaluer si un composant Astro est correct, vous ne saurez pas quand l’IA vous génère quelque chose de bancal. C’est aussi un site de contenu, pas une application avec beaucoup d’état. Plus votre projet est interactif, plus chaque composant demande de supervision.

La suite

Ce site est la base de tout ce qu’on va publier : études de cas, plongées techniques, tout ce qu’on a appris en gérant plus de 400 sites sur des clusters Kubernetes.

Prochain sujet : comment nos agents IA gèrent toute la flotte sans qu’on touche à rien. Voir tous nos articles ou contactez-nous si vous voulez qu’on construise quelque chose de similaire.