Lire un devis d'application mobile : 5 clauses qui coûtent cher

Réponse courte

Un devis d'application mobile honnête contient cinq clauses précises : périmètre exhaustif des fonctionnalités avec ce qui est explicitement exclu, propriété du code source dès le premier commit, gestion des changements par avenant chiffré, tests et recette avec critères d'acceptation écrits, publication stores sur les comptes développeurs du client. Sans ces clauses, le devis final dépasse régulièrement le budget initial de 20 à 50 pourcent. Les surprises se situent entre 15 et 35 k€ HT additionnels sur un devis initial de 28 k€.

Un devis flou vend du flou

Beaucoup de fondateurs lisent un devis mobile comme un contrat de plombier. Ils regardent le total en bas et la durée globale, puis signent. Sauf qu'un devis mobile à 28 k€ tient sur trois pages ou sur quinze pages selon le prestataire, et la différence vaut souvent dix mille euros de surprises.

Un devis clair aide les deux parties. Le prestataire ne peut pas te vendre dix fonctionnalités en douce, et toi tu ne peux pas exiger cinq fonctionnalités imprévues sans discussion contractuelle. L'ambiguïté arrange tout le monde jusqu'au jour où elle ne t'arrange plus.

Les cinq clauses détaillées ci-dessous couvrent 90 pourcent des avenants surprise que je vois passer en seconde opinion de devis. Chacune représente plusieurs milliers d'euros de risque si elle manque.

Clause 1 : périmètre exhaustif avec exclusions explicites

Ce que tu dois trouver :

• Liste numérotée des fonctionnalités, au moins quinze à vingt-cinq lignes pour un MVP sérieux
• Chaque fonctionnalité chiffrée en jours ou en pourcentage du forfait
• Une section intitulée « explicitement exclu du périmètre », souvent oubliée. C'est là que se joue l'essentiel.
• Les intégrations tierces nommées explicitement, avec version API quand c'est pertinent (Stripe Checkout vs Stripe Connect, Firebase Auth vs Supabase Auth, Mangopay, SendGrid, etc.)

Signaux d'alarme :

• Mentions floues du type « fonctionnalités standards d'une app mobile »
• Formulations génériques « notifications push, chat, paiement, etc. »
• « Le reste sera précisé au démarrage du projet »
• Fonctionnalités listées sans jours associés

Pourquoi cette clause compte. Sur un périmètre flou, chaque discussion devient une négociation. Un fondateur demande « est-ce qu'on peut ajouter la connexion Apple ? », le prestataire répond « ce n'est pas prévu, c'est un avenant ». Sur un périmètre explicite listé avec ses exclusions, la même discussion devient « est-ce que la connexion Apple est dans la ligne 7 ? Non, elle est dans la liste des exclusions, donc avenant ». La règle est connue avant.

Coût moyen de la surprise si cette clause est absente : 5 à 10 k€ HT sur un projet de 3 à 4 mois, répartis sur 3 à 8 avenants moyens.

Clause 2 : propriété du code et transfert des accès

Ce que tu dois trouver :

• « Le code source appartient au client dès le premier commit »
• « Le repository Git est hébergé sur un compte du client (GitHub, GitLab, Bitbucket) et le studio y accède en tant que collaborateur »
• « Les accès aux services tiers (Supabase, Stripe, Sentry, EAS Build…) sont créés sur les comptes du client dès le premier jour »
• « Le compte développeur Apple (99 $/an) et le compte Google Play (25 $) sont au nom du client, pas du studio »

Signaux d'alarme :

• « Le code source est propriété de l'agence, licencié au client pendant la durée du contrat ». Piège complet, le client ne peut pas changer de prestataire sans tout racheter.
• « Le code sera fourni à la fin du projet, après règlement intégral ». Sans précision sur l'hébergement intermédiaire, ça permet au studio de retenir le code en cas de litige.
• « La publication se fait sur notre compte développeur ». Le client devient locataire de sa propre application, et la perd en cas de faillite du prestataire.

Pourquoi cette clause compte. Le code source d'une application mobile n'est pas un livrable comme un rapport PDF. C'est un actif vivant. Le fondateur doit pouvoir le reprendre à tout moment, soit pour continuer en interne, soit pour confier la suite à un autre studio. Le détail juridique est développé dans la propriété du code.

