Le chiffrage de projet informatique à partir du cahier des charges

Ne sachant pas par quel bout prendre le sujet du chiffrage dans le cadre de la gestion de projet informatique, j’ai décidé d’en parler comme ça se passe dans la vraie vie : un cahier des charges arrive dans votre boîte mail et un chiffrage du projet vous est demandé pour la veille. Comment faire ?

Cahier des charges : lire, comprendre, relire, poser des questions

Voici les premiers réflexes à avoir à la réception d’un cahier des charges :

  • Il faut lire, relire et encore relire le cahier des charges (voir l’article sur la vision périphérique et le photoreading, ça peut servir)
  • S’imprégner du contexte : demander du contexte au commercial qui a reçu le cahier des charges, consulter l’historique du compte.
  • Comprendre le besoin : pourquoi souhaitent-ils développer cette application ? s’agit-il d’une refonte d’un existant ? d’une nouvelle application from scratch ? à quel besoin cela répond-il concrêtement ?
  • Comprendre les enjeux : quelle est l’urgence et la criticité du projet pour le client ? y’a-t-il un contexte politique (arrivée à un poste, concurrence avec un autre service, …) ? Est-il moteur sur le projet ou bien a-t-il récupéré une patate chaude ? mesurer son engagement.
  • Contacter le client : ne serait-ce que commercialement, sinon pour mieux comprendre le besoin, préciser des points du cahier des charges et poser des questions utiles. Une question utile va amener une réponse qui va vous aider à chiffrer. Que la couleur d’un bouton d’un écran d’application soit bleu, rouge ou vert, ne va rien changer au chiffrage que vous allez effectuer, soyez pertinents, vous avez peu de temps !

Les informations recueillies vont vous permettre de donner du contexte à un chiffrage, inconsciemment vous allez en tenir compte pour évaluer les problèmes potentiels, les risques. Cela va vous aider à vous projeter dans le projet (voir également les articles sur le planning projet) et alimenter votre expérience à la fin du projet (un contexte politique avec beaucoup d’interlocuteurs va par exemple entraîner souvent une surcharge en gestion de projet, un client peu impliqué peut entraîner une recette laborieuse, etc.).

Le chiffrage du projet : décomposition en tâches

Le maître mot pendant cet exercice est : décomposer ! mais pas trop … !

J’ai reçu une fois un cahier des charges très minimaliste : « Développer un équivalent à monster.fr » (le site de recherche d’emploi). Je passe sur les doutes que j’avais vis-à-vis de la stratégie autour d’un tel projet .. et mon premier réflexe a été : « Wow ! un monster like ? rien que ça .. (soupir)… ». Il faut rapidement commencer à décomposer le projet en tâches ou pour utiliser des termes appropriés, réaliser le WBS ou Work Breakdown Structure (à sortir en entretien annuel pour avoir une augment’).

Généralement, je pars des scénarios d’utilisation que je déduis du cahier des charges ou que j’ai notés à partir des informations orales du client. Dans tous les cas, ces scénarios servent d’hypothèses de chiffrage et doivent être mentionnés dans la réponse.

Cela peut être assez intuitif : pour l’exemple ci-dessus, il s’agit d’une application web, il y a donc une page d’accueil, puis la possibilité de s’authentifier mais pour s’authentifier il faut d’abord s’inscrire. S’inscrire en tant que candidat ou comme recruteur ? il y a donc plusieurs profils, que peut faire chacun de ces profils ? …

.. et parfois moins intuitif selon le métier auquel vous avez à faire … Il faut donc bien comprendre le fonctionnel pour lister les différents écrans d’ajout, modification, suppression de données, quels sont les reportings attendus, les interactions avec d’autres applications, etc. Garder toujours en tête que vous devez comprendre le fonctionnel dans l’objectif de chiffrer le projet, pas de le spécifier.

Ces étapes vont vous permettre d’établir un premier chiffrage, un premier jet qui va remonter certaines interrogations techniques ou fonctionnelles qui seront ensuite à préciser soit avec un expert technique soit avec le client.

Attention à ne pas trop décomposer sans quoi vous allez « gonfler » les charges sans vous en rendre compte car généralement on ne chiffre pas en dessous d’un seuil propre à chacun (0,25 jour .. 0,5 jour pour d’autres … 1 jour ou encore 10 jours pour certains ..). Donc si on décompose trop (développement du formulaire, ajout du bouton submit, affichage du message d’erreur, insert en base de données, …) on se retrouve bloqué par le seuil et un formulaire web simple d’ajout de données va prendre 4 jours de développement .. Et généralement soit le client vous le dit gentiment soit vous ne gagnez pas le projet .. A doser donc !

En pratique, les pièges à éviter pour le chiffrage

Eh bien là aussi, il faut se projeter dans l’application et sa réalisation. Restons sur l’exemple de l’application web du monster like :

– Pour commencer à développer un écran, il faut pouvoir le faire tourner dans un environnement de développement. Ca paraît évident mais combien de fois sa mise en place n’est pas chiffrée ? c’est dommage de commencer les développements avec 3 jours de retard dès le départ .. Il y a donc quelques questions à se poser : Quelles sont les contraintes techniques ? le choix du langage a-t-il été fait ? sur quel système d’exploitation tournera le serveur web ? quelle est la base de données ? Plus proche vous serez de l’environnement cible, moins vous risquez d’avoir de problèmes à la livraison. Donc la première tâche est de recréer un environnement identique à la cible et ça se chiffre. En réalisation d’une part et en rédaction dans un dossier d’architecture.

