Publié le · Par l’équipe IT LABS PRO
Confier un site ou une application à une équipe externe, qu’elle soit à Casablanca, à Paris ou ailleurs, suppose qu’elle comprenne exactement ce que vous attendez. Le cahier des charges est l’outil qui rend cela possible. Trop vague, il entraîne des devis incomparables, des malentendus et des corrections coûteuses. Trop technique ou trop long, personne ne le lit. Voici comment rédiger un cahier des charges efficace pour un projet web externalisé.
Pourquoi le cahier des charges est décisif
- Il permet des devis justes : tous les prestataires chiffrent le même périmètre.
- Il réduit les malentendus, surtout quand l’équipe ne partage pas votre quotidien.
- Il sert de référence pendant le projet et lors de la recette : ce qui est écrit est dû, ce qui ne l’est pas se discute.
- Il vous oblige à clarifier votre besoin, ce qui révèle souvent des questions que vous ne vous étiez pas posées.
La structure type
1. Le contexte et les objectifs
Présentez l’entreprise (ou votre client), son activité et la raison du projet. Surtout, formulez des objectifs mesurables : « recevoir 30 demandes de devis par mois », « réduire de moitié le temps de traitement des commandes », « permettre aux clients de suivre leurs dossiers en ligne ».
2. Les utilisateurs
Qui utilisera le site ou l’application ? Visiteurs, clients connectés, commerciaux, administrateurs… Pour chaque profil, indiquez ce qu’il doit pouvoir faire et ce qu’il ne doit pas voir.
3. Le périmètre fonctionnel
La liste des pages et des fonctionnalités, classées par priorité : indispensable pour la première version, utile, confort. C’est la partie la plus importante pour le chiffrage.
4. Les contenus
Qui fournit les textes, les photos, les traductions ? Combien de pages, de produits, de langues ? Les contenus sont souvent la première cause de retard d’un projet web.
5. Les contraintes techniques
Technologie imposée ou libre, hébergement existant, outils à connecter (CRM, comptabilité, paiement), exigences de sécurité, de performance ou d’accessibilité, navigateurs et appareils à prendre en charge.
6. Le design
Charte graphique, maquettes existantes ou à produire, sites de référence que vous appréciez (et pourquoi).
7. Le planning et le budget
Date de mise en ligne souhaitée, contraintes fortes (salon, lancement commercial), et si possible une fourchette budgétaire : elle aide le prestataire à proposer la solution adaptée plutôt qu’une solution idéale hors de portée.
8. Les modalités
Recette, formation, documentation, maintenance, propriété du code, confidentialité, réversibilité.
Les maquettes : un schéma vaut mieux qu’un long discours
Pour un projet externalisé, les maquettes sont le meilleur moyen de partager une vision commune. Même des schémas simples (« wireframes ») des écrans principaux évitent des pages de description. Si vous disposez de maquettes graphiques finalisées, précisez les états à prévoir : survol, erreur, liste vide, affichage mobile.
Les user stories : décrire le besoin du point de vue de l’utilisateur
Une user story décrit une fonctionnalité en une phrase simple : « En tant que [profil], je veux [action] afin de [bénéfice]. » Par exemple : « En tant que client, je veux télécharger mes factures depuis mon espace afin de ne plus les demander par e-mail. » Ce format oblige à préciser qui utilise la fonctionnalité et pourquoi, ce qui aide l’équipe de développement à faire les bons choix.
Les critères d’acceptation : savoir quand c’est terminé
Chaque user story importante devrait s’accompagner de critères d’acceptation vérifiables. Pour l’exemple précédent :
- les factures sont listées de la plus récente à la plus ancienne ;
- chaque facture se télécharge au format PDF ;
- un client ne voit que ses propres factures ;
- la liste s’affiche correctement sur smartphone.
Ces critères servent directement à la recette : la fonctionnalité est acceptée quand tous sont vérifiés.
Les erreurs fréquentes
- Décrire la solution au lieu du besoin : laissez le prestataire proposer la meilleure réponse technique.
- Oublier les cas particuliers : que se passe-t-il si un paiement échoue, si un stock est vide, si un utilisateur oublie son mot de passe ?
- Ne pas prioriser : sans priorités, tout semble indispensable et le budget explose.
- Oublier l’après : maintenance, évolutions, hébergement.
- Rédiger seul : impliquez les futurs utilisateurs, ils connaissent les vrais irritants.
Le modèle de sommaire
- Contexte et objectifs mesurables
- Profils utilisateurs et droits
- Fonctionnalités par priorité (avec user stories)
- Critères d’acceptation des fonctionnalités clés
- Contenus et langues
- Contraintes techniques et intégrations
- Design et maquettes
- Planning, budget et jalons
- Recette, formation, maintenance, propriété du code
Et si vous n’avez pas le temps de tout rédiger ?
C’est fréquent. Dans ce cas, un atelier de cadrage avec votre prestataire permet de construire le cahier des charges ensemble : vous apportez la connaissance du métier, il apporte la méthode et les questions techniques. Cette phase, parfois facturée séparément, est souvent l’investissement le plus rentable du projet.
Exemple de fonctionnalité bien décrite
Voici comment décrire une fonctionnalité de manière exploitable pour une équipe externe :
- Nom : demande de devis en ligne.
- User story : en tant que visiteur, je veux demander un devis en indiquant mon type de projet, afin d’obtenir une réponse adaptée.
- Champs : nom, téléphone, e-mail, type de projet (liste), message.
- Règles : nom, téléphone et e-mail obligatoires ; protection contre les envois automatisés.
- Après l’envoi : message de confirmation à l’écran, e-mail à l’équipe commerciale, enregistrement de la demande.
- Critères d’acceptation : un envoi incomplet affiche un message clair ; l’équipe reçoit l’e-mail en moins d’une minute ; le formulaire fonctionne sur mobile.
Questions fréquentes
Quelle longueur pour un cahier des charges ?
Il n’y a pas de longueur idéale : pour un site vitrine, quelques pages suffisent ; pour une application métier, le document est plus détaillé. Mieux vaut un document court et précis qu’un long document que personne ne lit.
Faut-il un cahier des charges pour un petit projet ?
Oui, même succinct. Une page qui liste les objectifs, les pages et les fonctionnalités évite déjà la plupart des malentendus.
Le cahier des charges peut-il évoluer pendant le projet ?
Oui, mais chaque changement doit être tracé et, si besoin, chiffré. Au forfait, une évolution du périmètre donne généralement lieu à un avenant.
En résumé
Un bon cahier des charges formule des objectifs mesurables, décrit les besoins des utilisateurs, priorise les fonctionnalités et définit comment le résultat sera validé. C’est la meilleure garantie d’un projet externalisé réussi. Vous préparez un projet ? Découvrez notre offre de sous-traitance de développement web ou notre guide sous-traiter son développement web au Maroc.