Gestion de projet

Comment rédiger un cahier des charges pour un projet logiciel ou web

Par Codevista InnovationsPublié le 12 octobre 20269 min de lecture

Un bon cahier des charges logiciel décrit le besoin, pas la solution : qui sont les utilisateurs, ce qu'ils doivent pouvoir faire, à quelles conditions une fonctionnalité est terminée, et dans quelles contraintes (sécurité, hébergement, langues, budget, délais). Il tient en huit rubriques, des objectifs métier jusqu'à la propriété du code et la maintenance. Bien rédigé, il sert de référence commune au client et au prestataire, puis se prolonge en backlog agile pendant le projet.

À quoi sert un cahier des charges pour un projet web ?

Le cahier des charges traduit un besoin métier en attentes compréhensibles par une équipe de développement. Pour une direction générale ou une DSI, c'est l'outil qui permet de comparer des offres, d'estimer un budget réaliste et de piloter le projet sans malentendu.

Il protège le client : sans document de référence, difficile de démontrer qu'une fonctionnalité manque ou qu'une livraison n'est pas conforme. Il protège aussi le prestataire : un périmètre écrit limite les demandes ajoutées sans être chiffrées.

Une fois le document prêt, notre guide pour choisir une agence de développement à Casablanca détaille les questions à poser aux candidats.

Quelle structure pour rédiger un cahier des charges logiciel ?

Voici un plan type, à adapter à la taille du projet. On part du pourquoi avant le quoi, et du quoi avant le comment.

1. Contexte et objectifs : la situation actuelle, le problème à résoudre, et les indicateurs métier que l'entreprise suivra elle-même pour juger le résultat (délai de traitement d'un dossier, erreurs de saisie, tâches encore faites à la main).
2. Utilisateurs et personas : qui utilisera l'outil (clients, commerciaux, back-office, managers), sur quel appareil et dans quelle langue.
3. Périmètre fonctionnel : les besoins exprimés en user stories, chacune avec ses critères d'acceptation et sa priorité.
4. Exigences non fonctionnelles : performance, sécurité, accessibilité, hébergement, langues.
5. Intégrations : ERP, CRM, messagerie, passerelle de paiement en ligne, authentification unique (SSO), API de partenaires.
6. Données et migration : données existantes à reprendre, leur qualité, les durées de conservation et les données personnelles concernées.
7. Contraintes, budget et calendrier : une fourchette budgétaire, une échéance impérative ou souhaitée, les contraintes réglementaires ou internes.
8. Livrables, propriété et maintenance : ce qui est remis, à qui appartiennent le code et la propriété intellectuelle, comment le logiciel sera maintenu.

Quelques pages bien structurées valent mieux qu'un document volumineux que personne ne relit. Joignez maquettes et captures de l'existant en annexe.

Comment décrire les fonctionnalités : user stories et critères d'acceptation

La forme la plus efficace est la user story : « En tant que [utilisateur], je veux [action] afin de [bénéfice] ». Elle oblige à préciser qui a le besoin et pourquoi.

Chaque story est accompagnée de critères d'acceptation : des conditions vérifiables qui permettent de dire, sans débat, si la fonctionnalité est terminée. Par exemple, pour une demande de congé :

• le salarié voit son solde avant de valider sa demande ;
• le manager reçoit une notification et peut accepter ou refuser avec un commentaire ;
• une demande qui chevauche une période déjà acceptée est bloquée avec un message explicite.

