Un devis d'application sur mesure illisible cache souvent un projet mal cadré. Voici la structure qu'on devrait y trouver, poste par poste, pour comparer sérieusement deux propositions et éviter les mauvaises surprises.
Pourquoi la structure du devis compte
Un devis d'application n'est pas un prix : c'est une lecture du projet. Deux prestataires sérieux peuvent livrer la même chose à des budgets différents (méthodes, stack, profil seniorité), mais aucun des deux ne devrait livrer un forfait global sans détail.
Un devis lisible permet trois choses : comparer sérieusement, négocier un périmètre, et éviter les dérapages parce que tout le monde sait ce qui est dans le scope et ce qui n'y est pas.
Les postes attendus dans un devis sérieux
| Poste | Ce qu'il couvre | À quoi être attentif |
|---|---|---|
| Cadrage / atelier | Sessions de définition du périmètre, parcours utilisateur, entités, contraintes. | Doit avoir lieu avant le chiffrage final pour les gros projets. |
| Design UX/UI | Wireframes, maquettes des écrans clés, design system. | Précise le nombre d'écrans, sinon dérapage garanti. |
| Développement front-end | Pages, composants, état, interactions, intégration design. | Précise framework et niveau de réutilisation (composants partagés ou non). |
| Développement back-end | API, base de données, authentification, logique métier. | Précise la stack (Next.js, Node, Postgres, etc.) et les choix d'hébergement. |
| Intégrations externes | Connexions CRM, ERP, paiement, signature, mail transactionnel. | Liste précise des connecteurs : un seul oubli peut décaler le projet. |
| Tests | Tests automatisés (unit, intégration) + recette manuelle. | Distinguer tests dev vs recette client. Tous deux nécessaires. |
| Déploiement / mise en production | Configuration serveur, CI/CD, monitoring, sauvegardes. | À inclure : un projet déployé manuellement à la main vieillit mal. |
| Formation / documentation | Prise en main par les utilisateurs internes, doc technique. | Souvent oublié, indispensable pour les outils métier. |
| Garantie post-livraison | Période de correction de bugs après livraison sans surcoût. | Standard : 1 à 3 mois. Au-delà, on passe sur du contrat maintenance. |
Le récurrent : à séparer du build
Les coûts qui reviennent chaque mois ou chaque année doivent apparaître explicitement, séparés du chiffre du build initial.
- Hébergement : serveur, base de données, CDN, services tiers (Stripe, mail, etc.). Estimable en €/mois.
- Maintenance corrective et préventive : mises à jour de dépendances, correction de bugs résiduels, monitoring. Forfait mensuel ou facturation à l'heure.
- Évolutions fonctionnelles : ajout de features après la mise en ligne. Au temps passé ou par sprints.
- Licences SaaS branchées : si l'app utilise Stripe, Twilio, un service IA, etc., le coût est porté par vous.
Les hypothèses : la zone qui sauve ou qui ruine
Les hypothèses du devis sont aussi importantes que les chiffres. Elles décrivent sur quoi le prestataire s'est basé pour chiffrer. Tout ce qui sort de ces hypothèses devient hors-périmètre.
Hypothèses à exiger dans le devis :
- Volume : nombre d'utilisateurs, de données, de transactions attendues.
- Périmètre fonctionnel précis : liste des écrans / modules inclus, avec mention des exclusions.
- Intégrations exactes : nom des outils tiers, version d'API, scope (lecture seule, écriture, synchro bidirectionnelle).
- Contraintes RGPD / sécurité : type de données traitées, hébergement européen ou non, niveau d'audit attendu.
- Disponibilité client : nombre de jours/semaine du référent côté client. Un projet ralentit toujours quand le client n'est pas disponible pour les validations.
Modalités de paiement standard
Acompte signature
30 à 40 % du build à la signature. Engage les deux parties.
Tranches intermédiaires
1 à 3 tranches sur jalons précis : validation du cadrage, validation du design, fin du développement. Évite le tout en fin de projet.
Solde à la livraison
20 à 30 % à la livraison et validation de recette. Le maintenir intact donne un levier sain pour s'assurer que la livraison est conforme.
Pour les projets sur plusieurs mois, une facturation au temps passé mensuel (équivalent forfait jour) peut remplacer ce modèle. Voir modes de facturation d'une application si publié.
Comment lire deux devis côte à côte
Si vous avez deux devis à comparer, ne regardez pas d'abord le total. Regardez :
- Le périmètre fonctionnel : est-il identique entre les deux ? Si non, le moins cher livre peut-être moitié moins.
- Les hypothèses : qui prend quoi en charge ? Qui fournit le contenu, les comptes, les accès ?
- La stack technique : du sur-mesure dans les deux cas ? Du no-code ? Du SaaS personnalisé ? Le coût de propriété à 3 ans diffère énormément.
- Le récurrent estimé : un build moins cher avec un récurrent 3× supérieur peut coûter plus cher à 2 ans.
- Les profils mobilisés : profil senior plein temps ou junior encadré ? Le delivery sera très différent.
Pour discuter de votre projet et obtenir un devis structuré, prévoyez un premier appel. Sans engagement, on cadre le besoin et je vous envoie une proposition lisible sous quelques jours.
Questions fréquentes
Pourquoi certains devis affichent un prix au forfait global sans détail ?
Soit parce que c'est plus simple à présenter, soit parce que le prestataire préfère ne pas exposer comment il chiffre. Dans les deux cas, ça vous empêche de comparer ou de négocier un périmètre. Un devis transparent détaille les postes même s'ils sont vendus ensemble.
Faut-il signer avant l'atelier de cadrage ou après ?
Tout dépend de la taille. Pour un MVP standard, le devis peut couvrir le cadrage + le build dans un même contrat. Pour un projet plus ambitieux, un contrat de cadrage séparé (quelques jours) est sain : il permet de chiffrer le build avec un vrai recul, sans s'engager sur un budget total avant de comprendre le périmètre. Voir Analyse et cadrage.
Quelle proportion d'acompte est normale à la signature ?
Standard du marché : 30 à 40 % à la signature. Au-delà de 50 %, le prestataire se protège peut-être de mauvaises expériences passées, mais cela vous expose : si le projet déraille, vous avez peu de levier. En dessous de 20 %, c'est rare et souvent réservé à des clients très récurrents.
Le devis doit-il inclure la maintenance et les évolutions ?
Ces postes doivent apparaître mais idéalement dans un contrat séparé, mensualisé. Mélanger build (one-shot) et maintenance (récurrent) dans un même chiffre rend la comparaison impossible. Demander la maintenance détaillée à part est légitime.
Que faire si le devis ne précise pas les hypothèses ?
Le demander explicitement par écrit. Sans hypothèses listées (volume de données, nombre d'utilisateurs, intégrations précises, contraintes RGPD), le devis n'engage à rien : tout dépassement pourra être justifié par « ce n'était pas dans le périmètre ».