Nous pouvons vous affirmer, sans aucun doute, que le développement de votre application web vous coûtera entre une voiture 🚘 et une maison 🏡 ! Si cette fourchette ne vous convient pas, vous devrez rédiger ✍ un cahier des charges car un projet web – surtout s’il est stratégique – ne se lance pas à la légère. Il vous engage par la vision que vous portez et il vous « oblige » à décrire les fonctionnalités attendues pour pouvoir estimer les travaux 🏗. C’est tout simplement le « premier élément clé de succès » de votre projet.

Avant de vous lancer, veuillez noter que cet article a été écrit à l’attention d’un.e dirigeant.e ou d’un.e décisionnaire dans une PME ou une ETI (Entreprise de Taille Intermédiaire) qui porte un projet de développement d’une application web 👏.

Ceci étant dit, un cahier des charges vous permet de définir le périmètre fonctionnel de votre projet avant de solliciter des prestataires pour qu’ils puissent estimer les travaux associés. Pour vous, c’est un peu comme retourner à l’école ^^ quand vous deviez faire des dissertations (moi j’adorais ça !) mais sur un sujet concret pour votre entreprise. Cet exercice sera dans tous les cas bénéfique car il va vous pousser à vous projeter dans votre projet et il va diminuer le risque d’écart de perceptions entre vous – le donneur d’ordre – et l’équipe de développement.

PS : si vous n’avez que 5 minutes à accorder au sujet (bouh…👎) allez directement au paragraphe « Notre exemple de plan pour rédiger un cahier des charges web » 😉

 

Nos conseils avant de se lancer dans la rédaction :

Bien calibrer son cahier des charges

La première étape de votre rédaction consiste à mesurer 📏 votre effort  pour ne pas rédiger un « brief » trop léger pour définir votre vision, ni retarder votre projet pour écrire un cahier des charges trop détaillé 📚 qui deviendra, comble du paradoxe, difficile à comprendre pour les développeur.se.s. En effet, le terme cahier des charges regroupe en réalité différents types de documents en fonction de la taille de votre projet, il peut s’agir d’un « brief » par e-mail, d’un document descriptif de 3 à 10 pages, en passant par des spécifications détaillées de plus de 100 pages… Nous vous conseillons de refreiner vos velléités de produire un document trop gros qui risque d’être contre-productif, ce n’est pas grave si vous oubliez des détails, vous devez surtout donner la vision « macro » 🔍 de votre projet. Gardez à l’esprit qu’une expression de besoins de 6/7 pages bien construite 🏆 est généralement suffisante pour exprimer la vision d’un projet web.

Communiquer sur votre projet au travers du cahier des charges

La rédaction d’un cahier des charges n’est pas uniquement un exercice de style, elle implique de se mettre à la place de vos interlocuteurs pour vérifier qu’ils vous comprennent 😉. Ce qui est évident pour vous dans votre métier n’est peut-être pas du tout évident pour un prestataire et peut devenir une source d’échec pour votre projet. Ainsi, le cahier des charges doit avoir pour fonction d’être un outil de communication « universel » pour exprimer le besoin d’un projet 📣, aussi bien pour vos collaborateur.rice.s que pour un prestataire qui ne vous connaît pas. Vous allez donc devoir rendre votre vision compréhensible à tous et faire en quelque sorte votre « auto-psychanalyse » 🃏 (il était temps^^) pour différencier ce que vous avez en tête de ce qui doit être compris sur, le contexte, l’expression des besoins métiers, les objectifs, et les retours sur investissement attendus.

Rédiger vous-même votre cahier des charges

Nous conseillons très fortement de ne pas déléguer ⛔ la rédaction de votre cahier des charges car vous ne serez plus porteur de la vision et vous perdrez une manière simple de vous investir dans votre projet. A la rigueur si vous n’avez pas assez de temps, mettez en place la structure du document, faite le plan, mettez vos idées « grosses mailles » puis confiez la rédaction à proprement parlé à un.e de vos collaborateur.rice.s ou un.e consultant.e.

Définissez votre besoin fonctionnel

Autant vous le dire tout de suite, on n’attend pas de vous que vous vous transformiez en expert technique ^^. Votre rôle consiste principalement à décrire les fonctionnalités attendues et certainement pas à définir quelles technologies utiliser. Il vaut mieux parler de vos « besoins » que des solutions. Votre prestataire précisera lui-même la partie technique : les « inputs », l’architecture de votre projet (la stack technique), la description des mécanismes de manipulations de données, les solutions d’hébergement etc. En ayant une certaine liberté, vos prestataires vous proposeront les meilleures technologies 👍 qui favoriseront le succès de votre projet. Par contre, si vous avez du temps, vous pouvez compléter votre cahier des charges avec des maquettes ou des schémas de workflow pour inspirer l’équipe de développement et préciser votre vision.

 

Notre exemple de plan pour rédiger un cahier des charges :

