« Fais-moi un site d'articles. Pour le reste, je te fais confiance ! »
L'IA s'y met avec enthousiasme : plus d'articles, plusieurs langues, des articles liés, des liens internes, un moteur de recherche, des contrôles qualité, des contrôles de sécurité et même de la réparation automatique. Ce qui devait être une petite épicerie de quartier devient une usine géante, avec service traduction, service contrôle, bureau d'audit et un « comité de validation des virgules ».
Et à la fin, l'écran affiche BUILD FAILED.
L'IA : « C'est corrigé. » Build suivant : échec. L'IA : « J'ai corrigé autre chose. » Encore raté. On bat le boss final, et un nouveau boss final apparaît. Voici pourquoi ça arrive, avec Cloudflare Pages et Astro comme exemple, et comment s'en sortir. C'est une explication générale, pas le diagnostic d'un site en particulier.
1. Un build, ça sert à quoi au juste ?
Vos textes en Markdown, vos images, votre mise en page et votre code ne sont que des ingrédients, pas un site fini. Le build, c'est l'étape qui transforme ces ingrédients en pages et en fichiers que le navigateur peut afficher. Astro place en général les fichiers statiques prêts à être mis en ligne dans un dossier appelé dist.[1]
Le texte, c'est la recette ; le build, c'est la cuisine. Poser un oignon cru et un livre de recettes sur la table en annonçant « à table ! », ça ne passe pas.
2. Que fait Cloudflare, et que ne fait-il pas ?
Cloudflare Pages peut récupérer votre code depuis Git, lancer la commande de build que vous avez configurée, puis mettre le résultat en ligne.[2] L'ordre habituel : récupérer le code → installer les outils → vérifier en amont → générer les pages → contrôler le résultat → déployer. Les étapes exactes dépendent des réglages de votre projet.
Le build, c'est fabriquer ; le déploiement, c'est expédier et mettre en ligne. Si le nouveau build échoue, cette version ne sort pas. Cloudflare fournit le bâtiment, mais la chaîne de production en forme de labyrinthe, à l'intérieur, vient souvent du propre code du site.
3. Un site qui publie tout seul travaille déjà beaucoup avant de créer la moindre page
Un blog simple transforme le texte en HTML, et c'est tout. Un système de publication automatique peut ajouter plein de tâches avant et après : cet article a-t-il le droit d'être publié ? Toutes les traductions sont-elles là ? L'identifiant de l'article correspond-il à l'URL ? Les articles liés et les liens internes sont-ils bons ? Peut-on générer les données de recherche ? Titres, descriptions d'images, publicités et règles de sécurité sont-ils respectés ?
Prise une par une, chaque vérification se tient. Le problème, c'est quand modifier une phrase oblige tous les services à refaire la réunion du matin. Vous vouliez juste corriger une virgule, et toute l'entreprise débarque en casque de chantier.
4. Pourquoi c'est plus dur avec beaucoup de pages et de langues ?
10 000 pages ne veulent pas forcément dire 10 000 fois plus de travail. Mais le nombre de fichiers grimpe, les articles se renvoient les uns aux autres, et chaque langue ajoute ses propres URL correspondantes et ses données de recherche. Si chaque build compare chaque article à tous les autres, tout s'alourdit à mesure que le site grandit.
Il vaut donc mieux ne recalculer que ce qui a changé, garder les résultats réutilisables et chronométrer chaque étape. Ce qui est lent, on le repère avec des chiffres, pas au feeling. Si chaque nouveau livre obligeait à reclasser toutes les bibliothèques du pays, le bibliothécaire fondrait en larmes.
5. Pourquoi chaque correction fait apparaître une nouvelle erreur ?
Quand les étapes s'enchaînent dans l'ordre, une erreur au début cache celles qui suivent. La vérification des articles bloque, on corrige. Puis la vérification des liens bloque, on corrige. Puis la génération des pages. Puis les données de recherche.
Ça ne prouve pas que chaque correction a créé un nouveau bug. Les problèmes étaient peut-être tous là dès le départ, à attendre leur tour. Mais une correction peut aussi vraiment casser autre chose. Pour savoir lequel des deux, il faut regarder les journaux (logs) et l'historique des modifications. On ouvre la porte du donjon, il y a une autre porte, et chacune porte l'inscription « DERNIER NIVEAU ».
6. Les 6 causes les plus courantes d'un build raté
1) Code et paquets : faute de frappe, paquet manquant, mauvaise version. 2) Données d'entrée : texte manquant, mauvais format. 3) Règles de contrôle : la page se génère, mais une règle la bloque. 4) Ressources : limite de temps, de mémoire ou de nombre de fichiers. 5) Environnement : les réglages de votre ordinateur et ceux de Cloudflare ne sont pas les mêmes. 6) Mise en ligne : le contrôle final ou l'envoi échoue.
Cloudflare Pages considère un build comme raté quand la commande se termine avec un code différent de 0.[2] Autrement dit, le « Build failed » tout en bas, c'est le résultat, pas forcément la cause. La couverture d'un polar ne vous dit pas qui est le coupable.
7. Lire le journal : cherchez la première erreur
Le Build log s'ouvre depuis les détails du déploiement dans Cloudflare.[3] Ne restez pas bloqué sur la dernière ligne rouge : cherchez la première étape qui a vraiment échoué, puis classez-la : données, code, règle, ressources ou environnement ? Si vous pouvez lancer cette étape seule, reproduisez le problème à part. Distinguez le rafistolage de la vraie correction, et une fois réparé, vérifiez que les étapes suivantes passent aussi.
Cliquer 100 fois sur « tout relancer » ne fera pas apparaître un fichier qui n'existe pas. Ce qu'il faut, c'est le numéro de la machine en panne, pas plus de motivation.
8. Cloudflare n'a pas qu'une seule limite
D'après la documentation officielle au 10 octobre 2026, l'offre gratuite de Pages donne droit à 500 builds par mois, 1 build à la fois, 20 minutes maximum par build et jusqu'à 20 000 fichiers statiques par site.[4] Sur un gros site, il n'y a pas que le HTML qui compte : les images et les fichiers de recherche entrent aussi dans le total.
Workers a ses propres limites sur le nombre de requêtes et le temps d'exécution. Les requêtes de Pages Functions peuvent être comptées côté Workers, mais avoir épuisé le quota Workers ne prouve pas que c'est pour ça que le build Pages a échoué.[4][5] Quand quelqu'un crie « on n'a plus de budget ! », demandez d'abord : lequel ?
9. Sophistiqué ne veut pas dire nécessaire
Une fuite de données personnelles, une grave faille de sécurité ou une page importante cassée doivent bloquer la publication. Mais arrêter tout le site parce que l'ordre des articles liés n'est pas parfait ? C'est une autre histoire.
Rangez vos contrôles en trois groupes : ceux qui bloquent la publication / ceux qui se contentent d'avertir / ceux qui tournent à part, à intervalles réguliers. Le critère, c'est le tort réel causé aux lecteurs et à ceux qui gèrent le site, pas le nom impressionnant du contrôle. Fermer l'usine pour toujours à cause d'un peu de poussière sur la poignée du bureau de contrôle, c'est laisser le contrôle prendre le pouvoir.
10. Le piège du « débrouille-toi »
« Fais en sorte qu'on remonte sur Google. » « Ajoute des langues. » « Que ça ne casse plus jamais. » « Ajoute encore un contrôle. » L'IA ajoute des fonctions en un clin d'œil. Chacune a l'air juste, mais en les enchaînant toutes, on peut finir avec un système où aucun article ne sort tant que chaque service n'a pas mis son tampon.
Ce n'est pas propre à l'IA : les équipes humaines aussi accumulent trop de fonctions et de la dette technique. L'IA va juste plus vite. Pas besoin d'écrire chaque ligne de code vous-même, mais il faut décider ce qu'on protège, ce qui peut attendre et où on s'arrête. On demande à l'IA de passer le balai, elle crée un comité de surveillance de l'aspirateur robot. Le sol est toujours sale.
11. Remettre le site en ligne en 3 étapes
Stopper l'hémorragie : mettez en pause les nouvelles fonctions, protégez la dernière version publiée correctement et trouvez la première erreur. Ne désactivez pas à la légère les contrôles de confidentialité ou de sécurité.
Séparer : dans chaque build, ne gardez que la génération des pages vraiment nécessaire. Le lourd, comme l'analyse de tout le site ou les petits contrôles, passe dans des tâches à part. Cloudflare propose les Build watch paths (pour choisir quels changements déclenchent un build) et un cache de build.[6][7] Mais les activer ne transforme pas comme par magie vos propres scripts qui traitent tout le site en scripts qui ne traitent que les changements.
Éviter que ça recommence : notez le temps de chaque étape, les types d'erreurs, le nombre de fichiers générés, le taux de publications réussies et le temps de remise en route. Le succès, ce n'est pas « l'IA a dit que c'était corrigé », c'est une version qui a passé tous les contrôles et qui est vraiment en ligne.
12. Et si le boss final, c'était le câblage de votre propre usine ?
Gérer beaucoup d'articles, plusieurs langues, des liens entre articles et des contrôles qualité, c'est vraiment difficile. Mais rien n'oblige à tout entasser dans un seul build. Demandez-vous pourquoi cet avertissement bloque la publication, pourquoi tout est recalculé à chaque fois, et quelles tâches pourraient continuer de leur côté.
L'idéal : pendant que vous dormez, les articles à risque sont bloqués, les autres sortent normalement, et seule l'étape en panne vous envoie une alerte.
L'IA : « Tout est prêt ! » L'humain : « Donc c'est en ligne ? » L'IA : « Le build a échoué. »
La seule chose vraiment automatisée, c'était la fabrique d'excuses.
Références (7)
- Astro Docs, CLI reference: astro build docs.astro.build
- Cloudflare Docs, Build configuration (updated 2026-09-18) developers.cloudflare.com
- Cloudflare Docs, Debugging Pages (updated 2026-06-02) developers.cloudflare.com
- Cloudflare Docs, Pages limits (updated 2026-09-05) developers.cloudflare.com
- Cloudflare Docs, Workers limits (updated 2026-09-05) developers.cloudflare.com
- Cloudflare Docs, Build watch paths (updated 2026-04-21) developers.cloudflare.com
- Cloudflare Docs, Build caching (updated 2026-05-27) developers.cloudflare.com