Coût moyen de la surprise si cette clause est absente : 3 à 7 k€ HT pour racheter les droits, plus plusieurs mois de retard si le studio d'origine traîne. Dans certains cas de rupture, la perte est totale.

Clause 3 : gestion des changements de scope

Ce que tu dois trouver :

• Une règle claire : « toute modification hors périmètre fait l'objet d'un avenant chiffré avant démarrage des travaux »
• Un TJM ou un forfait d'avenant précis. En France en 2026, un dev senior mobile se facture entre 500 et 800 € HT par jour ouvré.
• Une définition de ce qui n'est pas un change : correctif de bug (couvert par la garantie), ajustement visuel mineur, précision d'une fonctionnalité déjà prévue mais dont le détail n'avait pas été figé

Signaux d'alarme :

• « Toute demande sera étudiée au cas par cas ». Aucun cadre = tarifs élastiques dans le mauvais sens.
• « Nous acceptons les modifications avec souplesse ». Tarifs élastiques dans l'autre sens, pour maintenir la bonne relation et faire payer plus tard.
• Absence totale de clause change dans le devis.

Pourquoi cette clause compte. Sur tout projet mobile de plus de 4 semaines, il y a entre 3 et 8 changements de scope. C'est normal, c'est le signe que le fondateur apprend sur son produit en voyant la première version prendre forme. Ce qui compte, ce n'est pas d'éviter les changements. C'est de savoir à l'avance combien ils coûtent.

Coût moyen de la surprise si cette clause est absente : 5 à 10 k€ HT sur un projet de 3 à 4 mois, souvent facturés en une seule fois en fin de projet.

Clause 4 : tests, recette et garantie corrective

Ce que tu dois trouver :

• Nature des tests prévus : unitaires sur les fonctions critiques, tests d'intégration pour les parcours principaux, tests manuels sur les devices cibles
• Durée de la recette : combien de jours entre « code figé » et « livraison validée », nombre de rounds de retours client
• Critères d'acceptation écrits : comment on décide qu'une fonctionnalité est livrable
• Politique bug post-livraison : combien de temps les corrections sont incluses, à partir de quand une évolution devient un avenant payant

Signaux d'alarme :

• Aucune mention des tests
• « Recette : 2 jours » (impossible sur un MVP sérieux)
• « Support bug post-livraison : 1 semaine » (dérisoire pour une app en production)
• Absence totale de politique corrective

Bonne pratique en 2026. Recette entre 2 et 4 semaines selon la complexité, garantie corrective entre 1 et 3 mois post-livraison, tests unitaires au minimum sur les fonctions critiques (paiement, authentification, synchronisation offline). Chez Inyka, le forfait inclut un mois de support correctif à la livraison, et le pack Care prend ensuite le relais à 290, 590 ou 1 190 € par mois selon le niveau de couverture.

Coût moyen de la surprise si cette clause est absente : 2 à 5 k€ HT en tickets bug post-livraison facturés hors forfait, pendant les deux à trois mois qui suivent la mise en production.

Clause 5 : publication stores et comptes développeurs

Ce que tu dois trouver :

• Qui crée le compte Apple Developer (99 $/an) et le compte Google Play (25 $ en une fois)
• Qui rédige les métadonnées stores : titre, description, mots-clés, screenshots, catégorie, politique de confidentialité
• Qui gère la première publication et les mises à jour suivantes
• Qui répond aux refus de l'App Review Apple, qui peut rallonger la publication de 1 à 4 semaines selon le motif

Signaux d'alarme :

• « Publication non incluse dans le forfait »
• « Publication incluse, mais la gestion des refus store est facturée en sus »
• Aucune mention de qui crée les comptes développeurs
• Omission totale de la rédaction des métadonnées stores

Pourquoi cette clause compte. Publier une application sur l'App Store et sur Google Play n'est pas un bouton magique. Chaque store a ses règles, ses motifs de refus récurrents, ses demandes de documentation (politique de confidentialité, politique de suppression de compte, démonstration des fonctionnalités payantes). Un prestataire qui n'inclut pas la publication laisse ce bazar au fondateur, qui met souvent 3 à 5 semaines à s'en sortir seul.

Coût moyen de la surprise si cette clause est absente : 1 à 3 k€ HT + 3 à 5 semaines de retard de publication, voire plus si l'App Review refuse plusieurs fois.

Tableau récapitulatif des 5 clauses

