devis application mobile

Trois prestataires consultés, trois devis reçus, et des montants qui vont du simple au triple. C’est le scénario que nous racontent la plupart des porteurs de projet qui nous contactent. Le réflexe naturel consiste à comparer les totaux. C’est une erreur : un devis d’application mobile ne se juge pas à son total, il se juge à ce qu’il détaille. Depuis 2014, nous avons chiffré des dizaines de projets chez Squirrel, et relu presque autant de devis concurrents apportés par nos clients. Voici notre grille de lecture : les postes qui doivent apparaître ligne par ligne, les questions à poser sur chacun, et les signaux qui doivent vous alerter.

Une précision de périmètre avant de commencer. Si vous en êtes encore à préparer votre consultation, nous avons détaillé ailleurs comment obtenir des devis comparables pour votre application. Et si c’est le budget global qui vous préoccupe, consultez les fourchettes de prix d’une application mobile. Ici, nous parlons du document lui-même : ce qu’il contient, et comment le décortiquer.

Que doit contenir un devis d’application mobile ?

Une application, ce n’est jamais « une application ». C’est un ensemble de briques : l’app que l’utilisateur télécharge, l’API qui fait circuler les données, le back office qui permet d’administrer le tout, le design qui rend l’ensemble utilisable, la gestion de projet qui tient les délais et les tests qui garantissent que ça marche. Un devis sérieux fait apparaître chacune de ces briques avec son coût propre. S’il n’en montre qu’une, demandez-vous où sont passées les autres.

Les six postes d’un devis d’application mobile sérieux

Poste Ce qu’il couvre Questions à poser
Gestion de projet Cadrage, ateliers de conception, planification, points réguliers, coordination de l’équipe, comptes rendus. Qui pilote mon projet ? À quelle fréquence a-t-on un point ? Combien de jours sont prévus pour ce poste ?
Design UX/UI Parcours utilisateurs, wireframes, maquettes de tous les écrans, états d’erreur et cas vides, kit graphique. Combien d’écrans sont maquettés ? Les maquettes seront-elles validées avant le développement ? Combien d’allers-retours sont inclus ?
Développement de l’application Le code de l’app elle-même, fonctionnalité par fonctionnalité, sur iOS et Android. Quelle technologie (natif, Flutter, React Native) et pourquoi ? Le chiffrage est-il détaillé par fonctionnalité ?
API et architecture serveur Les échanges de données entre l’app et le serveur, l’authentification, la sécurité, l’hébergement. L’API est-elle chiffrée à part ? Qui souscrit et paie l’hébergement ? Que se passe-t-il si le nombre d’utilisateurs décolle ?
Back office L’interface d’administration : gestion des contenus, des utilisateurs, des commandes, statistiques. Que pourrai-je gérer moi-même sans repasser par l’agence ? Le back office est-il sur mesure ou basé sur un outil existant ?
Tests et recette Plans de test, correction des anomalies, stabilisation, accompagnement de la publication sur les stores. Les tests ont-ils une ligne dédiée dans le devis ? Sur quels appareils l’app est-elle testée ? Que couvre la garantie après la mise en ligne ?

Ce découpage n’est pas une coquetterie d’agence. Il vous sert directement : c’est lui qui vous permet de négocier intelligemment (réduire le périmètre du back office plutôt que raboter les tests), de phaser le projet, et de comparer deux offres poste par poste au lieu de comparer deux totaux opaques.

Nos ordres de grandeur internes, pour situer les proportions

Chaque agence a ses ratios. Voici les nôtres, issus de nos chiffrages réels depuis plus de dix ans, non pas comme des vérités universelles mais comme des points de repère pour lire un devis.

Comment nous chiffrons chez Squirrel : l’API représente souvent autour de 20 % du temps de développement. La gestion de projet pèse environ 15 % du budget global. Et les tests sont systématiquement chiffrés, sur une ligne dédiée. Si l’un de ces trois postes est absent du devis que vous avez sous les yeux, le travail sera fait quand même : soit il est caché dans une autre ligne (et vous ne pouvez plus rien comparer), soit il n’a pas été prévu (et vous le paierez en avenant ou en bugs).

Un devis dont la gestion de projet représente 2 % du total ne décrit pas une équipe plus efficace. Il décrit un projet que personne ne pilotera. Même logique pour des tests à zéro : personne ne livre une application sans la tester, donc ce temps existe, quelque part, facturé sous un autre nom ou improvisé en fin de projet.

Comment comparer plusieurs devis d’application mobile

Comparer à périmètre égal, sinon rien

La condition numéro un d’une comparaison honnête : tous les prestataires doivent avoir reçu les mêmes informations. Un cahier des charges détaillé, ou mieux, des maquettes qui montrent les écrans et l’arborescence attendus. Sans ce socle commun, chaque prestataire chiffre sa propre interprétation de votre idée, et les écarts de prix reflètent des écarts de compréhension, pas des écarts de compétitivité.

Si ce travail de formalisation vous semble lourd, notre modèle de cahier des charges pour créer une application est téléchargeable gratuitement : il pose les questions auxquelles répondre pour cadrer votre besoin avant d’envoyer quoi que ce soit.

Ensuite, ramenez chaque devis à la même grille : combien de jours par poste, quel taux journalier, quelles fonctionnalités incluses, quelles exclusions. Deux devis à 40 000 et 65 000 euros peuvent cacher le même coût réel une fois que vous ajoutez au premier le back office « en option », les tests « offerts » (donc invisibles) et la publication sur les stores facturée à part.

