Ce que les gens cherchent en tapant « exemple de cahier des charges », c’est une trame à copier, pas un cours. La voici, telle qu’on l’utilise en cadrage de projet, section par section, avec ce qu’il faut écrire dans chacune et les formulations qui vous protègent.
Un avertissement d’abord : un bon cahier des charges ne décrit pas un logiciel, il décrit un problème et la façon dont vous saurez qu’il est résolu. Si vous partez en dessinant des écrans, vous imposez une solution avant d’avoir énoncé le besoin, et vous vous privez de l’expertise de celui qui va construire. La trame ci-dessous est organisée pour éviter ce piège.
Section 1 : contexte et objectif
Trois paragraphes, pas plus. Qui vous êtes, ce qui ne va pas aujourd’hui, et ce que vous voulez obtenir.
La phrase à écrire absolument, et que presque personne n’écrit : comment vous saurez que le projet a réussi. Pas « améliorer la productivité », mais quelque chose de vérifiable. « La saisie d’une commande ne demande plus qu’une seule intervention au lieu de trois. » « Le délai entre la demande client et le devis passe sous les vingt-quatre heures. » Si vous n’arrivez pas à écrire cette phrase, vous n’êtes pas prêt à consulter, et aucun prestataire ne pourra vous le dire à votre place.
Section 2 : les utilisateurs et ce qu’ils font
Listez les profils, pas les personnes. Pour chacun : combien ils sont, dans quel contexte ils travaillent, et ce qu’ils doivent pouvoir accomplir.
Cette section sert à doser l’exigence. Un outil interne utilisé par cinq collaborateurs entraînés n’a pas besoin du même soin qu’une application vue par des milliers de clients. Traiter tout au même niveau, c’est soit gaspiller du budget, soit livrer une interface que personne ne comprend.
Formulation utile : « Le magasinier, sur tablette, en mouvement, avec des gants. » Cette phrase-là vaut trois réunions.
Section 3 : les processus, du début à la fin
Le cœur du document. Décrivez le parcours réel, pas le parcours idéal.
Et surtout, décrivez ce qui se passe quand ça se passe mal. Le client annule après paiement. Deux personnes modifient la même fiche en même temps. Le fichier importé est corrompu. La connexion tombe au milieu d’une validation. Ces cas de bord ne se voient jamais dans une démonstration, et ils représentent souvent la moitié du travail réel. Un prestataire qui les découvre en cours de route vous les facturera en avenant, légitimement.
Une bonne manière de les faire remonter : demandez à vos opérationnels ce qu’ils font aujourd’hui quand le système refuse. Leurs contournements sont la carte des cas de bord.
Section 4 : les connexions à l’existant
À quels outils ce logiciel doit-il parler ? ERP, CRM, facturation, messagerie, paiement, logistique.
Cette section est le premier générateur d’avenants du secteur. Chaque point de connexion est un contrat technique à respecter, avec ses règles, ses limites et ses pannes possibles. Et une intégration prévue dès le départ coûte une fraction de la même intégration ajoutée à mi-parcours, parce que l’architecture n’aura pas été pensée pour elle.
Pour chaque connexion, écrivez trois choses : quel outil, dans quel sens circulent les données, et à quelle fréquence. Si vous ne savez pas si votre outil dispose d’une interface de programmation, écrivez-le aussi : c’est une question à instruire, pas à cacher.
Section 5 : les données à reprendre
Combien d’historique, depuis quel système, et dans quel état.
Soyez franc sur le dernier point. Reprendre dix ans de données incohérentes, avec des champs vides, des formats mélangés et des doublons, n’a rien à voir avec démarrer à vide. Le nettoyage devient alors un projet dans le projet. Le dire au départ évite la mauvaise surprise budgétaire à la fin, et permet d’arbitrer : tout reprendre, ne reprendre que le vivant, ou faire arriver le reste plus tard.
Section 6 : les contraintes non fonctionnelles
Celles qu’on oublie et qui coûtent cher si elles arrivent tard.
Où les données doivent-elles être hébergées ? Combien d’utilisateurs simultanés au maximum, et cette limite va-t-elle bouger ? Quel volume de données à un an, à trois ans ? Quelles exigences de disponibilité, et que se passe-t-il si le système est indisponible une demi-journée ? Y a-t-il des obligations réglementaires, de conformité au règlement européen sur les données personnelles, d’accessibilité, de secteur régulé ?
Un logiciel conçu pour cent utilisateurs peut s’effondrer à dix mille. Si personne ne l’a écrit au départ, il faudra le reprendre en profondeur au moment où le succès arrive, c’est-à-dire au pire moment.
Section 7 : les critères de recette
La section que presque tout le monde oublie, et la plus importante du document.
Une liste de conditions vérifiables qui, si elles sont remplies, signifient que le travail est fait. Pas « le système doit être performant », mais « la recherche sur le catalogue complet renvoie un résultat en moins de deux secondes ». Pas « l’import doit fonctionner », mais « un fichier de dix mille lignes comportant des erreurs de format est importé, les lignes valides sont enregistrées et les lignes rejetées sont listées avec leur motif ».
Sans cette section, la fin de projet devient une discussion sans fin sur le sens du mot « terminé ». Avec elle, c’est un simple oui ou non, ligne par ligne. C’est aussi ce qui rend un forfait honnête possible : ce qui est dedans est dû, ce qui n’y est pas devient un avenant décidé consciemment.
Section 8 : le cadre du projet
Ce qui n’est pas du produit mais qui décide de sa réussite.
Qui décide, côté vous ? Nommez une personne, pas un comité. Un projet sans arbitre unique s’enlise dès la première contradiction entre deux services. Quelle est la disponibilité réelle de vos équipes pour les validations, en heures par semaine ? Quelles sont les échéances qui ne se négocient pas, et pourquoi ? Que devient le code et la documentation à la fin, et qui en est propriétaire ?
Cette dernière question mérite une phrase explicite dans le document. « Les sources, la documentation et les accès sont transmis au client à la livraison, sans restriction d’usage. » Une phrase, et vous venez d’éviter le scénario du prestataire qui détient votre outil.
Ce qu’il ne faut pas mettre dedans
Trois habitudes à abandonner.
Les choix techniques imposés sans raison. Écrire « le projet sera développé en PHP » quand vous n’avez aucune contrainte d’équipe interne, c’est réduire le champ des solutions sans bénéfice. Si vous avez une vraie raison, écrivez la raison, pas seulement la contrainte.
Les fonctionnalités décoratives. Chaque ligne d’un cahier des charges coûte de l’argent. La question à se poser devant chaque item : qu’est-ce qui se passe si on ne le fait pas ? Si la réponse est « rien de grave », c’est une vague deux.
Les formules de style. « Solution innovante et évolutive », « interface moderne et intuitive » : ces phrases ne sont pas vérifiables, donc elles ne protègent personne. Elles occupent de la place et laissent croire que le besoin est exprimé.
Le point aveugle du cahier des charges écrit seul
Un cahier des charges rédigé dans son coin porte toujours la même faiblesse : il décrit le besoin tel que vous le comprenez, avec les angles morts de quelqu’un qui n’a pas construit ce type de système. Les cas de bord manquent, les connexions sont sous-estimées, l’état réel des données est optimiste.
C’est pour ça que le meilleur document naît d’un dialogue, pas d’un exercice de rédaction. Vous apportez le métier, quelqu’un qui a construit apporte les pièges. C’est l’objet d’un cadrage court et rémunéré : on ouvre le capot, on regarde vos données, on liste les vraies connexions, et on écrit ensemble un périmètre que les deux parties comprennent de la même façon.
Et si personne en interne n’a le temps de porter ce travail face aux prestataires, c’est exactement le métier d’une assistance à maîtrise d’ouvrage : écrire le document, challenger les devis, puis tenir le périmètre jusqu’à la réception.
La trame, en fichier à remplir
Cette page décrit les huit sections. Si vous voulez le document lui-même, il est téléchargeable en Word, avec les tableaux déjà en place et les clauses de non-perte de données, de propriété du code et de réversibilité déjà rédigées. Sans inscription, et réutilisable comme vous voulez.
Pour aller plus loin
- Modèle de cahier des charges à télécharger : la même trame, en fichier Word à remplir
- Rédiger un cahier des charges : la méthode qui évite les avenants : le raisonnement derrière cette trame
- Recette d’un logiciel : le plan de tests qui évite la mise en production ratée : ce que deviennent les critères de recette
- Combien coûte un logiciel sur-mesure : les cinq postes qui font exploser une facture
- Assistance à maîtrise d’ouvrage : quand le document doit être porté par quelqu’un de votre côté
- Expression de besoin ou cahier des charges : l’étape qui précède cette trame, et qu’on saute presque toujours