fbpx
Sélectionner une page

Introduction

Rédiger un cahier de charges, un exercice casse-tête pour vous ? Pour faire développer une application web, mobile ou tout autre logiciel, le cahier de charges est un document exigé dans un cadre professionnel.

Tout commence par vous, non informaticien, chef de projet ou chargé de rédiger un cahier de charges pour votre projet informatique. C’est vous la maitrise d’ouvrage ou MOA, c’est vous qui maitrisez le domaine à informatiser. A ce titre, votre travail consiste essentiellement à exprimer les besoins en termes de fonctionnalités. D’où l’appellation : cahier de charges fonctionnel.

Avant de vous proposer un modèle simple, faisons un cadrage : votre périmètre de travail en tant MOA, la définition du cahier des charges fonctionnel et son objectif.

Cahier de charges, le périmètre de la maîtrise d’ouvrage

    Comme annoncé, tout commence par le maître d’ouvrage (MOA). Fort de sa parfaite maitrise du domaine du projet, celui-ci exprime les besoins en termes de fonctionnalités. On dit qu’il décrit les les spécifications fonctionnelles. C’est à juste titre que ce document est appelé cahier de charges fonctionnel.

    Par la suite, l’informatique complète le document avec les spécifications et les contraintes techniques pour en faire un cahier de charges ou CDC en abrégé.

    Objectif du cahier de charges fonctionnel

    Elaborer un cahier des charges est indispensable dans le cadre du développement d’un projet, d’un logiciel ou une application. Dans la majorité des cas, ce document sert de contrat avec le prestataire ou l’équipe de développement.

    Pour ce faire, il définit le problème à résoudre, l’objectif visé, le périmètre de travail, identifie et déccrit les fonctionnalités à développer, afin que toutes les parties prenantes comprennent bien le projet. L’idée est de faire connaître exactement les attentes et les résultats attendus par tous les acteurs impliqués dans le projet. Voici donc notre guide pour vous faciliter la rédaction.

    Modèle de cahier de charges

    1. Contexte et définition du problème

    Si le cahier de charges est adressé à des prestataires externes, il est bon de présenter l’entreprise pour laquelle le projet sera réalisé. Il suffit de lister les informations essentielles à la compréhension de la raison d’être de l’entreprise.

    Ensuite, on expose les fondements de la demande. Pour le technicien, connaitre le problème à résoudre permet de proposer des solutions adaptées. De plus, donner du sens au développement facilite la compréhension de vos besoins et de vos contraintes.

    Exemple

    BAGLOU est une Start Up de distribution de colis et de plis. Pour assurer efficacement ses livraisons, BAGLOU s’est doté d’un parc auto composé de véhicules et de motos.

    Depuis l’an dernier, nous avons enregistré une hausse des dépenses liés à notre parc auto. Le DG a demandé une analyse de ces dépenses afin de proposer des pistes permettant de les réduire. Nous utilisons MS Excel pour gérer le parc auto. Le suivi n’est pas évident à cause de la non marise de l’outil (doublons, erreurs de saisies, trop de retraitements pour générer des états pertinents. Nous voulons donc passer de MS Excel à une application pour nous simplifier la tâche.

    1. Objectif du projet

    Ici, on ne parle pas d’objectif du cahier des charges, mais de l’objectif du projet. L’objectif du projet c’est le pourquoi du projet. Et, cet objectif peut être décliné en des objectifs spécifiques. Ces objectifs peuvent être quantitatifs, qualitatifs et datés. Une façon de fixer ses objectifs est de se demander quelles mesures pertinentes et engageantes prises montreront que le projet est un succès ?

    Exemple

    Dans notre exercice de parc auto, l’objectif est l’optimisation de nos dépenses de parc auto. De façon spécifique, nous voulons :

    • Découvrir les postes de dépenses « budgétivores »
    • Identifier les engins qui gonflent nos charges
    • Connaitre les périodes de pics de dépenses

    Les réponses à ces questions nous permettons de comprendre et solutionner le problème posé.

    1. Périmètre du projet

    Lors de la réalisation d’un cahier des charges, on prend le soin de limiter le périmètre du projet. Cette disposition aide à rester focus sur ce qui constitue le projet. Le périmètre concerne les acteurs internes et/ou externes, les processus, les zones géographiques concernés par le projet, etc.

    Exemple

    L’application sera utilisée par l’équipe en charge de la gestion du parc auto avec un tableau de bord accessible au DG aussi. Le logiciel restera focus sur les dépenses du parc auto. Les conducteurs ne sont pas utilisateurs de l’application. 

    1. Description fonctionnelle du projet

    Cette section concerne l’expression des besoins fonctionnels. Cette section demande d’identifier et de décrire les processus qui couvrent l’activité. Voici une définition simplifiée d’un processus.

    Définition de processus : selon ITLV4, c’est un ensemble d’activités interdépendantes et interagissantes qui transforment des entrées en livrables. Pour simplifier on dira qu’un processus décrit ce qui est fait pour atteindre un objectif. Et, on décrit les processus dans les procédures.

    Exemple, édition d’une facture. Ce processus est décrit comme suite :

      • se connecter à l’application,
      • rechercher une facture selon des critères
      • imprimer la facture
    1. t échéance

    L’élaboration d’un cahier de charges fonctionnel inclut aussi la définition des livrables. Les livrables sont généralement :

    • l’application, les interfaces développées
    • la base de données, le système de base de données et les données
    • les codes sources, les codes écrits par l’équipe de développement

    Pour une application développée en interne, pas de problème. Mais, lorsque le logiciel est développé par un prestataire externe, bien définir le propriètaire de chaque livrable évite des suprises désagréables. Bien attendu, ce choix a un coût, une incidence sur le budget du projet.

    Pour finir, on donne un délai pour la livraison du produit final