Projet web sur mesure : ce qui change par rapport à un CMS standard

“Pourquoi payer pour du sur-mesure alors qu’on peut utiliser WordPress ?” C’est la question qu’on pose souvent, et elle est légitime. La réponse honnête : dans beaucoup de cas, un CMS standard suffit amplement. Mais il y a des situations où le sur-mesure est la seule option viable, et d’autres où c’est un investissement qui se rentabilise rapidement.

Ce que couvre “web sur mesure”

Le terme recouvre des réalités très différentes :

• Site vitrine custom : design unique, animations, performances, intégration CMS Headless pour l’éditorial
• Application web métier : outil interne, extranet client, plateforme SaaS — avec authentification, données, workflows
• API et backend : logique applicative, intégrations SI, microservices exposés à un frontend existant
• E-commerce personnalisé : catalogue spécifique, prix dynamiques, workflow de commande non standard

Ce ne sont pas les mêmes projets, les mêmes durées, ni les mêmes compétences.

CMS standard ou développement custom : le bon critère

La bonne question n’est pas “combien ça coûte ?” mais “quels sont les besoins que le standard ne peut pas couvrir ?”

Rester sur un CMS standard (WordPress, Drupal, Webflow) si :

• Le site est principalement éditorial (articles, pages, blog)
• Les fonctionnalités nécessaires sont disponibles via des plugins matures
• L’équipe n’a pas de développeurs et doit gérer le contenu en autonomie
• Le budget ne dépasse pas 5 000-15 000€

Passer au sur-mesure si :

• Le processus métier est trop spécifique pour les plugins disponibles
• Les performances sont critiques (les CMS génériques sont lents par défaut)
• L’intégration avec un SI existant (ERP, CRM, PIM) est profonde
• Le volume de trafic ou de données dépasse les capacités d’un hébergement standard
• La sécurité est un sujet non-négociable (secteur bancaire, santé, défense)

Architecture typique d’un projet web sur mesure

Option 1 — Jamstack / Headless

Astro / Next.js / Nuxt (Frontend)
         ↑
         │ GraphQL ou REST
         ↓
Strapi / Contentful / Sanity (CMS Headless)
         +
Spring Boot / Node.js (Backend métier)
         +
PostgreSQL / MongoDB (Données)
         ↓
CDN (Cloudflare / Vercel) + Hosting

Avantages :

• Performances exceptionnelles (pages statiques servies depuis le CDN)
• Sécurité renforcée (pas de surface d’attaque côté serveur pour le front)
• Scalabilité gratuite sur CDN (trafic pic sans surcoût)

Idéal pour : sites marketing, blogs à fort trafic, vitrines avec contenu éditorial

Option 2 — SPA + API

React / Angular / Vue (Frontend SPA)
         ↑
         │ REST API / GraphQL
         ↓
Spring Boot / Node.js / Django (Backend)
         ↓
PostgreSQL + Redis (cache) + S3 (fichiers)
         ↓
Docker + Kubernetes / VM

Avantages :

• Séparation claire frontend/backend (équipes peuvent travailler en parallèle)
• L’API peut être consommée par d’autres clients (mobile, partenaires)
• Flexibilité sur les technologies de chaque couche

Idéal pour : applications métier, SaaS, extranets, dashboards

Option 3 — Rendu côté serveur (SSR)

Next.js / Nuxt / Spring MVC + Thymeleaf
         ↑
         │ Données en base ou APIs
         ↓
Base de données + Cache

Avantages :

• SEO optimal (le HTML est pré-rendu)
• Premier rendu rapide (pas de JS à exécuter avant d’afficher)
• Meilleur pour les apps avec beaucoup de pages indexables

Idéal pour : e-commerce, fiches produit, sites avec fort besoin SEO

Ce qui prend vraiment du temps

La partie “développer des fonctionnalités” représente 40-50% du temps total. Le reste :

Phase de cadrage et design (20-25%)

• Recueil des besoins, maquettes wireframe
• Choix d’architecture
• Spécifications fonctionnelles et techniques

Bâcler cette phase est la première cause de dérive sur les projets sur-mesure.

Infrastructure et DevOps (10-15%)

• Configuration des environnements (dev, staging, prod)
• Pipeline CI/CD (build, test, déploiement automatique)
• Monitoring, alertes, sauvegardes

Un projet sans pipeline CI/CD en 2025 est un risque opérationnel. Chaque déploiement manuel est un point de défaillance.

Tests et recette (15-20%)

• Tests unitaires et d’intégration
• Tests fonctionnels avec les utilisateurs finaux
• Corrections de bugs de recette

C’est la phase systématiquement sous-estimée dans les estimations initiales.

Documentation et formation (5-10%)

• Documentation technique pour la maintenance
• Guide utilisateur si l’équipe gère le contenu
• Formation de l’équipe sur les outils

Estimation de coûts réalistes

À titre indicatif, les fourchettes que je constate sur le marché freelance senior :

Projet	Durée estimée	Fourchette
Site vitrine sur-mesure (Astro + design custom)	15-25 jours	7 500 – 12 500 €
Site avec CMS Headless (Astro + Strapi)	20-30 jours	10 000 – 15 000 €
Application web simple (CRUD + Auth + API)	25-40 jours	12 500 – 20 000 €
E-commerce custom (sans Shopify)	40-60 jours	20 000 – 30 000 €
Application métier complexe	60-120 jours	30 000 – 60 000 €

Ces fourchettes excluent : hébergement, licences logicielles, contenu (textes, photos), traductions.

Ce qu’on évite en investissant dans le sur-mesure

Les dépendances aux plugins tiers Avec WordPress + WooCommerce + 30 plugins, la mise à jour d’un plugin peut casser l’ensemble du site. Un projet sur-mesure maîtrise ses dépendances.

Les limites arbitraires du CMS “Je veux que la fiche produit affiche le stock en temps réel depuis notre ERP” — non faisable avec un plugin WooCommerce standard. Sur-mesure : 3 jours de développement.

Les performances dégradées Un site WordPress avec 30 plugins et un thème premium fait souvent 5-8 secondes de chargement. Un site Astro statique charge en 0.8 secondes sur mobile — même réseau, même serveur.

Les coûts cachés du “gratuit” WooCommerce est gratuit, mais les extensions dont vous avez besoin ne le sont pas : Stripe (0€ + %) + WPML (99€/an) + Advanced Custom Fields (100€/an) + Yoast (89€/an)… Plus la maintenance, les mises à jour de sécurité, et les développeurs qui facturent 600€/jour pour modifier un site WordPress parce que c’est devenu un château de cartes.

Le bon moment pour changer d’approche

Vous êtes probablement au bon moment pour envisager du sur-mesure si :

• Votre site actuel sur CMS vous empêche de faire quelque chose d’important pour votre activité
• Vos développeurs passent plus de temps à contourner le CMS qu’à développer de la valeur
• Les performances sont un problème mesurable (bounce rate élevé, Google Search Console en rouge)
• Vous avez un nouveau besoin métier qui ne s’intègre pas dans l’existant

---

Si vous avez un projet en tête ou une situation où votre outil actuel est devenu un frein, décrivez votre contexte — je vous donne mon analyse en 24h.