Quand la vitesse du site, c'est de l'argent

Chaque seconde de chargement réduit le CTR et augmente le CPC. Une landing page Next.js rapide, c'est un coût par lead plus bas, un meilleur Quality Score, une meilleure position publicitaire pour le même budget.

Seuil de rentabilité : budget publicitaire de 1 500+ CHF/mois. En dessous — la différence de résultats est trop faible pour justifier le surcoût de Next.js par rapport à WordPress.

WordPress fonctionne bien jusqu'à un certain seuil de trafic. Au-delà de 10 000 visites mensuelles (ou de pics de 1 000+ visiteurs simultanés), l'architecture devient déterminante : Next.js avec ISR (Incremental Static Regeneration) absorbe ce trafic sans limite serveur.

Pour référence : un site d'entreprise de 30 sous-pages avec 20 000 visites/mois en Next.js fonctionne sur un VPS à 40 CHF/mois. En WordPress, cela nécessiterait un hébergement dédié à 150-250 CHF/mois.

Next.js gère nativement les API Routes, les webhooks, le streaming, les Server Actions. Intégrations avec HubSpot/Salesforce/Pipedrive, synchronisation avec un entrepôt de données, endpoints sur mesure pour une application mobile — sans se battre avec des extensions WordPress.

Cas concret : une plateforme B2B avec des intégrations vers 5 systèmes externes. En WordPress = 12 extensions + code sur mesure. En Next.js = un monorepo, un contrôle total sur le flux de données, testable.

Next.js permet de développer le site de façon modulaire : vous ajoutez un blog, un espace client, une application mobile, un tableau de bord — sans réécrire le code existant. TypeScript + tests automatisés signifient que les changements dans 2 ans ne cassent pas les fonctions déployées aujourd'hui.

À l'inverse, WordPress accumule typiquement de la dette technique après 2-3 ans (extensions obsolètes, PHP ancien, extensions incompatibles entre elles). Le coût de maintenance augmente, l'évolution nécessite une refonte.

Déploiement Next.js typique : tout en SSR ou tout en SSG, sans réflexion. Nous choisissons la stratégie par route :

• SSG (Static Site Generation) pour les pages produit, blog, documents juridiques — charge serveur nulle, mise en cache CDN
• ISR (Incremental Static Regeneration) pour les contenus issus du CMS — vitesse du SSG + actualité des changements CMS
• SSR (Server-Side Rendering) pour les pages spécifiques à l'utilisateur (tableau de bord, panier) — uniquement là où c'est vraiment nécessaire

> Résultat : la plupart des pages se chargent depuis le CDN en 200-400 ms (TTFB), pas depuis un serveur Node.js en 800-1500 ms. Différence visible dans le score Lighthouse et les métriques réelles de Core Web Vitals.

La plupart des projets Next.js que nous avons vus lors de migrations : TypeScript en mode « laxiste » (plein de any), zéro test automatisé, @ts-ignore au-dessus de chaque problème. Résultat : chaque changement dans six mois est une loterie.

Nos choix par défaut :

• Mode strict TypeScript (noImplicitAny, strictNullChecks, noUnusedLocals)
• Validation Zod aux frontières (formulaires, API, données externes)
• Tests E2E Playwright pour les parcours critiques (connexion, paiement, envoi de formulaire)
• Tests unitaires Vitest pour la logique métier
• ESLint + Prettier en CI/CD (merge bloqué si ça ne passe pas)

> Conséquence : le code dans 2 ans peut être développé, pas refactorisé. TypeScript détecte le problème à la compilation, pas en production à 3h du matin.

Déploiement typique : mise en production, puis l'agence « disparaît ». L'erreur en production est signalée par le client par téléphone — généralement avec du retard, après avoir déjà perdu des conversions.

Nos projets avec monitoring :

• Sentry — suivi des erreurs avec trace complète, breadcrumbs, session utilisateur
• Uptime Robot — surveillance de disponibilité toutes les 5 min, alertes SMS/email
• PostHog — analytics + relecture de session (nous voyons exactement ce que l'utilisateur faisait avant l'erreur)
• Lighthouse CI — bloque le déploiement si la performance descend sous le seuil

> Résultat : c'est nous qui vous signalons l'erreur en production, pas l'inverse. La relecture de session montre exactement ce qui s'est passé. Correctif déployé généralement en 2-4h après l'incident.