Cahier des charges : application mobile et web, sans angle mort.

Un cahier des charges application utile ne débute pas par une galerie d’écrans. Il commence par une scène de travail précise. Une responsable reçoit-elle des demandes par plusieurs canaux ? Un technicien ressaisit-il une intervention une fois revenu au bureau ? Un client doit-il appeler pour connaître l’état d’un dossier ? Décrivez ce qui se passe aujourd’hui, le moment où cela bloque et la conséquence concrète : attente, erreur, absence de trace ou information indisponible.

Cette première partie doit nommer les utilisateurs sans les réduire à une catégorie vague. Un administrateur ne travaille pas comme un agent de terrain, un responsable d’équipe ou un client externe. Pour chaque profil, indiquez son environnement, ses droits, le matériel employé et ce qui lui arrive quand le réseau est absent. Une application destinée à une tablette partagée dans un entrepôt ne se conçoit pas comme un portail ouvert depuis un ordinateur personnel.

• Le déclencheur : un événement qui crée le besoin, tel qu’une demande, une visite, une alerte ou une échéance.
• Le geste actuel : les fichiers consultés, les personnes sollicitées et les doubles saisies réalisées.
• Le point de friction : une décision lente, une donnée introuvable, une erreur répétée ou un suivi impossible.
• Le résultat attendu : un dossier complet, une réponse vérifiée, une action tracée ou une information accessible.

Ajoutez quelques exemples réels et anonymisés : une demande complète, une demande incomplète et un cas exceptionnel. Ils aideront l’équipe qui conçoit une application mobile à mesurer la variété du flux. Nous déconseillons de commander une application lorsque le processus reste contesté entre les équipes. Dans ce cas, un atelier de cadrage permet d’abord de fixer la règle métier qui manque.

La liste « connexion, tableau de bord, notifications » ne dit presque rien de l’effort nécessaire. Un cahier des charges application web devient exploitable lorsqu’il raconte des parcours complets. Prenez une personne, un point de départ, les informations disponibles, l’action attendue et l’état final. Par exemple, un demandeur crée un dossier, joint un document, reçoit une confirmation, puis son responsable valide ou renvoie le dossier en expliquant ce qui manque.

Pour chaque parcours, précisez les règles qui changent le comportement. Une demande peut-elle être enregistrée sans pièce jointe ? Qui peut modifier une validation après coup ? Une notification est-elle immédiate, groupée ou désactivable ? Ces détails évitent les réponses coûteuses découvertes pendant la recette. Ils révèlent aussi les exceptions, souvent plus importantes que le chemin idéal : doublon, erreur de saisie, changement de responsable, document illisible ou utilisateur sans droit.

1. Indispensable au lancement : la fonction sans laquelle le parcours principal ne rend pas le service promis.
2. Utile après validation : une amélioration qui peut attendre les premiers retours d’usage.
3. À instruire : une idée dont la valeur, la règle ou la faisabilité doit être vérifiée par une maquette.

Cette séparation est une décision de budget autant que de produit. Elle protège le premier périmètre des demandes ajoutées pendant la réalisation. Demandez au prestataire de signaler les fonctions dépendantes d’une application web, d’un service tiers ou d’une donnée non encore disponible. Une fonction peut paraître petite dans l’interface et pourtant demander une intégration longue ou une règle de contrôle approfondie.

Terminez chaque parcours par une phrase testable. « L’application est intuitive » devient « un nouvel utilisateur retrouve une intervention assignée, ajoute une photo et la soumet sans consulter de guide ». Cette formulation donne au métier un moyen de relire la conception et à l’équipe technique un critère qui ne dépend pas d’une impression.

Les écrans visibles ne représentent qu’une partie d’une application. Les données, les permissions et les connexions aux logiciels existants déterminent souvent le calendrier réel. Dressez une liste des sources que le futur outil doit consulter ou mettre à jour : CRM, ERP, annuaire, agenda, gestion documentaire, outil de paiement ou base métier. Pour chacune, indiquez le propriétaire interne, le type d’accès envisagé et l’existence d’un environnement de test.

Ne supposez pas qu’un logiciel « se connecte facilement » parce qu’il est déjà utilisé dans l’entreprise. L’équipe doit savoir si une API existe, si les droits sont administrés par un tiers, si des limites de volume s’appliquent et si un export manuel constitue le seul échange possible. Un fournisseur peut alors chiffrer une hypothèse claire au lieu de cacher cette dépendance dans une ligne générique.

• Listez les informations créées, lues, modifiées, archivées ou supprimées par chaque profil.
• Indiquez les données personnelles, confidentielles ou soumises à une conservation particulière.
• Décrivez les rôles : consultation, contribution, validation, administration et accès de support.
• Précisez les actions qui doivent laisser une trace : changement de statut, export, suppression ou décision.

Si une fonction d’IA est envisagée, ajoutez les documents qu’elle peut utiliser, les personnes autorisées à vérifier sa sortie et les actions qui restent interdites sans validation humaine. Le même inventaire sert à discuter du contrat de sous-traitance, de l’hébergement et de la journalisation. Les enjeux d’accès et de localisation des données peuvent être approfondis avec notre page sécurité et souveraineté.

