Le chiffrage de projet informatique : crédibilité, principes et idées-clés

Beaucoup de choses à dire sur le chiffrage de projets, l’estimation des coûts dépendant de nombreux facteurs et leur suivi encore plus ..

Nous avons vu comment chiffrer un projet à partir d’un cahier des charges, nous avons vu comment chiffrer la gestion de projet, la documentation, une équipe near-shore, voici maintenant un petit récapitulatif – en vrac – des principes et idées-clés.

Quelle crédibilité accorder à un chiffrage ?

N’importe qui peut chiffrer une ou plusieurs tâches, je peux demander à ma grand-mère de me sortir un chiffrage. La qualité d’un chiffrage est donc très relative, et ne pourra être évaluée réellement qu’à la fin de la réalisation de la tâche .. D’ailleurs, le meilleur chiffrage (et encore … voir plus loin), c’est de réaliser la tâche et de voir combien de temps on y a passé .. Rares sont ceux qui vont se challenger par rapport au chiffrage initial et une fois le projet en feu, on a d’autres préoccupations que de faire un bilan ..  Donc tout le monde va avoir son mot à dire pour un chiffrage, y compris ceux qui n’interviendront aucunement dans le delivery (la réalisation des livrables), donc méfiance …

Mais alors comment avoir un chiffrage de qualité ?

La qualité d’un chiffrage dépend du contexte et de l’engagement qui lui est associé : si je m’engage à faire une tâche en 2 jours et que si je dépasse cette charge, je ne suis pas payé, je suis beaucoup plus engagé que si j’annonce 2 jours mais que si je dépasse je serai payé de la charge et du dépassement. La motivation n’est pas la même et le risque non plus. Un chiffrage sans notion d’engagement n’a donc pas de valeur. La SNCF annonce un délai de 2h02 pour faire Paris-Lyon mais finalement ne s’engage à payer une compensation réduite qu’à partir de 30 minutes de retard si le retard est imputable à la SNCF … l’engagement est modéré. Il est donc facile de faire un chiffrage « bas » pour vendre un projet avec peu d’engagement.

Bien évidemment, un niveau de confiance peut déjà exister entre le demandeur et le réalisateur, le chiffrage sert à ce moment-là d’indication plus ou moins fiable pour évaluer le délai de réalisation et/ou le budget associé. Dans ce cas, une évaluation du chiffrage initial en regard du chiffrage réel peut permettre de mesurer régulièrement la fiabilité.

Voir également l’article : Perdre toute crédibilité en 3 minutes en phase d’avant-vente projet

Un chiffrage n’a d’intérêt que s’il est piloté !

Le chiffrage doit être accompagné d’un pilotage : si j’ai 2 jours pour peindre 4 murs, si personne ne vérifie au bout d’une journée que j’en ai bien peint 2, le risque de dépasser les 2 jours augmente .. Il ne s’agit pas de « fliquer » les personnes de l’équipe mais de vérifier qu’elles n’ont pas rencontré une difficulté technique ou fonctionnelle non détectée au préalable ou traîné sur facebook toute la journée … Cela permet de réagir avant la fin du délai : informer à l’avance le client d’un potentiel retard, renforcer l’équipe (si possible), recadrer une personne de l’équipe, faire intervenir un expert, …

L’idéal est de faire chiffrer la tâche par la personne qui va l’exécuter et de lui demander de s’engager dessus (ce qui ne marche qu’avec ceux qui comprennent la valeur de l’engagement). Mais en pratique, le chiffrage est déjà fait .. c’est donc à vocation pédagogique.

Attention, quand la personne qui chiffre est différente de la personne qui pilote le projet ou le réalise, la qualité du chiffrage est également très relative car l’engagement n’est pas le même .. C’est souvent le problème entre les équipes avant-vente et les équipes de réalisation ..

Attention aux règles et abaques de chiffrage

Attention aux abaques et règles de chiffrages toutes faites : appliquer du générique à du spécifique est source d’erreur, plus vous vous projeterez dans la future application, plus votre chiffrage sera réaliste. Et vous perdrez moins de temps à réfléchir si l’écran A est simple, complexe, hors norme, … Faites-vous vos propres règles et/ou tâchez de bien comprendre celles que vous utilisez.

Challenger une répartition de charges selon des pourcentages est donc peu judicieux. On entend souvent la gestion de projet c’est 15% du projet, les spécifications 20% de la réalisation (valeurs à adapter selon les cultures). Si les deux premières parties de ce thème ne vous ont pas convaincus, les points suivants devraient finir de vous expliquer pourquoi les règles absolues comme celles-ci ne sont pas gages d’un bon chiffrage. En effet, celui-ci dépend :

