Cahier des charges logiciel : comment le rédiger quand on n'est pas technique

Vous avez décidé de commander un logiciel sur mesure. Vous savez ce que vous voulez. Maintenant, il faut le mettre par écrit de sorte que le développeur comprenne exactement ce que vous attendez.

Et là, vous vous demandez : "Comment faire un cahier des charges quand je n'y connais rien en informatique ?"

Bonne nouvelle : vous n'avez pas besoin d'être technique. Vous avez juste besoin de savoir comment votre entreprise fonctionne vraiment. Et c'est déjà ça.

Voici comment écrire un cahier des charges qui ne soit pas un roman de 50 pages personne ne lira, mais plutôt un document utile que vous et votre prestataire allez vraiment utiliser.

Oublie tout ce que tu as vu sur les cahiers des charges "complets"

D'abord, un mythe à démolir : le cahier des charges ne doit pas être une documentation technique de 100 pages avec des termes comme "architecture système" et "flux de données". C'est pour les gros projets. Pas pour vous.

Un bon cahier des charges pour une PME, c'est :

• •3 à 5 pages maximum
• •Écrit en français simple, comme vous parlez
• •Structuré de façon logique
• •Avec des exemples concrets de votre métier

C'est tout. Le reste, c'est du bruit.

---

Les trois questions de base

Avant même d'écrire quoi que ce soit, répondez à ces trois questions. Honnêtement.

Question 1 : Qu'est-ce que je veux résoudre ?

Pas "je veux un logiciel". Mais : "J'ai un vrai problème concret qui me coûte du temps et de l'argent. C'est quoi ?"

Exemple : "Chaque matin, je dois appeler le responsable logistique pour savoir combien de commandes on a en retard. Je passe 30 minutes à ça. Je voudrais un logiciel où je peux voir l'état des commandes en un clic."

Question 2 : Pour qui je construis ce logiciel ?

Combien de personnes vont l'utiliser ? Quel est leur niveau technique ? Est-ce qu'elles vont vraiment l'utiliser chaque jour ou juste une fois par mois ?

Exemple : "Pour nous, ça va être utilisé par 3 personnes : moi, mon responsable logistique, et ma secrétaire. Ma secrétaire ne sait presque rien en informatique. Il faut que ce soit très simple pour elle."

Question 3 : Qu'est-ce que je vais faire avec ce logiciel ? Vraiment.

Quels sont les gestes quotidiens ? Les rapports mensuels ? Les cas exceptionnels ?

Exemple : "Tous les jours, on reçoit des commandes (par email, par téléphone, par formulaire web). Il faut les encoder. On doit pouvoir les modifier si le client change d'avis. À la fin du mois, je dois générer un rapport pour voir combien on a vendu et à qui."

---

La structure simple d'un cahier des charges (que vous devez écrire)

Voilà la structure que je propose. Elle est simple. Elle fonctionne.

1. Contexte et objectif (0,5 page)

Décrivez en deux ou trois phrases :

• •Qui vous êtes
• •Quel est votre métier actuel
• •Quel est le problème
• •Quel sera le résultat après le logiciel

Exemple pour une PME de négoce : "Nous sommes une PME de 8 personnes, spécialisée dans la distribution de fournitures industrielles. Actuellement, nos commandes clients sont gérées sur Excel et par email. Cela nous coûte 3-4 heures par jour rien que pour mettre à jour les données. On cherche un logiciel qui unifiée tout : réception des commandes, suivi du stock, facturation. Résultat attendu : zéro heure perdue à la saisie, visibility complète sur nos commandes en retard."

2. Les utilisateurs (0,5 page)

Listez qui va utiliser le logiciel. Pour chacun, dites :

• •Leur rôle
• •Combien d'heures par jour ils l'utiliseront
• •Leur niveau technique

Exemple :

3. Les fonctionnalités principales (1 page)

C'est le cœur du cahier. Listez ce que vous voulez faire avec le logiciel. Pas comment ça doit marcher techniquement, mais ce que vous allez faire avec.

Trois ou quatre fonctionnalités maximum. Si vous en listez dix, vous n'avez pas réfléchi.

Pour chacune, décrivez le "workflow" (le cycle de travail) en langage simple.

Exemple pour notre PME de négoce :

Fonctionnalité 1 : Recevoir et encoder les commandes "Quand Sophie reçoit une commande (par email, téléphone, ou formulaire web), elle peut l'ajouter au logiciel. Elle remplit : client, produits commandés, quantités, date souhaitée de livraison, remarques spéciales. Le logiciel crée automatiquement un numéro de commande. Sophie peut revenir modifier la commande si le client appelle pour changer quelque chose."

