Héberger un site généré par IA : Lovable, v0, Bolt

Ce que contient le zip, et ce qu’il ne contient pas

Lovable, v0 et Bolt produisent tous à peu près la même chose : un projet Vite + React, en TypeScript, souvent avec Tailwind et des composants shadcn/ui. Ouvrez l’archive, vous y trouverez un package.json, un dossier src/, un index.html qui ne contient presque rien, et un vite.config.

Ce que vous n’y trouverez pas, c’est votre site. L’index.html d’un projet Vite contient une div vide et une balise script : tout le contenu est produit par du JavaScript qui n’a pas encore été compilé. Déposez ce dossier tel quel chez un hébergeur classique et vous obtiendrez une page blanche — non pas parce que quelque chose est cassé, mais parce qu’il manque l’étape que votre machine n’a jamais faite.

$ cat index.html

<!doctype html>
<html lang="fr">
  <head>
    <meta charset="UTF-8" />
    <title>Mon app générée par IA</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/src/main.jsx"></script>
  </body>
</html>

Sortie réelle, sur un projet Vite + React, le 2 septembre 2026.

Il manque trois choses entre ce fichier et un site en ligne : l’installation des dépendances (npm install), la compilation (npm run build, qui écrit un dossier dist/), et un serveur pour servir ce dossier en HTTPS. Un hébergeur qui accepte des projets d’IA est simplement un hébergeur qui fait ces trois étapes à votre place.

On l’a fait pour de vrai, et ça a raté trois fois

Plutôt que de décrire un déploiement idéal, nous en avons lancé un sur notre propre production, avec un projet fraîchement créé. Voici ce qui s’est passé, dans l’ordre.

Première panne : la version de Node

Le premier envoi échoue au bout de 85 secondes. Notre constructeur — Nixpacks — regarde le projet, n’y trouve aucune indication de version, et applique sa valeur par défaut : Node 18. Or la chaîne de compilation moderne de Vite ne s’exécute plus sur Node 18.

$ journal du déploiement dep_…n6185p

> demo-vite@0.0.0 build
> tsc -b && vite build

SyntaxError: The requested module 'node:util' does not provide an export
named 'styleText'
import { formatWithOptions, styleText } from "node:util";
                            ^^^^^^^^^
Node.js v18.20.5

ERROR: process "/bin/bash -ol pipefail -c npm run build" did not complete
successfully: exit code: 1

Sortie réelle, sur notre nœud sw6c-3, le 2 septembre 2026 à 12h12.

styleText est une fonction ajoutée à Node 20. Le message ne parle jamais de version : il parle d’un export manquant dans un module interne, ce qui n’aide personne. La correction tient en trois lignes dans le package.json, et c’est la seule chose que la plupart des exports d’IA demandent :

package.json

{
  "engines": {
    "node": "22"
  }
}

Déclarer la version de Node. À faire systématiquement, quel que soit l’hébergeur.

Deuxième panne : le verrou de dépendances vient de votre Mac

Deuxième envoi, deuxième échec, en 57 secondes cette fois. Node 22 est bien pris en compte, mais la compilation s’arrête sur un message déroutant.

$ journal du déploiement dep_…ten386

