Site web vs application web : la différence qui change tout
La confusion est fréquente. Un site web présente du contenu — il répond à "qu'est-ce que vous faites ?". Une application web traite des données, gère des flux de travail et répond à "comment faites-vous votre travail ?". La distinction technique : une app web nécessite une authentification, un modèle de données, des règles métier et des droits d'accès.
Site web
- Contenu consultatif
- Pas d'authentification (ou simple)
- Pas de traitement de données métier
- Outil : Webflow, WordPress, Framer
- Budget : 2–30 k€
Application web ← vous êtes ici
- Données, flux, workflow
- Authentification, rôles, droits
- Logique métier complexe
- Outil : Next.js, Supabase, sur mesure
- Budget : 15–200 k€
5 signaux qui imposent une application web sur mesure
- Plusieurs types d'utilisateurs avec des droits différents — Admin, manager, opérateur, client externe : dès que les utilisateurs n'ont pas le même accès aux mêmes données, vous avez besoin d'une vraie gestion de rôles. Aucun CMS ne fait ça correctement.
- Des données métier propriétaires à structurer — Catalogue produit avec variantes complexes, suivi de chantiers, gestion de stocks multi-entrepôts, historique de devis : si vos données ont une structure que les SaaS génériques ne peuvent pas modéliser, c'est le moment du sur mesure.
- Des workflows d'approbation ou d'automatisation — "Quand une commande dépasse 5 000 €, envoyer un email au directeur et bloquer jusqu'à validation" : ce type de règle métier nécessite du code, pas une config de SaaS.
- Des intégrations API avec vos outils existants — Connecter votre ERP, votre comptabilité, votre CRM, vos plateformes logistiques dans une interface unifiée : le no-code atteint ses limites très vite sur les intégrations bidirectionnelles avec gestion d'erreurs.
- Une interface qui doit refléter votre marque et votre UX — Vos clients ou vos équipes passent des heures dans cet outil chaque jour. Une interface générique mal adaptée à vos process fait perdre 20–40 minutes par utilisateur et par jour. Sur 50 utilisateurs, ça représente un ETP à l'année.
Comparatif : No-code vs développement sur mesure
| Critère | No-code (Bubble, Glide) | Développement sur mesure |
|---|---|---|
| Délai MVP | 2–4 semaines | 6–10 semaines |
| Budget initial | 2–15 k€ | 15–200 k€ |
| Performance | ⚠ Limitée (Bubble lent à > 1000 records) | ✅ Optimisé (< 200 ms server-side) |
| Logique métier complexe | ⚠ Contournements fragiles | ✅ Illimitée |
| Intégrations API avancées | ⚠ REST simple, pas de WebSocket | ✅ Toutes intégrations possibles |
| Propriété du code | ❌ Dépendance éditeur | ✅ 100 % propriétaire |
| Scalabilité (> 10 000 users) | ❌ Coûts prohibitifs | ✅ Architecture distribuée |
| Idéal pour | Validation d'idée, prototype, < 500 users | Production, process métier, scalabilité |
Les 4 types d'applications web sur mesure et leurs budgets
🗂️
Backoffice métier
20–50 k€
Interface de gestion interne : CRUD avancé, tableaux de bord, exports, gestion d'utilisateurs, workflow d'approbation. Délai : 8–14 semaines.
🏢
Portail client / extranet
25–60 k€
Espace client sécurisé : suivi commandes/projets, documents, messagerie, facturation. Intégration CRM ou ERP. Délai : 10–18 semaines.
📊
SaaS B2B
40–100 k€
Multi-tenant, abonnements Stripe, onboarding autonome, analytics par compte. Architecture isolée par tenant. Délai : 3–6 mois.
🔄
Marketplace / plateforme
80–200 k€
Double-side market, paiements (Stripe Connect), système de réputation, recherche avancée, modération de contenu. Délai : 6–12 mois.
La stack recommandée en 2026
Il n'existe pas une seule bonne réponse, mais une stack qui couvre 90 % des besoins B2B avec un excellent rapport productivité/performance :
FRONTEND
Next.js 15 + React 19
Server Components, App Router, Turbopack. Rendu hybride SSR/CSR selon les pages. TypeScript strict.
STYLE
Tailwind CSS 4
Design tokens, responsive automatique. Composants shadcn/ui pour aller vite sur les éléments standards.
BASE DE DONNÉES
Supabase (PostgreSQL)
Self-hosted ou cloud, RLS (Row Level Security) pour les droits d'accès, Realtime subscriptions, Storage.
AUTH
Supabase Auth
Email/MDP, OAuth (Google, Microsoft), Magic Link, MFA. Gestion des sessions côté serveur.
DÉPLOIEMENT
Vercel ou VPS dédié
Edge Functions, CDN mondial, preview deployments sur chaque PR. VPS pour les contraintes de souveraineté.
MONITORING
Sentry + Pino logs
Error tracking temps réel, alerte sur p95 > 1,5 s, structured logging avec request_id pour le debug.
Les 6 étapes d'un projet réussi
- Cadrage fonctionnel (1–2 semaines) — Identifier les 3–5 parcours utilisateurs critiques, les données manipulées, les règles métier et les intégrations. Un bon cadrage évite 80 % des dépassements de budget.
- Architecture et modèle de données (1 semaine) — Concevoir le schéma PostgreSQL, définir les règles RLS, choisir les patterns (server actions vs API routes, optimistic updates, caching strategy).
- Design UI/UX sous Figma (1–3 semaines) — Wireframes → maquettes haute-fidélité → design system. Ne pas coder avant d'avoir validé les parcours avec de vrais utilisateurs. Le bug le plus coûteux est celui qu'on découvre après avoir codé.
- Développement en sprints de 2 semaines — Commencer par l'authentification et les permissions (ce qui coûte le plus cher à refaire), puis les parcours critiques, puis les fonctionnalités secondaires. Démo à la fin de chaque sprint.
- Tests et sécurité (1–2 semaines) — Tests unitaires (Vitest), tests end-to-end (Playwright), audit OWASP (injection SQL, XSS, IDOR, CSRF), tests de charge (k6), revue des droits d'accès.
- Mise en production et suivi (continu) — CI/CD automatisé, monitoring actif, SLA de correction bug critique < 4h, plan de maintenance mensuelle (mises à jour de sécurité, optimisations).
Les 5 erreurs qui font exploser les projets
- Spec floue au départ — "On verra au fur et à mesure" est la phrase la plus coûteuse en développement. Chaque itération sur un écran déjà codé coûte 3 à 5 fois plus cher qu'une itération sur une maquette Figma. Budget le cadrage correctement : il vaut 10 % du budget total.
- Vouloir tout dans le MVP — L'erreur classique : ajouter des fonctionnalités jusqu'à ce que le MVP ressemble à la version 3.0. Règle : le MVP contient exactement les fonctionnalités qui permettent au premier utilisateur réel de faire son travail. Pas plus.
- Ne pas penser aux droits d'accès dès le début — Rétrofitter un système de rôles sur une app déjà construite coûte 20–40 % du budget initial. Les règles RLS et la logique de permissions doivent être conçues au même moment que le modèle de données.
- Choisir la stack la plus tendance plutôt que la plus appropriée — Le dernier framework en vogue n'est pas nécessairement le bon choix pour une app de gestion B2B. Stabilité, écosystème, disponibilité des développeurs et facilité de maintenance comptent plus que les étoiles GitHub.
- Pas de tests automatisés — "On testera à la main" fonctionne pour le v1. Dès que l'app a 3 mois et 20 fonctionnalités, chaque modification peut casser quelque chose ailleurs. Les tests Playwright sur les parcours critiques prennent 10 % du budget mais économisent 30 % en maintenance.
Coûts de maintenance sur 3 ans
Le budget de développement n'est que le début. Prévoir en plus :
| Poste | Backoffice (20–50 k€) | SaaS B2B (40–100 k€) | Marketplace (80–200 k€) |
|---|---|---|---|
| Hébergement / infrastructure | 600–1 800 €/an | 1 200–6 000 €/an | 3 600–18 000 €/an |
| Maintenance technique | 2–5 k€/an | 5–15 k€/an | 10–30 k€/an |
| Évolutions fonctionnelles | 5–15 k€/an | 15–40 k€/an | 30–80 k€/an |
| Total TCO 3 ans | 40–90 k€ | 100–250 k€ | 200–560 k€ |
Un projet d'application web sur mesure ?
On cadre gratuitement votre besoin en 30 minutes : stack recommandée, estimation budgétaire, délai réaliste. Sans engagement.
Discuter du projet →