Modèle de cahier des charges pour une application mobile

Un cahier des charges application mobile doit préciser ce que la personne pourra accomplir avec son téléphone, y compris lorsque les conditions se dégradent : connexion perdue, permission refusée, interruption ou données en attente. Décrire les écrans ne suffit pas. Le document doit relier chaque usage à une règle de fonctionnement, à un livrable et à une preuve de validation.

Ce modèle original Anaska, rassemble des rubriques à compléter dans votre propre document. Les contrôles proposés sont des recommandations de la rédaction. Tous les scénarios présentés sont des exemples pédagogiques, sans référence à un projet client. Pour chaque rubrique, distinguez les décisions prises, les hypothèses à vérifier et les exclusions.

1. Définir le service mobile et sa première version

Commencez par une action concrète plutôt que par une ambition générale. Indiquez qui utilisera l’application, dans quel environnement et avec quelle difficulté actuelle. Expliquez pourquoi l’usage envisagé nécessite une application mobile : consultation en déplacement, capture sur le terrain ou accès à des informations déjà enregistrées. Cette justification doit permettre de discuter le périmètre sans transformer chaque possibilité du téléphone en fonctionnalité.

Trame à compléter : nom du service ; responsable des arbitrages ; utilisateurs concernés ; situation de départ ; action principale ; bénéfice attendu ; fonctionnalités incluses ; fonctionnalités différées ; exclusions explicites. Ajoutez une version du document et un registre des décisions. Une idée reportée doit rester identifiable, avec la raison du report et sa dépendance éventuelle.

Exemple pédagogique : une application de carnet de visite permet de préparer une intervention, de rédiger une observation et de retrouver son état de transmission. Le partage public des observations reste exclu. Cette distinction évite de confondre collecte personnelle et publication.

Validation recommandée : demandez au responsable du service de reformuler le parcours principal et ses limites. Le livrable attendu est une fiche de cadrage approuvée. Si plusieurs personnes décrivent des services différents, poursuivez l’arbitrage avant de détailler les écrans. Évitez notamment une première version définie uniquement par une liste de menus.

2. Choisir les appareils et les systèmes ciblés

Inscrivez séparément les plateformes envisagées, les versions de système retenues et les catégories d’appareils à couvrir. Ne laissez pas « compatible mobile » tenir lieu de décision. Précisez si les tablettes, les appareils pliables, l’orientation paysage et les changements de taille de fenêtre font partie du périmètre. Pour chaque exclusion, indiquez ce que l’équipe devra communiquer à l’utilisateur.

Le guide d’architecture Android, mis à jour le 5 octobre 2026, rappelle que les changements de configuration peuvent affecter l’état de l’interface et que le système peut arrêter le processus d’une application pour récupérer des ressources. Ces caractéristiques Android justifient de décrire précisément les états à restaurer, sans présumer un comportement identique sur toutes les plateformes.

Trame à compléter : plateforme ; versions ciblées ; formats couverts ; orientations prévues ; fonctions matérielles nécessaires ; appareils disponibles pour la recette ; limites connues. Demandez une justification technique du choix d’architecture, liée à ces contraintes et aux compétences nécessaires pour entretenir le produit.

Validation recommandée : préparez une matrice de couverture et associez chaque configuration à un essai réel. Dans un exemple pédagogique, une observation commencée doit retrouver son texte après une rotation lorsque cette orientation est couverte. Le livrable est la matrice approuvée, accompagnée des comportements de restauration attendus. Évitez de promettre une couverture universelle sans liste vérifiable.

3. Décrire les parcours et les interruptions

Pour chaque parcours, indiquez le point d’entrée, l’état initial, les actions possibles et le résultat attendu. Ajoutez les sorties intermédiaires : retour à l’écran précédent, fermeture volontaire, ouverture d’un autre contenu ou reprise après authentification. Le téléphone ne doit pas être traité comme une session continue durant laquelle rien ne vient interrompre la personne.

Trame à compléter pour une exigence : identifiant ; profil autorisé ; déclencheur ; conditions préalables ; action ; résultat visible ; donnée modifiée ; comportement en cas d’interruption ; critère d’acceptation. Séparez les règles du service des choix graphiques. Une maquette montre une disposition ; elle n’explique pas à elle seule quand une observation devient définitive.

Exemple pédagogique : la personne commence une note, quitte temporairement l’application puis revient. Le cahier des charges précise si elle retrouve un brouillon, si elle doit s’identifier et si son texte reste disponible pendant cette identification. La reprise devient ainsi un comportement à vérifier.

Validation recommandée : faites relire les parcours par une personne qui n’a pas participé à leur rédaction. Elle doit pouvoir identifier ce qui est conservé, perdu ou confirmé à chaque étape. Le livrable est un ensemble de fiches de parcours reliées aux exigences. Évitez les formulations « retour normal » ou « sauvegarde automatique » sans préciser le moment et la portée de la sauvegarde.

4. Prévoir les permissions et les solutions de remplacement

