Vous n'êtes d'ailleurs pas obligé d'en avoir un pour nous contacter : quand il n'existe pas, c'est nous qui le rédigeons avec vous pendant le cadrage. Mais le remplir vous-même, même grossièrement, fait gagner du temps et permet de comparer honnêtement plusieurs devis.
Ce qu'un cahier des charges n'est pas
Ce n'est pas un document de 60 pages. Plus il est long, moins il est lu, et plus il fige des choix qui auraient mérité une discussion. Ce n'est pas non plus une liste de technologies (« en React », « avec une base MySQL ») : sauf contrainte réelle de votre système existant, laissez ce choix au prestataire et jugez-le sur le résultat.
Ce qui arrive sans cahier des charges
Démarrer un projet sans cahier des charges, c'est aller au-devant de problèmes de cadrage, de périmètre, de budget et de planning. Nous l'avons vu sur des projets de développement logiciel qui n'en finissaient plus : le client ajoutait des demandes sans arrêt, puisque rien n'était écrit, rien ne pouvait être refusé ni chiffré à part. Aucune recette par étape, donc aucun moment où l'on valide ce qui est fait avant de passer à la suite. Aucune obligation claire, ni d'un côté ni de l'autre.
Au bout du compte, personne n'est protégé : le client n'a aucune garantie sur ce qu'il recevra, ni quand, ni pour quel prix, et l'agence de développement n'a aucune sécurité sur ce qu'elle doit livrer et sur ce qui lui sera payé.
Le cahier des charges règle tout cela. Il permet de comparer des devis bâtis sur les mêmes critères, de choisir en connaissance de cause, de découper le projet en étapes que l'on recette une par une, et de distinguer clairement ce qui est prévu de ce qui sera une évolution, chiffrée à part.
Le modèle, rubrique par rubrique
1. Le problème à résoudre
En quelques lignes : qu'est-ce qui ne va pas aujourd'hui, et qu'est-ce que vous voulez obtenir ? Une phrase du type « nous perdons des demandes de devis parce qu'elles arrivent par trois canaux différents » vaut mieux qu'une page de fonctionnalités.
À remplir :
- la situation actuelle (outils utilisés, fichiers Excel, papier) ;
- ce qui coûte du temps, de l'argent ou des erreurs ;
- le résultat attendu, si possible mesurable.
2. Les utilisateurs
Qui va se servir de l'application, combien de personnes, et avec quels droits ? Un commercial, un technicien sur le terrain, un comptable et un dirigeant n'ont ni les mêmes écrans ni les mêmes droits.
À remplir :
- les profils d'utilisateurs et leur nombre ;
- ce que chacun doit pouvoir voir, créer, modifier ou valider ;
- les utilisateurs extérieurs éventuels (vos clients, vos sous-traitants).
3. Les gestes du quotidien
C'est la rubrique la plus utile. Décrivez une journée ou une semaine type, étape par étape, pour chaque profil : « le technicien reçoit son planning le matin, il note ses heures sur place, il prend une photo de l'installation, le client signe sur la tablette ». Ces récits révèlent les vrais besoins bien mieux qu'une liste de fonctions.
4. Les données
Quelles informations l'application doit-elle gérer (clients, dossiers, interventions, produits, factures) ? D'où viennent-elles aujourd'hui, et faut-il reprendre l'existant ? Joignez vos fichiers actuels, même imparfaits : ils valent tous les discours.
5. Les règles métier
Les calculs, les validations et les cas particuliers : comment se calcule un prix, qui doit valider une dépense au-delà d'un montant, que se passe-t-il quand un client annule. Ces règles sont souvent cachées dans une formule Excel ou dans la tête d'une seule personne : c'est le moment de les écrire.
6. Les outils à connecter
Logiciel de comptabilité, paiement en ligne, messagerie, agenda, site web, signature électronique : listez ce avec quoi l'application doit échanger des informations, et dans quel sens.
7. Les contraintes
- la sécurité et la confidentialité des données (données de santé, données personnelles, secret des affaires) ;
- l'hébergement (en France, chez vous, chez nous) ;
- l'usage sur téléphone ou tablette, sur le terrain, avec ou sans réseau ;
- les dates qui comptent (une saison, un salon, une échéance réglementaire).
8. Le budget et les priorités
Donner une fourchette de budget n'est pas se mettre en position de faiblesse : c'est permettre au prestataire de proposer ce qui tient dedans, plutôt qu'un projet idéal hors de portée. Classez aussi vos besoins en trois niveaux : indispensable pour démarrer, important, et « plus tard ». La première version ne contient que le premier niveau.
Ce qu'il faut demander en retour au prestataire
Une fois votre cahier des charges envoyé, un bon prestataire doit vous rendre : sa compréhension du besoin reformulée, une architecture de la solution, un périmètre découpé en versions, un délai et un devis détaillé. Chez Qualitech-Conseil, vous recevez aussi un devis de référence établi comme le ferait une agence classique, à côté du nôtre, pour comparer sur pièces. Notre façon de mener un projet de bout en bout est décrite dans du cahier des charges à la mise en production, et notre offre sur la page développement d'application métier sur mesure.
Notre avis
Un projet sans cahier des charges n'offre aucune garantie au client et aucune sécurité au prestataire. Même court, même imparfait, il vaut mieux qu'aucun : c'est lui qui fixe ce que l'on doit livrer, ce que l'on recette à chaque étape, et ce qui relève d'une évolution. Et si vous n'avez pas le temps de l'écrire, faites-le écrire avec vous pendant le cadrage, mais ne vous en passez pas.