Un cahier des charges application mobile utile ne décrit pas des écrans. Il rend décidables les quelques points qui pèsent vraiment sur le coût, le délai et la fiabilité : les gestes métier à accélérer, la donnée qui doit rester disponible sans réseau, les droits, et ce qu'il faudra encore financer dans deux ans. Voici la méthode que nous appliquons pour produire un document court, lisible aussi bien par un développeur que par un acheteur.

Ce qu'un cahier des charges doit réellement trancher

Deux travers reviennent sans cesse. Le premier est le document de cent pages qui décrit chaque bouton : il vieillit avant la première ligne de code et transforme le moindre ajustement en avenant. Le second est la page et demie qui réclame « une application mobile pour les techniciens » : chaque prestataire chiffre alors un projet différent, et comparer les devis n'a plus aucun sens.

Entre les deux, le bon format tient en dix à vingt pages et répond à une seule question : qu'est-ce qui doit être vrai pour que cette application soit ouverte tous les jours ? Tout ce qui ne change ni le coût, ni le risque, ni l'usage n'a rien à faire dans le document. Un cahier des charges est un outil de décision, pas un inventaire.

Étape 1 : partir des gestes, pas des fonctionnalités

Avant d'écrire la moindre ligne, allez observer trois utilisateurs en situation et chronométrez les trois gestes qu'ils répètent le plus souvent : un relevé sur chantier, une saisie de bon de livraison, une photo à rattacher à un dossier. Notez la durée actuelle, le nombre d'occurrences par jour et ce qui bloque concrètement.

Ces mesures apportent deux choses précieuses. D'abord la liste des parcours à traiter en priorité. Ensuite un critère de réussite chiffré, vérifiable après la mise en service. Une application qui fait passer un relevé de quatre minutes à cinquante secondes se défend toute seule ; une application riche en fonctionnalités mais sans gain mesurable finit en icône jamais ouverte.

Étape 2 : les 8 sections d'un cahier des charges application mobile

  1. Le problème et le gain attendu. Une page maximum : la situation actuelle, le coût de l'existant, le gain visé exprimé en temps, en erreurs évitées ou en délai de traitement.
  2. Les utilisateurs et leurs conditions réelles d'usage. Combien de personnes, avec quels appareils, dans quel environnement : gants, plein soleil, sous-sol, terminal partagé entre deux équipes.
  3. Les parcours prioritaires. Trois à cinq enchaînements décrits du déclencheur jusqu'au résultat, avec les cas particuliers connus. C'est le cœur du document.
  4. Le modèle de données et la source de vérité. Quelles informations sont créées dans l'application, lesquelles viennent d'ailleurs, et qui fait foi en cas de divergence.
  5. Le comportement hors connexion. Ce qui doit fonctionner sans réseau, ce qui peut attendre, et ce qui doit être refusé plutôt que stocké en attente.
  6. Les droits, les comptes et l'authentification. Profils, périmètre de visibilité, arrivée et départ d'un salarié, mode de connexion retenu.
  7. Les intégrations. Les systèmes à interroger ou à alimenter, le sens des échanges, la fréquence attendue et ce qui se passe quand l'un d'eux est indisponible.
  8. L'exploitation. Canal de distribution, rythme des mises à jour, support, sauvegarde, propriétaire des comptes, conditions de réversibilité.

Les trois sections que l'on bâcle le plus souvent

La source de vérité de la donnée

Dès qu'une application mobile coexiste avec un ERP, un tableur ou un logiciel de gestion, la même information existe à deux endroits. Le cahier des charges doit désigner, au moins objet par objet, qui détient la version faisant autorité. Sans cette règle écrite, l'arbitrage se fera dans l'urgence, au moment de la reprise de données, et rarement dans le bon sens.

Les conditions réelles de réseau

Ne vous contentez pas d'écrire que l'application doit fonctionner hors ligne. Précisez quelles actions restent possibles sans réseau, combien de temps un appareil peut rester déconnecté, et ce que l'utilisateur voit quand une donnée locale n'est pas encore synchronisée. Ces trois réponses changent radicalement la charge de développement.

Le cycle de vie des comptes

Une application métier survit aux personnes qui l'utilisent. Décrivez ce qui se passe quand un salarié arrive, change de service ou quitte l'entreprise : que deviennent ses saisies, ses photos, ses affectations en cours ? Traité dès le cahier des charges, ce point évite les comptes fantômes et les reprises de données douloureuses.