Error: Cannot find native binding. npm has a bug related to optional
dependencies (https://github.com/npm/cli/issues/4828). Please try
`npm i` again after removing both package-lock.json and node_modules
directory.
  cause: Error: Cannot find module '@rolldown/binding-linux-x64-gnu'
    cause: Error: Cannot find module '../rolldown-binding.linux-x64-gnu.node'

Sortie réelle, sur notre nœud sw6c-3, le 2 septembre 2026 à 12h14.

Traduction : le package-lock.json présent dans l’archive a été produit sur un Mac. Il fige les binaires compilés pour macOS et ignore ceux de Linux, sur lequel tourne le serveur. C’est un défaut connu de npm, référencé depuis 2022, et il frappe tous les outils modernes qui embarquent du code natif — rolldown, esbuild, swc, sharp.

La parade est contre-intuitive : n’envoyez pas votre verrou de dépendances s’il a été fabriqué sur une autre plateforme que celle qui compile. Le serveur résoudra les versions lui-même, sur Linux, avec les bons binaires.

terminal

tar czf mon-app.tar.gz \
  --exclude=node_modules \
  --exclude=dist \
  --exclude=package-lock.json \
  -C mon-app .

À l’archivage, ou simplement en supprimant le fichier avant l’envoi.

Troisième panne : 22.11 n’est pas 22.12

Troisième échec, en 19 secondes. Et c’est le plus fin des trois. Notre constructeur installe bien Node 22 comme demandé — mais la version 22.11.0. Or les dernières versions de Vite exigent ^20.19.0 || >=22.12.0. Il manque une version corrective.

$ journal du déploiement dep_…hrf2zn

npm warn EBADENGINE Unsupported engine {
npm warn EBADENGINE   package: 'vite@8.2.2',
npm warn EBADENGINE   required: { node: '^20.19.0 || >=22.12.0' },
npm warn EBADENGINE   current: { node: 'v22.11.0', npm: '10.9.0' }
npm warn EBADENGINE }

Sortie réelle, sur notre nœud sw6c-3, le 2 septembre 2026 à 12h16.

Notez que npm émet un avertissement, pas une erreur : la compilation continue, et casse plus loin, sur un message qui ne mentionne plus la version. C’est le piège classique — la ligne qui explique la panne défile trente secondes avant celle qui l’annonce.

La réserve

Ce troisième échec est de notre faute, pas de la vôtre, et il n’est pas corrigé au moment où ce guide est publié. Nous avons essayé les contournements avant de vous les proposer, et aucun ne marche : les trois versions que fournit notre constructeur sont 18.20.5, 20.18.1 et 22.11.0, c’est-à-dire trois versions toutes situées juste en dessous des seuils exigés. Pire, demander "node": "24" ne produit pas d’erreur : le constructeur ne connaît pas cette version et retombe silencieusement sur Node 18, ce qui vous ramène à la première panne sans rien vous dire.

Donc, tant que nous n’aurons pas mis notre constructeur à jour : si votre projet utilise la toute dernière version de Vite, restez sur la précédente. C’est un aveu, pas un conseil, et c’est à nous de le faire disparaître. Nous le publions parce qu’un guide qui ne montre que les pannes des autres n’est pas un guide honnête.

Ce qui a fonctionné, et en combien de temps

Quatrième essai, avec une pile réaliste — celle que produisent réellement Lovable et Bolt aujourd’hui, c’est-à-dire Vite 6 et React 18, et non le tout dernier échafaudage de npm que nous avions pris au départ. Le package.json tient en quinze lignes et déclare sa version de Node.

$ journal du déploiement dep_…62mf4q

╔═══════════════════════ Nixpacks v1.34.1 ═══════════════════════╗
║ setup      │ nodejs_22, npm-9_x                                ║
║ caddy      │ pkgs: caddy                                       ║
║ install    │ npm i                                             ║
║ build      │ npm run build                                     ║
║ start      │ exec caddy run --config /assets/Caddyfile         ║
╚════════════════════════════════════════════════════════════════╝

✓ build en 49.9s
→ déploiement de la charge wl_proj_01M1GSZ44J4596NZCFFVA90CFZ
✓ charge running
✓ en ligne : https://demo-ia-blog.swigs.cloud

Sortie réelle, sur notre nœud sw6c-3, le 2 septembre 2026 à 12h18.

Cinquante-cinq secondes entre l’envoi de l’archive et le site en ligne, dont cinquante de compilation. Le certificat HTTPS a été émis dans la foulée, sans intervention.

Vérifiez vous-même

Le site de démonstration est encore en ligne au moment où vous lisez ceci. Vérifiez son certificat et sa provenance vous-même.

curl -sI https://demo-ia-blog.swigs.cloud/ | head -1

echo | openssl s_client -connect demo-ia-blog.swigs.cloud:443 \
  -servername demo-ia-blog.swigs.cloud 2>/dev/null \
  | openssl x509 -noout -issuer -dates

Un 200, et un certificat Let’s Encrypt émis le 2 septembre 2026 à 09h19 UTC — une minute après la fin du déploiement.

Un point mérite d’être relevé dans le journal : la ligne start ne lance pas Node, elle lance Caddy. Le constructeur a reconnu une application à page unique, compilé le dossier dist/, et l’a confié à un serveur de fichiers. Vous n’avez donc pas besoin d’ajouter un script start à votre projet — c’est une erreur fréquente, et elle est inutile.

Tableau de bord Swigs Cloud affichant quatre projets : un en ligne et trois en échec — Le tableau de bord à la fin de l’expérience : trois échecs, une réussite. C’est l’état réel du compte de démonstration, pas une mise en scène. Capture du 2 septembre 2026.

La liste à vérifier avant d’envoyer

À vérifier	Pourquoi	Comment
La version de Node est déclarée	Sans elle, le constructeur choisit, et il choisit vieux.	`"engines": { "node": "22" }` dans le `package.json`.
node_modules n’est pas dans l’archive	Des centaines de mégaoctets inutiles, et souvent faux pour Linux.	L’exclure de l’archive.
Le verrou vient de la même plateforme	Sinon, binaires natifs manquants au moment de compiler.	L’exclure aussi, ou le régénérer sous Linux.
Les clés d’API ne sont pas dans le code	Une clé compilée dans un fichier JavaScript est publique.	Variables d’environnement, préfixées `VITE_` seulement pour ce qui peut être public.
Le projet compile chez vous	Un projet qui échoue en local échouera sur le serveur.	`rm -rf node_modules && npm i && npm run build`

Ce qu’il faut retenir

Un export d’IA n’est pas un site, c’est un projet à compiler. Les trois pannes que nous avons rencontrées tiennent toutes à la même cause : ce qui marche sur votre machine dépend de choses que le zip ne transporte pas — votre version de Node, votre système d’exploitation, vos variables d’environnement. Déclarez la première, ne transportez pas les traces du deuxième, et gardez les troisièmes hors du code.

Le reste est l’affaire de l’hébergeur, et se compte en secondes.

Sources

[1]npm/cli issue 4828 — dépendances optionnelles et binaires natifs — le défaut à l’origine de la deuxième panne, ouvert en 2022 et toujours d’actualité.
[2]Journaux de déploiement — les quatre déploiements cités ont eu lieu le 2 septembre 2026 entre 12h11 et 12h18 sur le nœud sw6c-3 de Swigs Cloud. Les identifiants figurent dans les extraits.
[3]Nixpacks — le constructeur qui détecte le type de projet et fabrique l’image. Version 1.34.1 au moment de l’expérience.