La rédaction d’un cahier des charges est une étape incontournable dans le démarrage de tout projet.
Dans cet article, je vous guiderai dans la réalisation d’un cahier des charges en vous indiquant les étapes à suivre, les éléments à ne pas oublier ainsi que les pièges à éviter.
On n’aborde pas de la même manière la rédaction d’un cahier des charges qu’il s’agisse de la construction d’un produit à lancer sur le marché, d’un outil à concevoir pour répondre aux problèmes de votre entreprise ou bien d’un projet à réaliser par vos équipes en interne.
Avant de vous lancer dans la rédaction, posez-vous donc les quelques questions suivantes afin de déterminer le contexte de votre projet:
Analysez le contexte et dressez le décor de votre projet. Faîtes le tout d’abord pour vous, mais partagez également ces éléments avec les candidats dans le cahier des charges.
Si vous partez de zéro et avez du mal à identifier ce que vous attendez de votre application, commencez par définir la problématique à laquelle vous essayez de répondre au travers de ces quelques questions…
Tout d’abord, qui sont vos utilisateurs:
Ensuite, identifiez ce qu’apportera votre application:
En répondant à ces questions simples, vous allez commencer à identifier, sans les détailler, des grands modules fonctionnels et à dessiner le périmètre de votre projet.
Travaillez sous forme d’ateliers avec des utilisateurs, ou leurs représentants, sur chaque grand module identifié précédemment et listez pour chaque utilisateur ses cas d’usages.
Commencez par dresser un inventaire des fonctionnalités. Pour chacune, classez-la dans une des catégories ci-dessous:
Ce classement, qui est directement inspiré de la méthode MoSCoW, vous permet de faire une première mesure de la valeur métier des fonctionnalités que vous avez identifiées. Il ne s’agit pas pour l’instant de définir un ordre de réalisation, mais bien de chercher à trier ce qui est vital, de ce qui est accessoire dans le projet.
Décrivez par un court paragraphe chaque fonctionnalité en essayant d’expliquer clairement les cas d’usage concernés. Essayez de faire apparaître au maximum les contraintes et règles de gestion liées aux cas d’usages, cela permettra aux candidats d’estimer au mieux la complexité et le coût du projet.
Essayez de faire apparaître les complexités là où il y en a. Les candidats ne connaissent pas votre métier, ils ne sont pas à même de « lire entre les lignes » de votre cahier des charges.
Plus votre cahier des charges expliquera votre métier et mettra en évidence les règles et complexités, meilleure sera la précision de leurs chiffrages.
Pour faciliter ce travail, nous vous conseillons également de réaliser ou de faire réaliser des mockups (ou wireframes). A ce stade du projet, les wireframes sont bien souvent très éloignés de la finalité du projet… l’intérêt est surtout dans l’exercice de leur réalisation qui permet de se placer tout de suite dans le concret du point de vue de l’utilisateur et de commencer à réfléchir et à faire émerger, soit de nouveaux besoins, soit de nouvelles problématiques non identifiées auparavant.
Dans le cas où vous attendez un engagement forfaitaire des candidats, je vous déconseille très fortement de masquer la complexité en espérant obtenir un chiffrage plus bas. Un prestataire peut toujours sortir d’un projet s’il perd de l’argent, et cela même s’il est engagé forfaitairement… De votre côté, vous aurez perdu du temps, de l’argent et vous vous retrouverez à la case départ en devant relancer un nouvel appel d’offres.
Un cahier des charges ne décrit pas que fonctionnellement vos attentes, il doit également décrire ce que vous attendez techniquement: les contraintes, les exigences, la sécurité, la performance ainsi que le niveau de qualité attendu.
Vous devez décrire vos attentes sur ces points pour d’une part obtenir un engagement de la part du prestataire qui réalisera l’application mais également pour vous permettre de comparer des offres des candidats équivalentes et réalisées sur la même base d’exigences.
La pérennité de la solution technique sur laquelle s’appuieront les développements de votre application est un élément à ne pas négliger. Nous vous encourageons à, soit orienter directement les candidats qui répondent à votre cahier des charges vers la ou les technologies que vous choisissez, soit à intégrer les exigences techniques suivantes dans votre cahier des charges:
De plus, vous devez intégrer dans votre cahier des charges des exigences vous garantissant la qualité du code produit ainsi qu’une bonne maintenabilité de la solution après livraison.
En précisant ce niveau d’exigence qualitatif, vous maîtrisez le niveau de dette technique de votre projet et ne la subissez pas (d’autant plus que cela vous permettra de comparer des offres des candidats équivalentes techniquement).
Vous pouvez, cependant, décider de « contracter » une dette technique parce que vous avez un budget limité ou que vous souhaitez mettre très rapidement sur le marché votre produit pour doubler la concurrence. La dette technique est ici choisie et assumée, mais gardez en tête qu’une dette technique se paye tôt ou tard.
Vous devez aborder la sécurité applicative dans votre cahier des charges pour obtenir un engagement de la part des candidat sur ce point. Je vous conseille de préciser que vous effectuerez un audit de sécurité en cours et en fin de projet (et je vous conseille de le faire).
Afin d’obtenir un engagement sur les performances, vous devez préciser dans votre cahier des charges les volumétries attendues. Ces volumétries portent sur le nombre d’utilisateurs, sur le nombre de données traitées ainsi que l’évolution de ces volumétries dans le temps. Cela permettra au prestataire de vous faire une proposition technique cohérente avec la croissance envisagée de votre application.
Je vous conseille également de préciser les temps de réponse attendus sur lesquels vous attendrez un engagement du candidat.
Vous pouvez préciser les technologies à utiliser dans la conception (si des langages ou solutions sont préférées)
Toutes les technologies ne sont pas équivalentes en terme de coût de maintenance, de licences, … De plus, vous devez vous orienter vers des technologies répandues pour lesquelles il existe une offre importante sur le marché.
Afin de maîtriser les coûts de la reprise de votre application en interne ou par un autre prestataire, vous ne devez pas vous enfermer dans des technologies connues d’une poignée de prestataires « experts » et à coût élevé et pour lesquels, généralement, les ressources sur le marché du travail (pour une embauche) sont également rares (et chers) et difficile à intéresser.
Précisez dans votre cahier des charges les plateformes cibles qui doivent être compatibles avec votre application:
Cela vous permettra d’obtenir un engagement de la part du prestataire sur le bon fonctionnement de l’application sur les plateformes cibles. A noter que plus le nombre de plateformes cibles sera élevé, plus cela représentera une charge importante pour le prestataire (et donc un coût pour vous) car cela nécessitera un effort de tests et d’adaptation plus important.
Précisez également de quelles manières l’application à réaliser devra s’interfacer avec votre S.I. Pour cela, décrivez votre S.I, les plateformes existantes ainsi que les outils et logiciels qui graviteront autour de l’application à réaliser.
Si votre projet est lié à d’autres contraintes, n’oubliez pas de les préciser dans le cahier des charges, comme par exemple:
Même s’il existe un certain « état de l’art » sur la qualité des développements, les propositions techniques des candidats peuvent varier de manière importante. Pour un prestataire, la qualité, la sécurité et les performances peuvent, malheureusement, « assez facilement » devenir des variables d’ajustement pour rentrer dans un budget ou un planning client.
De votre côté, cela peut vite devenir compliqué de comparer des offres qui ne se basent pas sur le même niveau d’engagement qualitatif, ni sur les mêmes exigences et contraintes techniques.
Pour certaines fonctionnalités, il peut y avoir une certaine incertitude sur la faisabilité technique ou sur le fait que le coût de réalisation soit « raisonnable » par rapport au projet.
Nous vous conseillons de lever rapidement ces doutes en évaluant la faisabilité technique ainsi que le coût de ces points avant la publication de l’appel d’offres. Réalisez ou faîtes réaliser des POC (proof-of-concept) ainsi qu’une évaluation du temps de réalisation de ces points pour déterminer s’ils sont réalisables dans un budget cohérent avec votre projet.
Avant la publication de votre cahier des charges dans le cadre d’un appel d’offres, évaluez le coût de réalisation des fonctionnalités. Si vous n’avez pas les compétences techniques pour le faire, faîtes réaliser une évaluation par un prestataire « neutre » (ne répondant pas pour la réalisation). N’oubliez pas dans votre évaluation de considérer les charges de pilotage, de tests, de spécifications,… du prestataire. Dans le cadre d’un engagement forfaitaire, ces charges peuvent, en effet, représenter jusqu’à 2x la charge de développement.
Evaluez également la disponibilité nécessaire de vos équipes en interne.
Une fois l’évaluation des charges réalisée, vous pouvez procéder à la priorisation des tâches en fonction du coût et de la valeur métier de chaque fonctionnalité… Vous pourrez ainsi définir un macro-planning et une roadmap de réalisation de votre application en la découpant éventuellement en différents lots fonctionnels.
Cette étape vous permettra tout d’abord de mettre en évidence d’éventuels problèmes liés au budget ou au planning du projet et ainsi d’arbitrer sur certaines fonctionnalités avant la publication de l’appel d’offres. De plus le macro-chiffrage et le macro-planning que vous aurez réalisés vous permettront d’avoir une base de comparaison quand vous recevrez les offres des candidats.
Evitez de réaliser un cahier des charges « liste au Père-Noël » qui contiendrait trop de fonctionnalités « accessoires » non vitales, peu détaillées ou avec une grande incertitude sur la complexité de réalisation. En faisant cela, vous risqueriez de décourager les candidats et de limiter ainsi le nombre d’offres reçues.
Pour chaque fonctionnalité, croisez les éléments suivants: coût de la fonction / valeur métier / complexité et arbitrez si besoin. Si vous souhaitez toujours les intégrer à votre cahier des charges, vous pourrez toujours les demander « en option ».
Identifiez les contraintes de réalisation de votre projet autant interne qu’externe et décrivez les dans le cahier des charges.
N’ayez pas peur d’indiquer une fourchette du budget du projet. Cela permettra d’éliminer d’emblée les offres farfelues ou les candidats ne pouvant pas répondre dans votre budget.
Précisez dans votre cahier des charges les documents que vous attendez des candidats. Je vous conseille de demander les éléments suivants:
Afin de vous faciliter le travail d’analyse et de comparaison des offres reçues, vous pouvez également joindre les annexes, ci-dessous, à compléter par les candidats:
En effet, dans le cas où les candidats ne répondent que partiellement aux fonctionnalités, il peut vite devenir difficile, voir impossible, de comparer des offres qui ne se basent pas sur le même périmètre fonctionnel.
Le travail autour de la rédaction du cahier des charges est un travail passionnant où vous allez commencer à imaginer et à donner vie à votre projet en vous projetant dans sa réalisation.
Il vous permet, d’une part, de vous poser les bonnes questions quant à votre besoin et la manière d’y répondre, mais c’est également l’occasion de réaliser un document partagé par tous les acteurs du projet et qui formalisera les objectifs et les attentes de l’application à réaliser.
Nous vous accompagnons dans la réalisation d’une étude préalable pour affiner le besoin, définir les exigences fonctionnelles et techniques et évaluer la faisabilité technique, le budget et le planning de votre projet.
Vous êtes dans les premiers pas de votre projet…
Si vous voulez en savoir plus, cliquez sur le bouton ci-dessous…