Fonctionnalité 2 : Suivi du stock "Je dois voir en permanence combien d'unités on a en stock pour chaque produit. Le stock doit diminuer automatiquement quand on valide une commande. Je dois pouvoir voir aussi le stock en réapprovisionnement (commandes qu'on a émises au fournisseur et qui ne sont pas encore arrivées)."

Fonctionnalité 3 : Visualiser les commandes en retard "Je dois avoir un écran simple qui me montre : combien de commandes ne sont pas encore expédiées ? Lesquelles devraient être expédiées aujourd'hui mais ne l'ont pas été ? Qui est le client ? Depuis quand c'est en retard ?"

Fonctionnalité 4 : Rapport mensuel "Je veux un rapport que je peux générer chaque mois (ou à tout moment) qui dit : combien j'ai vendu ce mois ? À qui ? Quel produit revient le plus souvent ?"

C'est ça. Quatre fonctionnalités clés. Pas de liste de 50 trucs.

4. Les cas exceptionnels (0,5 page)

Maintenant, listez les cas bizarres que personne n'a anticipés mais qui arrivent quand même.

Exemple :

• •"Parfois, un client veut une commande partielle. Il commande 100 unités de produit A, mais on en a que 50. On lui envoie 50 maintenant, 50 dans deux semaines. C'est une même commande en deux expéditions."
• •"Parfois, un client annule sa commande après l'avoir passée. On doit pouvoir annuler et remettre les produits en stock."
• •"Parfois, un client nous appelle pour renouveller une ancienne commande (une commande identique à une qu'il a passée il y a trois mois). On doit pouvoir dupliquer une commande."

Ne listez que les cas qui arrivent vraiment souvent (au moins une fois par mois).

5. Les données à migrer (si applicable) (0,5 page)

Si vous avez déjà des données nulle part (dans Excel, dans un vieux logiciel, sur papier), dites-le maintenant.

Exemple : "Nous avons un fichier Excel avec 2 000 clients, 10 000 historiques de commandes des 3 dernières années, et une liste de 300 produits. Il faut migrer tout ça dans le nouveau logiciel. Le fichier Excel est disponible. Attention : les données ne sont pas ultra propres (il y a des doublons, des adresses qui ne sont pas complètes)."

---

Les trois points CRITIQUES à clarifier

Au-delà de la structure, voilà les trois pièges qu'on voit tout le temps.

Piège 1 : Ne pas définir qui va encoder les données

C'est banal, mais ça change TOUT.

Vous dites : "Je veux un logiciel de gestion de stock." Le développeur comprend : "Je vais construire un logiciel de gestion de stock très simple, qu'on utilise une fois par mois pour vérifier les stocks." Vous espériez : "Tous mes salariés vont l'utiliser 8 heures par jour, il doit être ultra-simple."

Clarifiez : Qui va entrer les données chaque jour ? Quel est son niveau ? Est-ce qu'il va vraiment l'utiliser ou il va fuir c'est logiciel ?

Piège 2 : Mélanger "j'aimerais avoir" et "j'ai besoin de"

Exemple : "Idéalement, j'aimerais que le logiciel se connecte à mon système comptable et qu'il fasse la facturation automatiquement."

Ça peut être important ou pas. C'est vous qui savez.

Clarifiez : Listez les fonctionnalités en deux colonnes.

• •Colonne "impératif" : sans ça, le logiciel ne sert à rien
• •Colonne "bonus" : ce serait cool, mais on peut s'en passer

Votre prestataire va d'abord faire le "impératif". Le "bonus" vient après si le budget le permet.

Piège 3 : Ne pas parler de la volumétrie

C'est-à-dire : combien de "trucs" le logiciel va gérer.

• •Combien de clients ?
• •Combien de commandes par mois ?
• •Combien de produits ?
• •Combien d'utilisateurs simultanément ?

Ça change le design du logiciel.

Exemple : "Petite PME : 200 clients, 50 commandes/mois, 50 produits, 2 utilisateurs." vs. "Grosse PME : 5 000 clients, 2 000 commandes/mois, 2 000 produits, 20 utilisateurs."

Ce n'est pas le même logiciel.

Clarifiez : Donnez les chiffres dès le départ.

---

Un template réaliste à remplir (15 minutes de travail)

Voilà un template super simple. Remplissez-le. C'est votre cahier des charges.

---

CAHIER DES CHARGES : [NOM DE VOTRE PROJET]

1. Contexte

