Combien coûte une application web : authentification, rôles, données, intégrations, tests, déploiement, workers. Symfony, Nuxt, ou les deux. Je refuse les fourchettes « de 3 à 80 k » sans cadrage préalable : elles ne servent personne. Cet article liste ce qui fait bouger le budget, le MVP vs le SI, et le soin à trois ans. Voir aussi la TMA Symfony, le déploiement et Messenger.
🧮 Ce n'est pas une vitrine
Des états (brouillon, payé, livré), des droits, des erreurs métier. Chaque parcours testé coûte. Une app « simple » de 8 parcours n'est pas simple.
Le build sans TMA : dans un an, plus personne ne déploie. Budgétez le soin.
Une petite app métier : un simulateur de devis
Des choix, des règles de prix, un résultat et un contact transmis. Même à cette taille, chaque parcours se conçoit et se teste.
🔌 Intégrations
Chaque API externe (paiement, ERP, SSO) est un projet dans le projet. Les estimer « 0,5 jour » est le plus grand classique. Je les isole dans le devis.
Messenger, cron, exports : du temps, de la TMA. Le worker oublié a un article.
- Écrire les parcours utilisateurs
- Lister les rôles et leurs droits
- Isoler chaque intégration dans le devis
- Chiffrer le déploiement et la maintenance
📈 Le coût après la mise en ligne
Une application vit. Les bibliothèques sortent des versions de sécurité, PHP change de version majeure tous les deux ou trois ans, les API externes modifient leurs formats. Chaque année a donc un coût, même sans nouvelle fonctionnalité.
Je le chiffre dès le devis initial : mises à jour, surveillance, sauvegardes, petites évolutions. Un budget qui s'arrête à la livraison oublie la moitié de la vie du projet.
✅ Parler argent
Après un cadrage d'un à quelques jours, une fourchette serrée est honnête. Avant, seules les familles de coût le sont. Combien coûte une application web : assez pour décider ensemble, pas assez pour un chiffre en l'air dans un mail.
Une application sans parcours écrits n'a pas encore de prix. Elle n'a qu'une estimation au doigt mouillé.
✅ Ce qu'on fixe avant de chiffrer
On décrit qui utilise l'application, pour faire quoi, avec quelles données, et ce qui compte pour la première version. Le reste attend la suivante.
Sauvegarde des données, accès à votre nom, hébergement documenté. Après la livraison, 24 à 72 h de suivi : connexions, erreurs, tâches de fond. Sans ce suivi, le premier incident réel sert de test.
- Besoin écrit en une page
- Environnement de test prévu au budget
- Première version limitée à l'essentiel
- Recette humaine puis 24 h de suivi
📌 Ce que je refuse sur ce sujet
Je refuse de chiffrer une application sans avoir compris le besoin. Je refuse de promettre une date sans périmètre. Je refuse de livrer sans documentation ni accès à votre nom.
Je refuse aussi de me taire : si un outil existant ou un site simple répond à votre besoin, je vous le dis. Cet article n'est pas là pour vendre du sur-mesure à tout prix.
🧭 Questions fréquentes
Faut-il lancer le projet tout de suite ? Pas avant d'avoir écrit le besoin en une page. Une application chiffrée sur une idée floue coûte plus cher à corriger qu'à préparer.
Peut-on développer sans environnement de test ? Non : une application a des données, des utilisateurs et des mises à jour. Cet environnement fait partie du budget, pas d'une option de confort.
Combien de temps ? Quelques semaines pour un premier outil simple, plusieurs mois pour un produit complet. Les estimations en jours sans cahier des charges ne valent pas grand-chose.