Prévenez aussi les dépendances internes : personne capable d’ouvrir les accès, équipe qui fournit les jeux de données, responsable qui valide les règles de conservation. Une intégration sans interlocuteur identifié est un risque de projet, même si le connecteur semble techniquement simple.

Une application mobile répond à des contraintes que le navigateur de bureau ne rencontre pas toujours : main occupée, appareil photo, déplacement, batterie faible, réseau intermittent ou usage sur un appareil partagé. Un cahier des charges application mobile doit dire quels usages justifient ce support. Un technicien peut-il travailler hors connexion ? Une photo doit-elle être compressée avant envoi ? L’application doit-elle empêcher l’accès si le téléphone est perdu ? Ces réponses influencent l’architecture et les tests à prévoir.

Pour une application web, documentez les postes réellement employés, les navigateurs à prendre en charge, les résolutions fréquentes et les contraintes d’accessibilité. Un tableau dense qui convient à un contrôleur sur grand écran devient illisible sur une tablette. À l’inverse, une interface de saisie rapide sur mobile ne suffit pas à administrer les comptes ou corriger une importation. Les deux supports peuvent partager des données tout en proposant des expériences différentes.

• Joignez des croquis annotés plutôt qu’une maquette qui prétend résoudre tous les détails.
• Fournissez des exemples de contenus longs, vides, erronés ou multilingues.
• Définissez les langues de l’interface, les formats de date et les règles de notification.
• Indiquez si la diffusion passe par les stores, un accès navigateur ou une distribution interne.

Les captures d’un outil actuel sont précieuses si elles sont accompagnées d’une explication : ce qui doit être conservé, ce qui pose problème et ce qui n’est qu’une habitude. Demandez à l’équipe de distinguer l’interface, la logique métier et les données affichées. Cela évite de reproduire un ancien écran alors que la bonne réponse consiste à simplifier le parcours.

Prévoyez un environnement de démonstration et un environnement de recette distincts de la production. Les utilisateurs peuvent ainsi manipuler des scénarios réalistes sans altérer des dossiers actifs. Cette précaution est particulièrement importante lorsque l’application échange avec un outil métier déjà utilisé quotidiennement.

La recette ne consiste pas à cliquer librement dans une version presque terminée. Elle vérifie, avec des cas prévus, que l’application répond aux règles convenues. Pour les fonctions importantes, rédigez un critère d’acceptation observable. Exemple : un demandeur autorisé dépose un document ; le responsable reçoit une alerte ; il accepte ou refuse avec un motif ; les deux personnes retrouvent l’historique. Ce scénario met au jour les droits, les notifications et la traçabilité sans vocabulaire abstrait.

Constituez un petit jeu de recette contenant des cas normaux, des données incomplètes et des cas limites. Désignez les personnes qui testent et celles qui prononcent l’acceptation. Une anomalie doit être décrite avec le contexte, l’action réalisée, le résultat attendu et le résultat observé. Sans cette discipline, une discussion de ressenti remplace la vérification du périmètre.

• Authentification : méthode de connexion, gestion des comptes et procédure de départ d’un collaborateur.
• Continuité : sauvegardes, restauration, surveillance et personne à prévenir en cas d’incident.
• Traçabilité : opérations à historiser, durée de conservation et accès aux journaux.
• Déploiement : ordre de déploiement, groupe pilote, formation nécessaire et retour arrière possible.

La mise en service demande aussi un propriétaire métier : il répond aux questions des utilisateurs, arbitre les demandes d’évolution et confirme que l’outil continue de servir le processus initial. La maintenance applicative couvre ensuite les corrections, les mises à jour techniques et les évolutions convenues. Elle ne peut pas être correctement estimée si le cahier des charges ne précise ni les responsabilités ni le niveau de disponibilité attendu.

Lorsqu’un flux traite des informations sensibles, faites relire les exigences par les personnes compétentes de votre organisation avant le démarrage. Un document de cadrage peut identifier le sujet ; il ne remplace pas une analyse juridique ou de sécurité adaptée au contexte.

Un devis n’est comparable que si les prestataires répondent au même besoin. Envoyez le même modèle cahier des charges, les mêmes exemples de parcours et la même liste de questions. Demandez une réponse structurée : périmètre couvert, éléments exclus, hypothèses, livrables, méthode de recette, dépendances à votre charge et conditions de maintenance. Une proposition moins chère peut omettre la migration des données, la publication sur les stores ou la reprise d’une erreur d’intégration.

Examinez la façon dont chaque équipe traite les inconnues. Une question bien posée est souvent plus utile qu’une certitude hâtive. Le prestataire devrait distinguer ce qui est confirmé, ce qui est estimé et ce qui nécessite une phase de conception. Vous pourrez alors choisir d’instruire un point avant de signer, de le sortir du lancement ou de le transformer en option explicitement chiffrée.

Le guide des prix d’une application mobile permet de préparer les questions budgétaires, mais il ne remplace pas la compréhension du périmètre. Vérifiez ce que chaque devis inclut réellement. Ne retenez pas une proposition qui refuse de documenter ses exclusions : elles deviennent souvent des décisions tardives, donc plus difficiles à arbitrer.

Gardez enfin une version datée du cahier des charges et consignez chaque décision qui le modifie. Cet historique évite que le mot « prévu » désigne deux périmètres différents selon l’interlocuteur.