Agence web Lille Cahier des charges d’une application mobile : modèle en 10 rubriques

L’essentiel en 30 secondes

• Un cahier des charges d’application mobile sert d’abord à obtenir des devis comparables : sans lui, chaque agence chiffre une application différente.
• Il tient en 10 rubriques : objectif, utilisateurs, fonctionnalités, plateformes, back-office, comptes, données personnelles, publication sur les stores, design, budget et planning.
• Les oublis qui coûtent le plus cher sont presque toujours les mêmes : le back-office, le fonctionnement hors connexion, les connexions à vos logiciels, les règles des stores (dont la suppression de compte) et la maintenance après la mise en ligne.
• Pas besoin d’un document de 40 pages : 5 à 10 pages claires valent mieux qu’un document exhaustif que personne ne lit.

Nous recevons régulièrement des demandes de devis d’application mobile qui tiennent en trois lignes : « une appli comme Doctolib, mais pour les coiffeurs ». Impossible à chiffrer sérieusement. À l’inverse, quelques pages bien construites suffisent pour donner un prix fiable et un planning réaliste. Voici le modèle que nous aimerions recevoir, rubrique par rubrique, avec un exemple rempli.

À quoi sert un cahier des charges d’application mobile

Il a trois rôles, et le troisième est souvent oublié.

• Comparer des devis. Trois agences qui lisent le même document chiffrent la même application. Sans document, l’une vous propose un prototype, l’autre une plateforme complète, et les écarts de prix ne veulent plus rien dire.
• Choisir ce qui entre dans la première version. L’écrire oblige à trier : ce qui est indispensable au lancement, et ce qui peut attendre.
• Servir de base au contrat. Le contrat de développement renvoie au cahier des charges pour définir ce qui est livré. C’est aussi le moment de régler la propriété du code : Bpifrance rappelle que commander un logiciel sur mesure ne rend pas automatiquement le client titulaire des droits, et qu’un contrat de cession de droits doit être annexé au contrat de développement.

Le modèle : les 10 rubriques à remplir

Pour chaque rubrique, voici ce qu’il faut écrire et la question que l’agence se posera en vous lisant.

1. Le contexte et l’objectif

Qui vous êtes, pourquoi cette application, et comment vous saurez qu’elle a réussi. Un objectif mesurable vaut mieux qu’une intention : « 30 % des rendez-vous pris depuis l’application au bout de six mois » plutôt que « moderniser la relation client ».

2. Les utilisateurs et leurs usages

Décrivez chaque type d’utilisateur et la situation dans laquelle il ouvre l’application : dans la rue, sur un chantier, en consultation, avec une seule main libre. C’est ce qui décide du nombre d’écrans, de la taille des boutons et du besoin de fonctionner sans réseau. S’il y a plusieurs profils (clients, livreurs, administrateurs), listez-les tous.

3. Les fonctionnalités, classées par priorité

Écrivez chaque fonction du point de vue de l’utilisateur, sous la forme d’une user story : « En tant que client, je veux reprogrammer mon rendez-vous, afin de ne pas appeler le salon. » Puis classez-les avec la méthode MoSCoW : Must (sans elle, la version est un échec), Should (importante, mais pas bloquante), Could (si le temps le permet) et Won’t (pas pour cette version).

Les « Must » forment votre première version, le MVP (minimum viable product) : la plus petite application qui permet d’apprendre quelque chose de vos vrais utilisateurs. C’est elle qu’on chiffre en premier.

4. Les plateformes et les appareils

iPhone, Android, ou les deux ? Tablettes comprises ? Quelles versions minimales des systèmes (par exemple iOS 15 et Android 11) ? Ces choix changent le temps de test. Sur la technologie, vous n’avez pas à trancher vous-même : dites ce qui compte pour vous (budget, délai, performances, accès au GPS ou à l’appareil photo), et laissez l’agence proposer. Chez A&F, nous développons en React Native : une seule base de code pour iOS et Android, comme pour l’application de paiement ToneoFirst.

5. Le back-office et les données

C’est la rubrique la plus souvent oubliée, et celle qui fait le plus varier le prix. Derrière l’application, il faut presque toujours un outil web pour gérer les contenus, les utilisateurs, les commandes ou les statistiques, et un serveur qui stocke les données. Précisez qui l’utilisera, ce qu’il doit permettre, et si l’application doit se connecter à un logiciel existant (ERP, CRM, caisse, agenda). Si ce back-office devient un outil métier à part entière, il relève d’un développement d’application métier sur mesure.