– Pour la réalisation de l’application, regrouper par briques fonctionnelles (espace administration, espace recruteur, espace public, …) est une bonne idée, ça permet de garder une cohérence et de regrouper les tâches.

Lister chacun des écrans nécessaires et penser à la mécanique derrière. Si vous n’arrivez pas à chiffrer, décomposez ce qu’il y a à faire pour vous aider à voir le temps qu’il faudra y passer.

Penser aux tests : certains développements nécessitent des tests plus ou moins longs (environnement à simuler, jeux de test à créer, ..), il faut donc tenir compte du temps passé à tester une fonctionnalité. Si l’application doit s’authentifier sur un annuaire d’entreprise, il faut pouvoir le tester et parfois il faut se déplacer sur place pour le faire (on peut aussi demander au client de le faire à notre place ..), c’est donc à prendre en compte.

Comment chiffrer les spécifications d’un projet

Chiffrer la réalisation et la spécification en même temps : chaque tâche ne se spécifie pas et ne se réalise pas de la même manière, vous passerez plus ou moins de temps selon la nature de la tâche. Evitez les règles et abaques de chiffrage toutes faites sans les comprendre : « Les spécifications c’est 20% de la réalisation. » en est un exemple. Vous pouvez avoir un écran de reporting fastidieux à spécifier avec le client car le besoin n’est pas clair mais « classique » et rapide à réaliser.

Défendez votre chiffrage : pour un projet de développement d’une application fonctionnelle, on ne peut pas comprendre le métier du client en 2 heures de réunion, ce serait réducteur … Donc soyez réaliste sur le temps à passer, expliquez-le et défendez-le.

– Il faut tenir compte : de la prise de contexte, de la compréhension, de la rédaction, de la relecture, de l’intégration des retours clients, des mises à jour pendant la phase de réalisation, …

Attention aux entrants : les documentations fournies par le client doivent être figées, plus aucune mise à jour des fournitures ne doit intervenir pendant la phase de spécifications voire le projet sinon vos hypothèses de chiffrage ne sont plus bonnes. Elles doivent également être pertinentes : imaginez que votre client vous envoie 3 fois par semaine une mise à jour d’une documentation fonctionnelle de 500 pages sans vous dire ce qui a été modifié précisément .. ça promet des nuits blanches … surtout si 10 pages seulement vous sont utiles. Des entrants figés et pertinents sont donc un pré-requis à mentionner dans la réponse.

Quelles bonnes pratiques pouvez-vous partager ?

Suite au prochain épisode .. dans la deuxième partie !

12 réflexions au sujet de “Le chiffrage de projet informatique à partir du cahier des charges”

    • Gardes en tête que l’important c’est qu’à la fin de l’exécution du projet, tu évalues ton chiffrage initial et que tu regardes pourquoi il y a eu des différences. Bon courage Aurélien !

      Répondre
  1. Bonjour JP et merci pour cet article. Je suis à la recherche d’un developpeur pouvant m’aider à chiffrer un projet de communauté en ligne dans le site de Fashiolista. Aurais tu des contacts pour m’aider?

    Merci d’avance

    Anaya

    Répondre
    • Bonjour Anaya, j’ai transmis ta demande mais ça semble très occupé déjà.
      A suivre ..

      Pour prendre de l’avance, tu peux préparer un cahier des charges précis avec la description de chaque fonctionnalité. Plus ce sera précis, et plus le chiffrage pourra l’être aussi.

      Répondre
  2. Bonjour,
    On me propose un chiffrage de projet Agile basé sur des nombres de semaine (et non de jours) suivant la suite de Fibonacci : hormis que cette méthode me parait aberrante et extraordinairement grossière, je me demande si cela est classique ou récurrent, à votre connaissance ?
    Merci d’avance
    S.L.

    Répondre
    • J’ai piloté du projet agile mais au sens (très) large, et je ne suis pas familier avec la méthode de la suite de Fibonacci.

      En regardant rapidement, si j’ai bien compris, cela part du principe que plus une fonctionnalité est grosse / complexe et plus l’évaluation est imprécise. Et donc on attribue une estimation plus élevée selon les valeurs de la suite de Fibonacci. J’ai bon ? 🙂

      Pour ma part, je suis old school et j’aime les choses simples : si une fonctionnalité est trop grosse et mal cadrée en périmètre, je la découpe, et j’estime combien de temps ça va prendre pour chacune des parties. Agile ou pas agile.

      Parce qu’au final, j’aime bien dire à un développeur :
      1) ce qu’il a fait de manière claire et cadrée
      2) combien de temps il a pour le faire pour qu’il me dise si l’estimation est réaliste ou non

      Pour moi, une fonctionnalité trop grosse ou trop complexe c’est qu’elle n’est pas claire et on va dans le mur direct en terme de planning / budget (ce qui ne plait pas au client généralement). Quant à utiliser des « points » au lieu de durées (qui dépendent de la personne qui réalise quand même !), je trouve que ça perd encore plus le développeur. Pour moi c’est plus clair de dire à quelqu’un qu’il a 2 jours pour développer une fonctionnalité que de dire que la fonctionnalité a 13 points de complexité.

      Mais comme dit, mon expérience agile / Scrum est limitée, il y a certainement un intérêt à utiliser ce genre de choses mais jusqu’à présent, je ne l’ai pas vu …

      Répondre
  3. Bonjour, je me permets de relever une typo (dans « défendez votre chiffrage ») : « expliquer le » -> « expliquez-le ».

    Merci pour cet article de qualité qui m’a beaucoup aidé !

    Répondre

Répondre à Lucas Annuler la réponse