Cahier des chargesMéthodeApplication métierPMEPrototype
Rédiger le cahier des charges d'une application interne
10 min de lecture
Pour rédiger le cahier des charges d'une application interne, décrivez le problème avant la solution : objectifs mesurables, utilisateurs et leurs droits, processus actuel, règles métier, données, outils à connecter, contraintes de sécurité et critères de recette. Gardez-le court, priorisez chaque besoin, puis vérifiez le tout sur un prototype visuel avant de faire chiffrer.
Le reste de cet article détaille chaque rubrique, avec ce qu'il faut y écrire, ce qu'il vaut mieux laisser au prestataire, et une checklist à passer avant d'envoyer le document.
À quoi sert vraiment ce document
Un cahier des charges n'est pas un exercice de style. Pour une application interne, il doit rendre trois services, et un seul suffit à juger s'il est réussi.
- Permettre un chiffrage. Un prestataire doit pouvoir estimer le travail sans deviner ce que vous avez en tête.
- Permettre une comparaison. Deux réponses au même document doivent porter sur la même application, sinon leurs prix ne se comparent pas.
- Permettre une recette. À la livraison, chaque exigence doit pouvoir être vérifiée par oui ou par non.
Un document qui accumule les pages sans servir ces trois usages coûte du temps à écrire, du temps à lire, et il ne protège personne.
La trame en neuf rubriques
| Rubrique | La question à laquelle elle répond | Exemple de contenu |
|---|---|---|
| Contexte et objectifs | Pourquoi ce projet, et comment saurez-vous qu'il a réussi ? | « Supprimer la ressaisie des bons d'intervention, aujourd'hui recopiés le soir » |
| Périmètre | Qu'est-ce qui est inclus, et surtout qu'est-ce qui ne l'est pas ? | « La facturation reste dans l'outil comptable actuel » |
| Utilisateurs et droits | Qui se sert de l'outil, et qui peut faire quoi ? | Technicien : saisit. Responsable : valide. Comptabilité : consulte |
| Processus actuel | Comment le travail se fait-il aujourd'hui, réellement ? | Le parcours d'un bon, du terrain à l'archivage, avec ses détours |
| Règles métier | Quelles conditions, quels calculs, quelles exceptions ? | « Une intervention de plus de 4 heures exige une validation » |
| Données | Quelles informations, d'où viennent-elles, qui en est la source ? | Clients, sites, interventions, pièces, temps passé |
| Intégrations | Avec quels outils l'application doit-elle échanger ? | ERP, outil comptable, annuaire de l'entreprise |
| Contraintes | Sécurité, RGPD, hébergement, accès mobile, accessibilité | « Saisie possible sans réseau, synchronisée au retour » |
| Recette et suite | Comment valider, puis qui maintient l'outil ? | Critères vérifiables, jalons, maintenance et évolutions |
L'ordre compte : les objectifs et le périmètre conditionnent tout le reste. Une règle métier n'a de sens que rattachée à un objectif, et une intégration ne se justifie que si une donnée doit vraiment circuler.
Les règles métier, cœur du document
C'est la rubrique la plus utile et la plus souvent bâclée. Les écrans se dessinent vite ; ce sont les règles qui font le travail, et le prix. Une règle bien écrite tient en une phrase de la forme « quand telle situation, alors tel comportement », suivie de ses exceptions.
- Bien écrit : « Quand une intervention dépasse 4 heures, elle passe au statut "à valider" et le responsable du secteur est prévenu. Exception : les contrats de maintenance annuelle, validés d'office. »
- Inutilisable : « Le système gère les validations. »
Cherchez les règles là où elles se cachent : dans les formules des tableurs, dans les colonnes « remarques », dans les cellules colorées à la main, dans les « on fait toujours comme ça » des équipes. Si votre processus vit aujourd'hui dans un fichier Excel, ce fichier est déjà une bonne partie de votre cahier des charges, comme l'explique notre article sur le remplacement d'un tableur.
Des exigences vérifiables, pas des intentions
Chaque exigence doit pouvoir se tester. Les adjectifs ne se testent pas.
| Formulation vague | Formulation vérifiable |
|---|---|
| L'application doit être rapide | La liste des interventions du jour s'affiche en moins de 2 secondes sur un téléphone en 4G |
| L'outil doit être simple | Un technicien saisit un bon complet sans aide après une démonstration de 15 minutes |
| Les données doivent être sécurisées | Chaque utilisateur se connecte avec un compte nominatif, et chaque modification est historisée |
| Il faut pouvoir exporter | Export mensuel au format CSV, avec les colonnes listées en annexe |
Les seuils de cette colonne de droite sont des exemples : c'est à vous de les fixer, en fonction de ce que vos équipes vivent réellement. Ce qui compte, c'est qu'ils existent.
Prioriser : tout n'est pas indispensable
Un cahier des charges où tout est obligatoire ne laisse aucune marge de manœuvre, ni sur le prix, ni sur le délai. La méthode MoSCoW, popularisée par la méthode agile DSDM, classe chaque besoin en quatre niveaux :
- Must : sans lui, l'outil ne sert à rien ;
- Should : important, mais une première version peut s'en passer ;
- Could : appréciable si le budget le permet ;
- Won't (pour l'instant) : écarté de cette version, et écrit comme tel.
La dernière catégorie est la plus précieuse. Écrire noir sur blanc ce qui n'est pas demandé évite qu'un prestataire le chiffre « par sécurité », et qu'un utilisateur le réclame en recette.
Ce qu'il vaut mieux ne pas y mettre
- Une solution technique imposée sans expertise interne pour la porter. Le choix du langage, de la base de données ou de l'hébergeur revient au prestataire, qui doit le justifier. Vous fixez les contraintes (hébergement en Europe, authentification par l'annuaire de l'entreprise), pas l'architecture.
- Une maquette dessinée au millimètre dans un outil bureautique. Elle fige des choix d'ergonomie avant que quiconque ait testé le parcours.
- Des fonctionnalités « au cas où ». Chacune a un coût de développement, puis un coût de maintenance pour toute la vie de l'application.
Contraintes : la sécurité et le RGPD dès le départ
Une application interne manipule presque toujours des données personnelles : noms des salariés, coordonnées des clients, parfois des données plus sensibles. Le RGPD impose de penser la protection des données dès la conception (article 25) et d'encadrer par contrat le prestataire qui les traite pour votre compte (article 28). Le cahier des charges est le bon endroit pour l'écrire :
- quelles données personnelles l'outil contient, et pourquoi ;
- qui y a accès, selon quel profil ;
- combien de temps elles sont conservées ;
- où l'application est hébergée.
Ces quatre lignes coûtent peu à rédiger et évitent des reprises coûteuses une fois l'application construite.
Un exemple condensé
Voici, à titre d'illustration, à quoi ressemble l'essentiel d'un cahier des charges pour un outil de suivi des interventions :
Objectif : supprimer la ressaisie des bons d'intervention et réduire le délai de facturation. Utilisateurs : douze techniciens sur le terrain, deux responsables de secteur, une personne en comptabilité. Règles : une intervention de plus de 4 heures exige une validation ; les pièces utilisées décrémentent le stock. Données : clients et sites issus de l'ERP, pièces issues du catalogue. Intégration : les interventions validées remontent dans l'ERP pour facturation. Contraintes : saisie possible sans réseau, comptes nominatifs, hébergement en Europe. Hors périmètre : la facturation elle-même.
Dix lignes, et un prestataire sérieux sait déjà quelles questions poser. La remontée vers l'ERP, à elle seule, mérite un échange approfondi : nous la détaillons dans notre article sur l'intégration d'une application à un ERP existant.
Du document au prototype
Même bien écrit, un cahier des charges reste un texte, et un texte se lit de plusieurs façons. « Le responsable valide l'intervention » ne dit pas s'il valide depuis son téléphone, en lot ou une par une, ni ce qu'il voit avant de valider. Ces questions ne surgissent souvent qu'en recette, au moment où y répondre coûte le plus cher.
Un prototype visuel referme ces interprétations : les écrans, les parcours et des données réalistes, que vos équipes peuvent commenter avant toute ligne de code. Le document dit ce qu'il faut faire ; le prototype montre comment ce sera fait. Les deux se complètent, et c'est souvent le prototype validé qui devient la référence du chiffrage, comme nous l'expliquons dans notre article sur le prototype.
La checklist avant d'envoyer le document
- Les objectifs sont mesurables, et chacun dit comment on saura qu'il est atteint.
- Le périmètre liste aussi ce qui est exclu.
- Chaque profil d'utilisateur a ses droits décrits.
- Les règles métier sont écrites en « quand… alors… », avec leurs exceptions.
- Chaque donnée a une source désignée, et une seule.
- Les outils à connecter sont nommés, avec un interlocuteur pour chacun.
- Chaque exigence se vérifie par oui ou par non.
- Les besoins sont priorisés, y compris ce qui est écarté pour l'instant.
- Les données personnelles, leur durée de conservation et l'hébergement sont précisés.
- La suite est prévue : qui maintient l'outil, et comment les évolutions sont demandées. Notre article sur la maintenance détaille ce que ce poste recouvre.
Un document qui passe cette liste se chiffre sérieusement. Il permet aussi de choisir le bon cadre contractuel, ce que nous comparons dans forfait ou régie, et de comprendre ce qui fera le prix de l'application.
Et si vous n'avez pas le temps de l'écrire ?
C'est fréquent, et ce n'est pas bloquant. Chez LPR Studio, un premier échange suffit : vous décrivez le problème, vous partagez les fichiers et documents qui le portent aujourd'hui, et nous vous présentons en visio, sous 5 jours ouvrés, un prototype visuel gratuit. Il sert ensuite de cahier des charges si le projet continue, et vous choisissez la formule qui vous convient : forfait à prix fixe, abonnement sans payer le développement, ou édition SaaS.