Comment décrire votre besoin avant de demander un devis de logiciel ?

Vous avez demandé trois devis pour le même outil, et ils ne se comparent pas. L'un prévoit une dizaine d'écrans, l'autre trois fois plus, et le troisième ne dit rien de vos données. Le plus souvent, les prestataires n'ont pas compris le même besoin, faute de l'avoir lu au même endroit. Un cahier des charges logiciel règle ce problème : c'est le document qui décrit ce que l'outil doit permettre, pour que chacun chiffre la même chose. Voici ses rubriques, la façon de les remplir et les erreurs qui faussent les devis.

À quoi sert un cahier des charges de logiciel ?

Le document sert d'abord à votre équipe. L'écrire oblige à se mettre d'accord sur le besoin avant de dépenser quoi que ce soit, et révèle souvent des désaccords entre services.

Il sert ensuite aux prestataires. Remis à l'identique à chacun, il rend leurs devis comparables, rubrique par rubrique. Pendant le projet, il devient enfin la référence pour trancher une question : était-ce prévu ou non ?

Deux formes existent. Le cahier des charges fonctionnel décrit ce que l'outil doit permettre, du point de vue de ceux qui l'utilisent. Le cahier des charges technique décrit comment le construire : langage, hébergement, architecture. Pour une PME qui achète un logiciel, le fonctionnel suffit le plus souvent, complété par quelques contraintes techniques réelles.

Partir d'un process, pas d'une liste de fonctions

Le réflexe courant consiste à lister des fonctions : « un tableau de bord », « des alertes », « un export ». Ces mots ne disent pas ce que fait votre équipe, et chaque prestataire les comprend à sa façon.

Partez plutôt d'un process, c'est-à-dire une tâche que l'équipe répète, comme le suivi d'une commande fournisseur ou le traitement d'une réclamation. Décrivez-le comme il se passe aujourd'hui :

1. Le déclencheur : un appel, un e-mail, une date.
2. Les étapes, dans l'ordre, avec la personne qui fait chacune d'elles.
3. Les décisions prises en route, et qui les prend.
4. Le résultat attendu à la fin.
5. Les cas qui sortent de la règle, comme une commande urgente ou un client sans numéro.

Les fonctions découlent ensuite de ce récit. Une étape où quelqu'un attend une validation appelle une alerte. Une étape où il recopie des chiffres appelle une liaison entre deux logiciels.

Les rubriques d'un cahier des charges logiciel

Un document clair suit toujours le même plan. Les prestataires y retrouvent vite l'information, et vous voyez d'un coup d'œil ce qui manque.

Classez chaque besoin en trois niveaux : indispensable dès le départ, utile ensuite, et plus tard. Ce classement donne aux prestataires une base pour proposer un premier périmètre réaliste.

Les données et les logiciels à relier

Les données et les liaisons pèsent souvent lourd dans un devis. Ce sont pourtant les rubriques les plus souvent oubliées.

Pour les données, dressez l'inventaire de ce que l'outil doit gérer : clients, articles, commandes, interventions. Pour chacune, notez où elle se trouve aujourd'hui, son volume approximatif, son état (doublons, champs vides) et la personne qui la tient à jour. Précisez aussi l'historique à reprendre, car reprendre dix ans d'archives ne coûte pas le même effort que reprendre l'année en cours.

Pour les logiciels à relier, décrivez chaque échange en une ligne :

Demandez à l'éditeur de chaque logiciel s'il propose une API, c'est-à-dire une porte d'entrée entre deux logiciels, ou un simple export de fichier. La réponse change le travail à prévoir.

Écrire comment vous jugerez le résultat

Un besoin sans critère de réussite se discute sans fin à la livraison. Écrivez dès maintenant les essais qui diront si l'outil fait le travail.

Un bon critère se vérifie par une personne, sur des données réelles, sans interprétation. Il prend la forme d'un scénario. Par exemple, quand un technicien clôt une intervention, le client reçoit le compte rendu. La facture apparaît alors à valider dans la comptabilité. Prévoyez un scénario par process important, et un pour chaque cas qui sort de la règle.

Ces scénarios servent deux fois. Avant le devis, ils montrent au prestataire ce que vous attendez vraiment. À la livraison, ils forment la liste des essais à passer avant de valider.

Les erreurs qui faussent les devis

Certaines erreurs reviennent dans presque tous les premiers jets. Elles rendent les devis incomparables ou gonflent leur montant.

• Imposer une solution technique. Écrire « en application mobile » ou nommer un langage ferme la porte à une solution plus simple. Décrivez le besoin, par exemple « saisir une intervention depuis le chantier, sans réseau ».
• Recopier l'outil actuel. Reproduire chaque écran de l'ancien logiciel reconduit aussi ses défauts.
• Empiler les souhaits sans priorité. Une liste où tout est indispensable pousse chaque prestataire à tout chiffrer.
• Oublier les exceptions. Les cas particuliers représentent souvent une grande part du travail, et leur absence produit des devis trop bas, rattrapés plus tard.
• Écrire un document que personne ne lit. Un texte trop long noie les points importants. Visez la précision plutôt que l'exhaustivité.

Prévoyez enfin la question de la propriété dès la consultation. Faites écrire dans le contrat que le code vous appartient, car sans clause de cession, le prestataire reste propriétaire du code livré.

Remettre le document aux prestataires

Envoyez la même version du document à chaque prestataire, à la même date. Si l'un d'eux pose une question, répondez par écrit et transmettez la réponse à tous.

Demandez ensuite que chaque devis reprenne vos rubriques, dise ce qui est exclu et liste ses hypothèses. Vous comparerez alors les offres ligne par ligne, et non sur un seul total. Pour situer les montants reçus, notre article pour estimer le budget d'un logiciel sur mesure détaille les postes qui font varier le prix.

Un forfait suppose un besoin précis, car chaque oubli devient ensuite un ajout à négocier. Un cahier des charges complet vous permet donc de demander un prix ferme sur un périmètre figé, l'un des garde-fous d'un projet sur mesure.

Faire appel à Zero License

Chez Zero License, nous partons de vos process réels. Un projet complet commence par un audit, à l'issue duquel le périmètre est figé, puis il se paie au forfait fixe par sprint, une courte étape de travail (le déroulé d'un projet). Au mois 12, nous vous transférons le code source, l'hébergement et la propriété du logiciel.

Pour un premier pas, nous construisons un prototype gratuit sur l'un de vos process, et vous le gardez. Votre cahier des charges, même incomplet, en est un bon point de départ.