La rédaction d'un cahier des charges pour un projet agile

Quand on parle de projet informatique, d'autant plus pour un développement d'un nouveau projet, on parle rapidement de la nécessité d'un cahier des charges, d'une expression de besoin ou d'un simple brief projet, peu importe le nom de de document écrit. Ce document va formaliser les besoins, les attentes et les contraintes pour le développement du projet. Son écriture peut être fastidieuse, rarement exhaustive, et sujette à discussion lorsque la réalisation du projet est faite par la suite en mode forfait où un prestataire s'engage à réaliser le périmètre décrit.

En agilité, où on privilégie la co-conception, le cahier des charges disparaît de la méthode de développement qui va privilégier backlog et user stories.

Est-il du coup toujours nécessaire en agilité ?

Il y a des contextes où écrire un cahier des charges n'est parfois pas nécessaires. Vous avez déjà confiance dans un prestataire, votre équipe de développement est déjà constituée, vous pouvez expliquer sommairement votre projet à l'oral, le projet est la refonte d'un existant connu, etc. Il nous arrive donc parfois de démarrer un projet en agilité en constituant le backlog directement et en lançant la réalisation sans attendre l'écriture d'un document ressemblant à un cahier des charges.

Mais si vous avez besoin de choisir un prestataire ou même de décider si le projet doit être lancé en interne , vous allez sans doute attendre une réponse à votre demande présentant une solution technique possible avec un budget chiffré. C'est le contenu de la réponse et le budget donné qui vous permettront de valider que le projet est réellement faisable. Le cahier des charges aura alors permis de définir le budget nécessaire et donc un objectif en nombre de journées de développement nécessaires.

Mais en agilité, le cahier des charges n'a pas par la suite la même valeur qu'il peut avoir pour la réalisation d'un projet au forfait où le prestataire s'engage sur le périmètre de ce cahier des charges. Car en agilité, ce qui comptera par la suite c'est les user stories. Il faudra donc oublier un peu ce cahier des charges qui aura surtout servi à répondre à des questions avant le début du projet. Après, si un prestataire s'engage à réaliser votre projet en méthode agile tout en étant au forfait, c'est une autre histoire mais demandez vous comment il peut réaliser cet exploit de s'engager sur un périmètre qui doit pouvoir évoluer tout au long de la conception...

Quelle forme doit il avoir ?

La première question qui revient souvent dans nos échanges, c'est est-ce que vous avez un modèle ? Non, il n'y a pas de modèle type. Vous trouverez peut être des modèles censés vous aider à rédiger un cahier des charges en répondant à des questions mais le résultat est souvent fort peu probant. Et il n'y a pas de modèle type car chaque projet est différent.

Sur la forme donc, privilégiez plutôt une rédaction à des slides et des phrases à des bullet points. Attention aussi à formuler les phrases sans trop d'équivoques. Mieux vaut expliciter quelque chose que de le laisser implicite en pensant que son interlocuteur doit savoir de quoi on parle.

Si vous mettez des abréviations, pensez à en donner la définition tout comme vous pouvez essayez de définir les mots clés de votre métier. Mettre un petit lexique des termes les plus utilisées est souvent appréciable, tout comme avoir un sommaire, avec des pages numérotées pour pouvoir s'y référer lors de questions supplémentaires.

Présentez vous

Si vous avez sollicité des prestataires qui ne vous connaissent pas, pensez à présenter votre société, son métier, ses clients, ses particularités et ce qui pour vous semble important en fait. Cela peut paraître sans intérêt de prime abord mais ça permettra à votre interlocuteur de comprendre a minima qui vous êtes et fera une bonne introduction pour votre lecteur.

Le contexte

Votre projet a une histoire, racontez la. D'où est venu l'idée ? Que vient il remplacer ou modifier dans votre organisation ? Quelle difficulté vient il soulager voire effacer ? Il est intéressant aussi d'expliquer les ambitions et les attentes le concernant. La réponse ne sera sans doute pas la même qu'il s'agisse d'un projet clé pour l'entreprise ou d'un développement annexe peu critique.

Les fonctionnalités

Que doit faire votre application ? Il ne s'agit pas là de rentrer dans les micro détails. Rappelez vous que vous n'êtes pas en train d'écrire des spécifications. Par contre, un panorama complet des fonctionnalités attendues est nécessaire pour comprendre ce que vous attendez comme résultat.

Vous n'avez pas à parler technique, pas la peine par exemple d'essayer de dresser un modèle de données ou faire un schema. Il sera bien plus intéressant de comprendre ce que vous souhaitez faire plutôt que comment vous imaginez ça sera fait. Décrivez donc vos besoins métiers et comment vous comptez vous servir de l'application.

Ne laissez pas par contre de non-dit ou d'éléments imprécis. Dans un développement sur mesure, il n'y a pas de fonctionnalités toutes prêtes. C'est pourquoi il est important de vous projeter et imaginer toutes les capacités de votre application.

Les particularités

Vous pouvez détailler les points importants de votre application. Il y a forcément des parties qui vous semblent un peu plus complexes dans votre projet et qui méritent toute l'attention de votre futur prestataire. N'hésitez pas à décrire de façon plus approfondie ce qui vous semble sortir de l'ordinaire.

Les contraintes

Si votre projet a quelques contraintes, expliquez les. Même si cela vous semble anodin, c'est le moment où jamais de prévenir votre prestataire. Peut-être que, par exemple, vos utilisateurs seront souvent déconnectés car travaillant majoritairement dans une zone non couverte par un réseau donnant accès à internet auquel cas la conception de la solution devra prendre en compte cette problématique. Ou peut-être est-ce une contrainte plus technique : votre application sera hébergée directement par vous et vous avez comme pré-requis d'utiliser une base de données bien particulières. Même si vous n'êtes pas sûrs qu'un point en particulier puisse être une contrainte, votre prestataire pourra l'infirmer ou le confirmer, et au moins il aura toutes les clés en main pour comprendre vos problématiques.

Les délais et le budget

Enfin, les deux contraintes principales sont souvent les délais et le budget. Bien souvent, vous allez naturellement communiquer sur les délais en donnant une date de mise en production souhaitée. Gardez bien à l'esprit que cette date doit être réaliste et mise à l'épreuve d'une évaluation chiffrée mais aussi de la capacité du prestataire à mettre en place l'équipe nécessaire. Il faut donc que cette date soit aussi réellement une contrainte de votre part, si vous n'avez pas cette contrainte, précisez le tout simplement.

A l'opposée, vous allez être réticent à communiquer un budget alors que pourtant cette contrainte, car c'en est une, peut elle aussi avoir un fort impact sur la solution proposée. Elle permet d'adapter au mieux la solution possible à votre budget et de cadrer avec votre ambition. Si vous pensez que votre prestataire peut tirer parti de l'annonce de votre budget, ça ne peut pas être le cas s'il facture le temps passé sur votre projet agile.

Au final, oubliez le un peu...

Et une fois votre cahier des charges écrit et votre projet lancé, pensez à le mettre un peu de coté quitte à l'oublier. Le cahier des charges a rempli son rôle. Il vous aura permis de vous assurer que votre prestataire et vous parliez du même projet et en avait la même compréhension minimum. La méthodologie agie viendra prendre la relève pour co-concevoir le projet au fur et à mesure. Pour que votre projet soit une réussite, votre cahier des charges devra rester à sa place et ne pas venir polluer l'agilité de votre projet.