Qui êtes-vous ? (Taille, secteur) Quel est le problème que vous résolvez ? (Chiffrez si possible) Quel sera le résultat ? (Qu'est-ce qui va changer dans votre entreprise ?)

Exemple réponse : "On est une PME de 12 personnes, cabinet-conseil en paie. On utilise actuellement un logiciel générique qui ne correspond pas à nos besoins métier. On passe 3-4 heures par mois juste à adapter les rapports générés. On veut un logiciel qui génère les rapports qu'on vend vraiment à nos clients."

---

2. Utilisateurs

---

3. Les 3-4 fonctionnalités principales

Fonctionnalité 1 : Décrivez ce que vous allez faire avec (en langage simple, comme vous raconteriez à un ami).

Fonctionnalité 2 : ...

---

4. Les cas bizarres qui arrivent

• •Cas 1 : ...
• •Cas 2 : ...
• •Cas 3 : ...

---

5. Données actuelles à migrer

Vous avez des données à migrer ? D'où ? (Excel ? Un vieux logiciel ?) Combien de lignes ? Dans quel état ?

Exemple : "Excel avec 500 clients, données partielles"

---

6. Volumétrie estimée

• •Nombre de clients : ...
• •Nombre d'enregistrements par mois : ...
• •Nombre de produits/catégories : ...
• •Nombre d'utilisateurs simultanés : ...

---

7. Impératif vs Bonus

Listez les fonctionnalités en deux colonnes : ce qu'il FAUT (sans ça, c'est inutile) et ce qu'on aimerait mais pas crucial.

---

8. Budget et délai

Budget : ... (ou "À discuter") Délai préféré : ...

---

C'est ça. Remplissez ce template. Vous avez votre cahier des charges.

---

Les erreurs à NE PAS faire

Erreur 1 : Écrire comme un informaticien Ne dites pas : "Je veux une API REST avec OAuth 2.0 et une base de données PostgreSQL." Dites : "Je veux que mes clients externes puissent accéder à leurs données de commande de chez eux."

Erreur 2 : Être trop flou Ne dites pas : "Je veux un système de gestion." Dites : "Je veux pouvoir lister toutes les commandes, les filtrer par client ou par date, et générer un rapport mensuel."

Erreur 3 : Mélanger le "comment" et le "quoi" Ne dites pas : "Je veux un logiciel avec une interface à gauche et les détails à droite." Dites : "Je veux pouvoir voir la liste des commandes et accéder rapidement aux détails d'une commande."

Le "comment", c'est le boulot du développeur, pas le vôtre.

Erreur 4 : Demander la lune Ne listez pas 50 fonctionnalités. Listez les 3-4 vraiment critiques. Le reste, ça peut attendre.

Erreur 5 : Oublier de dire ce qui change après Une fois le logiciel livré, comment vous allez travailler différemment ? Qui va le maintenir ? Qui va faire les mises à jour ? Ce n'est pas une question technique, c'est une question d'organisation.

---

Après avoir écrit le cahier

Une fois que vous l'avez rempli :

1. •

   Relisez-le vous-même. Est-ce que c'est clair ? Est-ce qu'un ami pourrait le lire et comprendre ce que vous voulez ?

2. •

   Testez-le auprès d'un utilisateur. Montrez-le à Sophie qui va utiliser le logiciel chaque jour. Elle va peut-être dire : "Attends, tu as oublié que je dois aussi gérer les retours clients." Ajoutez-le.

3. •

   Envoyez-le à votre prestataire. Demandez-lui : "Est-ce que c'est clair pour toi ? Est-ce que tu vois des trous ?"

C'est là qu'il va poser des questions d'approfondissement. C'est normal. C'est comme ça qu'on améliore le cahier.

1. •Validez ensemble. Au final, vous devez être d'accord : le prestataire et vous devez parler de la même chose.

---

Ce qu'il faut vraiment retenir

Écrire un cahier des charges, ce n'est pas compliqué. Il faut juste répondre à trois questions :

1. •Quel est le problème ?
2. •Qui va utiliser le logiciel ?
3. •Qu'est-ce qu'on va faire avec ?

Le reste, c'est du détail. Et le "détail technique", c'est le travail du prestataire de creuser.

Un cahier des charges de 3-5 pages que vous comprenez vraiment, c'est infiniment mieux qu'un document de 50 pages que personne ne relira.

---

À retenir :

• •Un cahier des charges n'a pas besoin d'être technique — décrivez juste votre métier et votre problème
• •3-5 pages, c'est suffisant — lister 50 fonctionnalités est une perte de temps
• •Clarifiez les trois pièges : qui encode, impératif vs bonus, volumétrie
• •Testez votre cahier auprès d'un utilisateur avant de l'envoyer au prestataire