Vous avez reçu un devis d'application sur mesure (le vôtre ou comparatif entre prestataires) et vous voulez savoir si c'est sérieux. Voici la check-list complète : ce qui doit y figurer, ce qui doit alerter, et les questions à poser avant de signer.
Les postes à exiger dans le devis
Un devis d'application sur mesure sérieux doit lister explicitement, même s'ils sont vendus en bloc :
| Poste | Pourquoi il doit apparaître |
|---|---|
| Cadrage / atelier | Définit le périmètre, indispensable sur les projets ambitieux. |
| Design UX/UI | Maquettes des écrans clés, design system, charte. |
| Développement front-end | Pages, composants, état, interactions, intégration design. |
| Développement back-end | API, base de données, authentification, logique métier. |
| Intégrations externes | CRM, ERP, paiement, signature, mail — chacune chiffrée. |
| Tests | Tests automatisés + recette manuelle distinguée. |
| Déploiement / mise en production | Configuration serveur, CI/CD, monitoring, sauvegardes. |
| Formation / documentation | Prise en main utilisateurs internes, doc technique. |
| Garantie post-livraison | 1 à 3 mois standard, au-delà c'est de la maintenance contractuelle. |
Les hypothèses : la zone critique
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 en sort devient hors-périmètre.
- Volume : utilisateurs simultanés, données stockées, transactions/mois.
- Périmètre fonctionnel précis : liste des écrans / modules inclus, avec mention claire 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, niveau d'audit attendu.
- Disponibilité client : nombre de jours/semaine du référent côté client pour valider et débloquer.
Le récurrent : à séparer du build
Doit apparaître explicitement, même chiffré approximativement :
- Hébergement : serveur, base de données, CDN, services tiers.
- Maintenance corrective et préventive : mensualisé ou au temps passé.
- Évolutions fonctionnelles : au temps passé ou par sprints.
- Licences SaaS branchées : Stripe, Twilio, IA, APIs externes.
Modalités de paiement à valider
Acompte signature
30 à 40 % du build à la signature. Standard.
Tranches intermédiaires
1 à 3 tranches sur jalons précis : validation cadrage, validation design, fin du développement.
Solde livraison
20 à 30 % à la livraison et validation de recette. À garder intact pour maintenir un levier sain.
Les red flags à repérer
- Forfait global sans détail ou refus de détailler.
- Aucune hypothèse listée : tout dépassement deviendra hors-périmètre.
- Acompte demandé supérieur à 50 % à la signature.
- Récurrent absent ou non chiffré.
- Propriété du code non précisée ou ambiguë.
- Aucune garantie post-livraison mentionnée.
- Stack exotique ou propriétaire qui vous enferme chez ce prestataire.
- Délai annoncé suspect (« 2 semaines » pour un projet complexe = irréaliste).
- Prix significativement plus bas que la concurrence sans explication claire.
Pour faire vérifier un devis ou obtenir un second avis, prévoyez un premier appel. Voir aussi structure d'un devis d'application et Applications & SaaS.
Questions fréquentes
Que faire si le devis est un forfait global sans détail ?
Le demander détaillé par écrit. Un forfait global de 25 000 € sans détail des postes est impossible à comparer, négocier ou contrôler. Si le prestataire refuse de détailler, c'est un signal d'alerte sérieux : soit il ne sait pas comment il chiffre, soit il ne veut pas qu'on le voie.
Comment vérifier que les hypothèses sont complètes ?
Cinq zones à vérifier : volume (nombre d'utilisateurs, données), périmètre fonctionnel précis (liste des écrans/modules), intégrations exactes (nom des outils tiers, scope), RGPD/sécurité (type de données, hébergement), disponibilité client (référent, validation). Toute zone non couverte = potentiel hors-périmètre futur.
Quels acomptes sont normaux à la signature ?
Standard : 30 à 40 % à la signature. Au-delà de 50 %, le prestataire se protège peut-être trop, vous vous exposez : si le projet déraille, vous avez peu de levier. En dessous de 20 %, c'est rare et souvent réservé aux clients récurrents.
Le devis doit-il préciser qui sera propriétaire du code ?
Oui, c'est même essentiel. Par défaut en droit belge, le développeur prestataire est titulaire des droits sur le code, sauf clause de cession explicite. Le devis ou le contrat doit clairement stipuler que vous serez propriétaire du code livré, avec accès au repository (GitHub, GitLab).
Comment comparer deux devis côte à côte ?
Ne pas comparer d'abord le total. Vérifier : (1) périmètre fonctionnel identique ? (2) hypothèses similaires ? (3) stack technique (sur mesure vs no-code change tout) ? (4) récurrent estimé ? (5) profils mobilisés ? Le moins cher peut livrer moitié moins, ou avec un coût de propriété 3× supérieur à 2 ans.