La plupart des projets logiciels qui dérapent ne le font pas à cause de la technique, mais d'un malentendu au départ. Le client imaginait un outil, le développeur en a compris un autre. Le cahier des charges sert à éviter ce malentendu. Encore faut-il qu'il décrive les bonnes choses.
L'erreur la plus fréquente : décrire des écrans
Beaucoup de cahiers des charges commencent par « il faut un menu avec telle liste et tel bouton ». C'est prématuré. Ce qui compte, c'est ce que les utilisateurs doivent pouvoir faire, dans quel ordre, et avec quelles règles. Les écrans viennent après, et un bon prestataire vous en proposera souvent de meilleurs que ceux imaginés au départ.
Les sept blocs d'un cahier des charges utile
1. Le contexte
Qui êtes-vous, quelle activité, et surtout : quel problème l'application doit-elle résoudre ? Décrivez la situation actuelle honnêtement, y compris les fichiers Excel et les contournements.
2. Les utilisateurs
Qui va utiliser l'outil ? Pour chaque profil (commercial, magasinier, comptable, client, direction), indiquez ce qu'il doit faire et ce qu'il ne doit pas voir.
3. Les processus
Le cœur du document. Décrivez chaque processus comme une histoire : « Le commercial reçoit une demande, crée un devis, le fait valider par la direction au-delà d'un certain montant, puis l'envoie au client. » N'oubliez pas les exceptions : elles représentent souvent la moitié du travail.
4. Les fonctionnalités, priorisées
Listez ce que l'outil doit permettre, puis classez chaque point avec la méthode MoSCoW :
| Priorité | Signification | Exemple |
|---|---|---|
| Must | Indispensable dès la première version | Créer et envoyer un devis |
| Should | Important, mais l'outil reste utilisable sans | Relance automatique des devis sans réponse |
| Could | Appréciable si le budget le permet | Tableau de bord des taux de conversion |
| Won't | Exclu de cette version, explicitement | Application mobile dédiée |
5. Les données
Quelles informations l'outil manipule-t-il ? D'où viennent-elles, faut-il reprendre l'existant, et avec quels autres logiciels faut-il échanger (comptabilité, site web, messagerie) ? Pour ce dernier point, voir Relier son site web à son logiciel de gestion : les API expliquées simplement.
6. Les contraintes
Budget, délai, hébergement, langues (français, arabe, anglais), accès sur téléphone, sécurité, confidentialité des données.
7. Les critères de réussite
Comment saurez-vous que le projet est réussi ? « Ne plus utiliser le fichier de suivi partagé », « préparer un devis en moins de dix minutes »… Des critères concrets évitent les débats à la livraison.
Les erreurs qui font déraper un projet
- Tout mettre en priorité « Must ». Une première version qui fait l'essentiel, livrée vite, vaut mieux qu'un projet complet qui n'aboutit jamais.
- Écrire sans les utilisateurs. La personne qui fait la tâche tous les jours connaît les exceptions que la direction ignore.
- Oublier la reprise des données. Nettoyer et importer l'existant est un travail à part entière.
- Figer le document. Un cahier des charges évolue pendant le projet : ce qui compte, c'est que chaque changement soit discuté et chiffré.
Charika Pro réunit aujourd'hui des appels d'offres, un annuaire d'entreprises, des consultations privées et une interface en trois langues. Un tel périmètre ne se définit pas d'un coup : il se construit et se priorise version après version. Nous présentons la plateforme dans Charika Pro : centraliser les appels d'offres pour les entreprises.
Et si vous ne savez pas par où commencer ?
Pas besoin d'un document parfait pour contacter un prestataire. Une page qui décrit le problème, les utilisateurs et le processus principal suffit pour un premier échange. Le cahier des charges se construit ensuite à deux. Si vos processus reposent aujourd'hui sur des tableurs, lisez aussi Fichiers Excel partagés : quand passer à une application métier ?, puis présentez-nous votre projet.
Questions fréquentes
Combien de pages doit faire un cahier des charges ?
Il n'y a pas de bonne longueur. Pour une première application métier, dix à vingt pages bien structurées valent mieux qu'un document de cent pages que personne ne relit.
Faut-il inclure des maquettes ?
Des croquis peuvent aider à exprimer une idée, mais ils ne doivent pas figer la solution. Décrivez d'abord ce que l'utilisateur doit accomplir.
Le prestataire peut-il rédiger le cahier des charges ?
Il peut vous aider à le structurer, souvent lors d'une phase de cadrage. Les connaissances métier, elles, viennent de votre entreprise.