Il n’existe pas « les 10 commandements » 📜 pour bien rédiger un cahier des charges web… mais nous allons tout de même vous donner un plan généraliste pour aborder les principaux éléments attendus par les développeur.se.s pour pouvoir estimer leur travail. A ce stade, vous entrez dans la partie rédaction, et nous vous conseillons de choisir un support où vous êtes à l’aise (.docx, .pptx etc.) afin de perdre le moins de temps possible pour la mise en forme de vos idées.

Voici le plan que nous vous proposons (ta-ta-tin) :

Introduction (1/2 à 1 page) :

L’introduction est une partie synthétique et stratégique 🎯. Elle va donner l’impulsion et initier le style de votre document, aussi n’hésitez pas à passer du temps de dessus pour qu’elle soit la plus claire possible en considérant, qu’à l’écrit comme à l’oral, les débuts doivent donner rapidement la ligne directrice de votre pensée pour que votre interlocuteur vous comprenne. La première partie de l’introduction situe le contexte du projet : votre structure, votre équipe sur le projet, le porteur du projet (vous), votre marché. La deuxième partie exprime votre besoin en détaillant votre problématique, par exemple, vous ne pouvez pas traiter toutes les sollicitations de vos clients, votre équipe est débordée par la charge de travail, un de vos partenaires vous impose d’automatiser vos échanges, vos clients demandent à gérer eux-mêmes leurs comptes dans un espace clients etc. Vous pouvez, pour illustrer vos propos, ajouter un ou deux exemples d’applications équivalentes de vos concurrents. La troisième partie anticipe les résultats attendus : augmentation du nombre d’affaires réalisés, amélioration de la productivité de votre équipe, augmentation de la satisfaction etc.

L’introduction aide les développeur.se.s à contextualiser le projet et à comprendre votre besoin ce qui leur permettra être proactif 💡. N’oubliez pas qu’une agence de développement est en mesure de comprendre toutes vos problématiques si elles sont bien explicitées ^^.

1/ Description fonctionnelle de la solution (3 à 4 pages) :

Il s’agit du gros morceau de votre document et la partie qui doit exprimer précisément votre vision sur la solution.

Avant de vous lancer dans la rédaction, vous pouvez faire un schéma de l’arborescence (sous forme d’un arbre) entre les différentes pages envisagées pour votre solution. Ce schéma vous servira de guide 🗂 pour la rédaction (page d’accueil, page profil, page recherche etc.).

En ce qui concerne la rédaction, l’exercice consiste à vous projeter dans votre solution et vous mettre à la place d’un utilisateur pour décrire une navigation type au sein de votre future solution (comme si elle existait déjà). Pour chaque page, vous pouvez lister et décrire ce que vous envisagez : pour les fonctionnalités visibles de l’utilisateur final, les fonctionnalités visibles des administrateurs, et les fonctionnalités invisibles des utilisateurs (par exemple, un algorithme ou un système d’envoi d’e-mail automatique etc.). Enfin, si vous envisagez un gros projet, vous pouvez l’allotir en fonction de vos priorités pour définir une première version avec les fonctionnalités essentielles (=MVP). N’oubliez pas que votre cahier des charges est un très bon outil pour vous aider à porter votre vision à court terme et moyen terme pour mettre en place votre stratégie digitale 😉.

2/ Environnement technique (1/2 page) :

Pour cette partie il ne s’agit pas de préconiser une technologie mais de faire l’inventaire des technologies actuelles de votre système d’information 🖥 (site, CRM, Extranet, app mobile, espace clients, etc.) et éventuellement des ressources – internes ou externes – qui s’en occupent 👫 (maintenance, développement, etc). Avec ces informations, le prestataire pourra envisager l’insertion de la solution au sein de votre système d’information. Et puisque vous êtes en train de faire le tour de vos outils informatiques existants, vous pouvez en profiter pour regrouper toutes les documentations sur les technologies que vous avez afin de pouvoir facilement les transmettre à votre prestataire le moment voulu.

3/ Conditions financières (1/2 page) :

Nous vous conseillons fortement d’indiquer votre budget 💰 à tous vos prestataires afin qu’il vous fasse une proposition adaptée à vos moyens. En tant que prestataire, nous avons trop souvent entendu : « Notre budget ? Ça dépendra des réponses que nous avons… » A fonctionner de cette manière, vous allez sélectionner votre prestataire uniquement sur le prix même si vous vous persuaderez du contraire ^^ et vous développerez une application non évolutive qui, si elle est livrée, vous coûtera chère en maintenance… Aussi réfléchissez en amont au budget que vous souhaitez mettre sur le projet et « indiquez » le dans votre cahier des charges. Cette approche vous permet de dimensionner votre projet en termes d’engagement pour votre équipe et pour les prestataires sollicités. Le seul risque que vous avez est d’identifier plus rapidement un budget erroné (trop bas ou trop élevé).