Les contraintes de plateforme à inscrire noir sur blanc

Une application mobile n'est jamais livrée une fois pour toutes : les plateformes imposent leur propre calendrier. Deux exemples vérifiés le 11 septembre 2026 le montrent clairement.

Côté Android, la documentation Google Play prévoit que, depuis le 31 août 2026, les nouvelles applications et les mises à jour doivent viser Android 16 (niveau d'API 36) ou supérieur, et que les applications existantes doivent viser au moins Android 15 (niveau d'API 35) sous peine de ne plus être proposées aux nouveaux utilisateurs équipés de versions récentes, une prolongation restant possible jusqu'au 1er novembre 2026. Autrement dit, une application qui n'est pas maintenue disparaît progressivement du magasin sans qu'aucune panne ne soit visible.

Côté Apple, la règle 5.1.1(v) des consignes d'examen impose depuis le 30 juin 2022 que toute application permettant de créer un compte permette également de le supprimer depuis l'application elle-même, une simple désactivation temporaire étant jugée insuffisante. Cette exigence a des conséquences directes sur votre modèle de données et sur vos règles de conservation : mieux vaut l'avoir écrite au départ que la découvrir au moment de la soumission.

Trois lignes suffisent dans le cahier des charges : un budget annuel de maintenance de compatibilité, l'engagement du prestataire à suivre les échéances des plateformes, et la propriété des comptes éditeurs au nom de votre entreprise, jamais à celui du prestataire.

Ce qui n'a rien à faire dans le document

Évitez de figer la technologie. Écrire « natif iOS et Android », ou au contraire imposer un cadre de développement précis, revient à choisir la réponse avant d'avoir posé la question, et vous prive des propositions les plus pertinentes. Exprimez plutôt les contraintes qui, elles, sont réelles : fonctionnement hors ligne, accès à un capteur, taille de la flotte, compétences internes disponibles pour la suite.

Évitez aussi les maquettes détaillées au pixel en annexe d'un appel d'offres. Elles donnent une fausse impression de précision et seront de toute façon revues après les premiers retours du terrain. Une esquisse de parcours suffit largement à cadrer le chiffrage.

Cinq erreurs fréquentes

  • Rédiger le document sans avoir observé un seul utilisateur au travail.
  • Lister deux cents fonctionnalités sans aucune priorité, ce qui rend tout arbitrage impossible en cours de projet.
  • Oublier la reprise de l'existant, souvent le poste le plus sous-estimé du budget.
  • Ne désigner aucun décideur métier unique, capable de trancher en quelques jours.
  • Omettre l'après : mises à jour, support, évolutions, et ce qui se passe si vous changez de prestataire.

Questions fréquentes

Quelle longueur pour un cahier des charges d'application mobile ?

Dix à vingt pages suffisent dans la grande majorité des projets de PME. Au-delà, le document décrit généralement l'interface plutôt que le besoin et devient impossible à maintenir pendant le projet.

Faut-il indiquer un budget dans le cahier des charges ?

Oui, au moins une fourchette. Elle permet aux prestataires de calibrer leur proposition et d'écarter d'emblée un projet hors d'atteinte. Sans indication, vous recevez des devis incomparables et vous perdez plusieurs semaines.

Faut-il choisir la technologie dans le document ?

Non, sauf contrainte imposée par votre système d'information existant. Décrivez les contraintes réelles et laissez les candidats justifier leur choix technique : leur argumentaire vous en apprendra beaucoup sur leur sérieux.

Qui doit rédiger le cahier des charges ?

L'entreprise reste propriétaire du besoin. Un prestataire peut animer les ateliers et mettre en forme le document, mais la description des gestes métier et les critères de réussite doivent être validés par les équipes qui utiliseront l'application.

Que faire si le besoin évolue en cours de projet ?

C'est normal et même souhaitable. Prévoyez dès le départ un rythme de livraisons courtes et une règle d'arbitrage : toute demande nouvelle entre dans le périmètre en remplacement d'une autre, ou fait l'objet d'un chiffrage séparé.

Vous préparez une application mobile pour vos équipes et vous voulez un cahier des charges qui tienne la route ? Parlons de votre projet : nous vous aidons à cadrer le besoin avant d'écrire la moindre ligne de code.