Comment rédiger un cahier des charges pour un projet IT
Un cahier des charges utile ne décrit pas une solution : il décrit un problème, des contraintes et des critères de réussite. La structure en sept parties que j'utilise, et les trois pièges classiques.
En résumé : un cahier des charges utile décrit ce que vous voulez obtenir et comment on saura que c'est réussi — pas la solution technique, que le prestataire est mieux placé que vous pour proposer. Il tient souvent en dix à vingt pages. Un document de cent pages qui spécifie des écrans sans définir de critère de réussite est un document qui vous protège moins bien qu'une page qui les définit.
La structure en sept parties
- Contexte et problème — ce qui ne fonctionne pas aujourd'hui, avec un chiffre si possible : temps perdu, commandes égarées, ressaisies.
- Objectifs mesurables — ce qui doit avoir changé après. « Réduire de deux jours à deux heures le délai entre commande et lancement en production » est un objectif. « Améliorer la productivité » n'en est pas un.
- Périmètre fonctionnel — les processus couverts, et explicitement ceux qui ne le sont pas. La liste des exclusions évite plus de conflits que la liste des inclusions.
- Contraintes — systèmes existants à interfacer, obligations légales (dont la loi 09-08 sur les données personnelles au Maroc), contraintes de disponibilité, langues.
- Données — ce qui doit être migré, depuis quelles sources, et qui est responsable de leur nettoyage. Cette partie évite le litige le plus fréquent en fin de projet.
- Critères de recette — la liste des vérifications à passer pour que le livrable soit accepté. Écrite avant le développement, pas après.
- Organisation — qui décide, à quelle fréquence on se voit, sous quel délai les questions du prestataire obtiennent une réponse.
Les trois pièges classiques
Spécifier la solution au lieu du besoin
« Un bouton bleu en haut à droite qui exporte en Excel » ferme la porte à une meilleure réponse. « Le responsable doit pouvoir récupérer la liste filtrée pour la retravailler hors ligne » la laisse ouverte. Décrivez l'intention ; laissez la solution au prestataire, et jugez-la.
Oublier les critères de recette
Sans critères écrits à l'avance, la recette devient une négociation d'opinion en fin de projet, au moment où vous avez le moins de marge de manœuvre. C'est la partie la plus rentable du document, et la plus souvent absente.
Confondre exhaustivité et précision
Un cahier des charges long dilue les points importants. Si tout est prioritaire, rien ne l'est : classez explicitement en « indispensable », « souhaitable », « plus tard ».
Le test à faire avant d'envoyer
Donnez le document à quelqu'un qui ne connaît pas votre entreprise et posez-lui deux questions : qu'est-ce qui doit être construit ? et comment saura-t-on que c'est réussi ? S'il ne peut pas répondre à la seconde, le document n'est pas prêt — et aucun prestataire ne pourra vous chiffrer sérieusement.
Une exigence réécrite jusqu'à devenir testable
- Floue : « Le système doit gérer les commandes efficacement. »
- Meilleure : « Un commercial peut créer une commande et l'envoyer en production. »
- Testable : « Un commercial crée une commande de 50 lignes maximum en moins de deux minutes ; la production la voit dans sa file sous 60 secondes ; une commande sans date de livraison ne peut pas être envoyée. »
Seule la troisième version peut être acceptée ou refusée sans discussion.
Modèle en huit sections
- Problème et contexte (avec un chiffre si possible)
- Utilisateurs et rôles (les rôles cachent beaucoup de périmètre)
- Exigences classées : indispensable, souhaitable, plus tard
- Modèle de données : entités, relations, champs qui comptent
- Critères d'acceptation, rédigés avant le développement
- Hors périmètre de la v1, par une liste explicite
- Contraintes et intégrations
- Gouvernance : qui décide, en combien de temps
Ce que ça change sur les devis
Un fondateur avait deux devis pour la même application mobile : 18 000 $ et 47 000 $. Après huit jours de rédaction du cahier des charges, le moins cher n'avait prévu ni mode hors ligne, ni gestion des rôles, ni back-office d'administration, soit environ 60 % du produit en charge. Le devis élevé n'était pas cher : l'autre chiffrait autre chose.
Besoin d'un document prêt à envoyer ? Voir l'offre cahier des charges et spécifications : dix jours, je rédige sans répondre à l'appel d'offres, donc le document reste neutre.
Articles similaires
Notes
Audit de code : ce qu’il vérifie et ce qui détermine son prix
Ce que couvre un audit de code utile, des constats réels tirés de projets en production, ce qui fait varier le prix et cinq questions à poser à tout auditeur.
Notes
Modèle de cahier des charges pour une application mobile
Le modèle en neuf rubriques que j’utilise pour une application mobile, avec des critères d’acceptation testables et les erreurs à éviter.
Notes
Comment évaluer le travail d’une agence de développement sans lire le code
Noter chaque livrable face à des critères écrits, tester côté métier, repérer les cinq signaux d’alerte et vérifier ce qui est entre vos mains.
Newsletter
Recevez mes prochains articles directement dans votre boîte mail.