Forfait ou agile : deux façons de chiffrer, deux lectures différentes

Quand le besoin est bien défini, maquettes et spécifications à l’appui, le chiffrage au forfait est le plus confortable : un prix global, un périmètre contractuel, une prévisibilité budgétaire. C’est la formule que nous recommandons pour la majorité des premières versions.

Quand le projet comporte une vraie part d’inconnu (un concept à affiner, des hypothèses à tester en cours de route), l’approche agile est plus honnête. Le devis annonce alors un budget de référence qui pourra bouger. Dans notre pratique, nous prévenons nos clients qu’un chiffrage agile peut fluctuer d’environ 30 % autour du montant de base, dans un sens comme dans l’autre. Un prestataire qui vous vend de l’agilité avec un prix ferme au centime près entretient une confusion : on ne peut pas promettre à la fois un périmètre mouvant et un budget figé.

Freelance ou agence : des devis qui ne mesurent pas la même chose

Vous recevrez peut-être des devis de freelances et des devis d’agences pour le même projet. Ne les mettez pas dans la même colonne. Sur les consultations que nous voyons passer, l’écart va couramment du simple au triple, parfois davantage. Ce n’est pas que l’un est honnête et l’autre non : un freelance vend le temps d’une personne, une agence vend une équipe (chef de projet, designer, développeurs iOS, Android et back-end, testeur) et la continuité de service qui va avec.

La bonne question n’est pas « lequel est le moins cher » mais « de quoi mon projet a-t-il besoin ». Pour une première version minimaliste destinée à tester un concept, un freelance peut suffire. Pour une application complexe, avec API, back office et enjeux de fiabilité, l’équipe complète se justifie. Notre méthodologie de travail détaille ce que recouvre concrètement l’accompagnement d’une agence, de l’atelier de cadrage à la mise en ligne.

Les signaux d’alarme dans un devis d’application

Certains devis se disqualifient tout seuls, à condition de savoir quoi regarder. Trois cas reviennent sans arrêt.

Le devis en une ligne. « Développement application mobile : 25 000 € ». Nous sommes catégoriques là-dessus : c’est un signal d’alarme, pas un gain de simplicité. Un total sans découpage signifie que le prestataire n’a pas analysé votre besoin, ou qu’il ne veut pas que vous puissiez discuter le détail. Dans les deux cas, vous signez un chèque sur une promesse floue.

Le devis établi sans maquettes ni spécifications. Un chiffrage produit en 24 heures sur la base d’un appel téléphonique n’engage à rien, quel que soit le sérieux apparent du document. Le prestataire pourra toujours soutenir, de bonne foi ou non, que telle fonctionnalité « n’était pas prévue ». Les avenants feront le reste. Un devis ne vaut que par la précision de ce qu’il décrit.

Le devis anormalement bas. Quand une offre est 50 % moins chère que toutes les autres à périmètre identique, il y a une explication, et elle est rarement bonne : postes escamotés (tests, gestion de projet, back office), sous-traitance non annoncée, ou stratégie du pied dans la porte avec rattrapage par avenants. Le devis le moins cher au moment de la signature est régulièrement le plus cher au moment de la mise en ligne.

Notre position, sans détour : un devis d’application mobile qui tient en une ligne, ou qui a été rédigé sans maquettes ni cahier des charges, ne vous protège de rien. Il protège celui qui l’a émis. Exigez le détail par poste avant de comparer quoi que ce soit.

Ce qu’il faut retenir avant de signer

Un bon devis d’application mobile raconte votre projet : on y retrouve vos fonctionnalités, vos écrans, votre back office, et le temps que chaque brique demande. Il se compare poste par poste avec les offres concurrentes, à condition que tout le monde ait chiffré le même périmètre. Et il assume ses zones d’incertitude au lieu de les masquer derrière un prix rond.

C’est exactement ce que nous produisons pour nos clients depuis 2014 : des chiffrages détaillés par poste, construits sur un référentiel issu de nos projets livrés, avec les hypothèses écrites noir sur blanc. Parce qu’un client qui comprend son devis est un client avec qui le projet démarre bien.

Envie de situer votre projet avant de consulter ? Notre simulateur gratuit vous donne une estimation budgétaire en quelques minutes, fonctionnalité par fonctionnalité.

Estimer mon application

FAQ : lire et comparer un devis d’application mobile

Que doit contenir un devis d’application mobile ?

Au minimum six postes chiffrés séparément : gestion de projet, design UX/UI, développement de l’application, API et serveur, back office, tests et recette. Chaque poste doit indiquer le nombre de jours prévus et ce qui est inclus. Les exclusions et les hypothèses doivent être écrites, pas sous-entendues.

Pourquoi deux devis pour le même projet vont-ils du simple au triple ?

Parce que les prestataires n’ont pas chiffré la même chose : périmètre interprété différemment, postes omis chez l’un et détaillés chez l’autre, profils d’équipe distincts (freelance seul ou équipe complète). Pour comparer, envoyez à tous le même cahier des charges ou les mêmes maquettes, puis ramenez chaque offre à la même grille de postes.

Un devis d’application mobile engage-t-il vraiment le prestataire ?

Un devis au forfait engage sur le périmètre qu’il décrit. Toute la nuance est là : si le périmètre est flou, l’engagement l’est aussi. Un devis rédigé sans maquettes ni spécifications laisse la porte ouverte aux avenants. En mode agile, le devis vaut budget de référence, avec une variation possible que nous estimons, dans notre pratique, à environ 30 % autour du montant annoncé.

Comments are closed.