Ce retour d’expérience détaille la reconstruction complète d’un site institutionnel de 83 pages en 5 jours avec Next.js, Payload CMS et l’IA. Le stack headless a permis d’atteindre un score PageSpeed de 100/100 et un temps de chargement inférieur à 1 seconde. L’IA (Claude, Cursor) a accéléré le développement d’un facteur 3 à 5 sur la génération de composants et la migration de contenu.
260 commits. 5 jours. 1 développeur. 83 pages. Zéro ligne de PHP.
Quand un expert WordPress décide de sortir de sa zone de confort pour reconstruire un site institutionnel complet avec une stack JavaScript moderne — et que l'IA co-signe 80% du code — ça donne quoi exactement ?
Retour d'expérience sur la refonte du site Pôle Sup Vincent de Paul (Nîmes), un établissement d'enseignement supérieur. Un projet qui m'a fait repenser tout ce que je croyais savoir sur la création de sites web.
Ce type de projet illustre pourquoi l’accompagnement par un expert WordPress change la donne quand on sort du CMS traditionnel.
Pourquoi j'ai quitté WordPress (pour ce projet)
Soyons clairs d'entrée : je n'ai pas quitté WordPress. WordPress reste mon outil principal, mon expertise, le sujet de ce blog depuis plus de 10 ans. Ce que j'ai fait, c'est reconnaître qu'un projet spécifique méritait une approche différente.
Le brief était le suivant : reconstruire le site vitrine de Pôle Sup Vincent de Paul, un établissement d'enseignement supérieur à Nîmes. Le site devait présenter 14 formations (BTS, Bachelor, Mastère, Titres Professionnels), plus de 40 fiches métiers, une section actualités, l'équipe pédagogique, et toutes les pages institutionnelles associées.
Les raisons du choix
La performance avant tout. Un site institutionnel doit charger vite, surtout sur mobile — les lycéens et leurs parents consultent principalement sur smartphone. Avec la génération statique (SSG), chaque page est pré-rendue en HTML pur. Pas de requêtes base de données à chaque visite. Pas de PHP à interpréter. Le résultat : un score Lighthouse mobile de 94/96/100/100 (Performance/Accessibilité/Bonnes pratiques/SEO).
La sécurité par design. Un site WordPress exposé sur Internet, c'est une surface d'attaque que je connais très bien — et que les attaquants connaissent aussi. Avec un site statique servi par CDN, il n'y a littéralement rien à attaquer côté frontend. L'admin CMS est isolé, protégé, rate-limité.
L'esthétisme et la modernité. React + Tailwind CSS v4 + Framer Motion permettent des animations fluides, un design system cohérent, et une liberté créative que les page builders WordPress n'offrent tout simplement pas au même niveau.
L'expérience d'édition. Payload CMS offre un éditeur rich text (Lexical) moderne, un live preview instantané, et une interface admin épurée. Pour un client non-technique, c'est plus intuitif qu'un WordPress surchargé de plugins.
La stack choisie : Next.js + Payload CMS + Netlify
Voici l'architecture complète du projet. Si vous êtes développeur, les encadrés techniques vous donneront les détails d'implémentation. Si vous êtes plutôt intéressé par la vision d'ensemble, les paragraphes narratifs suffisent.
Next.js 16 — Le framework
Next.js est le framework React le plus populaire au monde. Il est maintenu par Vercel et utilisé par des entreprises comme Netflix, TikTok, Nike ou Notion. Pour ce projet, j'utilise la version 16.1.6 avec l'App Router et la génération statique (SSG).
Concrètement, Next.js me permet de :
- Générer 83+ pages en HTML statique lors du build (pas de serveur à maintenir)
- Optimiser automatiquement les images (redimensionnement, formats modernes, lazy loading)
- Avoir un routing basé sur le système de fichiers — chaque dossier = une route
- Utiliser les React Server Components — le code serveur et client cohabitent intelligemment
🔧 Encadré technique — Architecture dual route groups
Le projet utilise deux route groups Next.js isolés :
- app/(site)/layout.tsx — pages publiques (fonts Google, SEO, GA4, Navbar, Footer)
- app/(payload)/layout.tsx — admin Payload (layout autonome)
Chaque group a son propre <html> et <body>. C'est une contrainte Payload CMS : si on partage un layout racine, on obtient une erreur d'hydration (double <html>). Cette séparation garantit aussi qu'aucun asset admin ne pollue le bundle public.
Payload CMS 3.77 — Le CMS headless
Si vous ne connaissez pas encore Payload CMS, retenez ceci : c'est un CMS headless open source, code-first, qui s'intègre nativement dans Next.js. Contrairement à WordPress où le CMS est le site, ici le CMS est un outil d'administration intégré au projet.
7 collections structurent le contenu :
| Collection | Contenu | Nombre |
|---|---|---|
| Posts | Articles / Actualités | 10 |
| Formations | BTS, Bachelor, Mastère, Titre Pro | 14 |
| Jobs | Fiches métiers détaillées | 40+ |
| Team | Membres de l'équipe pédagogique | 15 |
| Media | Images et documents | 57 |
| Users | Administrateurs | 2 |
| Subscribers | Inscrits newsletter | — |
8 Globals permettent d'éditer chaque page du site directement depuis l'admin : Homepage, Contact, Entreprises, Pôle Sup, Candidater, Équipe, Formations, et les paramètres généraux du site.
🔧 Encadré technique — Dual database
Le projet utilise un système de double base de données :
db: process.env.DATABASE_URI
? postgresAdapter({ pool: { connectionString: process.env.DATABASE_URI } })
: sqliteAdapter({ client: { url: 'file:./payload-data.db' } })
- En développement : SQLite local (zéro configuration, fichier unique)
- En production : PostgreSQL sur Neon (Frankfurt, pour la latence EU)
Ce pattern permet de développer sans connexion internet tout en bénéficiant d'une vraie base relationnelle en production.
Netlify — L'hébergement
Netlify héberge le site avec un déploiement continu depuis GitHub. Chaque git push sur main déclenche automatiquement un build et un déploiement en ~90 secondes.
Mais ce qui rend l'architecture vraiment élégante, c'est le webhook de rebuild automatique. Quand un administrateur modifie du contenu dans Payload CMS (ajoute un article, met à jour une formation…), un hook afterChange déclenche automatiquement un rebuild Netlify. Le site est régénéré avec le nouveau contenu en moins de 2 minutes, sans aucune intervention technique.
Le site est servi par le CDN Edge de Netlify — les pages statiques sont distribuées dans le monde entier et servies depuis le point de présence le plus proche du visiteur.
Cloudflare R2 — Le stockage média
Les médias (images, PDF) sont stockés sur Cloudflare R2, un service de stockage objet compatible S3 mais sans frais de bande passante sortante (egress). Un hook Payload custom uploade automatiquement chaque fichier vers R2 après son ajout dans l'admin.
Côté visiteur, une redirection Netlify transparente (/api/media/file/* → R2) sert les fichiers directement depuis le CDN Cloudflare.
🔧 Encadré technique — Pourquoi pas le plugin officiel S3 ?
J'ai initialement essayé @payloadcms/storage-s3, le plugin officiel Payload pour le stockage S3. Résultat : écran blanc total sur l'admin. Le plugin causait un mismatch d'hydration React Server Components (RSC) — le HTML initial était rendu en thème light mais le JavaScript client tentait de s'hydrater en dark.
La solution : un hook custom afterChange qui utilise directement @aws-sdk/client-s3 avec un import dynamique. Plus léger, plus fiable, et totalement maîtrisé.
GitHub — Le versionnage
Tout le projet est versionné sur GitHub avec une convention de commits stricte : [TYPE] Description (FEAT, FIX, STYLE, REFACTOR, PERF, SEO, DOCS, UX, SEC…). Cette convention permet de retracer instantanément l'historique du projet et de comprendre la nature de chaque modification.
En 5 jours : 260 commits, soit une moyenne de 52 commits par jour. Ce rythme intense n'est possible que grâce à l'IA.
L'IA comme co-pilote : Claude Code + Gemini
C'est le cœur de cet article et probablement ce qui vous intéresse le plus : comment l'IA a-t-elle été utilisée concrètement ?
Les chiffres parlent d'eux-mêmes
Sur les 260 commits du projet :
| Co-auteur IA | Commits | Part |
|---|---|---|
| Claude Opus 4.6 | 155 | 59.6% |
| Claude Sonnet 4.6 | 34 | 13.1% |
| Claude Sonnet 4.5 | 12 | 4.6% |
| Anti-Gravity (Gemini) | 4 | 1.5% |
| Sans IA | 55 | 21.2% |
| Total avec IA | 205 | 78.8% |
Près de 80% du code a été co-écrit avec une intelligence artificielle. Mais attention, " co-écrit " ne veut pas dire " généré aveuglément ". Voici comment la collaboration fonctionnait réellement.
VSCode + Claude Code : le duo quotidien
Claude Code est l'outil CLI officiel d'Anthropic pour Claude. Il s'intègre directement dans le terminal VSCode et a accès au contexte complet du projet : fichiers, git, terminal, historique.
Mon workflow typique ressemblait à ça :
- Je décris ce que je veux en langage naturel — "Ajoute une section FAQ avec accordion animé sur la page Candidater, utilise Framer Motion pour les animations"
- Claude Code explore le codebase — il lit les fichiers existants, comprend l'architecture, identifie les patterns en place
- Il propose une implémentation — code TypeScript/React complet, cohérent avec le design system existant
- Je review, j'ajuste, je valide — comme avec un développeur junior très rapide
- On commit ensemble — le commit est co-signé Co-Authored-By: Claude Opus 4.6
Ce qui rend Claude Code particulièrement efficace, c'est sa mémoire du projet. Grâce au fichier CLAUDE.md à la racine du projet et aux fichiers mémoire associés, Claude connaît :
- Les conventions du projet (couleurs brand, structure des composants, patterns CSS)
- Les pièges à éviter (versions instables, plugins incompatibles, configs sensibles)
- L'état actuel de la production (pages déployées, collections, scores Lighthouse)
- Les leçons des erreurs passées
C'est comme travailler avec un développeur qui ne part jamais en vacances, ne perd jamais le contexte, et a lu toute la documentation.
Anti-Gravity (Gemini) : le bootstrapper
Le projet a en réalité commencé avec Anti-Gravity, un outil basé sur Gemini 2.5 Pro (Google). Anti-Gravity a généré le squelette initial du projet : structure Next.js, premières pages, composants de base.
Ce premier jet a ensuite été affiné, restructuré et enrichi par Claude Code. Les 4 commits d'Anti-Gravity représentent le point de départ — les 256 suivants représentent l'évolution vers le produit final.
C'est une approche que je recommande : utiliser le meilleur de chaque IA. Gemini excelle dans la génération de projets complets à partir de zéro (scaffolding). Claude excelle dans le raffinement, la résolution de problèmes complexes et la cohérence sur la durée.
Le rôle de l'humain
Soyons honnêtes : l'IA ne fait pas tout. Mon rôle était crucial à chaque étape :
- Direction créative — L'IA propose, je décide. Le choix des couleurs, la structure des pages, le ton éditorial, tout ça vient de moi et du brief client.
- Architecture — C'est moi qui ai décidé de migrer de Keystatic vers Payload CMS, de passer à R2 pour le stockage, d'adopter la convention de commits.
- Debugging critique — Quand l'admin Payload affichait un écran blanc, c'est la collaboration humain + IA qui a identifié le mismatch RSC. L'IA seule n'aurait pas pu reproduire le bug dans un environnement serverless.
- Quality assurance — Chaque modification est relue, testée, vérifiée en production. L'IA peut écrire 100 lignes de code en 10 secondes, mais si ces 100 lignes cassent le build, elles ne valent rien.
- Décisions business — Le choix de l'hébergeur, le budget, les priorités de développement — tout ça reste humain.
L'IA est un multiplicateur de force, pas un remplaçant. Un bon prompt sans expertise technique ne donnera que du code médiocre. Une expertise technique sans IA donnera un bon résultat, mais en 10 fois plus de temps.
Chronologie : 5 jours de build intensif
Voici le journal détaillé de ces 5 jours de développement. Chaque jour avait son thème principal.
Jour 1 — Lundi 17 février : Le scaffolding (56 commits)
La journée commence avec Anti-Gravity (Gemini) qui génère le projet initial : structure Next.js, pages de base, premiers composants. On obtient rapidement un squelette fonctionnel avec les pages Accueil, Équipe, Contact, et les pages légales.
Premier CMS intégré : Keystatic (fichiers Markdown). Puis dans la foulée, test de Decap CMS avec Netlify Identity. Deux approches, deux limitations.
Bilan du jour : un site qui tourne, mais pas encore satisfaisant côté gestion de contenu.
Jour 2 — Mardi 18 février : La grande migration CMS (46 commits)
C'est LE tournant du projet. Après avoir testé Keystatic puis Decap CMS, la décision est prise : migration vers Payload CMS 3.0.
Pourquoi ? Payload est code-first (tout est TypeScript), s'intègre nativement dans Next.js (même processus Node), offre un éditeur rich text moderne (Lexical), et un live preview instantané. C'est un CMS fait pour les développeurs qui veulent garder le contrôle.
En une seule journée :
- 7 collections créées et structurées
- 8 Globals câblés aux pages existantes
- 14 pages entièrement connectées au CMS
- 40+ fiches métiers importées et enrichies
- Script de migration automatique depuis Keystatic (133 records migrés)
🔧 Encadré technique — 3 CMS en 5 jours
Le projet a traversé 3 CMS en 5 jours :
- Keystatic (fichiers Markdown/YAML) → Trop limité pour le contenu structuré
- Decap CMS (ex-Netlify CMS) → Dépendance Netlify Identity, UX datée
- Payload CMS 3.77 → Code-first, TypeScript natif, Lexical editor, live preview
La migration a été facilitée par un script seed.ts qui a automatiquement transféré les 133 records Keystatic vers Payload. Leçon apprise : ne pas s'attacher au premier outil choisi. Migrer tôt coûte moins cher que migrer tard.
Jour 3 — Mercredi 19 février : Design et infrastructure (51 commits)
Journée dédiée au polish visuel et à l'infrastructure :
- Intégration du logo officiel et de la nouvelle charte graphique
- Mise en place de Cloudflare R2 pour le stockage des médias
- Personnalisation de l'admin Payload — thème custom, override dark mode, composants dashboard
- Newsletter fonctionnelle avec l'API Resend
- Éditeur Lexical enrichi — toolbar fixe, styles inline, alignement, listes
Le design system prend forme : couleurs brand (#1e3a8a bleu institutionnel, #c5e035 vert accent), typographie Outfit (Google Fonts), animations Framer Motion.
Jour 4 — Jeudi 20 février : Sécurité et accessibilité (43 commits)
Journée audit. Trois phases d'audit successives :
Phase 1 — Sécurité :
- HSTS avec preload
- Content Security Policy restrictive (sans unsafe-eval)
- Headers de sécurité (X-Frame-Options, COOP, X-Content-Type-Options)
- Masquage du header X-Powered-By
- Rate limiting sur les API
- Blocage de /api/access (exposait la structure des collections)
Phase 2 — Accessibilité :
- Attributs ARIA sur tous les éléments interactifs
- Contrastes vérifiés (le vert accent #c5e035 a un contraste de 1.5:1 sur blanc — insuffisant pour du texte, ok pour des boutons avec texte foncé)
- Navigation clavier complète
- prefers-reduced-motion respecté
Phase 3 — Monitoring :
- Mise en place de Lighthouse CI automatique (GitHub Actions)
- Configuration de UptimeRobot (5 monitors : site, admin, DNS, SSL, réponse API)
- Build standalone optimisé pour rester sous la limite de 250 MB de Netlify
Jour 5 — Vendredi 21 février : Tests et finalisation (64 commits)
Le jour le plus intense (64 commits !). Focus sur la qualité :
- 81 tests E2E Playwright écrits et exécutés sur 3 navigateurs (Chromium, Firefox, WebKit)
- Audit SEO complet — URLs canoniques, balises Open Graph avec type, titres optimisés, JSON-LD (Course, FAQPage, BreadcrumbList)
- Corrections UX finales — simplification des hero articles, breadcrumbs intégrés dans les PageHero
- Page 404 personnalisée — landing autonome en plein écran
Et sur mobile, le site reste parfaitement utilisable :
🔧 Encadré technique — L'audit SEO en détail
Le score SEO est passé de 72 à ~90/100 grâce à :
- URLs canoniques sur toutes les pages
- Balises og:type correctement propagées (piège Next.js : le shallow merge d'openGraph perd le type si une page le override sans le redéclarer)
- JSON-LD structuré : Course pour les formations, FAQPage pour les FAQ, BreadcrumbList pour la navigation
- Sitemap dynamique générée depuis Payload
- Meta descriptions uniques par page
- Titres <h1> uniques et pertinents
Les défis techniques (et comment on les a résolus)
Aucun projet n'est sans embûches. Voici les 5 défis majeurs rencontrés et leurs solutions.
1. L'écran blanc de l'admin Payload
Le problème : Après l'installation du plugin officiel @payloadcms/storage-s3, l'interface d'administration /admin/ retournait une page complètement blanche. Code HTTP 200 (pas d'erreur serveur), aucune erreur console, body vide.
Le diagnostic : Le plugin causait un mismatch d'hydration React Server Components (RSC). Le HTML initial généré côté serveur utilisait le thème light, mais le JavaScript côté client tentait de s'hydrater avec le thème dark (hérité du système d'exploitation). Cette incohérence faisait crasher silencieusement toute l'application admin.
La solution : Abandon complet du plugin officiel. Remplacement par un hook custom afterChange qui utilise directement le SDK AWS (@aws-sdk/client-s3) avec un import dynamique pour éviter de polluer le bundle client.
La leçon : Ne jamais modifier simultanément payload.config.ts, next.config.ts ET netlify.toml. Un seul changement à la fois, push, vérification en production, puis le suivant.
2. Le crash serverless Drizzle
Le problème : L'admin Payload retournait des erreurs 500/502 en production après certains déploiements.
La cause : L'option push: true de l'adaptateur PostgreSQL Drizzle lance un prompt interactif dans le terminal pour confirmer les modifications de schéma. En environnement serverless (Netlify Functions), il n'y a pas de stdin → blocage infini → timeout → 502.
La solution : push: false systématiquement en production. Les modifications de schéma sont faites en local avec push: true contre la base de développement, puis le code est déployé avec push: false.
3. Le bundle trop volumineux
Le problème : Les fonctions serverless de Netlify ont une limite de 250 MB. Avec Payload CMS, les dépendances (Sharp, GraphQL, Drizzle, SQLite/Postgres adapters) gonflent rapidement le bundle.
La solution : Combinaison de output: 'standalone' (Next.js trace et ne copie que les fichiers nécessaires) et outputFileTracingExcludes pour exclure les assets statiques du bundle serveur. Résultat : un bundle fonctionnel bien en dessous de la limite.
4. Le contenu Lexical fragmenté
Le problème : En copiant-collant du contenu dans l'éditeur Lexical de Payload, certains éléments de liste étaient fragmentés — un listitem se retrouvait coupé en un fragment de liste + un paragraphe séparé, cassant le rendu frontend.
La solution : Vérification systématique du contenu via l'API Payload (GET /api/formations/[id]), identification des fragments dans l'AST Lexical, et correction manuelle via PATCH. Le RichTextRenderer custom a été renforcé pour gérer gracieusement ces cas edge.
5. Les images R2 en doublon
Le problème : L'URL coverImage.url retournée par Payload CMS pointait vers la redirection Netlify → R2, qui servait parfois des doublons d'images.
La solution : Abandon de l'URL dynamique CMS pour les images d'articles. Utilisation d'images statiques mappées (POST_IMAGE_MAP) ou servies depuis /images/posts/${slug}.jpg. Plus prévisible, plus rapide, plus fiable.
Résultats et métriques
Après 5 jours de développement intensif, voici les résultats concrets.
Lighthouse (mobile)
| Métrique | Score |
|---|---|
| Performance | 94 |
| Accessibilité | 96 |
| Bonnes pratiques | 100 |
| SEO | 100 |
Pour comparaison, la plupart des sites WordPress obtiennent des scores entre 40 et 70 en performance mobile, même avec des plugins d'optimisation.
Core Web Vitals
| Métrique | Valeur | Verdict |
|---|---|---|
| First Contentful Paint | 1.3s | Bon |
| Largest Contentful Paint | 3.0s | À surveiller |
| Total Blocking Time | 0ms | Excellent |
| Cumulative Layout Shift | 0 | Parfait |
0ms de Total Blocking Time — c'est la magie du SSG. Aucun JavaScript bloquant à charger.
Volume de contenu
| Élément | Quantité |
|---|---|
| Pages SSG générées | 83+ |
| Formations détaillées | 14 |
| Fiches métiers | 40+ |
| Articles actualités | 10 |
| Membres équipe | 15 |
| Médias uploadés | 57 |
| Tests E2E | 81 (3 navigateurs) |
Code
| Métrique | Valeur |
|---|---|
| Commits totaux | 260 |
| Lignes TypeScript | 56 522 |
| Composants React | 17+ |
| Collections Payload | 7 |
| Globals Payload | 8 |
| Durée de build | ~90 secondes |
| Temps de rebuild (contenu) | ~2 minutes |
Voici quelques pages représentatives du volume et de la qualité du contenu :
Comparatif honnête : WordPress vs Next.js + Payload
Je connais WordPress mieux que quiconque — c'est mon métier depuis plus de 10 ans. Voici un comparatif honnête, sans parti pris.
Tableau comparatif
| Critère | WordPress | Next.js + Payload CMS |
|---|---|---|
| Courbe d'apprentissage | Faible (interface visuelle) | Élevée (code TypeScript) |
| Temps de mise en place | 1-2 jours (thème + plugins) | 3-5 jours (code custom) |
| Performance (Lighthouse) | 40-70 (typique, mobile) | 90-100 (SSG natif) |
| Sécurité | Surface d'attaque large (PHP, plugins, DB exposée) | Surface minimale (statique + admin isolé) |
| Hébergement | Mutualisé classique (~5-15€/mois) | Netlify gratuit ou ~19$/mois |
| Maintenance | Mises à jour WP + plugins + PHP + thème | npm update + redeploy |
| Personnalisation | Limité par thème/plugins | Illimité (code custom) |
| Écosystème plugins | 60 000+ plugins | Limité (mais extensible en code) |
| SEO | Via Yoast/RankMath + plugins | Natif (metadata API, JSON-LD, sitemap) |
| Édition contenu | Gutenberg / Builders visuels | Payload Admin (Lexical editor) |
| Multilingue | WPML / Polylang | i18n natif Next.js |
| E-commerce | WooCommerce (complet) | À développer ou Snipcart/Shopify |
| Coût total 1ère année | 200-500€ | 0-250€ |
Quand choisir WordPress
- Blog personnel ou professionnel
- Site e-commerce (WooCommerce est imbattable)
- Client qui veut modifier le design lui-même
- Budget serré avec besoin de fonctionnalités riches (plugins)
- Pas de développeur dans l'équipe
Quand choisir Next.js + Payload
- Site vitrine haut de gamme où la performance est critique
- Projets avec des besoins de design très spécifiques
- Équipe avec des compétences JavaScript/TypeScript
- Sites avec du contenu structuré et des relations complexes
- Projets où la sécurité est une priorité absolue
- Quand on veut un contrôle total sur chaque aspect
Mon verdict
WordPress reste le choix par défaut pour 80% des projets web. Mais pour les 20% restants — les sites vitrines premium, les applications web, les projets avec des exigences de performance extrêmes — la stack Next.js + Payload CMS est aujourd'hui la meilleure alternative que j'ai testée.
Ce qui a fondamentalement changé la donne, c'est l'IA. Sans Claude Code, ce projet aurait pris 3 à 4 semaines au lieu de 5 jours. L'IA compense largement la courbe d'apprentissage de la stack JavaScript pour quelqu'un venant du monde WordPress.
Combien ça coûte ?
Transparence totale sur les coûts de ce projet.
Hébergement et infrastructure
| Service | Coût mensuel | Notes |
|---|---|---|
| Netlify (hébergement) | 0€ (gratuit) | Tier gratuit : 100 GB bande passante, 300 min build/mois |
| Neon (PostgreSQL) | 0€ (gratuit) | Tier gratuit : 0.5 GB stockage, 190 heures compute |
| Cloudflare R2 (stockage) | 0€ (gratuit) | Tier gratuit : 10 GB stockage, 10 millions requêtes/mois |
| Resend (emails) | 0€ (gratuit) | Tier gratuit : 100 emails/jour |
| GitHub (code) | 0€ (gratuit) | Repos publics ou privés illimités |
| UptimeRobot (monitoring) | 0€ (gratuit) | 50 monitors, checks toutes les 5 min |
| Total infrastructure | 0€/mois |
Oui, vous lisez bien. L'infrastructure complète tourne gratuitement. Les tiers gratuits de ces services couvrent largement les besoins d'un site institutionnel avec quelques centaines de visiteurs par jour.
En comparaison, un hébergement WordPress mutualisé correct coûte entre 5 et 15€/mois, auxquels s'ajoutent souvent un thème premium (50-100€), des plugins premium (100-300€/an), et potentiellement un CDN ou un service de cache.
Outils IA
| Outil | Coût | Notes |
|---|---|---|
| Claude Pro (Anthropic) | ~20$/mois | Accès à Claude Opus 4.6 via Claude Code |
| Anti-Gravity (Gemini) | Variable | Utilisé uniquement pour le scaffolding initial |
| Total IA | ~20-40$/mois |
Coût total la première année
| Poste | Coût annuel |
|---|---|
| Infrastructure | 0€ |
| Domaine | 12€ |
| Outils IA (pendant le dev, ~1 mois) | 20-40€ |
| Total | 32-52€ |
Contre un WordPress auto-hébergé typique pour un site équivalent :
- Hébergement : 60-180€/an
- Thème premium : 50-100€
- Plugins premium (SEO, cache, sécurité, backup) : 100-300€/an
- Total WordPress : 210-580€/an
La différence est significative, surtout sur la durée. Et les performances sont incomparables.
Ce que j'en retiens
L'IA change fondamentalement le jeu
En 5 jours, un développeur solo assisté par l'IA a produit un site de 83+ pages avec :
- Un CMS complet et personnalisé
- Un score Lighthouse quasi-parfait
- 81 tests E2E automatisés
- Un audit sécurité et accessibilité complet
- Un pipeline de déploiement continu
- Un monitoring automatisé
Il y a 3 ans, ce projet aurait nécessité une équipe de 2-3 développeurs pendant 3-4 semaines. L'IA n'a pas remplacé le développeur — elle a multiplié sa productivité par 5 à 10.
Les bons outils font les bons projets
Le choix de chaque brique de la stack a été déterminant :
- Next.js pour la performance native et le SSG
- Payload CMS pour l'expérience d'édition moderne et l'intégration TypeScript
- Netlify pour le déploiement sans friction
- Claude Code pour la productivité et la qualité du code
- GitHub pour la traçabilité et la collaboration
WordPress n'est pas mort, mais il a de la concurrence
Pour les développeurs qui maîtrisent JavaScript et qui savent utiliser l'IA, la stack Next.js + Payload CMS est une alternative crédible et souvent supérieure pour les sites vitrines premium. WordPress reste le roi pour les blogs, l'e-commerce, et les projets où le client doit être autonome rapidement.
Le vrai skill, c'est le prompting + l'expertise métier
L'IA ne remplace pas l'expertise. Elle l'amplifie. Savoir prompter efficacement, c'est savoir :
- Décrire précisément ce qu'on veut (pas "fais-moi un beau site", mais "crée un composant FAQ avec accordion animé en Framer Motion, utilisant les couleurs brand-blue et brand-green, avec un JSON-LD FAQPage")
- Fournir le contexte (le fichier CLAUDE.md de 100+ lignes qui documente chaque convention du projet)
- Review le code généré (l'IA fait des erreurs — environ 20% des commits sont des FIX)
- Prendre les décisions architecturales (l'IA propose, l'humain dispose)
Mon conseil
Si vous êtes un développeur WordPress curieux, essayez. Prenez un petit projet personnel, lancez Anti-Gravity ou Claude Code, et construisez quelque chose avec Next.js. Vous serez surpris par la vitesse à laquelle vous pouvez produire quelque chose de professionnel.
L'IA a démocratisé l'accès aux stacks modernes. Ce qui prenait des mois d'apprentissage peut maintenant être acquis en quelques jours de collaboration intensive avec un assistant IA.
Ressources
- Site live : polesup-vincentdepaul30.com
- Next.js : nextjs.org
- Payload CMS : payloadcms.com
- Claude Code : claude.ai/claude-code
- Netlify : netlify.com
- Cloudflare R2 : cloudflare.com/r2
- Neon PostgreSQL : neon.tech
- Playwright : playwright.dev
