Rédiger le cahier des charges d'un logiciel (même court)
Demander un devis pour « une application qui gère nos interventions », c’est s’exposer à recevoir trois propositions impossibles à comparer, l’une deux fois plus étoffée que l’autre. Le cahier des charges sert précisément à éviter cela : il décrit ce que l’entreprise attend, avec ses mots, pour que les prestataires répondent à la même question. Nul besoin d’un document de cinquante pages : cinq à dix pages claires valent mieux qu’un pavé que personne ne lit.
À quoi sert vraiment un cahier des charges
Il remplit trois fonctions :
- clarifier le besoin en interne, ce qui révèle souvent des désaccords entre associés ou entre services ;
- obtenir des devis comparables, puisque chacun chiffre le même périmètre ;
- servir de référence pendant le projet, pour vérifier que ce qui est livré correspond à ce qui était demandé.
Il ne s’agit pas de décrire la solution technique. C’est le rôle du prestataire. Votre rôle est de décrire le problème, les utilisateurs et les règles du métier.
Le plan type
1. Le contexte
En quelques paragraphes : l’activité de l’entreprise, sa taille, l’organisation actuelle et ce qui ne fonctionne pas. Décrivez la situation de départ honnêtement, y compris les bricolages (tableurs, e-mails, papier). Un prestataire comprend beaucoup mieux un besoin quand il voit d’où l’on part.
2. Les objectifs
Ce que le logiciel doit changer, de façon vérifiable autant que possible : supprimer une double saisie, réduire le délai de réponse à un client, permettre aux techniciens de saisir leurs rapports sur place, disposer d’un tableau de bord fiable.
3. Les utilisateurs
Qui utilisera l’outil, combien de personnes, depuis quel appareil (poste fixe, ordinateur portable, téléphone sur un chantier), avec quels droits. Un commercial, un comptable et un client externe n’ont pas besoin de voir les mêmes informations.
4. Les fonctions attendues
C’est le cœur du document. La méthode la plus lisible consiste à décrire des situations concrètes : « le technicien ouvre la fiche d’intervention du jour, ajoute des photos, fait signer le client sur la tablette, et le rapport part au bureau ». Chaque situation devient une fonction à chiffrer.
5. Les données
Quelles informations le logiciel manipule (clients, produits, interventions, factures), d’où elles viennent, et s’il faut reprendre des données existantes. La reprise de l’historique est un poste souvent oublié dans les devis. Si des données personnelles sont concernées, mentionnez-le : cela a des conséquences sur la sécurité et sur le contrat (voir RGPD dans une TPE).
6. Les liens avec l’existant
Logiciel de comptabilité, outil de facturation, site web, messagerie : listez ce avec quoi le nouvel outil devra échanger. Chaque connexion a un coût et une fragilité propres. Avec la généralisation de la facture électronique, la question des échanges avec l’outil de facturation mérite d’être posée dès le départ.
7. Les contraintes
Délai souhaité, contraintes d’hébergement (en France, dans l’Union européenne), exigences de disponibilité, accessibilité, langues, fonctionnement hors connexion. Indiquez aussi ce qui est imposé et ce qui est négociable.
8. Ce que vous attendez du prestataire
Format de la réponse, éléments à fournir (planning, méthode, références vérifiables, conditions de maintenance, cession des droits, documentation), date limite de remise.
Prioriser : indispensable, utile, confort
Le piège classique est la liste au père Noël. Pour l’éviter, classez chaque fonction :
| Niveau | Signification | Exemple |
|---|---|---|
| Indispensable | Sans elle, l’outil ne sert à rien | Créer et suivre une intervention |
| Utile | Gain réel, mais l’outil fonctionne sans | Export automatique vers la comptabilité |
| Confort | Agréable, à réserver pour une seconde phase | Statistiques personnalisables |
Cette hiérarchie permet de demander aux prestataires un chiffrage par niveau et de lancer une première version limitée à l’indispensable. C’est souvent le meilleur moyen de maîtriser le budget, comme nous l’expliquons dans l’article sur le coût d’un logiciel sur mesure.
Les erreurs fréquentes
- Décrire l’écran plutôt que le besoin : « un bouton vert en haut à droite » n’aide personne ; « valider une commande en un geste depuis un téléphone » est utile.
- Oublier les cas particuliers : annulations, avoirs, clients sans adresse e-mail, interventions sur plusieurs jours. Ce sont eux qui font exploser les délais.
- Rédiger seul : interrogez ceux qui utiliseront l’outil. Ils connaissent les exceptions que la direction ignore.
- Ne rien dire de l’après : qui hébergera, qui corrigera les anomalies, comment récupérer les données si l’on change de prestataire.
- Figer le document : il évoluera après les premiers échanges avec les prestataires, et c’est normal. Datez chaque version.
Et si le besoin peut être couvert par un logiciel existant ?
Rédiger un cahier des charges est utile même si vous n’êtes pas sûr de vouloir du sur mesure. Le même document permet d’interroger des éditeurs de logiciels standards et de vérifier, fonction par fonction, ce qu’ils couvrent. Il arrive souvent que l’exercice révèle qu’un outil du marché suffit, éventuellement complété par un petit développement. Pour cette réflexion préalable, voir logiciel sur mesure ou SaaS.
Une version courte, si le temps manque
À défaut de mieux, une page bien construite répond à six questions : quel problème, pour qui, quelles cinq fonctions indispensables, quelles données, avec quels logiciels échanger, pour quand. C’est déjà suffisant pour engager une discussion sérieuse avec un prestataire et pour juger de la qualité de ses questions en retour, un critère que nous détaillons dans choisir un prestataire de développement.
Cet article peut contenir des liens partenaires. Ils n'influencent jamais ce que nous écrivons.