Un bon cahier des charges application mobile ne décrit pas des écrans : il décrit ce que des gens doivent pouvoir faire, dans quelles conditions, et ce qui se passe quand cela se passe mal. C'est la différence entre un document que trois prestataires chiffrent au même prix et un document qui produit trois devis incomparables. Le modèle ci-dessous tient en huit blocs. Chacun est illustré par une formulation exacte, que vous pouvez recopier telle quelle en remplaçant les mots entre crochets.
Les deux erreurs qui font dérailler un projet
Première erreur : dessiner au lieu de décrire. Beaucoup de cahiers des charges ressemblent à une liste d'écrans — « écran d'accueil », « écran profil », « écran historique ». Le prestataire chiffre alors des écrans, pas un service. Le jour de la livraison, tous les écrans existent et pourtant rien ne fonctionne bout en bout, parce que personne n'avait écrit ce qui relie les écrans entre eux : que se passe-t-il si le paiement échoue, si le réseau tombe au milieu d'une saisie, si deux utilisateurs modifient la même fiche ?
Deuxième erreur : s'arrêter à la livraison. Une application vit dans deux magasins qui imposent leur calendrier, leurs comptes et leurs règles. Un cahier des charges muet sur les comptes développeurs, les mises à jour obligatoires et la propriété du code prépare une mauvaise surprise douze mois plus tard, au moment de changer de prestataire. Le dernier bloc y est consacré : c'est celui qui manque le plus souvent.
Bloc 1 — Le problème, en trois phrases
Commencez par ce que l'application doit changer dans votre activité, en langage de gestion. Pas de vocabulaire technique, pas de « solution innovante ».
Aujourd'hui, [nos commandes arrivent par appels et messages WhatsApp] et [nous perdons la trace de X commandes par semaine en période de pointe]. L'application doit permettre de [recevoir, suivre et clôturer chaque commande dans un seul outil]. Nous considérerons le projet réussi si, six mois après la mise en ligne, [aucune commande ne se perd et le temps de préparation est visible pour l'équipe].
Cette phrase vaut dix pages d'annexes. Elle donne au prestataire le droit de vous proposer plus simple que ce que vous aviez imaginé.
Bloc 2 — Qui utilise l'application, et pour faire quoi
Listez les rôles, pas les personnes. Pour chaque rôle, trois lignes : ce qu'il fait le plus souvent, ce qu'il ne doit surtout pas pouvoir faire, et dans quelles conditions il travaille.
Rôle « livreur » : consulte les courses du jour, change le statut d'une course, prend une photo à la livraison. Ne peut pas modifier un prix ni voir les courses d'un autre livreur. Travaille debout, à une main, sur un téléphone Android d'entrée de gamme, parfois sans réseau.
Cette dernière ligne — les conditions réelles d'usage — est celle qui fait le plus économiser. Un prestataire qui sait qu'on utilise l'application à une main, en plein soleil, avec des gants, ne dessine pas la même interface.
Bloc 3 — Les parcours, racontés du début à la fin
Pour chaque rôle, écrivez deux ou trois parcours complets, sous forme de récit numéroté, en incluant systématiquement ce qui rate.
Parcours « passer une commande » : 1. le client ouvre l'application et voit le catalogue du jour ; 2. il ajoute des articles au panier ; 3. il choisit la livraison ou le retrait ; 4. il confirme avec son numéro de téléphone et un code reçu par SMS ; 5. il reçoit une confirmation avec un numéro de commande. Si le code SMS n'arrive pas : [proposer un renvoi après 60 secondes, puis un appel vocal]. Si un article devient indisponible pendant la commande : [prévenir immédiatement et proposer le retrait de l'article].
Ce sont ces cas d'échec qui séparent une application qui tient en production d'une démonstration qui marche une fois.
Bloc 4 — Le hors connexion, à décider explicitement
C'est le bloc spécifiquement mobile, et celui que les cahiers des charges copiés sur des modèles français oublient. Sur le terrain — un souk, un sous-sol, une route entre Agadir et Taroudant, un entrepôt en zone industrielle — le réseau disparaît. Le cahier des charges doit trancher, fonction par fonction.
Hors connexion, l'application doit permettre de [consulter la tournée du jour et saisir une livraison]. Les saisies faites hors connexion sont [conservées sur le téléphone et envoyées automatiquement au retour du réseau, avec un indicateur visible du nombre d'éléments en attente]. Les fonctions [paiement et création de compte] ne sont pas disponibles hors connexion.
Écrire « l'application doit fonctionner hors ligne » sans cette précision revient à signer un chèque en blanc : la synchronisation différée est l'une des parties les plus coûteuses d'un développement mobile.
Bloc 5 — Les données, et qui a le droit de les voir
Listez les données que l'application collecte, et pour chacune : à quoi elle sert, combien de temps elle est conservée, qui y accède. Ce n'est pas un exercice théorique. Au Maroc, le traitement de données personnelles relève de la loi 09-08 et la CNDP prévoit une déclaration préalable des traitements, avec un récépissé délivré sous 24 heures et une autorisation préalable pour certaines catégories sensibles. Une application qui enregistre des numéros de téléphone, des adresses de livraison ou une position GPS entre dans ce périmètre.
L'application collecte [nom, téléphone, adresse de livraison, position du livreur pendant son service]. La position n'est enregistrée que [pendant les heures de service et n'est conservée que 30 jours]. Le prestataire fournit la liste des données et des finalités dans un format directement réutilisable pour la déclaration CNDP.
Bloc 6 — Ce à quoi l'application se connecte
Une application isolée sert rarement. Nommez les systèmes existants et le sens de la circulation.
L'application doit [lire le catalogue et les stocks depuis notre logiciel de gestion] et [y déposer chaque commande validée]. La source de vérité pour les prix est [le logiciel de gestion], jamais l'application. En cas d'indisponibilité du logiciel, l'application [continue d'afficher le dernier catalogue connu et bloque la validation des commandes].
Ajoutez ici les services tiers attendus : passerelle de paiement, envoi de SMS, cartographie, messagerie WhatsApp. Précisez qui ouvre les comptes et qui paie les abonnements — ils sont facturés à l'usage et ne font jamais partie du prix du développement.
Bloc 7 — La recette : comment vous direz « c'est livré »
Écrivez les tests que vous ferez vous-même, avec des données réelles. Une recette qui tient en une page évite deux mois de discussions.
La recette se fait sur [trois téléphones : un iPhone récent, un Android milieu de gamme, un Android d'entrée de gamme de plus de trois ans]. Elle est réussie quand [dix commandes complètes ont été passées, préparées et livrées de bout en bout, dont deux en coupant le réseau en cours de saisie]. La garantie de correction des anomalies court [trois mois] après la mise en ligne.
Bloc 8 — L'après-livraison : comptes, mises à jour, propriété
Le bloc qui manque presque toujours. Trois sujets, trois phrases à ne pas négocier.
Les comptes développeurs Apple et Google sont ouverts au nom de [notre société], avec nos identifiants ; le prestataire y est invité comme collaborateur et cet accès est révocable. Le code source complet est notre propriété et nous est livré sur [un dépôt Git à notre nom], avec la documentation d'installation. À la fin du contrat, le prestataire fournit [l'ensemble des clés, certificats de signature et accès] sous quinze jours.
Pourquoi tant d'insistance ? Parce qu'une application publiée sous le compte du prestataire ne vous appartient pas en pratique : vous ne pouvez ni la mettre à jour, ni la transférer facilement. Les deux magasins exigent en outre des éléments d'identité d'entreprise — dont un numéro D-U-N-S — qu'il vaut mieux obtenir à votre nom, comme l'explique notre guide sur la publication d'une application sur le Play Store et l'App Store.
Ajoutez enfin une ligne sur l'entretien : les systèmes d'exploitation évoluent et les magasins imposent régulièrement de recompiler pour rester visible, un budget traité dans notre article sur le prix de la maintenance d'une application mobile.
Cahier des charges application mobile : le modèle en une page
| Bloc | Ce que vous écrivez | Longueur utile |
|---|---|---|
| 1. Problème | Situation actuelle, résultat attendu, critère de réussite | 3 phrases |
| 2. Rôles | Qui fait quoi, interdits, conditions d'usage réelles | 3 lignes par rôle |
| 3. Parcours | Récits numérotés, avec les cas d'échec | 2 à 3 par rôle |
| 4. Hors connexion | Ce qui marche sans réseau, ce qui est bloqué | 1 paragraphe |
| 5. Données | Liste, finalité, durée, accès, déclaration CNDP | 1 tableau |
| 6. Connexions | Systèmes existants, sens de circulation, source de vérité | 1 paragraphe |
| 7. Recette | Téléphones de test, scénarios de validation, garantie | 1 page |
| 8. Après-livraison | Comptes au nom de la société, propriété du code, sortie | 3 phrases |
Ce qui ne doit pas s'y trouver : le choix de la technologie. Écrire « application en Flutter » revient à choisir l'outil avant d'avoir décrit le travail. Laissez le prestataire proposer et justifier — la même logique vaut pour l'arbitrage entre une PWA et une application native, qui se tranche à partir de vos parcours. Pour un projet web, le modèle équivalent est notre cahier des charges de site web pour une PME.
Envoyez-nous votre cahier des charges, même incomplet : nous le relisons gratuitement et vous signalons les blocs manquants avant que vous ne le diffusiez à plusieurs prestataires. Vous pouvez nous joindre depuis la page d'accueil de Samed Agency et recevoir un devis gratuit sous 24 heures.
Questions fréquentes
Quelle longueur doit faire un cahier des charges d'application mobile ? Entre cinq et quinze pages pour un projet de PME. Au-delà, le document devient impossible à tenir à jour et personne ne le relit. La qualité se joue sur la précision des parcours et des cas d'échec, pas sur le nombre de pages.
Faut-il des maquettes dans le cahier des charges ? Non, et c'est même contre-productif au premier tour. Des maquettes figent des choix d'interface avant que le prestataire n'ait compris le besoin. Un croquis à main levée pour illustrer un parcours complexe suffit ; les maquettes se font ensuite, dans le projet.
Comment comparer des devis reçus sur ce cahier des charges ? Demandez à chaque prestataire de chiffrer bloc par bloc et de dire explicitement ce qu'il exclut. Un devis global sans détail ne se compare pas. Les écarts de prix s'expliquent presque toujours par le hors connexion, la synchronisation et le nombre de rôles — nos repères de budget sont dans l'article sur le prix d'une application mobile au Maroc.
Peut-on faire évoluer le cahier des charges en cours de projet ? Oui, à condition d'écrire dès le départ qui valide une demande de changement, sous quel délai et comment elle est chiffrée. Un projet qui évolue sans procédure écrite dérape toujours sur le budget.