Cahier des charges application mobile : méthode PME

Un cahier des charges d’application mobile décrit ce que l’application doit faire, pour qui, dans quelles limites et selon quels critères de validation. Ce document de cadrage sert de base au devis, au contrat et aux tests de recette. Sa qualité détermine la fiabilité des chiffres que vous recevrez.

Le sujet paraît administratif. Il ne l’est pas. Les spécifications incomplètes arrivent en tête des causes d’échec recensées par le rapport CHAOS du Standish Group. Une startup qui commande une application sans rien écrire ne compare pas des devis, elle compare trois interprétations différentes d’une idée floue.

Ce que le document de cadrage engage vraiment

Un document de décision, pas un document technique

Beaucoup de dirigeants repoussent la rédaction parce qu’ils se croient obligés de parler base de données et architecture. Faux problème. Un cahier des charges utile décrit des besoins métier, des utilisateurs et des règles de gestion. Le choix des technologies revient au prestataire, qui engage sa responsabilité dessus.

Votre travail consiste à répondre à quatre questions, dans cet ordre :

• quel problème l’application résout, et pour qui
• ce que chaque utilisateur doit pouvoir accomplir
• ce qui reste hors sujet pour la première version
• comment vous saurez que la livraison est conforme

Un document qui traite ces quatre points tient parfois en dix pages. Soixante pages qui les esquivent ne valent rien.

Ce qu’il protège quand le projet dérape

Le document de cadrage joue trois rôles successifs. Avant la signature, il sert à chiffrer. Pendant le développement, il tranche les arbitrages. À la livraison, il devient la référence de recette : conforme ou non conforme.

Sans lui, chaque désaccord se règle au rapport de force commercial. Avec lui, la discussion redevient factuelle.

Le baromètre France Num 2025, publié par la Direction générale des entreprises, montre que 78 % des dirigeants de TPE et PME reconnaissent des bénéfices réels au numérique. Transformer cette conviction en produit livré suppose un écrit, pas une conversation de couloir.

Les blocs qui composent un cahier des charges d’application mobile

Aucun modèle universel ne s’impose. La trame ci-dessous couvre ce que les prestataires attendent pour chiffrer sans provisionner du risque à l’aveugle.

Le contexte et les objectifs mesurables

Deux pages suffisent : votre activité, la cible visée, la raison du projet, et surtout le résultat attendu, formulé de façon vérifiable. « Diviser par deux le temps de prise de commande » se mesure. « Moderniser notre image » ne se mesure pas.

Cette section porte aussi le calendrier et l’enveloppe budgétaire. Cacher son budget reste une tactique perdante : le prestataire dimensionne au hasard.

Vérifiez d’abord que le besoin existe côté marché. Notre méthode pour valider une idée de produit avant de coder liste les tests qui évitent de cadrer un projet que personne n’attend.

Le périmètre fonctionnel et ce qui en est exclu

Le cœur du document. Listez les fonctions par acteur, en distinguant trois niveaux : indispensable à la mise en service, utile dans un second temps, écarté pour l’instant. Le troisième niveau est le plus rentable à écrire.

Un périmètre fonctionnel exploitable contient :

• les rôles utilisateurs et leurs droits respectifs
• les parcours principaux, décrits comme des suites d’actions
• les règles de gestion : calculs, statuts, notifications
• les données manipulées et leur provenance
• les connexions avec vos outils existants
• la liste de ce que la version 1 ne fera pas

Les exigences techniques, la partie oubliée

Ce sont elles qui font varier un devis du simple au double. Les exigences non fonctionnelles couvrent la performance attendue, les versions d’Android et d’iOS supportées, le fonctionnement hors connexion, la sécurité, l’accessibilité, les langues et le lieu d’hébergement des données.

La protection des données mérite un paragraphe explicite. La Cnil a publié le 24 septembre 2024 sa recommandation consacrée aux applications mobiles, actualisée en avril 2025, et annoncé une campagne de contrôles à partir du printemps 2025. Consentement, kits de développement tiers, permissions demandées au téléphone : ces choix se figent au cadrage, pas après la première livraison.

Écrire ce document sans être développeur

L’exercice tient davantage du mode d’emploi que du travail d’ingénierie. Racontez l’usage, laissez la solution technique ouverte.

Le cadre commercial de votre prestataire change aussi la façon de rédiger. Sparkana, agence web et IA installée à Nîmes et Alès, dans le Gard, travaille de cette manière avec des TPE et des startups : premier périmètre volontairement réduit, livraison rapide, code source remis au client, aucun abonnement imposé et aucune dépendance à une plateforme propriétaire, leur méthode est détaillée ici. Quand ces points sont acquis d’entrée, votre cahier des charges reste court et se concentre sur l’usage. Quand ils ne le sont pas, vous devez écrire noir sur blanc la propriété du code, la réversibilité et les conditions de sortie.

Partir des parcours, pas des écrans

Décrivez ce que la personne cherche à accomplir, du début à la fin. « Un livreur scanne un colis, signale une anomalie, fait signer le client, puis synchronise sa tournée » cadre à lui seul trois écrans et deux règles de gestion.

Le parcours utilisateur prime sur la maquette. Une maquette figée trop tôt empêche le prestataire de proposer plus simple et moins cher. Notre article sur l’UX design, sa définition et sa méthode montre comment ces parcours se construisent avant tout dessin d’interface.