Exemple : pour Umeos, l’application des patients ne représente qu’une partie du projet. Derrière elle, il y a une interface pour les praticiens, un back-office et une API, et les données de santé sont hébergées chez un hébergeur agréé HDS, comme l’exige la réglementation française. Ces éléments pèsent autant dans le devis que l’application elle-même.

6. Les comptes, la connexion et les notifications

Faut-il un compte ? Connexion par e-mail, par téléphone, avec Google ou Apple ? Une vérification d’identité ? Des notifications push, et déclenchées par quoi ? Notez une règle qui surprend souvent : Apple exige que toute application qui permet de créer un compte permette aussi de le supprimer depuis l’application. Mieux vaut le prévoir dans le devis que le découvrir au moment de la publication.

7. Les données personnelles et le RGPD

Listez les données collectées, à quoi elles servent et combien de temps vous les gardez. La CNIL a publié en septembre 2024 des recommandations dédiées aux applications mobiles : une application ne doit demander que les permissions réellement nécessaires (localisation, contacts, appareil photo), et le consentement est obligatoire pour les données qui ne servent pas au fonctionnement, comme le ciblage publicitaire. Refuser doit être aussi simple qu’accepter.

Les stores ajoutent leurs propres déclarations : la fiche « confidentialité » d’Apple et la section « Sécurité des données » de Google Play, qui doivent décrire aussi les données collectées par les outils tiers intégrés (statistiques, publicité, paiement). Une politique de confidentialité est exigée par les deux.

8. La publication sur les stores

Prévoyez les comptes développeur au nom de votre entreprise, pas de l’agence : 99 $ par an chez Apple, 25 $ une seule fois chez Google, avec une vérification d’identité. Pour un compte d’entreprise, Apple demande un numéro D-U-N-S : à anticiper, son obtention peut prendre quelques jours. Apple examine chaque version avant publication et demande un compte de démonstration si l’application a une connexion. Prévoyez aussi les textes et captures d’écran des fiches, et un délai de revue dans le planning.

9. Le design et les contenus

Avez-vous une charte graphique, des maquettes, des exemples d’applications que vous aimez ou détestez ? Qui fournit les textes, les photos, les traductions ? Un contenu qui arrive en retard décale la mise en ligne autant qu’un bug.

10. Le budget, le planning et la suite

Donnez une fourchette de budget, même large : elle permet à l’agence de proposer la bonne version plutôt qu’une application idéale hors de portée. Distinguez la date souhaitée de la date impérative (un salon, une saison, une levée de fonds). Et demandez que la maintenance soit chiffrée à part : mises à jour imposées par Apple et Google, correctifs, évolutions. Une application qui n’est plus mise à jour finit par ne plus fonctionner sur les nouveaux téléphones.

Pour estimer l’enveloppe, notre article sur le budget de développement d’une application mobile détaille les fourchettes et ce qui les fait varier.

Un exemple rempli

Une enseigne fictive de 12 salons de coiffure veut une application de prise de rendez-vous. Voici à quoi ressemble son cahier des charges, en version courte.

Les 5 oublis qui font exploser le devis

1. Le back-office, découvert en cours de projet : il faut bien quelqu’un pour saisir les contenus.
2. Le hors connexion : une application qui doit fonctionner sans réseau (chantier, entrepôt, sous-sol) demande une synchronisation des données, qui se conçoit dès le départ.
3. Les connexions à vos logiciels (caisse, ERP, CRM) : leur coût dépend surtout de la qualité de la documentation de l’autre logiciel.
4. Les règles des stores : suppression de compte, politique de confidentialité, déclarations de données, compte de démonstration.
5. La vie après la mise en ligne : nouvelles versions d’iOS et d’Android chaque année, correctifs, évolutions demandées par les utilisateurs.

Et si vous n’avez pas le temps de tout écrire ?

Envoyez ce que vous avez, même incomplet. Les rubriques 1, 2 et 3 suffisent pour un premier échange : c’est à l’agence de vous poser les questions sur le reste. Si vous préparez aussi un site, notre guide pour rédiger le cahier des charges d’un site internet suit la même logique. Et si vous hésitez encore entre une application et un site, lisez d’abord application mobile ou site responsive : que choisir.

Quand votre document est prêt, vous pouvez demander un devis d’application mobile à Lille : nous le lisons, nous vous disons ce qui manque, puis nous chiffrons la première version.

Sources

• Bpifrance Création : protection juridique d’un logiciel
• CNIL : recommandations pour les applications mobiles (2024)
• Apple : App Store Review Guidelines
• Apple Developer Program : adhésion
• Google Play Console : créer un compte développeur
• Google Play : section Sécurité des données
• Méthode MoSCoW (Wikipédia)