du contexte : s’agit-il de vendre ce chiffrage auprès d’un client dans un contexte d’appel d’offres ? souvent, plus il est petit, mieux c’est pour le client. On peut également être contraint de rentrer dans des grilles de chiffrage imposées avec une répartition spécifique, on peut donc être amené à chiffrer pour l’avant-vente et avoir un chiffrage différent dans le détail pour le suivi projet en interne.

de la personne qui va réaliser : si la personne de l’équipe a déjà exécuté ce type de tâche 20 fois, elle mettra moins de temps qu’une personne qui n’a jamais rencontré ce type de tâche. L’affectation va beaucoup jouer (et beaucoup changer ..).

de la tâche en elle-même bien évidemment : difficulté technique, difficulté fonctionnelle, difficulté à recetter, …

Comprenez ce que vous chiffrez !

Chiffrez sans connaître le budget !

Commercialement, c’est évidemment important d’avoir le budget pour que la proposition commerciale soit dans la cible. Mais en tant que chef de projet, on ne chiffre pas en fonction du budget d’un client : s’il a le budget pour une Clio, on ne peut pas lui fabriquer une Rolls Royce même si c’est ce qu’il souhaite. Après, c’est un effort commercial, mais il ne faut jamais diminuer la charge d’un projet, il faut diminuer le prix de vente. Il faudra toujours 2h02 pour faire Paris-Lyon mais la SNCF peut vous faire une remise de 30% sur le prix du billet (ou pas ..).

Et si le chef de projet connaît le budget ?

Inconsciemment, il va viser ce budget. Connaissant les tarifs journaliers généralement appliqué, il sait au fur et à mesure du chiffrage s’il va dépasser ou non et risque d’influencer les estimations restantes. Cela s’observe souvent chez les chefs de projet débutant qui considère que le budget du client correspond plus ou moins au chiffrage et du coup tâchent de faire rentrer le chiffrage dans le budget.  C’est seulement une question de confiance dans leur chiffrage. Bien sûr, avec l’expérience la confiance augmente et le fait de connaître le budget se fait moins ressentir.

Idées-clés pour un meilleur chiffrage : conclusions .. en vrac !

Un chiffrage doit s’expliquer, un chef de projet doit pouvoir le défendre devant un client : démontrer comment vous chiffrez va rassurer (ou non !) votre client, vous pouvez lui montrer ainsi que vous maîtrisez votre (futur) projet. Par ailleurs, expliquer votre chiffrage va peut-être permettre à votre client de comprendre que le chiffrage de votre concurrent a été fait à la louche ..

– Un chiffrage doit être à un niveau de granularité pertinent ou avec un découpage assez fin : que penser d’une tâche chiffrée à 80 jours ? Je suis client, je vois ça, je questionne mon fournisseur : « Et comment avez-vous évalué ces 80 jours ? qu’est-ce que vous allez faire pendant ces 80 jours ? » ou dit autrement « Où va passer mon argent ? »

– Un chiffrage doit être détaillé fonctionnellement : le chiffrage servira à cadrer le périmètre du projet. Par définition, une tâche non chiffrée ne fait pas partie du périmètre. Le pilotage projet pendant la phase de spécification permettra ensuite de gérer les petits aléas de périmètre.

– Vous pouvez avoir très bien chiffré, vous pouvez malgré tout avoir du dépassement si vous ne pilotez pas correctement votre projet : j’ai fini mon tout premier projet à 91 jours au lieu de 22 jours ! bon, quelqu’un d’autre avait chiffré et le client était de mauvaise foi (si si ! 😉 ) mais quand même .. Je vous raconte tout ici !

– Vous pouvez avoir très mal chiffré et finir à peu près dans les clous si vous pilotez votre projet de manière serrée pour ne pas dire agressive ! avec le risque que le client ne veuille plus travailler avec vous ensuite ..

L’apprentissage du chiffrage se fait surtout par la pratique en comparant l’estimé et le consommé, c’est comme ça que vous saurez où vous avez fait des erreurs et où vous pouvez progresser au prochain chiffrage.

– Gardez un oeil sur le budget, une journée de travail ne coûte pas la même chose selon la personne qui l’effectue. Faire développer toute votre application par un expert va vous coûter cher même si vous irez plus vite. Si les coûts sont homogènes, parlez en jour-homme ne pose pas de problème, s’il y a des disparités importantes, il est bon de suivre le budget plus que le chiffrage.

Ne chiffrez pas coûte que coûte : si vous n’avez pas assez de temps, si vous n’avez pas assez d’éléments pour chiffrer, si techniquement vos équipes ne sont pas compétentes, mieux vaut ne pas y aller ! Vous avez le droit de dire No-Go !

 

