Articles sur : 🌍 Hébergement web

Puis-je utiliser un fichier vercel.json ?

Hodifly lit le fichier vercel.json à la racine de votre dépôt et l'applique au déploiement. Pour la plupart des projets statiques, migrer depuis Vercel ne demande aucun changement : poussez le même dépôt, et vos redirections, en-têtes, URL propres et tâches cron sont reprises. Les fonctions serverless du dossier api/ tournent aussi : voir l'article dédié « Comment créer des fonctions serverless ? ».

Ce qui est converti

Clé vercel.json	Ce que fait Hodifly
`redirects`	Converties en règles Apache. `permanent: true` (ou absent) donne un 308, `permanent: false` un 307, `statusCode` est respecté (301, 302, ...). Les motifs `/blog/:slug`, `/files/:path` et les sources regex comme `/(.)` fonctionnent, et les paramètres nommés sont réutilisables dans la destination. Les URL externes sont permises.
`rewrites`	Converties en règles internes : l'URL reste telle quelle pendant qu'une autre page est servie (le classique fallback SPA `{ "source": "/(.*)", "destination": "/index.html" }` marche tel quel). Les vrais fichiers gagnent toujours sur une rewrite, exactement comme chez Vercel.
`headers`	Chaque motif `source` devient une règle d'en-têtes (en-têtes de sécurité, `Cache-Control`, ...).
`cleanUrls`	`/about` sert `about.html`, et `/about.html` répond une redirection 308 vers `/about`.
`trailingSlash`	`true` ajoute la barre finale avec un 308, `false` la retire.
`images`	Traduit en optimisation d'images avec PageSpeed : recompression à la quality configurée et conversion WebP. `sizes`, `domains` et `remotePatterns` n'ont pas d'équivalent (pas d'API de redimensionnement à la demande). Si vous utilisez déjà PageSpeed pour ce site, le vôtre gagne, rien n'est écrasé.
`crons`	Chaque entrée devient une vraie tâche cron sur votre compte, visible et modifiable dans cPanel, Tâches Cron. Si le projet a une variable d'environnement `CRON_SECRET`, les appels portent `Authorization: Bearer <secret>`, même convention que Vercel.
`buildCommand`, `outputDirectory`, `installCommand`	Lus dans le fichier à chaque déploiement : ils fixent l'installation, le build et le dossier publié. Le projet est détecté avec le framework « Vercel » et ces champs deviennent en lecture seule dans le formulaire cPanel, avec une note qui l'explique. Pour les changer : modifiez `vercel.json` et poussez.
Fonctions `api/`	Elles tournent réellement, avec ou sans vercel.json. Voir l'article sur les fonctions.

Le journal de déploiement liste précisément ce qui a été converti (nombre de règles) et avertit pour tout ce qui ne l'a pas été : rien à deviner.

Priorité

Si votre dépôt contient aussi des fichiers Netlify _redirects ou _headers, ils sont ignorés dès qu'un vercel.json existe : une seule source de configuration, pas de fusion silencieuse. Le journal de déploiement l'indique explicitement.

Ce qui n'est pas converti, et pourquoi

Les rewrites vers une URL externe (proxy) : servir un autre site à travers le vôtre demande une couche proxy que l'hébergement mutualisé n'expose pas. La règle est ignorée, avec un avertissement dans le journal. Les redirections vers des URL externes fonctionnent, elles.
Les conditions has / missing : le filtrage par cookie, query ou en-tête n'est pas traduisible en règles Apache par répertoire. Les règles concernées sont ignorées, chacune nommée dans le journal.
routes (l'ancienne syntaxe) : migrez ces entrées vers redirects / rewrites / headers ; Vercel lui-même a déprécié cette clé.
regions, fluid : propres à la plateforme Vercel, sans équivalent ici. Les images sont servies telles quelles (pas de pipeline d'optimisation).

Bon à savoir

Le fichier vercel.json lui-même n'est jamais servi : il est retiré de la sortie publiée.
Les redirections cleanUrls et trailingSlash cohabitent sans risque avec les rewrites SPA et les pages 404 personnalisées : les réécritures internes ne les redéclenchent jamais.
Tout est réappliqué à chaque déploiement. Modifier vercel.json puis pousser suffit.

Mis à jour le : 27/07/2026

Cet article a-t-il répondu à vos questions ?

Merci !