Pourquoi formaliser le projet dans un cahier des charges
Un cahier des charges d’application mobile transforme une idée générale en document de référence exploitable par les personnes chargées de la conception, du développement, du design, des tests et du suivi du projet. Il sert à réduire les interprétations divergentes et à rendre les arbitrages visibles avant d’engager des travaux techniques.
Le document ne doit pas chercher à décrire chaque ligne de code. Son objectif consiste plutôt à préciser le problème à résoudre, les utilisateurs concernés, les fonctionnalités attendues, les contraintes techniques, les règles de sécurité et les critères permettant de considérer une version comme terminée. Une bonne rédaction distingue donc les besoins métier, les comportements attendus et les choix de mise en œuvre.
Le cahier des charges peut évoluer. Chaque modification importante doit toutefois être datée, expliquée et reliée à ses conséquences éventuelles sur le périmètre, les interfaces, les données, les tests ou le calendrier. Cette discipline évite qu’une demande ajoutée en cours de projet soit traitée comme un détail alors qu’elle modifie l’architecture de l’application.
Commencer par le contexte et les objectifs du produit
La première rubrique présente le contexte dans lequel l’application sera utilisée. Elle répond à plusieurs questions : quel problème est rencontré aujourd’hui, par quels utilisateurs, dans quelles situations et avec quelles limites des solutions existantes ? Cette partie doit rester concrète. Une formulation comme « moderniser l’expérience » donne peu d’indications, tandis que « permettre la consultation d’un dossier depuis un téléphone, y compris lorsque la connexion est instable » décrit un besoin vérifiable.
Les objectifs doivent être séparés des moyens. Une application mobile n’est pas un objectif en soi. Elle peut servir à consulter une information, saisir une demande, suivre une opération, communiquer, piloter un équipement ou accéder à un service. Pour chaque objectif, indiquez la valeur attendue et la manière dont elle pourra être évaluée, sans annoncer de résultat garanti.
Cette section peut contenir :
- le contexte du projet et son origine ;
- les problèmes prioritaires à traiter ;
- les utilisateurs visés et leurs contraintes ;
- les objectifs fonctionnels et opérationnels ;
- les fonctionnalités explicitement exclues du premier périmètre.
La dernière rubrique est souvent négligée. Elle protège le projet contre l’extension progressive du périmètre et aide à distinguer une première version cohérente d’une feuille de route plus large.
Décrire les utilisateurs avec des profils concrets
Le cahier des charges doit identifier les catégories d’utilisateurs sans se limiter à une description démographique. Il faut préciser leur niveau de familiarité avec le numérique, leur contexte d’utilisation, leurs contraintes de temps, leur équipement probable et les informations auxquelles ils sont autorisés à accéder.
Les profils peuvent être complétés par des scénarios d’usage. Un scénario décrit une situation et un objectif, par exemple : « une personne reçoit une notification, ouvre l’application, consulte le détail d’une demande et répond depuis un réseau mobile ». Il ne s’agit pas d’un roman, mais d’un moyen de faire apparaître les étapes, les états intermédiaires et les exceptions.
Précisez aussi les rôles et les droits. Un utilisateur qui consulte des informations n’a pas nécessairement les mêmes autorisations qu’un opérateur qui les modifie. Si une interface d’administration est prévue, indiquez qui l’utilise, depuis quel type d’appareil et avec quelles restrictions. Une matrice des permissions peut être utile pour éviter les formulations ambiguës comme « accès complet ».
Délimiter le périmètre fonctionnel et les priorités
La liste des fonctionnalités constitue le cœur du document, mais une liste de noms ne suffit pas. Pour chaque fonction, décrivez le déclencheur, les données affichées ou saisies, le résultat attendu, les cas d’erreur et les règles de gestion associées.
Une fiche fonctionnelle peut suivre cette structure :
- nom de la fonctionnalité ;
- objectif utilisateur ;
- préconditions nécessaires ;
- déroulement nominal étape par étape ;
- comportements en cas d’erreur ou d’interruption ;
- données créées, consultées, modifiées ou supprimées ;
- règles d’accès et de validation ;
- critères d’acceptation.
Les priorités doivent être explicites. Vous pouvez distinguer les fonctions indispensables au lancement, celles qui améliorent la version initiale et celles qui relèvent d’une évolution ultérieure. Une méthode de priorisation n’a de valeur que si les catégories sont définies dans le document. Évitez de qualifier toutes les fonctions de « prioritaires », car cette pratique empêche les arbitrages.
Les critères d’acceptation rendent une demande testable. Au lieu d’écrire « la connexion doit être rapide », précisez le comportement attendu pendant le chargement, le message à afficher en cas d’échec, la possibilité de réessayer et la situation dans laquelle une session est considérée comme ouverte.
Préciser les écrans, la navigation et les états d’interface
Une application ne se résume pas à ses écrans principaux. Le cahier des charges doit aussi prévoir les états vides, les chargements, les erreurs, les confirmations, les permissions refusées, l’absence de réseau, l’expiration d’une session et les actions irréversibles.
Un schéma de navigation peut représenter les liens entre les écrans et les conditions d’accès. Il permet de repérer les impasses, les retours incohérents et les parcours trop longs. Pour chaque écran, indiquez les éléments visibles, les actions possibles, les informations obligatoires et les changements attendus après une action.
Les maquettes sont utiles, mais elles ne remplacent pas les règles fonctionnelles. Une image peut montrer un bouton sans préciser ce qui se passe après une pression répétée, lorsque le formulaire est incomplet ou lorsque le serveur ne répond pas. Associez donc chaque maquette à une description textuelle des comportements.
L’accessibilité doit être prévue dès cette étape. La taille des zones tactiles, le contraste, la lisibilité, la navigation au lecteur d’écran, les alternatives aux informations visuelles et la compréhension des messages d’erreur doivent figurer parmi les exigences. Les recommandations WCAG du W3C peuvent servir de cadre pour structurer cette analyse, en tenant compte des particularités des interfaces mobiles.
Définir les plateformes, les appareils et les contraintes techniques
Le document doit indiquer les systèmes mobiles ciblés, les versions minimales acceptées, les formats d’écran à prendre en compte et la stratégie de distribution. Une application native, une application multiplateforme ou une application web mobile ne répondent pas aux mêmes contraintes de maintenance, de performance et d’accès aux fonctions de l’appareil.
Ne choisissez pas une technologie uniquement parce qu’elle est connue. La décision doit découler des besoins : usage de la caméra, fonctionnement en arrière-plan, notifications, Bluetooth, géolocalisation, stockage local, contraintes de performance ou besoin de partager une base de code. Si la compatibilité avec certains appareils n’est pas prévue, indiquez-le clairement.
Précisez les exigences relatives à la connexion : fonctionnement hors ligne, synchronisation différée, reprise après interruption, gestion des doublons et résolution des conflits. Un formulaire rempli sans réseau doit-il être conservé localement ? Comment l’utilisateur sait-il que les données ont été transmises ? Ces réponses influencent fortement l’architecture.
La rubrique technique peut également décrire les environnements distincts pour le développement, la recette et la production, les modalités de configuration, les journaux techniques, les sauvegardes et les conditions de supervision. Il est préférable de demander un comportement observable plutôt qu’une technologie imposée sans justification.
Documenter les données et les intégrations
Pour chaque donnée, indiquez son origine, son format, son usage, sa durée de conservation, les personnes ou systèmes autorisés à la consulter et les opérations possibles. Cette cartographie concerne les données saisies par l’utilisateur, importées depuis un service tiers, produites par l’application ou enregistrées dans les journaux.
Les intégrations doivent être décrites avec précision : service concerné, type d’échange, fréquence, authentification, structure des réponses, gestion des erreurs, limites connues et comportement lorsque le service est indisponible. Si une interface de programmation applicative est utilisée, précisez les contrats attendus sans inventer de caractéristiques qui devront être confirmées ultérieurement.
La protection des données doit être intégrée dès la conception. Le RGPD, contrôlé en France par la CNIL, impose notamment de réfléchir à la finalité des traitements, à la minimisation des données, à l’information des personnes, à la durée de conservation et à l’exercice des droits. La rédaction du cahier des charges doit associer les exigences fonctionnelles aux exigences de confidentialité : suppression d’un compte, export des données, retrait d’un consentement ou limitation d’un traitement doivent être traduits en parcours concrets.
N’inscrivez jamais dans le document des données sensibles dont l’application n’a pas besoin. Chaque champ demandé augmente la surface de risque, les obligations de protection et la complexité des tests.
Inclure la sécurité dans les exigences dès le départ
La sécurité ne doit pas apparaître dans une annexe ajoutée à la fin du projet. Le cahier des charges doit préciser les mécanismes d’authentification, la gestion des sessions, la récupération de compte, les rôles, les autorisations et les traces nécessaires pour détecter des comportements anormaux.
Les exigences peuvent notamment porter sur :
- la transmission chiffrée des échanges ;
- la protection des secrets et des clés d’accès ;
- la limitation des tentatives de connexion ;
- la validation des données côté serveur, même si l’application réalise aussi des contrôles locaux ;
- la protection des données stockées sur l’appareil ;
- la révocation d’une session ou d’un appareil perdu ;
- la séparation des environnements de test et de production ;
- la journalisation sans exposer de données personnelles ou de secrets.
Les recommandations de l’ANSSI et les référentiels de sécurité applicative peuvent aider à compléter cette rubrique. Le document doit aussi préciser qui reçoit les alertes, qui traite une vulnérabilité et comment une correction est vérifiée. Une exigence de sécurité utile décrit un résultat contrôlable, par exemple l’impossibilité pour un rôle donné d’accéder à une ressource qui ne lui est pas destinée.
Prévoir les performances, la maintenance et l’exploitation
Une application peut fonctionner lors d’une démonstration et devenir problématique dans des conditions réelles. Le cahier des charges doit donc décrire les situations à prendre en compte : réseau mobile lent, appareil peu puissant, stockage presque saturé, batterie faible, retour depuis une autre application ou interruption pendant une opération.
Les exigences de performance doivent être formulées avec un contexte de mesure. La durée d’affichage dépend du réseau, du volume de données, du serveur et de l’appareil. Demandez plutôt une méthode de test, un volume représentatif et un comportement attendu lorsque le délai augmente. L’application doit informer l’utilisateur, éviter les doubles actions et conserver les données lorsque le parcours le prévoit.
La maintenance mérite une rubrique dédiée. Elle peut couvrir les mises à jour du système mobile, la compatibilité avec de nouvelles versions, la correction des anomalies, la gestion des certificats, le renouvellement des dépendances et la publication de versions correctives. Précisez également les livrables attendus : code source, documentation d’installation, schémas de données, procédures de déploiement, comptes techniques transférables et rapports de tests.
Sans cette anticipation, la livraison d’une application peut laisser une équipe sans moyens suffisants pour comprendre, surveiller ou faire évoluer le produit.
Construire une stratégie de tests et de recette
La recette vérifie que l’application répond au cahier des charges. Elle doit couvrir les parcours nominaux, mais aussi les situations qui provoquent des erreurs. Préparez une liste de cas de test à partir des fonctionnalités et des critères d’acceptation, puis ajoutez des tests de compatibilité, d’accessibilité, de sécurité, de reprise après interruption et de fonctionnement avec une connexion dégradée.
Un cas de test doit préciser les préconditions, les données utilisées, les actions, le résultat attendu et le résultat observé. Les anomalies doivent être classées selon leur impact et accompagnées d’éléments permettant leur reproduction, sans diffuser de données personnelles inutiles.
La validation peut être organisée par étapes :
- vérification des fonctions isolées ;
- vérification des échanges entre composants ;
- tests sur les parcours complets ;
- contrôles de compatibilité sur les appareils retenus ;
- recette fonctionnelle avec des données représentatives ;
- validation de la version destinée à la distribution.
Le cahier des charges doit préciser qui valide, dans quel environnement et selon quelle procédure une anomalie est acceptée, corrigée ou reportée. Cette règle évite qu’une livraison soit déclarée conforme sur la base d’une impression générale.
Les erreurs fréquentes à éviter
Plusieurs défauts reviennent dans les cahiers des charges d’applications mobiles. Le premier consiste à partir d’une solution technique avant d’avoir décrit le besoin. Le choix d’un langage, d’un framework ou d’un service ne remplace pas l’analyse des usages.
Une autre erreur consiste à employer des termes vagues : « intuitif », « moderne », « sécurisé », « rapide » ou « ergonomique ». Ces mots peuvent rester dans une intention éditoriale, mais ils doivent être traduits en comportements et en critères de vérification.
Évitez également :
- la liste de fonctionnalités sans règles métier ni cas d’erreur ;
- l’oubli des utilisateurs administrateurs et des droits associés ;
- la prise en compte tardive de l’accessibilité et de la protection des données ;
- l’absence de fonctionnement défini en cas de perte de réseau ;
- des maquettes présentées comme une spécification complète ;
- des délais annoncés sans dépendances ni hypothèses explicites ;
- l’absence de critères de réception ;
- la demande de toutes les plateformes et de tous les appareils sans priorisation ;
- la conservation de données dont la finalité n’est pas documentée ;
- un document impossible à versionner ou dont les modifications ne sont pas tracées.
Un cahier des charges trop long n’est pas forcément plus précis. La qualité dépend de la cohérence entre les rubriques, du niveau de détail adapté aux risques et de la capacité à vérifier chaque exigence.
Tableau récapitulatif des rubriques indispensables
| Rubrique | Questions à traiter | Livrables ou preuves utiles |
|---|
| Contexte et objectifs | Quel problème est traité et pourquoi ? | Objectifs, périmètre, exclusions |
| Utilisateurs | Qui utilise l’application, avec quels droits et contraintes ? | Profils, rôles, scénarios |
| Fonctionnalités | Que doit faire l’application dans chaque situation ? | Fiches fonctionnelles, critères d’acceptation |
| Interface et navigation | Quels écrans, actions, erreurs et états sont prévus ? | Parcours, maquettes annotées |
| Technique | Quelles plateformes, connexions et intégrations sont nécessaires ? | Architecture cible, contrats d’échange |
| Données et conformité | Quelles données sont traitées et pendant combien de temps ? | Cartographie, règles de conservation |
| Sécurité | Comment protéger les comptes, les échanges et les ressources ? | Règles d’accès, procédures d’alerte |
| Tests et maintenance | Comment valider et maintenir l’application ? | Plan de test, documentation, procédure de livraison |
Méthode de relecture avant validation
Avant de transmettre le document à une équipe technique, relisez-le avec plusieurs angles. Une première lecture vérifie la cohérence du parcours utilisateur. Une deuxième recherche les ambiguïtés, les termes non définis et les fonctionnalités qui n’ont pas de critère d’acceptation. Une troisième se concentre sur la sécurité, les données personnelles et les droits d’accès.
Pour chaque exigence, posez quatre questions : est-elle nécessaire, compréhensible, testable et compatible avec les autres exigences ? Vérifiez aussi que les écrans, les scénarios, les données et les tests décrivent le même comportement. Une incohérence entre une maquette et une règle métier doit être résolue avant le développement.
Enfin, identifiez les hypothèses qui restent à confirmer : disponibilité d’une interface externe, contraintes de distribution, compatibilité d’un appareil, validation juridique ou capacité d’un système existant. Une hypothèse explicitement listée peut être vérifiée. Une hypothèse silencieuse devient souvent une source de reprise coûteuse.
Le cahier des charges est prêt lorsque les personnes concernées partagent la même compréhension du produit, de ses limites et des conditions de validation. Il doit ensuite rester vivant, avec un historique des versions et une justification des changements importants.
FAQ
Quelle longueur prévoir pour un cahier des charges mobile ?
La longueur dépend de la complexité du projet, du nombre de rôles, des intégrations et du niveau de risque. Un document court mais précis vaut mieux qu’un texte volumineux rempli de généralités. Chaque fonctionnalité importante doit toutefois comporter son comportement nominal, ses exceptions et ses critères d’acceptation.
Faut-il choisir la technologie dans le cahier des charges ?
Le document peut exprimer des contraintes techniques et demander une proposition d’architecture. Une technologie précise peut être imposée lorsqu’elle répond à une contrainte existante, mais elle ne doit pas remplacer la description du besoin. Les choix techniques doivent être justifiés par les usages, la sécurité, la maintenance et la compatibilité recherchée.
Les maquettes remplacent-elles les spécifications fonctionnelles ?
Non. Elles illustrent l’interface et les parcours, mais elles ne décrivent pas toujours les règles d’accès, les erreurs, les données, les interruptions ou les états de chargement. Chaque maquette importante doit être accompagnée d’annotations et reliée aux exigences correspondantes.
Quand intégrer la sécurité et la conformité ?
Ces sujets doivent être traités dès la définition du périmètre. Les décisions prises sur les comptes, les données, les permissions, les journaux et les intégrations influencent l’architecture. Une vérification tardive peut conduire à modifier des écrans ou des traitements déjà développés.
Comment savoir si une exigence est suffisamment précise ?
Demandez à une personne qui n’a pas rédigé le document de décrire le comportement attendu à partir de cette exigence. Si plusieurs interprétations sont possibles ou si aucun test ne permet de conclure, la formulation doit être complétée par des préconditions, des règles, des exceptions et un résultat observable.