L’étape suivante après le chiffrage c’est le planning projet, je traite le sujet ici ! Vous pouvez également jeter un oeil à cet article sur comment cadrer un client avec un chiffrage.

Ce n’est pas transposable à tous les projets, ce n’est pas exhaustif, ce n’est pas la vérité absolue, cela ne fera pas de vous un chef de projet hors pair mais ça a vocation à faire réfléchir ..

Et vous ? quels problèmes liés au chiffrage avez-vous rencontrés ?

 

12 réflexions au sujet de “Le chiffrage de projet informatique : crédibilité, principes et idées-clés”

  1. Bonjour,

    Votre est site web est très intéressant avec plein de conseils et rassurant pour une étudiante comme moi.
    En effet, dans le cadre pédagogique de ma formation, je suis chef de projet pour la réalisation d’une étude préalable de refonte de processus de gestion d’une entreprise. Je dois donc chiffrer 2 solutions informatiques (solution acquisition d’ERP SAP et une solution de développement spécifique) pour le client. Pourriez-vous me renseigner sur des devis correspondants.

    Cordialement.

    Lila

    Répondre
  2. Bonjour,

    Considérez vous que c’est le rôle d’un ingénieur en étude et développement de faire des chiffrages ou celui d’un chef de projet.
    Je suis ingénieur en étude et développement dans une SSII et on me demande de faire des chiffrages et ensuite d’implémenter les fonctions, j’estime que je ne suis pas payé pour faire des chiffrages, ai-je raison ou suis-je en tort ?
    D’avance merci pour votre réponse.

    Répondre
    • Bonjour Coder !

      Je considère idéalement que c’est à la personne qui fait le travail, de réaliser le chiffrage qui va avec. De cette manière chaque personne est responsabilisée et est face à ses propres engagements.

      Chiffrer pour quelqu’un d’autre, c’est toujours plus facile, on engage la responsabilité de l’autre avant la sienne finalement.

      Le chef de projet peut aider la personne à faire son chiffrage, ou bien le challenger un peu si elle prend trop de gras :-). Le chef de projet a tout intérêt à ce que le chiffrage soit le plus juste possible, ni trop peu, ni trop haut. Alors qui mieux que la personne qui va réaliser sait combien de temps ça va lui prendre ?

      Et l’exercice du chiffrage vous suivra toute votre vie, autant commencer le plus tôt possible à maîtriser l’exercice ..

      Cela vous aide-t-il ?

      Répondre
  3. Merci pour cette réponse. Je comprend tout à fait votre point de vue, qui mieux que la personne qui va réaliser les dev, les tests, et l’intégration pour réaliser le chiffrage. Cependant, je viens à me poser cette question. Si l’ingénieur en étude et développement, écoute le besoin du client, rédige les specs techniques détaillés, réalise le chiffrage, implémente les fonctions, les teste, et les intègre, quid du travail de chef de projet ? Que fait il à part rédiger les specs fonctionnelles, suivre les deadlines et encadrer humainement son équipe ? non je demande ça parce qu’il me semble que le chef de projet gagne bcp plus que l’ingénieur en étude et dev par contre c’est ce dernier qui fait presque tout sur le projet, depuis l’écoute des besoins du client jusqu’à la livraison du service…
    Entre d’autre termes j’aimerai vraiment savoir où s’arrêtent les fonctions de chacun.

    Répondre
    • Avant tout un chef de projet ne passe pas forcément 100% de son temps sur le projet, il a peut-être moins de boulot à effectuer selon l’organisation et l’affectation des tâches, ce n’est pas anormal. En revanche, il a la responsabilité du résultat. Son salaire peut être indexé sur la tenue du budget, sur la satisfaction client, etc.

      Les fonctions de chacun peuvent varier d’un projet à l’autre, d’une entreprise à une autre. Le chef de projet peut aller au-delà de ses prérogatives comme il peut ne rien faire du tout :-).

      Rédiger les specs fonctionnelles n’est pas un exercice trivial surtout en mode forfait. Le chef de projet doit cadrer le client constamment pour que chaque fonctionnalité reste dans le budget imparti au départ. C’est parfois un bras de fer quotidien en phase de specs pour répondre au besoin du client mais en faisant en sorte qu’il reçoive une twingo s’il a le budget d’une twingo, qu’il reçoive une Mercedes s’il a le budget d’une Mercedes ..

      Encadrer humainement son équipe, ça peut paraître simple sur le papier, en pratique ça reste l’exercice le plus difficile pour un manager quel que soit le niveau. C’est le genre de truc qu’on ne comprend qu’un jour quand on gère une équipe et les problèmes qui vont avec (je détestais quand on me disait ça et pourtant …). Gérer un client, là aussi ça touche à l’humain donc cela fait appel à des qualités différentes d’un ingénieur étude et développement.

      Je ne défends pas le rôle de chef de projet (un peu quand même) mais j’ai coaché plusieurs ingénieurs de développement qui voulaient passer chefs de projets. Quand ils ont vu le boulot que c’était « en vrai », ils ont fait machine arrière direct. Il y avait un décalage fort entre ce qu’ils pensaient que c’était et la réalité.

      Si tu as un doute sur les fonctions de chacun, n’hésite pas à demander un éclaircissement, c’est ton droit. Tu peux également demander à participer à des réunions avec le client pour voir un peu comment ça se passe. Et si le coeur t’en dit et que tu gères déjà bien ton boulot actuel, demande plus de responsabilité projet et grimpe vers cette fonction, tu pourras ensuite demander le salaire qui va avec.

      Répondre
  4. Le chiffrage est la phase la plus délicate car d’un côté si celui-ci est sous estimé pour remporter le marché, faire signer le client, le projet pourra vraiment battre de l’aile du fait du manque de ressources allouées aux missions. De l’autre, si le chiffrage est trop élevé, le client signera tout simplement avec d’autres consultants…

    Répondre
  5. Bonjour Jean Philipe , je suis une apprentie en BTS Électrotechnique et dans le cadre de formation je dois effectuer un projet d’étude à la fin de l’année. Pour cela je suis taché à y organiser , à faire la conception et la mise du projet.
    Parmi les tâches que je dois effectuer c’est faire un devis pour le client et les sous traitants .
    Donc ma question celle-ci comment dois je me prendre ? Je peux toujours demander aux charges d’affaires de mon entreprise , mais vu que je ne suis pas toujours en entreprise ,raison pour laquelle que je me permets de vous poser cette question , afin que puisse déjà avoir une idée de la façon que je pourrai me prendre.

    Répondre
  6. Laissez-nous coder et être techniquement experts. Le chiffrage, ce n’est pas le rôle du developpeur, le test non plus, le cahier des charges non plus, le support non plus, la formation non plus, etc… Sinon je veux le salaire cumulé d’un dev, d’un cp, d’un testeur, d’un hotliner et d’un formateur, et là, et seulement là, on va commencer à chiffrer le salaire ! Vous savez combien ça gagne un dev aux USA ? Vu le salaire français, on ne va pas se casser le c…

    Répondre
    • Bonjour Anonyme,

      merci pour ce commentaire.

      Si tu ne testes pas ton code, bah c’est comme un chef qui ne goûte pas ses sauces, un garagiste qui ne vérifie pas que la voiture redémarre après l’avoir réparée, un marchand de chaussures qui ne te fait pas essayer la paire, un plombier qui n’ouvre pas le robinet pour voir si l’eau coule, un coiffeur qui ne te regarde pas après t’avoir coupé les cheveux, un tailleur qui ne te fait pas essayer le costume, …

      Vouloir faire du pur dev, sans responsabilité si jamais ça plante ou si les utilisateurs ne sont pas satisfaits, et sans engagement que ça marche, c’est utopique. C’est coder pour coder sans tenir compte de l’éco-système autour … qui te permet de toucher ton salaire.

      La valeur que tu produis en codant est directement liée à la valeur que tu apportes aux autres à travers ce code. Vouloir se couper de tout le reste, du chef de projet et son chiffrage à la c**, des utilisateurs avec leur cahier des charges incomplet et leurs bugs, des clients qui appellent parce qu’ils ont un problème, des autres membres de l’équipe qui ont besoin d’être formés, c’est enlever toute la valeur de ton travail.

      Il y a toujours plusieurs facettes à un métier .. Maintenant si tu penses que ton salaire n’est pas à la hauteur de la valeur que tu apportes aux autres, demande une augment’, change de poste, change de boîte, change de pays, … pour trouver quelqu’un qui saura mieux apprécier la valeur que tu produis.

      Excellente continuation,
      JP

      Répondre
  7. Bonjour JP

    J’ai vraiment aimé votre document. Actuellement je suis ingénieur étude et développement dans une boite. J’ai suivi vos conseils pour pas mal de projets dont je devais chiffrer. Maintenant j’aimerai évoluer dans le métier de chef de projet. Quel conseil me donnerez vous? pouvez vous m’encadrer dans ce domaine.
    Merci d’avance,
    Cordialement;

    Répondre

Répondre à antoine Annuler la réponse