Sommaire
Un bon cahier des charges ne fait pas 80 pages. Il fait le nombre de pages nécessaires pour qu’un développeur comprenne ce que l’application doit permettre, à qui, et pourquoi. C’est lui qui rend les devis comparables entre prestataires et qui évite les « ce n’est pas ce que j’avais en tête » en fin de projet.
Voici le plan que je recommande, en huit rubriques. Vous n’avez pas besoin de tout savoir : une rubrique incomplète vaut mieux qu’une rubrique inventée. Le cadrage sert justement à compléter les trous.
1. Le contexte et l’objectif
En quelques lignes : qui êtes-vous, quel problème voulez-vous résoudre, et comment saurez-vous que le projet est réussi ?
- Quelle situation actuelle pose problème (tableur, outil inadapté, tâches manuelles) ?
- Quel résultat attendez-vous : gagner du temps, éviter des erreurs, vendre plus, mieux suivre vos clients ?
- Un ou deux indicateurs de réussite, même approximatifs (« ne plus ressaisir les commandes », « devis envoyés le jour même »).
2. Les utilisateurs
Listez chaque type d’utilisateur et ce qu’il doit pouvoir faire. C’est souvent la rubrique la plus utile du document.
| Utilisateur | Ce qu’il doit faire | Sur quel appareil |
|---|---|---|
| Commercial | Créer un devis, suivre ses prospects | Ordinateur et téléphone |
| Responsable | Valider les devis, voir les chiffres | Ordinateur |
| Client | Consulter et accepter un devis | Téléphone |
3. Les fonctionnalités
Décrivez les fonctions du point de vue de l’utilisateur, pas de la technique. Une formule simple fonctionne bien : « En tant que [utilisateur], je veux [action] pour [bénéfice] ».
Classez-les ensuite en trois niveaux :
- Indispensable : sans cela, l’application ne sert à rien.
- Important : utile rapidement, mais peut attendre une deuxième version.
- Plus tard : les bonnes idées à garder pour la suite.
Ce classement est votre meilleur levier sur le budget : la première version ne contient que l’indispensable.
4. Les données
Quelles informations l’application doit-elle gérer (clients, produits, devis, interventions…) ? D’où viennent-elles aujourd’hui ? Faut-il reprendre un historique ?
Joignez un exemple de vos fichiers actuels : un extrait de votre tableur en dit souvent plus qu’une longue description.
5. Les connexions avec vos autres outils
Logiciel comptable, paiement en ligne, agenda, messagerie, site internet, CRM existant : listez les outils avec lesquels l’application doit échanger, et dans quel sens (envoyer, recevoir, les deux).
6. Les contraintes
- Délai : une date impérative (salon, saison, fin de contrat d’un logiciel) ?
- Budget : une fourchette, même large, permet de proposer la bonne solution plutôt que la plus complète.
- Sécurité et données personnelles : données sensibles, hébergement en France ou en Europe ?
- Usage terrain : besoin de fonctionner sans réseau ?
7. L’apparence
Pas besoin d’une maquette : votre logo, vos couleurs et deux ou trois exemples d’applications que vous trouvez agréables à utiliser suffisent. Les maquettes seront réalisées pendant le projet, et validées avant le développement.
8. L’après-mise en ligne
Qui administrera l’application ? Faut-il une formation ? Quel niveau de maintenance souhaitez-vous ? Ces questions conditionnent le choix de l’hébergement et le budget annuel.
Les erreurs à éviter
- Décrire la solution au lieu du besoin : « un bouton vert en haut à droite » plutôt que « valider un devis en un clic ».
- Tout mettre en priorité 1 : si tout est indispensable, rien ne l’est.
- Copier un logiciel existant : vous paieriez cher pour un clone de ce que vous pourriez louer.
- Oublier les utilisateurs secondaires : le comptable, le client, le remplaçant pendant les congés.
Mon conseil : rédigez une première version en une heure, même imparfaite, avec vos mots. On la complète ensemble pendant le cadrage, et c’est ce document finalisé qui sert de base au devis ferme.