Cahier des charges d'un logiciel métier : la méthode simple pour une PME

« Il nous faudrait un cahier des charges, mais on ne sait pas par où commencer. » C'est l'une des phrases que j'entends le plus souvent avant un projet de logiciel métier. Bonne nouvelle : pour une PME, un cahier des charges utile tient en quelques pages, et vous pouvez en rédiger l'essentiel vous-même. Voici une méthode simple, en 7 rubriques.

Pourquoi un cahier des charges (même court) change tout

Il sert à trois choses : faire comprendre votre besoin au développeur, obtenir un devis comparable et fiable, et garder une référence pendant le projet. Un document trop vague donne des devis qui varient du simple au quintuple ; un document trop technique enferme dans des solutions avant d'avoir posé le problème.

1. Le contexte en une page

Qui êtes-vous, combien de personnes, combien de sites, quelle activité. Puis le problème, raconté simplement : « Le planning des trois ateliers est géré sur un tableau blanc et un fichier Excel, et nous perdons environ une heure par jour à appeler pour savoir où en sont les véhicules. »

2. Les utilisateurs et leurs rôles

Listez les profils : direction, bureau, terrain, comptabilité, clients éventuellement. Pour chacun, ce qu'il doit pouvoir voir et faire. Cette rubrique conditionne une bonne partie du coût et de la sécurité.

3. Le parcours actuel, étape par étape

Décrivez le chemin d'un dossier type : de la demande du client à la facture. Qui fait quoi, avec quel outil, à quel moment. Joignez vos documents réels : fichiers Excel, bons papier, modèles de devis. Ce sont les pièces les plus précieuses pour le développeur.

4. Ce qui doit changer (les irritants)

Classez vos problèmes par importance : ressaisies, erreurs, informations introuvables, délais. Pour chaque irritant, une phrase sur ce que vous attendez : « Le technicien doit pouvoir remplir son rapport sur place et le client le recevoir le jour même. »

5. Les fonctionnalités, classées en trois niveaux

• Indispensable : sans cela, l'outil ne sert à rien.
• Important : à prévoir rapidement, mais peut attendre un second lot.
• Confort : les bonnes idées pour plus tard.

Ce classement permet de découper le projet en lots et de maîtriser le budget : on développe d'abord l'indispensable, on l'utilise, puis on décide de la suite.

6. Les données et les connexions

Quelles données faut-il reprendre (fichiers Excel, ancien logiciel, base Access ou Clipper) ? Avec quels outils l'application doit-elle échanger : logiciel comptable, agenda, site web, ERP ? Précisez les volumes approximatifs (nombre de clients, de dossiers par mois).

7. Les contraintes et le calendrier

Date souhaitée pour un premier usage, périodes à éviter (haute saison), budget envisagé si vous en avez un, exigences particulières (hébergement en France, accès depuis l'extérieur, utilisation sur tablette).

Ce que vous pouvez laisser au développeur

Le choix des technologies, le modèle de base de données, l'architecture et la sécurité technique. Votre rôle est de décrire le quoi et le pourquoi ; le comment revient au prestataire, qui doit vous l'expliquer simplement.

Les erreurs à éviter

• Vouloir tout spécifier dès le départ : les vrais besoins apparaissent en utilisant l'outil.
• Décrire des écrans plutôt que des besoins : laissez de la place aux propositions.
• Oublier les utilisateurs terrain : ce sont eux qui feront vivre l'outil.
• Négliger la reprise des données : c'est souvent un poste important.

Le cadrage, étape par étape

Si vous n'avez ni le temps ni l'envie de rédiger seul, la première étape de mes projets est justement un atelier de cadrage : je viens voir comment vous travaillez et je rédige avec vous un cahier des charges découpé en lots chiffrés. Pour en savoir plus, consultez la page logiciel métier sur mesure ou les ordres de grandeur de budget.