Sommaire
- Commencer par le problème, avec un résultat observable
- Décrire les utilisateurs et les permissions
- Documenter le parcours normal et les exceptions
- Faire l’inventaire des données et des systèmes
- Donner une priorité à chaque besoin
- Écrire les critères d’acceptation avant le devis
- Prévoir les décisions et les livrables du cadrage
- Un gabarit à copier dans votre document
- Sources et méthode
Le cahier des charges d’une application sur mesure doit permettre à une équipe de comprendre le travail à accomplir, les données manipulées et la manière de vérifier la livraison. Il n’a pas besoin de figer chaque écran. Il doit surtout rendre visibles les décisions qui influencent le périmètre, le coût et le risque.
En bref
- Partez d’un processus réel et de ses exceptions, puis identifiez les utilisateurs.
- Décrivez les données, les droits et les connexions avant les détails visuels.
- Préparez des critères d’acceptation que les opérations pourront vérifier.
Commencer par le problème, avec un résultat observable
« Nous voulons un portail » décrit une forme de solution. « Nos clients téléphonent pour connaître l’état de leur commande parce que trois équipes possèdent chacune une partie de l’information » décrit un problème. La seconde formulation permet d’examiner plusieurs options : un portail, une intégration, un changement de processus ou une combinaison.
Consignez le parcours actuel, les personnes impliquées, le volume approximatif et les situations qui nécessitent une intervention. Distinguez ce que vous avez observé de ce que vous supposez. Si le temps perdu n’a jamais été mesuré, indiquez-le : une courte observation du travail peut être plus utile qu’une estimation précise en apparence.
Le résultat attendu pourrait être qu’un client voie un statut fiable, qu’un employé ne ressaisisse plus une commande ou qu’un responsable repère les dossiers bloqués. Écrivez aussi ce que le premier projet ne cherche pas à changer. Cette frontière protège le budget lorsque des idées utiles apparaissent pendant les ateliers.
Décrire les utilisateurs et les permissions
Une même fiche peut servir à plusieurs rôles sans donner les mêmes droits. Le client consulte son dossier; le représentant corrige une information commerciale; la comptabilité valide une condition de paiement. Énumérez qui peut voir, créer, modifier, approuver et exporter chaque catégorie d’information.
Incluez les remplacements et les départs. Qui récupère les dossiers d’un employé absent? Comment retire-t-on les accès? Un compte commun paraît pratique, mais rend les actions difficiles à attribuer. Le cahier des charges doit permettre à l’équipe technique de concevoir les droits à partir des responsabilités réelles.
OWASP souligne les risques d’autorisation dans les API. Pour votre cadrage, cela signifie qu’une personne autorisée à consulter une commande ne doit pas nécessairement accéder aux commandes de tous les clients. Exigez des scénarios de vérification des limites, et pas seulement une page de connexion.
Documenter le parcours normal et les exceptions
Pour chaque processus prioritaire, écrivez le déclencheur, les étapes, les entrées, les sorties et la personne qui confirme le résultat. Ajoutez au moins un exemple réussi et un exemple d’exception. Une commande complète peut être simple; une commande annulée après facturation révèle les décisions que l’application doit gérer.
TableauDocumenter le parcours normal et les exceptions · bloc partageable
| Formulation vague | Formulation exploitable | |
|---|---|---|
| Résultat | Simplifier les opérations | Afficher les dossiers sans responsable et permettre leur attribution |
| Utilisateur | Les employés | Le superviseur attribue; le technicien met à jour uniquement ses dossiers |
| Exception | Gérer les erreurs | Conserver une demande interrompue et indiquer la prochaine action |
| Intégration | Connecter le CRM | Importer le numéro client et synchroniser le statut selon une règle définie |
| Acceptation | L’application fonctionne | Vérifier un jeu de dossiers représentatifs avec les responsables métier |
Cette grille illustre une méthode de cadrage, pas un périmètre universel. Vous pouvez l’utiliser dans un document simple. Il vaut mieux cinq processus décrits clairement qu’un catalogue de cent fonctionnalités sans priorité ni critère de réussite.
Faire l’inventaire des données et des systèmes
Listez les sources : tableurs, outil comptable, CRM, formulaires, documents et boîtes courriel. Pour chacune, identifiez le propriétaire, la fréquence de mise à jour, les identifiants et les problèmes connus. Deux colonnes portant le nom « client » ne désignent pas nécessairement la même chose.
Précisez la référence pour chaque donnée importante. Le prix vient-il de la comptabilité ou du catalogue? Le statut d’expédition vient-il du transporteur ou d’une saisie interne? Sans cette décision, une synchronisation peut remplacer une information juste par une ancienne valeur.
Décrivez également le besoin d’historique. Une équipe peut devoir consulter d’anciennes factures sans les modifier. Cela n’oblige pas toujours à reconstruire toutes les fonctions de l’ancien système. Prévoir une archive consultable peut réduire le périmètre, à condition de définir les accès et la conservation avec les personnes responsables.
Donner une priorité à chaque besoin
Classez les besoins en trois groupes : nécessaires pour exécuter le premier processus, utiles après validation du premier lot et à explorer. Pour chaque besoin nécessaire, demandez ce qui se passe s’il manque. Une réponse concrète aide à distinguer une exigence opérationnelle d’une préférence.
Illustration fictive : une entreprise de services peut lancer un premier lot qui crée les interventions, les attribue et en suit l’état. Le tableau financier complet peut venir plus tard si la comptabilité existante continue à jouer ce rôle. L’objectif du premier lot est de fermer un parcours utilisable, plutôt que de construire tous les modules partiellement.
Avant de retenir le sur mesure, relisez le cadre de décision entre application et SaaS. Le cahier des charges peut aussi servir à configurer un logiciel existant ou à construire seulement l’intégration manquante.
Écrire les critères d’acceptation avant le devis
Un critère d’acceptation décrit une observation. Par exemple : après l’ajout d’un dossier, le superviseur le retrouve dans sa file, l’attribue à un technicien et le client ne voit que son propre dossier. Préparez les données d’essai et nommez la personne qui décidera si ce comportement répond au besoin.
Ajoutez les critères d’exploitation : restauration à partir d’une sauvegarde, visibilité d’un échec de synchronisation et retrait d’un accès. Pour la performance, précisez le parcours, le volume et les conditions de mesure; « rapide » ne constitue pas un test reproductible.
L’accessibilité doit être intégrée à la planification, comme le recommande le W3C. Définissez les parcours à vérifier au clavier, la lisibilité des erreurs et les profils à consulter. Une démonstration sur le portable du développeur ne représente pas tous les utilisateurs ni toutes les conditions d’usage.
Prévoir les décisions et les livrables du cadrage
Le dossier final doit inclure les processus prioritaires, la carte des données, les intégrations, les rôles, les critères d’acceptation et les inconnues restantes. Ajoutez une liste des décisions avec leur responsable et leur échéance. Une équipe ne peut pas confirmer un devis fiable si l’accès à une API ou la qualité des données reste hypothétique.
Demandez que le devis sépare les hypothèses du périmètre ferme. Le nettoyage des données, la formation et la mise en service doivent être visibles. Le service d’application web sur mesure peut alors être discuté à partir d’un dossier commun et d’une première livraison mesurable.
Un gabarit à copier dans votre document
Ce gabarit proposé par Daillac peut tenir sur quelques pages. Remplacez chaque élément entre crochets et joignez un exemple anonymisé. Laissez les inconnues visibles : elles serviront à préparer l’atelier de cadrage plutôt qu’à être silencieusement transformées en hypothèses de devis.
- Problème actuel : [processus], [personnes concernées], [fréquence] et [conséquence observée].
- Résultat attendu : [action réalisable], [critère mesurable], [responsable qui accepte la livraison].
- Utilisateurs : [rôle], [données consultables], [actions autorisées], [actions interdites].
- Parcours prioritaire : [déclencheur], [étapes], [sortie attendue], [deux exceptions].
- Données : [source], [champs], [volumes], [qualité connue], [règle de conservation à préciser].
- Interfaces : [système], [sens de l’échange], [délai acceptable], [comportement en panne].
- Première version : [indispensable], [reportable], [explicitement exclu].
- Acceptation : [jeu de dossiers], [résultat attendu], [preuve à conserver].
- Exploitation : [hébergement], [responsable], [support], [accès et documentation à remettre].
- Questions ouvertes : [question], [personne qui tranche], [date de décision].
Exemple rempli : une PME de services terrain
Le cas suivant est fictif. Une entreprise de douze techniciens reçoit ses demandes par courriel; la coordination les retranscrit dans un tableur. L’objectif de la première version est qu’une demande approuvée devienne un bon d’intervention attribué, puis un dossier complet prêt à facturer. Le nombre de personnes sert à dimensionner les rôles; il ne prédit ni le prix ni la durée du projet.
TableauExemple rempli : une PME de services terrain · bloc partageable
| Décision de première version | Critère d’acceptation | |
|---|---|---|
| Coordination | Créer et attribuer une intervention | Le bon porte un numéro stable et un technicien |
| Technicien | Voir ses interventions et joindre un compte rendu | Le technicien A ne voit pas les dossiers de B |
| Facturation | Recevoir les interventions terminées | Une intervention incomplète n’est pas transmise |
| Données | Importer les clients actifs du tableur | Chaque ligne est importée ou figure dans un rapport de rejet |
| Exception | Client absent ou adresse incomplète | La demande reste en attente avec un motif visible |
| Hors périmètre | Optimisation automatique des tournées | Aucune estimation de ce module n’est incluse dans le MVP |
Un scénario de réception exploitable : la coordination crée une demande pour le client fictif CLIENT-042; elle l’attribue au technicien A; ce dernier joint le compte rendu; la facturation retrouve le dossier avec ses pièces. Rejouez ensuite le scénario sans pièce obligatoire et avec le compte du technicien B. La réception exige le succès du parcours complet et le refus des deux situations interdites. « Le formulaire fonctionne » ne couvre pas ces conditions.
Dans cet exemple, le fonctionnement sans réseau reste une question ouverte. Le fournisseur doit préciser s’il propose un brouillon local, une simple lecture hors connexion ou aucune prise en charge. Cette distinction influence le devis. Une phrase vague comme « application mobile » ne permet pas de trancher entre ces comportements.
Questions fréquentes
Faut-il dessiner tous les écrans avant de consulter une agence?+
Non. Quelques croquis peuvent clarifier un parcours, mais les processus, les données et les permissions sont plus importants à ce stade. Les écrans devront être ajustés avec les utilisateurs. Évitez de transformer trop tôt un dessin en exigence définitive.
Peut-on demander un devis avec un simple tableur?+
Oui, si le tableur décrit les besoins, les priorités, les exemples et les questions ouvertes. Le format du document compte moins que la qualité des informations. Les pièces jointes doivent être anonymisées si elles contiennent des données sensibles.
Quel niveau de précision faut-il pour les intégrations?+
Identifiez les systèmes, les données échangées, la fréquence, le sens de synchronisation et les exceptions. L’équipe pourra ensuite vérifier l’accès, les limites et les droits. Ne présumez pas qu’un connecteur disponible couvre tous vos processus.
Comment limiter les changements pendant le développement?+
Définissez un premier parcours complet et une liste des besoins différés. Pour chaque demande nouvelle, examinez sa valeur, ses dépendances et son effet sur le budget. Documentez la décision de remplacer, reporter ou ajouter une fonctionnalité.
Sources et méthode
W3C WAI — Planning and managing accessibility · OWASP — API Security Top 10, édition 2023. Sources consultées le 1er octobre 2026; les grilles et exemples de décision sont une analyse éditoriale de Daillac.
Passer de votre besoin à un premier périmètre
Présentez-nous un processus réel, un exemple de document et les principales exceptions. Nous pourrons cadrer une première livraison et les points à clarifier avant le devis.
D
Rédigé par
DaillacStratégie numérique et ingénierie logicielle — Saint-Jérôme · Grande région de Montréal
