Devis d’application mobile : comment éviter les surcoûts dès le cadrage

La plupart des surcoûts d’une application mobile ne viennent pas d’un prestataire malhonnête, mais d’un devis flou : un périmètre décrit en une ligne, des hypothèses techniques implicites, une recette non définie. Chaque zone floue devient une discussion, puis un avenant. Cet article ne parle pas du prix d’une application (voir notre guide budget) mais de la façon de lire et cadrer un devis pour que le prix annoncé soit le prix payé.

Les cinq zones floues qui coûtent cher

1. Les fonctionnalités décrites par un mot

« Messagerie », « paiement », « notifications » : chaque mot recouvre des réalités très différentes. Une messagerie peut aller d’un simple formulaire de contact à un chat temps réel avec pièces jointes. Exigez une description par fonctionnalité : qui fait quoi, sur quel écran, avec quel résultat.

2. Les cas particuliers

Que se passe-t-il si le paiement échoue ? Si l’utilisateur perd le réseau ? S’il supprime son compte ? Ces cas représentent une part importante du développement et sont rarement écrits. Un devis qui ne les mentionne pas les découvrira en cours de route.

3. Les hypothèses techniques

Versions minimales d’iOS et d’Android supportées, appareils de test, services tiers utilisés, hébergement du serveur : ces choix influencent le coût et doivent figurer dans le devis. Sans hypothèses écrites, chaque écart devient un avenant.

4. La recette

Comment décide-t-on qu’une fonctionnalité est terminée ? Sans critères d’acceptation, la recette devient une négociation. Demandez qu’ils soient listés pour chaque fonctionnalité majeure.

5. L’après-lancement

Publication sur les stores, corrections pendant la période de garantie, mises à jour système, hébergement : ce qui est inclus et ce qui ne l’est pas doit être clair avant la signature.

La grille de lecture d’un devis

Un devis plus long n’est pas un devis plus cher : c’est un devis qui a moins de chances de déraper.

Une méthode de cadrage en trois temps

D’abord le parcours principal. Décrivez le chemin que suit un utilisateur pour obtenir ce qu’il vient chercher, écran par écran. Si ce parcours n’est pas clair, aucun chiffrage ne l’est.

Ensuite le tri des fonctionnalités. Classez chaque idée en trois colonnes : indispensable au lancement, utile en deuxième version, à oublier. Ce tri est le levier le plus puissant pour réduire un budget sans dégrader l’application.

Enfin le découpage en lots. Un premier lot livrable et testable rapidement (le parcours principal), puis des lots successifs. Chaque lot a son prix, ses livrables et ses critères de recette. Si le projet doit s’arrêter ou changer de direction, vous avez quelque chose d’utilisable.

Les questions à poser au prestataire

• Quelles hypothèses avez-vous prises que je ne vois pas dans le devis ?
• Quelles fonctionnalités jugez-vous risquées, et pourquoi ?
• Que se passe-t-il si je veux modifier une fonctionnalité en cours de lot ?
• Qui est propriétaire du code, des comptes développeur et des données ?
• Comment se passent la publication et la validation sur les stores ?
• Quel est le coût mensuel de fonctionnement après le lancement (serveur, services tiers) ?

Les réponses comptent autant que le prix. Un prestataire qui identifie les risques dès le devis est un prestataire qui ne vous les fera pas découvrir à la livraison.

Le cas des changements en cours de projet

Changer d’avis en cours de projet est normal : on apprend en voyant l’application prendre forme. Ce qui coûte cher, c’est l’absence de règle. Convenez dès le départ d’un processus simple : toute demande nouvelle est décrite, estimée, puis acceptée ou repoussée au lot suivant. Ainsi, le budget reste sous contrôle sans bloquer les bonnes idées.

En résumé

Un devis d’application mobile fiable décrit les parcours, écrit les hypothèses, découpe en lots et définit la recette. Si votre devis actuel ne coche pas ces cases, demandez à le compléter avant de signer. Notre équipe applications mobiles propose un atelier de cadrage pour transformer une idée en périmètre chiffrable, et le guide officiel React Native aide à comprendre les choix techniques proposés.

FAQ

Comment cadrer les hypothèses techniques dans le devis ?

Listez les systèmes et versions minimales supportés, les appareils de test, les services tiers et l’hébergement. Sans hypothèses écrites, chaque écart découvert en cours de projet devient un avenant.

Faut-il demander plusieurs devis d’application mobile ?

Oui, deux ou trois, mais sur le même cahier des charges : sinon vous comparez des périmètres différents. Exigez le même découpage (fonctionnalités, hypothèses, recette, maintenance) pour lire les écarts de prix.

Un prix forfaitaire protège-t-il des surcoûts ?

Seulement si le périmètre est précis. Un forfait sur un périmètre flou se transforme en avenants. Le forfait protège quand les fonctionnalités, hypothèses et critères de recette sont écrits.