Clause	Signal d'absence	Surprise moyenne
Périmètre exhaustif	« etc. », « standards », « à préciser »	5 à 10 k€ HT
Propriété code	Code propriété agence, livré en fin	3 à 7 k€ HT + retards
Gestion changes	« Au cas par cas » ou rien	5 à 10 k€ HT
Tests et recette	Aucune mention, « 2 jours »	2 à 5 k€ HT
Publication stores	Non incluse, refus payants	1 à 3 k€ HT

Cumul des surprises probables sur un devis à 28 k€ sans ces cinq clauses : 15 à 35 k€ HT additionnels. Le devis « au prix du marché » devient un projet facturé 50 à 100 pourcent au-dessus du devis initial. C'est le mécanisme qui explique pourquoi beaucoup de fondateurs ont le sentiment que leur app a coûté « bien plus que prévu ».

Les trois questions à poser avant de signer

Si tu veux tester un devis en 5 minutes sans tout décortiquer, trois questions filtrent l'essentiel.

1. Est-ce que le devis liste explicitement ce qui est exclu du périmètre ? Une réponse « c'est implicite, ce qui n'est pas listé n'est pas inclus » = devis flou. Une réponse « oui, voir section X » = devis sérieux.
2. Le code m'appartient-il dès le premier commit ou à la livraison finale ? « Dès le premier commit, sur votre repo » = sérieux. « À la fin, après règlement intégral » = porte ouverte au bras de fer.
3. Quel est le TJM d'un avenant hors périmètre ? Un studio qui refuse de répondre ou donne une réponse évasive te facturera au doigt mouillé.

Un prestataire qui répond flou aux trois te vendra un flou pendant tout le projet.

À quoi ressemble un devis Inyka

Chez Inyka, les trois offres (Essential 7 500 €, Launch 14 000 €, Scale à partir de 24 000 € HT) sont construites autour de ces cinq clauses, écrites noir sur blanc dans chaque devis. Le code est hébergé sur un repo client dès le premier commit. La publication stores est incluse, refus Apple compris. Les avenants hors périmètre sont facturés à un TJM de 650 € HT par jour, annoncé avant signature.

Ce n'est pas spécifique à Inyka, c'est juste le minimum qu'un fondateur devrait exiger de n'importe quel studio. La grille de prix Inyka détaille ce qu'inclut chaque offre.

FAQ

Quelle longueur devrait faire un devis d'application mobile sérieux ? Entre 6 et 15 pages pour un MVP simple à 7-14 k€, entre 15 et 25 pages pour un projet à 24-50 k€. En dessous de 5 pages pour un budget supérieur à 20 k€, le devis est trop concis pour couvrir les cinq clauses.

Le code source m'appartient-il automatiquement ? Non. En l'absence de clause explicite, le droit d'auteur français considère que le code appartient à l'auteur, pas au commanditaire. Il faut un transfert de droits écrit dans le contrat ou le devis.

Combien coûte un avenant hors périmètre ? Entre 500 et 800 € HT par jour ouvré en France en 2026, selon le niveau du développeur. Un avenant « ajouter l'authentification Apple » représente souvent 1 à 2 jours, soit 500 à 1 600 €. Les avenants de scope plus larges (par exemple ajouter un module de paiement récurrent) grimpent à 5 à 10 jours.

Qui doit publier l'application sur les stores ? Les comptes développeurs doivent être au nom du client. La publication technique peut être gérée par le studio, mais sous les comptes du client, pas sous les siens. C'est la seule configuration qui garantit que le client peut récupérer son application en cas de litige.

Peut-on négocier ces clauses avec un studio ? Oui, et c'est même attendu. Un studio sérieux les accepte sans difficulté parce qu'elles correspondent à son fonctionnement normal. Un studio qui résiste sur plusieurs des cinq clauses envoie un signal fort sur la suite de la relation.

Faire relire ton devis

Un devis mobile de 20 à 50 k€ mérite une heure de relecture par quelqu'un qui n'a pas intérêt à ce que tu signes. Si tu as un devis en main et que tu veux le faire relire, envoie-le par email à contact@inyka.app (joindre le PDF), ou réserve un appel découverte de 30 minutes pour en discuter de vive voix. Retour écrit sous 5 jours ouvrés, gratuit, sans engagement de signer chez Inyka ensuite.

Pour aller plus loin sur le cadrage, voir le cahier des charges qui rend les devis comparables et la grille de prix Inyka 2026.