Aller au contenu

Cahier des charges : ce qu’il faut vraiment y mettre

Un cahier des charges utile tient en quelques pages. Ce qu’il doit contenir, ce qu’il faut en retirer, et une trame simple pour comparer les devis.

Trente pages qui ne disent rien

Il existe deux types de cahiers des charges. Le premier fait quatre pages, se lit en dix minutes, et permet à un prestataire de chiffrer sérieusement. Le second fait trente pages, contient une charte graphique, l’historique de l’entreprise, une liste de deux cents fonctionnalités — et laisse celui qui le lit sans savoir quel problème il est censé résoudre.

Le second est plus fréquent, parce qu’on confond épaisseur et sérieux. En pratique, plus il y a de pages, plus le prestataire doit deviner. Ce qu’il devine, il le chiffre large, par sécurité.

Un cahier des charges n’est ni un contrat ni une plaquette. C’est un document de travail qui doit permettre à quelqu’un d’extérieur de vous dire combien de temps il faut, combien ça coûte, et ce qu’il ne fera pas.

Les quatre questions auxquelles il doit répondre

Quel problème vous voulez résoudre. Pas « je veux un site », mais ce qui vous embête aujourd’hui : vous passez deux heures par semaine à noter des réservations au téléphone, vos commandes arrivent par SMS et vous en perdez. Le problème doit être concret et mesurable en temps ou en argent. C’est la partie que les documents épais oublient le plus souvent.

Qui va s’en servir. Vos clients ? Vos salariés ? Vous seul ? Combien de personnes, sur quel appareil, avec quel niveau d’aise devant un ordinateur ? Un outil pour trois personnes formées et un outil ouvert au grand public sur téléphone ne coûtent pas la même chose.

Ce qui existe déjà. Un nom de domaine, un logiciel de caisse, un fichier client sous Excel, un ancien site que personne ne met à jour. Tout cela pèse dans le chiffrage : à la baisse quand une base existante évite une ressaisie, à la hausse quand il faut se connecter à un logiciel fermé.

Ce qui est hors périmètre. C’est la question que personne n’écrit et qui évite le plus de conflits. Dire noir sur blanc « la facturation reste sur notre logiciel actuel » ou « pas de paiement en ligne cette année » vaut trente pages de spécifications.

  • Le problème concret, en une ou deux phrases
  • Qui utilise l’outil, combien de personnes, sur quel appareil
  • Ce qui existe déjà et doit être réutilisé ou remplacé
  • Ce qui est explicitement exclu de ce projet

Décrire un besoin sans décrire une solution

C’est le réflexe le plus courant et le plus coûteux : arriver avec la solution déjà choisie. « Je veux un bouton en haut à droite qui ouvre un formulaire en trois étapes. » Vous avez décrit une mécanique, pas un besoin, et le prestataire ne peut plus que l’exécuter, y compris si elle est mauvaise.

La formulation utile décrit ce qui doit être possible, pour qui, et pourquoi. « Un client doit pouvoir réserver une course sans nous appeler, en moins d’une minute, y compris le dimanche. » Là, on comprend l’enjeu. Le nombre d’étapes et la position du bouton redeviennent des décisions de conception, prises par quelqu’un dont c’est le métier.

Un bon test : relisez chaque ligne en vous demandant si elle décrit un résultat attendu ou une manière de faire. Dans le second cas, demandez-vous ce qu’elle est censée obtenir et écrivez cela à la place. Ne gardez la contrainte que si elle est réelle, par exemple parce que vos équipes travaillent déjà ainsi.

Ce qui n’a pas sa place dedans

Le choix des technologies, sauf contrainte réelle. Écrire « le site sera développé en WordPress » ou « en React » revient à choisir les matériaux avant d’avoir décrit la maison, et cela vous prive des propositions les plus adaptées. Les seules contraintes techniques légitimes viennent de votre situation : un logiciel métier auquel il faut se connecter, un hébergeur imposé, une équipe interne qui reprendra la maintenance et ne maîtrise qu’un outil.

Les détails graphiques n’ont pas non plus leur place ici. Couleurs, polices et emplacement du logo se décident pendant la conception, pas dans un document censé servir à chiffrer. Signalez seulement si vous avez une charte à respecter, ou aucune.