Recensez les accès envisagés aux fonctions du téléphone. Pour chacun, décrivez le besoin utilisateur avant de nommer une permission technique. Une photographie peut être utile à une observation sans devenir obligatoire pour toute utilisation du carnet. Demandez à l’équipe de préciser les mécanismes applicables aux plateformes et versions retenues ; ce modèle ne présume pas leurs règles.

Trame à compléter : fonction demandée ; justification ; moment de la demande ; explication présentée ; comportement après refus ; parcours après changement du réglage ; données conservées. Le tableau suivant propose des décisions pédagogiques à adapter, et non des caractéristiques communes à tous les systèmes.

Validation recommandée : livrez un inventaire des accès et les textes associés. Testez un refus, puis une modification du choix avant la reprise du parcours. Évitez les demandes groupées sans lien avec l’action en cours. Si aucune solution de remplacement n’est possible, expliquez précisément quelle fonction devient indisponible et faites approuver cette limite.

5. Définir les usages avec une connexion instable ou absente

Décidez du fonctionnement hors ligne action par action. Lire une information enregistrée, modifier un brouillon et obtenir une confirmation distante sont des opérations différentes. Pour chacune, renseignez les données nécessaires, leur disponibilité locale et le message affiché lorsque leur fraîcheur ne peut pas être vérifiée. Une mention générale « mode hors ligne » laisse ces décisions ouvertes.

Trame à compléter : action ; préchargement nécessaire ; lecture autorisée ; écriture autorisée ; état visible sans réseau ; condition de reprise ; possibilité d’annulation ; conséquence d’un échec. Décrivez aussi le cas où l’utilisateur n’a jamais chargé les informations. Un écran vide doit expliquer cette situation sans laisser croire que le service ne contient rien.

Exemple pédagogique : une observation rédigée sans connexion reste un brouillon local. Après une demande d’envoi, elle devient « en attente de transmission ». Elle ne passe à l’état « reçue » qu’après la confirmation définie avec le service distant. La personne peut distinguer rédaction terminée et transmission terminée.

Validation recommandée : fournissez une matrice des capacités hors ligne et des messages d’état. Coupez la connexion avant, pendant et après l’action testée, puis vérifiez la reprise. Évitez de présenter une action comme réussie au seul motif qu’elle a été enregistrée sur le téléphone. Définissez qui tranche lorsqu’une fonction doit rester exclusivement connectée.

6. Organiser le stockage et la synchronisation

Établissez un inventaire des données présentes sur le téléphone et dans les services distants. Identifiez le système qui fait référence pour chaque objet, ainsi que les personnes autorisées à le modifier. Précisez les conditions de suppression locale, de déconnexion et de changement de compte. Un brouillon appartenant à une personne ne doit pas devenir implicitement visible dans une autre session.

Trame à compléter : donnée ; emplacement ; propriétaire fonctionnel ; état de synchronisation ; règle de conflit ; règle de nettoyage ; traitement après mise à jour. Définissez également comment reconnaître une transmission déjà reçue lorsque la confirmation n’a pas atteint le téléphone. L’objectif rédactionnel est de rendre la décision explicite, sans imposer un mécanisme technique particulier.

Validation recommandée : le livrable associe dictionnaire des données et règles de synchronisation. Rejouez les conflits avec des contenus pédagogiques distincts. Évitez une règle globale donnant toujours priorité à la dernière modification sans examiner les pertes possibles.

7. Encadrer les notifications et leurs destinations

Rédigez une fiche pour chaque notification envisagée. Indiquez l’événement déclencheur, le destinataire, l’information utile et la destination à l’ouverture. Distinguez le message de rappel de l’état réel du dossier : l’application doit pouvoir présenter une information actualisée lorsque la personne consulte le contenu concerné.

Trame à compléter : nom du message ; événement ; condition d’éligibilité ; contenu ; préférence utilisateur ; destination ; comportement sans session ; traitement d’un contenu supprimé ; information accessible sans notification. Demandez une décision sur les détails visibles dans le message, notamment lorsque le téléphone peut être consulté par une autre personne.

Exemple pédagogique : un rappel invite à terminer une observation. Si celle-ci a déjà été transmise, l’ouverture mène à son état actuel et explique qu’aucune action supplémentaire n’est nécessaire. Si la personne est déconnectée, le parcours précise comment retrouver la destination après identification.

Validation recommandée : préparez un catalogue des messages et une carte des destinations. Testez les préférences désactivées, les contenus devenus indisponibles et l’ouverture depuis une application fermée. Évitez de faire dépendre une information essentielle de la seule réception d’une notification. Les modalités techniques d’émission et de réception restent à faire préciser pour les plateformes retenues, sans transformer leur livraison en résultat garanti.

8. Formaliser la sécurité et l’accessibilité des usages

Décrivez les informations à protéger et les actions réservées à certains profils. Demandez une proposition sur les sessions, le stockage local, les échanges et les journaux techniques. Pour chaque contrôle retenu, indiquez une preuve attendue et la personne chargée de l’examiner. Une rubrique « application sécurisée » ne permet pas de décider si la livraison est acceptable.

