J'ai vu une équipe de neuf personnes passer trois après-midi en démo, hocher la tête devant des écrans très propres, puis signer. Six semaines plus tard, la personne qui saisit les commandes contournait l'outil avec un tableur. Le logiciel ignorait le cas le plus banal de sa journée : une commande modifiée après envoi. Personne n'avait écrit ce cas noir sur blanc. Le cahier des charges tenait en douze puces, reprises sur la plaquette du vendeur.
Ce genre de scène revient souvent. Un texte court peut suffire. Encore faut-il qu'il colle au travail réel, avec ses horaires, ses fichiers bancals et ses exceptions.
Ce qu'il faut retenir
- Décrivez les journées de travail avant toute liste de fonctions.
- Nommez qui utilisera l'outil et décrivez ses tâches, titre compris.
- Séparez ce qui bloque le premier mois de ce qui peut attendre.
- Indiquez où vivent les données, qui y touche, et ce qui doit migrer.
- Faites relire le texte par le terrain, puis jouez cinq scénarios.
- Exigez du vendeur une réponse écrite sur vos cas, point par point.
Pourquoi écrire avant de comparer les outils
Le piège de la démo séduisante
Une démo est un théâtre. L'éditeur montre le chemin heureux : le clic qui marche, le tableau déjà rempli, le client fictif bien rangé. Vous repartez avec une impression. Cette impression laisse dans l'ombre le mardi matin, quand deux personnes modifient la même fiche, ou quand un export doit partir avant 9 h vers quelqu'un qui n'a pas de compte.
J'ai fait l'erreur, les premières années, de noter pendant la démo les fonctions qui me plaisaient et d'appeler ça un besoin. Le vendeur avait choisi l'ordre du récit. Mes notes suivaient son film. Le jour où l'équipe a rejoué une semaine normale, trois tâches quotidiennes n'avaient aucune ligne.
Écrire avant de comparer renverse cet ordre.
Vous arrivez avec vos cas. La démo devient un examen, et les sourires de la salle pèsent moins que la réponse à un cas pénible.
Ce que le document doit trancher
Un cahier des charges logiciel sert à décider. Il indique quel travail doit devenir plus fiable, ce qui reste hors périmètre, et à quoi ressemble une journée réussie quelques mois plus tard. S'il ne vous aide pas à écarter une option séduisante, il occupe une page pour rien.
Il aligne aussi l'équipe. Le dirigeant porte une vision d'ensemble. La personne à l'accueil pense au client qui appelle pour déplacer un créneau. Les deux réalités comptent. Tant que tout reste oral, chacun suppose que l'autre a compris, et le malentendu apparaît à la mise en route.
Posez une question simple. Si le projet s'arrêtait demain, quelle tâche continuerait de faire mal chaque semaine ? La réponse donne le cœur du document. Le reste s'organise autour d'elle.
Décrire le travail avant les fonctions
Une matinée concrète vaut un catalogue
Choisissez une matinée réelle, un jour chargé de la semaine dernière. Notez les outils déjà ouverts : le mail, le tableur, le papier sur le bureau, le message sur le téléphone, le dossier partagé.
Pour chaque étape, écrivez qui agit, ce qui casse si l'information est fausse, ce qui suit juste après, et combien de fois la scène revient dans la semaine. Ces quatre détails remplacent la formule creuse "gestion des commandes", qui peut tout dire et n'engage rien.
La ligne que je fais écrire ressemble à ceci. Léa ouvre le mail du client à 8 h 40, cherche le dossier dans le tableur, voit que le prix a changé hier, rappelle, puis met à jour deux fichiers. Cette phrase guide un paramétrage. Une étiquette abstraite guide une plaquette.
Qui clique, qui valide, qui subit
"Tout le monde utilisera l'outil." Dans une petite structure, deux personnes sont souvent dessus toute la journée. Le dirigeant ouvre un écran le vendredi. Un prestataire dépose un fichier de temps en temps. Écrivez ces rôles avec des prénoms, ou au minimum des fonctions précises, et ce que chacun a le droit de voir.
Une petite équipe peut rester sobre sur les droits d'accès. Elle a quand même besoin de deux réponses nettes : la personne en stage peut-elle exporter la liste des clients, et un avoir au-dessus d'un certain montant attend-il une validation ?
J'ajoute toujours l'absence : congés, maladie, départ, ou journée chez un client. Quand le savoir tient dans une seule tête, l'écran reste muet tant que cette personne n'a pas décrit ses réflexes. Le document force cette mise à plat avant le vendredi où elle s'absente.
Les blocs qui rendent le document exploitable
Fonctions, données, contraintes
Je range le texte en quatre blocs. Un bloc unique finit en liste de courses, et personne ne sait plus quoi tester.
Le contexte. Activité, taille de l'équipe, outils déjà en place, raison du projet. Cinq à dix lignes suffisent. Un lecteur externe doit comprendre le métier sans monopoliser une heure d'appel.
Le travail à couvrir. Des scénarios en phrases complètes. Créer un devis, l'envoyer, le relancer, le transformer en facture, enregistrer un acompte : chaque scénario se termine par un résultat visible. Un document. Une validation. Une alerte. Un export. On peut dire si ça tient, sans débat de goût sur la couleur des boutons.
Les données. Où elles vivent, sous quel format, qui peut les modifier, ce qu'on reprend, ce qu'on laisse en archive. Si le tableur contient des doublons, écrivez-le. J'ai vu une reprise s'enliser parce que le même client existait sous trois orthographes. Une phrase aurait prévu le nettoyage avant la migration.
Les contraintes. Langue de l'interface, usage sur téléphone, nombre de personnes connectées en même temps, durée de l'historique, nom de celui qui administrera l'outil après le projet, délai pour être opérationnel. "Simple et moderne" ne guide aucun choix. "L'accueil retrouve un client en moins d'une minute, par le nom ou le téléphone" en guide un.
Une grille de priorité qui autorise le renoncement
Tout classer en obligatoire, c'est refuser de choisir. Rangez chaque scénario dans deux cases : bloquant pour démarrer, ou reportable après le premier mois d'usage. Deux cases. Une échelle à cinq niveaux se dissout en réunion, parce que personne ne se bat pour le milieu.
Le bloquant, c'est la tâche dont l'absence renvoie l'équipe au vieux tableur dès la deuxième semaine. Le reportable reste désirable. Il attend la preuve que le socle tient dans la vraie semaine, avec les interruptions et les imprévus.
À partir de là, l'éditeur peut couvrir le socle et proposer la suite plus tard. Deux offres se comparent sur la même ligne de flottaison.
| Question | Liste de souhaits | Cahier des charges utile |
|---|---|---|
| Point de départ | Les écrans vus en démo | Une matinée de travail réelle |
| Forme des besoins | Des puces vagues, comme reporting | Des scénarios à fin observable |
| Priorité | Tout est marqué urgent | Bloquant pour démarrer, ou reportable |
| Données | On importera l'existant | Source, doublons, qui nettoie, archive |
| Critère de choix | L'outil paraît complet | L'outil passe les scénarios bloquants |
Faire relire avant d'acheter
Cinq scénarios pour tester le document
Avant l'envoi, lisez le texte à voix haute avec la personne qui répète le même geste toute la journée. Prenez cinq scénarios. Les plus pénibles. Ceux qu'une démo effleure ou saute.
- Le client modifie sa demande après l'envoi du document.
- Deux personnes éditent la même fiche dans la même heure.
- Une information obligatoire manque, et le dossier doit quand même avancer.
- Un collègue part en congés au milieu d'une série de relances.
- L'export doit partir vers quelqu'un qui n'ouvre jamais l'outil.
Si une ligne reste muette sur la suite attendue, complétez-la. Si votre collègue dit qu'en réalité le geste est différent, croyez-le. Le document raconte l'entreprise telle qu'elle tourne, contournements compris. Vous choisirez ensuite quoi abandonner. Retirer un contournement avant de l'avoir compris produit un bel écran, et une équipe qui retourne au tableur en douce.
Ce que vous demandez au vendeur en retour
Ajoutez une consigne claire : une réponse par scénario. Pour chaque cas bloquant, quatre issues possibles. Natif. Paramétrable. Contournement. Hors couverture. La démo se joue ensuite sur vos exemples, avec vos noms de champs. Le fichier de démonstration de l'éditeur est construit pour son propre parcours, et il passe à côté de vos exceptions sans même le vouloir.
La première fois que j'ai exigé ce retour écrit, un éditeur a répondu "contournement" sur le cas le plus fréquent de l'équipe. Pendant la démo, ce cas avait disparu du récit. L'offre est sortie de la liste, sans dispute et sans semaine perdue. Le document avait fait le tri.
Gardez ces réponses. Quelques mois plus tard, si une fonction annoncée au paramétrage manque encore, vous retrouverez la phrase exacte, et le nom de la personne qui l'avait écrite.
Après la signature, le texte continue de servir
La première semaine d'usage
Le jour du basculement, rejouez les scénarios bloquants sur une dizaine de vrais dossiers. Vous verrez vite si les champs tiennent, si les droits bloquent un geste normal, si l'export ressemble à ce que le destinataire sait lire.
Notez chaque écart sur le cahier des charges : ce qui était écrit, ce qui se passe, qui décide du correctif. Cette trace coupe court à la rumeur interne, celle qui gonfle jusqu'à "cet outil ne vaut rien". Parfois le texte était trop optimiste. Parfois le paramétrage a dérivé. Un écart nommé se corrige. Un écart raconté à la machine à café s'installe.
Ce qu'on ajoute quand le socle tient vraiment
L'envie d'activer toutes les options reportées arrive dès que l'équipe respire. Laissez passer quelques semaines. Un outil ouvert chaque matin, cantonné au socle, rend plus de service qu'une galerie de modules dont personne ne connaît le chemin.
Je rouvre alors la colonne reportable. Certaines lignes ont fondu : derrière, il n'y avait qu'une inquiétude. D'autres sont devenues bloquantes, parce que le volume ou l'équipe a changé. Le complément s'écrit court, avec le même format de scénario, et il repart vers l'éditeur avec la même exigence de réponse.
Un cahier des charges relie la promesse faite à l'équipe et le comportement réel de l'outil. Il suit le travail. Le figer le jour de la signature, c'est accepter de piloter de mémoire dès le mois suivant.
Le calme vient de ce qui est écrit
La prochaine fois qu'on vous propose une démo "rapide pour voir", envoyez d'abord deux scénarios tirés de votre semaine. S'ils peuvent être joués avec vos contraintes, la rencontre vaudra le temps de l'équipe. Si le récit revient tout de suite au parcours standard, vous aurez déjà votre réponse, sans bloquer trois après-midi.
Le bon document tient souvent en quelques pages. Il sent la maison : les prénoms, les horaires, les fichiers tordus, les cas que personne n'a envie de raconter en réunion. C'est ce concret-là qui protège mieux qu'une belle liste de fonctions.
Questions fréquentes
Un logiciel déjà en vente demande-t-il un cahier des charges ?
Oui, en version courte. Le texte sert à vérifier que l'outil couvre vos scénarios bloquants, et à comparer deux offres sur les mêmes cas. Une plaquette présente le meilleur angle de l'éditeur. Votre document présente votre semaine.
Quelle longueur viser dans une TPE ?
Quelques pages denses suffisent dans la plupart des petites structures. Une page de scénarios nets pèse plus que trois pages de contexte mou. Si vous dépassez une dizaine de pages avant d'avoir priorisé, vous êtes en train de dessiner une solution, là où il fallait encore décrire le travail.
Qui l'écrit quand personne n'est technique ?
La personne qui porte le projet rédige, avec celles et ceux qui font le geste chaque jour. Un regard extérieur, pair, associé ou prestataire, vient ensuite pour chercher les trous. Le métier reste l'auteur. Un texte écrit seulement depuis l'extérieur décrit une entreprise générique, propre, et à côté de la vôtre.
Peut-on recycler le document pour un second logiciel ?
Gardez la méthode, et une partie du contexte. Réécrivez les scénarios. Un outil de facturation et un outil de planification d'interventions ne posent pas les mêmes questions sur les données, les droits et la journée type. Coller l'ancien texte tel quel importe des besoins qui n'ont plus de place.