Retirez enfin tout ce qui n’engage rien : histoire de l’entreprise, valeurs, ambitions. Utile à un rédacteur plus tard, cela dilue ici l’essentiel.

  • Le langage ou le CMS, sauf contrainte technique avérée
  • Les couleurs, polices et maquettes détaillées
  • La présentation générale de l’entreprise
  • Les fonctionnalités « qu’on ajoutera peut-être un jour »

Le piège de la liste de fonctionnalités sans priorités

Beaucoup de cahiers des charges se résument à une liste : espace client, blog, newsletter, réservation, paiement, statistiques, multilingue. Tout est sur le même plan. Le prestataire chiffre tout, le total effraie, et le projet ne démarre pas — ou il démarre en coupant au hasard, souvent dans ce qui comptait vraiment.

Classez en trois catégories. Indispensable : sans cela, vous ne mettrez pas l’outil en ligne. Utile : cela améliore nettement les choses, mais on peut vivre un trimestre sans. Plus tard : c’est noté pour ne pas l’oublier et pour vérifier que la première version ne l’empêchera pas.

L’exercice est inconfortable, parce qu’il oblige à renoncer sur le papier. C’est précisément sa valeur. Une première version courte, mise en service et confrontée aux vrais utilisateurs, vous apprendra plus sur vos priorités que six semaines de réunions.

Rendre les devis comparables

Si vous consultez plusieurs prestataires, envoyez à tous exactement le même document. Cela paraît évident, mais la version envoyée au troisième contient souvent des précisions nées des échanges avec les deux premiers. Les devis deviennent incomparables, et vous choisissez sur un prix qui ne recouvre pas le même travail.

Demandez aussi la même structure de réponse : prix de la livraison, délai en jours ouvrés, ce qui est inclus, ce qui ne l’est pas, coût de la maintenance ensuite, et ce qui vous appartient à la fin — code, nom de domaine, hébergement, accès administrateur.

Un écart de prix important entre deux devis n’est presque jamais un écart de marge : c’est un écart de compréhension du périmètre. Quand cela arrive, ce n’est pas le prestataire le plus cher qu’il faut interroger en premier, c’est votre document, probablement ambigu quelque part.

  • Même document envoyé à tout le monde, sans ajout en cours de route
  • Prix de livraison et prix de la maintenance séparés
  • Délai annoncé en jours ouvrés, pas en semaines vagues
  • Ce qui est exclu, écrit noir sur blanc
  • Propriété du code, du domaine et des accès

Une trame réutilisable

Voici la structure à recopier telle quelle. Remplie, elle tient en trois à cinq pages, et c’est suffisant pour un projet de site ou d’application de TPE ou PME. Si vous dépassez huit pages, relisez : il y a probablement des solutions déguisées en besoins.

  • 1. Le problème : ce qui ne va pas aujourd’hui, en deux phrases concrètes
  • 2. Le résultat attendu : à quoi on saura que c’est réussi dans six mois
  • 3. Les utilisateurs : qui, combien, sur quel appareil, quel niveau technique
  • 4. L’existant : domaine, site actuel, logiciels en place, données à récupérer
  • 5. Les fonctionnalités classées indispensable / utile / plus tard
  • 6. Le hors périmètre : ce que le projet ne traitera pas
  • 7. Les contraintes réelles : réglementaires, techniques, calendaires
  • 8. Le budget et l’échéance souhaités, même approximatifs
  • 9. Ce que vous attendez dans la réponse : prix, délai, maintenance, propriété

Et si vous n’arrivez pas à l’écrire

C’est fréquent et ce n’est pas grave. Si vous bloquez sur les priorités ou le périmètre, ce n’est pas un problème de rédaction : le besoin n’est pas encore stabilisé. Écrire honnêtement « je ne sais pas encore » vaut mieux qu’inventer une réponse pour remplir la case ; un prestataire sérieux préfère une incertitude annoncée à une fausse certitude qu’il découvrira en cours de route.

Notre audit gratuit sert exactement à cela : clarifier le besoin, distinguer l’indispensable du confort, et vous laisser un document utilisable — y compris si vous consultez ensuite ailleurs. Les tarifs publics vont de 199 € HT pour un site vitrine livré en 10 jours ouvrés à partir de 1 200 € HT pour une plateforme avec espace d’administration ; le détail est sur omnipro-solutions.com/omnitech/tarifs, et vous pouvez nous exposer votre situation via omnipro-solutions.com/contact.