Ajoutez une priorité à chaque story, par exemple avec la méthode MoSCoW (Must, Should, Could, Won't : indispensable, important, souhaitable, exclu de cette version). C'est elle qui permettra d'arbitrer si le budget se resserre et de délimiter une première version réellement utilisable.

Exigences non fonctionnelles : sécurité, performance, langues et hébergement

Souvent oubliées, ces exigences sont coûteuses à rattraper. Décrivez le niveau attendu, pas une technologie.

• Performance : utilisateurs simultanés attendus, temps de réponse acceptable sur les écrans critiques, usage sur réseau mobile.
• Sécurité : rôles et droits, authentification, journalisation des actions sensibles, sauvegardes et restauration. Demandez aussi au prestataire comment il protège vos données de son côté ; une certification ISO/IEC 27001 en est un indice, comme l'explique notre article sur la sécurité des données chez un prestataire.
• Données personnelles : au Maroc, leur traitement est encadré par la loi 09-08. Les formalités auprès de la CNDP incombent au responsable du traitement, en principe l'entreprise cliente ; précisez ce que le prestataire doit fournir pour les préparer (finalités, catégories de données, mesures de sécurité).
• Accessibilité : contrastes, navigation au clavier, compatibilité avec les lecteurs d'écran ; le référentiel WCAG du W3C donne un vocabulaire commun pour fixer le niveau attendu.
• Hébergement : cloud ou serveurs internes, localisation des données si elle est imposée (le transfert de données personnelles hors du Maroc est lui aussi encadré par la loi 09-08), environnements de recette et de production.
• Langues : français, arabe, anglais, voire amazighe. L'arabe impose une interface de droite à gauche (RTL) : mise en page miroir, typographie adaptée, champs mêlant arabe et chiffres. Prévu dès le départ, c'est un choix de conception ; ajouté en fin de projet, c'est un chantier.

Intégrations, données et migration : la partie qu'on sous-estime

Un logiciel métier vit rarement seul. Pour chaque système à connecter, indiquez ce qu'il doit échanger, dans quel sens et à quelle fréquence, qui en est l'interlocuteur technique, et s'il existe une documentation d'API et un environnement de test. Une intégration dont le fournisseur ne répond pas peut bloquer un projet entier : mieux vaut le savoir avant de signer.

La reprise des données mérite la même attention. Listez les sources (fichiers Excel, ancienne application, base existante), estimez honnêtement leur qualité (doublons, champs vides, formats incohérents) et dites qui se charge du nettoyage. Prévoyez au moins une migration à blanc sur l'environnement de recette avant la bascule réelle, et une solution de retour en arrière si elle échoue.

Budget, délais, livrables et propriété du code

Beaucoup d'entreprises hésitent à indiquer un budget. Pourtant, une fourchette budgétaire permet aux prestataires de proposer une solution adaptée plutôt que des offres impossibles à comparer. Distinguez aussi échéance impérative et date souhaitée.

La rubrique livrables doit lever toute ambiguïté :

• remise du code source dans un dépôt dont l'entreprise détient les accès ;
• propriété intellectuelle du code développé pour vous, et conditions d'usage des briques réutilisées ou open source ; ne supposez pas que payer le développement suffit à en devenir propriétaire, faites écrire la cession des droits ;
• documentation technique, accès aux comptes d'hébergement et noms de domaine au nom de l'entreprise ;
• conditions de maintenance : correctifs, évolutions, délais d'intervention, réversibilité si vous changez de prestataire.

Ces clauses relèvent du contrat : faites-les relire par un juriste plutôt que de vous fier à un modèle générique.

Cahier des charges figé ou backlog agile : comment combiner les deux ?

Le cahier des charges « au forfait », qui fige tout le périmètre, rassure les achats mais suppose que tous les besoins sont connus d'avance, ce qui est rarement le cas. À l'inverse, un backlog sans cadre écrit laisse le client sans garde-fou budgétaire. La combinaison qui fonctionne :

1. figer dans le document ce qui ne doit pas bouger : objectifs, utilisateurs, exigences non fonctionnelles, budget, échéances, livrables et propriété ;
2. exprimer le périmètre fonctionnel en user stories priorisées, qui deviennent le backlog initial ;
3. prévoir une phase de découverte pour affiner les stories prioritaires ;
4. valider à chaque itération sur un environnement de recette, et arbitrer chaque nouvelle demande en remplaçant une story de moindre priorité.

C'est ainsi que travaille Codevista Innovations sur ses projets de développement : une phase de découverte et de design (UX/UI), puis des sprints de deux semaines avec des livraisons régulières sur un environnement de staging pour validation. Si vous hésitez sur la manière de faire vivre ce backlog, notre comparatif Scrum ou Kanban aide à choisir.

Côté client, la personne qui pilote le projet doit tenir le périmètre, les risques et les parties prenantes : ce sont précisément des domaines couverts par la formation PMP®, qui prépare à la certification du PMI.

Les erreurs fréquentes dans un cahier des charges d'application

• Décrire une solution au lieu d'un besoin : « un bouton Excel en haut à droite » plutôt que « les RH doivent exploiter l'historique dans leurs outils ». Le prestataire ne peut plus proposer mieux.
• Ne pas prioriser : quand tout est indispensable, rien ne l'est, et le premier arbitrage budgétaire devient un conflit.
• Oublier les critères d'acceptation : la recette se transforme en débat d'interprétation.
• Rédiger seul : un document écrit par la DSI sans les métiers, ou l'inverse, rate une partie des contraintes.
• S'arrêter à la mise en production : sans hébergement, maintenance et réversibilité prévus noir sur blanc, le logiciel livré devient vite une dépendance subie.

Vous voulez un regard extérieur sur votre cahier des charges ou cadrer un futur projet SaaS sur mesure ? L'équipe de Codevista Innovations à Casablanca peut en discuter avec vous : prenez contact.

Questions fréquentes

Quelle est la différence entre cahier des charges fonctionnel et technique ?

Le cahier des charges fonctionnel décrit ce que le logiciel doit permettre de faire, pour quels utilisateurs et avec quels critères de validation. Le cahier des charges technique décrit comment le réaliser : architecture, technologies, modèle de données, hébergement. Le client rédige le premier ; le prestataire produit en général le second, validé avec la DSI.

Combien de pages doit faire un cahier des charges pour une application web ?

Il n'existe pas de longueur idéale : un outil interne simple tient en quelques pages, une plateforme avec de nombreuses intégrations en demande davantage. Le bon critère est la vérifiabilité : chaque fonctionnalité attendue doit être identifiable, priorisée et assortie de critères d'acceptation. Court et relu par les métiers vaut mieux que long et ignoré.

Faut-il indiquer son budget dans le cahier des charges ?

Oui, au moins sous forme de fourchette. Sans indication, les prestataires dimensionnent leurs offres très différemment et les propositions deviennent impossibles à comparer. Une fourchette permet à chacun de proposer ce qui est réaliste et de suggérer un découpage en versions successives. Précisez aussi si le budget couvre la maintenance et l'hébergement après la mise en production.

Un cahier des charges est-il compatible avec la méthode Scrum ?

Oui, à condition de ne pas tout figer. Le document fixe les objectifs, les utilisateurs, les exigences non fonctionnelles, le budget, les livrables et la propriété du code. Le périmètre fonctionnel, exprimé en user stories priorisées, devient le Product Backlog initial, que le Product Owner ordonne et que l'équipe affine sprint après sprint. Chaque nouvelle demande est arbitrée contre les stories existantes, ce qui garde le budget sous contrôle.