Le référentiel OWASP MASVS distingue notamment des contrôles sur le stockage, l’authentification, les communications réseau, les interactions avec la plateforme et la confidentialité. La rédaction recommande de sélectionner les contrôles adaptés au périmètre et de documenter leur vérification. Mentionner ce référentiel ne constitue pas une certification.

Pour l’accessibilité, décrivez les parcours à essayer avec les aides techniques retenues, les textes agrandis et les modes d’interaction pertinents. Les WCAG 2.2, recommandation du W3C du 12 décembre 2024, définissent des critères testables pour le contenu web, y compris sur mobile. Pour une interface native, faites expliciter la correspondance choisie et les limites de l’évaluation.

Trame et validation recommandées : risque ou obstacle ; parcours concerné ; contrôle choisi ; méthode ; preuve ; réserve éventuelle. Le livrable est un plan de vérification. Évitez de déduire la conformité de l’ensemble du produit d’un contrôle isolé ou d’un outil automatique.

9. Préparer une recette sur des appareils réels

Reliez chaque exigence prioritaire à un scénario reproductible. Indiquez l’appareil, la version du système, la version de l’application, les données initiales et les conditions réseau. Décrivez ensuite l’action, le résultat attendu et la preuve à conserver. Cette précision aide à distinguer une anomalie du produit d’une différence de configuration ou de données.

Trame à compléter : exigence ; préparation ; matériel ; état des permissions ; état de session ; manipulation ; résultat ; observation ; décision. Prévoyez des essais sur appareils réels pour les comportements dépendant du téléphone. Demandez à l’équipe d’identifier les vérifications complémentaires réalisées dans d’autres environnements, avec leurs limites.

Exemple pédagogique : rédiger une observation, interrompre l’application, reprendre hors ligne puis transmettre après reconnexion. Vérifiez le texte conservé, les états affichés et l’absence de transmission supplémentaire. Pour les attentes de rapidité, définissez d’abord l’opération et le protocole de mesure ; la cible reste à convenir selon le contexte retenu.

Validation recommandée : le dossier de recette rassemble résultats, preuves, anomalies et réserves acceptées. Définissez qui peut accepter une réserve et quelle nouvelle vérification permettra de la lever. Évitez une validation fondée uniquement sur une démonstration guidée, sans rejouer les refus de permission, interruptions et reprises qui structurent l’usage mobile.

10. Préparer la distribution et la remise des livrables

Choisissez le mode de distribution envisagé et identifiez les comptes, accès et responsabilités nécessaires à sa préparation. Faites préciser par l’équipe les conditions applicables au canal retenu avant de les intégrer au document. Distinguez une version prête à soumettre, une soumission effectuée et une version effectivement accessible aux utilisateurs visés.

Trame à compléter : canal ; responsable du compte ; personne préparant la version ; personne validant les contenus ; accès nécessaires ; environnement associé ; procédure d’installation ; procédure de mise à jour ; traitement d’un blocage de diffusion. N’inscrivez pas une disponibilité garantie à partir du seul achèvement du développement.

Listez les livrables de reprise : code source, maquettes retenues, documentation des connexions, configuration des environnements, procédure de compilation, inventaire des dépendances et dossier de recette. Prévoyez une remise sécurisée des accès nécessaires, sans recopier de secrets dans le cahier des charges. Identifiez aussi les éléments qui restent dépendants d’un service tiers.

Validation recommandée : demandez une démonstration de compilation et d’installation à partir des éléments remis. Le livrable est un dossier de distribution et de reprise, avec les responsabilités associées. Évitez de confondre remise d’un fichier installable et capacité à maintenir l’application. Toute étape non exécutée doit être décrite comme telle, avec son responsable et sa condition d’achèvement.

11. Organiser la maintenance et les arbitrages futurs

Définissez comment un incident sera décrit, reçu et qualifié. Les informations utiles peuvent comprendre la version de l’application, l’appareil, le système, le parcours et l’état de connexion. Demandez de préciser les données de diagnostic réellement nécessaires et leur accès. Évitez de collecter le contenu des observations par défaut pour expliquer une erreur technique.

Trame à compléter : responsable du suivi ; canal de signalement ; critères de priorité ; périmètre de correction ; dépendances surveillées ; validation d’une mise à jour ; procédure de reprise après échec. Distinguez correction, adaptation à un environnement et nouvelle fonctionnalité. Pour chaque changement demandé, relevez les effets sur les données locales, les permissions, la synchronisation et la recette.

Prévoyez un scénario de mise à jour avec des données déjà présentes. Dans un exemple pédagogique, une observation en attente doit conserver un statut compréhensible après installation de la nouvelle version. Si une reprise automatique ne peut pas être assurée, le document doit préciser le traitement proposé et la décision attendue avant diffusion.

Validation recommandée : livrez un registre des versions et des décisions de maintenance. Avant de transmettre votre cadrage, vérifiez que chaque inconnue possède un responsable et que chaque fonction prioritaire possède une preuve attendue. Vous pouvez ensuite déposer votre projet avec ces arbitrages, ses limites et les questions restant à résoudre.