Décrire un besoin, jamais une solution technique

Écrivez « l’utilisateur retrouve son historique de commandes sans réseau » plutôt que « il faut une base locale embarquée ». La première formulation laisse le prestataire optimiser. La seconde impose un choix que vous ne saurez pas défendre trois mois plus tard.

Même logique pour l’intelligence artificielle. Le baromètre France Num 2025 relève que l’usage de l’IA a doublé en un an dans les TPE et PME françaises, pour atteindre 26 % d’entre elles. « Je veux de l’IA » ne se chiffre pas. « Classer automatiquement les demandes entrantes par degré d’urgence » se chiffre.

Ce qui fait déraper un devis

Un devis dérape rarement sur les fonctions annoncées. Il dérape sur ce que le document a passé sous silence.

Quatre oublis reviennent presque à chaque projet :

• les cas d’erreur : paiement refusé, réseau coupé, fiche modifiée par deux personnes au même moment
• l’administration : presque toute application suppose un back-office, rarement décrit
• la reprise de données : un historique tableur ou une base ancienne se chiffre à part
• la conformité : accessibilité, mentions légales, gestion des consentements

L’accessibilité illustre bien le piège. Depuis le 28 juin 2025, la réglementation européenne transposée en droit français impose des exigences d’accessibilité à plusieurs services numériques destinés au grand public, avec une exemption pour les entreprises de moins de 10 salariés réalisant moins de 2 millions d’euros. Le découvrir en phase de recette coûte une refonte d’interface. Nos règles d’accessibilité numérique pour une application précisent le référentiel applicable.

La publication ajoute ses propres contraintes. Depuis le 31 août 2025, Google exige que toute nouvelle application ou mise à jour cible Android 15 pour être soumise sur son magasin, et impose la déclaration « Sécurité des données », obligatoire depuis juillet 2022. Côté tarifs officiels 2026, le programme développeur d’Apple coûte 99 dollars par an, quand l’inscription à la console Google se règle une seule fois, 25 dollars. Inscrire ces contraintes dans les spécifications fonctionnelles évite de les découvrir plus tard sous forme d’avenant.

Les pièges de rédaction qui reviennent le plus souvent

Le périmètre élastique

Les idées s’ajoutent au fil des réunions, sans que rien ne sorte jamais de la liste. Le prestataire absorbe en silence, puis facture. Une application mobile cadrée applique une règle simple : toute fonction ajoutée après signature passe par un avenant chiffré, ou remplace une fonction déjà prévue.

La liste des exclusions désamorce la moitié des tensions futures. Une fonction écartée par écrit ne revient pas en réunion trois mois plus tard sous forme d’évidence oubliée par tout le monde.

Les critères d’acceptation absents

Sans critère écrit, la recette devient un débat d’opinion. Chaque fonction importante mérite sa condition de réussite, formulée comme un test : telle action, dans telles conditions, produit tel résultat.

Les critères d’acceptation transforment la livraison en fait vérifiable. Ils protègent aussi le prestataire, qui sait à quel moment son travail est terminé et payable.

La différence saute aux yeux sur un exemple. « Le livreur hors réseau enregistre une signature, qui remonte au serveur dès le retour de connexion » se teste en cinq minutes. « L’application doit être fluide » ne se teste pas et finit toujours en discussion tendue.

Le document que personne n’a relu

Un cadrage rédigé par le seul dirigeant décrit un usage théorique. Faites-le lire par deux ou trois utilisateurs finaux avant l’envoi : ceux qui saisissent les commandes, tiennent la caisse ou remplissent les rapports d’intervention. Leurs corrections coûtent une heure de réunion, contre plusieurs jours de développement une fois l’application livrée.

Traitez le volet juridique dès cette étape. La cession des droits sur le code, les licences des composants utilisés et les responsabilités en cas d’incident se négocient avec le contrat, jamais après. Nos repères sur le développement d’une application mobile en entreprise détaillent ces clauses.

Obtenir des devis réellement comparables

Ce que vous demandez à chaque prestataire

Envoyez le même document à trois structures, avec la même grille de réponse : chiffrage par lot fonctionnel, hypothèses retenues, éléments exclus, durée estimée, coût de maintenance annuelle et conditions de propriété du code.

Des devis comparables se reconnaissent à leurs hypothèses écrites. Un prix global sans détail ne se compare à rien. Un écart important entre deux propositions signale presque toujours une lecture différente du périmètre, pas une différence de compétence.

Pour situer les ordres de grandeur avant les rendez-vous, notre analyse des méthodes, outils et budgets du développement mobile en 2026 donne les repères de coût par type de projet.

Faire vivre le document après la signature

Le cadrage ne meurt pas à la commande. Il devient le journal de bord du projet : chaque arbitrage validé en réunion s’y inscrit, avec sa date et son auteur. À la recette, cette version à jour sert de référence unique, opposable des deux côtés.

Apple indique examiner 90 % des soumissions en moins de 24 heures, mais un refus motivé par la confidentialité ou le contenu repousse la mise en ligne de plusieurs jours. Inscrire les règles des deux magasins dans le document dès le départ réduit sensiblement ce risque de calendrier.

Prochaine étape : rédigez les parcours de votre version 1 cette semaine, une page par acteur, listez ce que vous excluez explicitement, puis envoyez ce document à trois prestataires avant de discuter du moindre prix.