Pour avoir une vision complète des coûts de votre projet, il faut aussi prendre en compte au-delà de votre budget pour les développements les autres coûts 💲 : le temps homme passé par votre équipe (et déductible sur un projet CII), le design (les développeurs sont rarement de grands artistes^^ après c’est à vous de voir), l’hébergement (regardez OVH ou CleverCloud #FrenchTech), les investissements webmarketing pour faire connaître votre solution, etc.

4/ Planning envisagé (1/2 page) :

Vous pouvez indiquer la date souhaitée pour la mise en ligne de la solution et vos éventuelles contraintes en terme de planning, par exemple, le lancement de l’application avant une date précise. Nous vous conseillons de ne pas demander l’impossible en terme de délai à vos prestataires pour éviter qu’ils n’aient pas les disponibilités pour vous répondre. Vous pouvez considérer qu’un projet web nécessite généralement entre 2 et 4 mois de travaux pour arriver à la mise en ligne d’une première version. Aussi, même si vous êtes pressé maintenant que vous vous êtes décidé 😉, vous pouvez compter entre un et deux trimestres après la fin de l’appel d’offres.

5/ Recommandations graphiques (1/2 à 1 page) :

Cette partie consiste à lister les éléments graphiques 🎨 dont vous disposez et qui pourront être utilisés par les développeur.se.s : logo, police, charte graphique, UI kit, Design System etc. Vous pouvez ajouter les éventuelles maquettes de quelques écrans afin d’aider les prestataires à visualiser la solution telle que vous l’envisagez. Il existe un multitude d’outils sur Internet pour faire des maquettes sans être un expert, à titre d’exemple vous pouvez utiliser, Balsamiq qui est très simple à prendre en main (vous ferez des croquis très clairs de votre solution), ou Figma qui est un peu plus compliqué à prendre en main mais beaucoup plus abouti (vous arriverez à faire un Design proche de votre solution finale).

Conclusion :

Pour terminer votre document, vous pouvez fixer les conditions de l’appel d’offres et particulièrement le « planning » 📆 de votre appel d’offres : une date de remise des offres, une date de retour suite à l’analyse des offres reçues, une période pour faire passer des oraux aux prestataires retenus, une date de prise de décision.

 

Votre projet après avoir rédigé un cahier des charges :

Vous pouvez maintenant partager 📤 votre cahier des charges même s’il n’est pas parfait ! La finalité de votre document est de pouvoir solliciter des prestataires ou votre équipe interne pour qu’ils estiment le temps de travail, et par extension le budget associé 💰. Vous allez initier une discussion avec vos prestataires ou votre équipe interne. Ils vont analyser votre document et vous solliciter pour écrire une proposition commerciale sur-mesure qui « redéfinira » le périmètre fonctionnel de votre solution pour pouvoir prendre des engagements. Ces échanges correspondent à un moment décisif et créatif 🎶 ou votre projet peut changer complètement pour la dernière fois avant son lancement 🚀. A noter que nous préconisons de ne pas partager les réflexions entre vos prestataires pour ne pas les influencer, certains ont peut-être des bonnes idées et ils risquent de les garder pour eux afin de ne pas les transmettre indirectement à leurs concurrents. Enfin, ces échanges vous permettront d’identifier les plus motivés et les plus sérieux, mais aussi ceux avec qui vous aurez un « feeling » pour travailler dans une bonne ambiance.

Force est de constater que la tendance actuelle consiste à co-construire en mode agile votre besoin fonctionnel plutôt que de rédiger un cahier des charges mais, en ce qui nous concerne, l’un ne doit pas annuler pas l’autre. L’agilité est un cadre de co-construction entre vous et l’équipe de développement, il ne s’agit pas d’un permis de partir dans tous les sens 😵 en espérant arriver à un résultat à la fin. L’agilité s’appuie sur la définition d’un besoin idéalement exprimé dans un cahier des charges 👍, et ainsi, elle permet d’optimiser la réalisation de celui-ci par rapport à votre budget.

Alors maintenant à vous de jouer… allez au boulot (!) et appelez nous quand vous avez rédigez votre cahier des charges 😉.

Bons projets et à bientôt, l’équipe d’Agilap 🌈

Categories: Projet

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Related Posts

Projet

Alone in the code !

Nous ne comptons plus les fois où nous avons été sollicités par des PME ou des ETI pour regarder le code d’un système d’information développé par une seule personne #OperationBoiteNoire ! Alors est-ce un pari Read more…

Projet

Guide du CII pour les PME innovantes

Toute PME qui souhaite innover se doit de connaître le Crédit Impôt Innovation (CII) ! C’est certainement le dispositif le plus avantageux et le plus simple à activer parmi la multitude des aides à l’innovation en Read more…

Projet

Choisir la meilleure stack technique 

Vous avez certainement déjà entendu le mot « stack » 📣, par exemple, « stack technique », ingénieur-développeur « full-stack », « stackoverflow »… ça parait tellement évident que l’on oublie souvent d’expliquer les enjeux qui se cachent derrière ce concept.   C’est Read more…