Le triangle Qualité, Coût, Délai

Quand on doit choisir la manière d’aborder un projet, il existe 3 notions fondamentales qu’il faut connaître et évaluer : la qualité, le coût et le délai.

 

Comprendre le triangle

  • Qualité : Il s’agit du soin qui est apporté à la réalisation fonctionnelle et technique du projet. Un projet de médiocre qualité remplira les besoins immédiats du client, en s’autorisant un certain nombre de raccourcis. Un projet de bonne qualité aura été spécifié pour couvrir certains besoins futurs identifiables, et offrira une ergonomie adaptée, des performances homogènes, une évolutivité étudiée, une documentation complète.
  • Coût : Un client est prêt à dépenser une certaine somme pour un projet donné. La valeur du projet peut éventuellement s’adapter à un certain nombre de critères, mais il y a forcément un seuil au-delà duquel il est impossible de le rentabiliser. La notion de coût englobe aussi bien les frais d’étude (en fonction du temps passé aux spécifications fonctionnelles et techniques) et de réalisation (suivant le nombre de développeurs nécessaires, le matériel mis à leur disposition, la présence d’une équipe de test et de validation, …), que les frais d’exploitation (matériel nécessaire pour faire tourner le projet en production, salaire de l’opérateur de maintenance, …).
  • Délai : Savoir combien de temps doit durer la réalisation d’un projet n’est pas aisé, même si cela fait partie du travail d’un ingénieur. Certains projets ne sont pas urgents, ni même importants, mais ils comportent forcément une deadline à partir de laquelle ils deviennent caducs.

Utiliser le triangle

Ces trois points sont interdépendants, et doivent être pris en compte soigneusement. Il faut donc comprendre – et faire comprendre – qu’il existe 3 possibilités :

  • Rapide et pas cher => Mauvaise qualité

C’est ce que demandent beaucoup de clients, sans se rendre compte qu’un projet vite fait et à moindre coût aura forcément des lacunes. Cela peut être satisfaisant pour un prototype qui doit valider un concept. Mais il faut bien expliquer les risques que cela peut faire prendre à moyen terme.

  • Rapide et de bonne qualité => Cher

Si le client peut se le permettre, c’est la solution parfaite. Un projet très important sera traité de manière prioritaire sur les autres, se verra affecter plus de moyens humains et techniques. Et donc forcément, cela a un coût important.

  • Bonne qualité et pas cher => Lent

Un projet bien fait, mais qui ne coûte pas cher ? Il va prendre du temps à être réalisé. Pour diminuer les coûts, ce projet va se retrouver à jouer le « bouche-trou » ; sa priorité est plus faible, et « on y travaille quand on a du temps ». Pareil pour les ressources techniques, qui sont disponibles d’abord pour les autres projets.

Ce qu’il faut éviter

Ce qui n’existe pas, ou ne devrait pas exister :

  • Rapide, de bonne qualité et pas cher

C’est un fantasme auquel beaucoup de « décideurs » continuent de rêver. Il faut être complètement déconnecté des réalités du monde du travail pour croire qu’on peut obtenir une réalisation de qualité irréprochable, pour un coût proche de zéro, livrée dès le lendemain de la signature du contrat. Fuyez les clients qui sont inflexibles sur ces aspects.

  • Lent, de mauvaise qualité, et cher

Personne n’est prêt à payer cher pour un mauvaise réalisation qui ne sera pas disponible rapidement. Et pourtant, combien de projets se retrouvent à être repoussés sans arrêt, et le client obligé de payer pour ajouter de nouveaux développements sans lesquels le projet ne peut pas être terminé, et qui au final ne remplit pas le cahier des charges ? Cela est souvent représentatif de 2 choses : le client ne sait pas ce qu’il veut, et le travail de spécification n’a pas été fait correctement.

Comment faire ?

Pas de miracle, il faut mettre en place une méthode de gestion de projets. Vous avez le choix : Cycle en cascade, cycle en V, cycle itératif, méthode agile, … Sans oublier que c’est à vous de d’adapter les méthodes en fonction des besoins ; et que si gérer des projets c’est bien, gérer des workflow, c’est mieux.

Quel outil de gestion de projets ?

Pour gérer vos projets, il existe pas mal de solutions à votre disposition. Fort de mon expérience, j’ai créé Skriv, un outil qui se veut plus efficace que ses concurrents. Il sait comment vous gérez vos projets, ce qui lui permet d’automatiser les tâches qui sont manuelles avec les autres outils ; votre équipe gagne en productivité. Il offre en plus des fonctionnalités qui sont des cerises sur le gâteau mais qui changent la vie au quotidien.

N’hésitez pas à le tester gratuitement. Je suis sûr qu’il s’adaptera parfaitement à vos besoins.

14 commentaires pour “Le triangle Qualité, Coût, Délai

  1. ce triangle a aussi été enrichi par Kent Beck (XP) avec le périmètre fonctionnel.
    KB affirme que les 3 paramètres sont souvent figés ou limités et que l’on peut uniquement jouer sur le périmètre fonctionnel pour maintenir le triangle.

  2. C’est une juste remarque, mais disons que j’évite d’aborder ces notions tant que je n’ai pas encore écrit d’article sur l’extrem programming.

    De toute manière, je pense que les 3 notions de ce triangle restent importantes, et qu’il faut les avoir en tête quand on entame un projet – quelle que soit la manière dont on l’aborde et la méthode qui va être utilisée.

    Le fait de connaître les contraintes du client, et donc du projet, permet de donner l’impulsion initiale. Une fois que l’on connaît la direction à suivre, on peut ensuite mettre en place les bonnes méthodes pour s’assurer que l’on reste toujours dans la bonne voie (y compris en suivant les changement de direction éventuels du client).

  3. Merci pour cet article intéressant;

    Si on veut résumer les points traités dans cet article en une formule mathématique simple, je dirai:

    q=cd

    qualite = cout x duree.

    A vous de vérifier.
    Mourad 🙂

  4. Tout à fait. On peut améliorer la qualité d’un projet en y consacrant plus de moyen ou plus de temps.

    Les deux corollaires sont donc :

    • coût = qualité / durée
      => le coût augmente avec la qualité, il diminue avec la durée
    • durée = qualité / coût
      => la durée augmente avec la qualité, elle diminue en y mettant les moyens
  5. Article très instructif, merci.

    q=cd -> ok
    d=q/c -> ok

    mais c=q/d, je ne suis pas tellement d’accord…

    le niveau de qualité à atteindre engendre des coûts identiques quelque soit la durée, non ?

  6. Non, pas en pratique. En fait, tout dépend de ce qu’on prend en compte sous le terme «qualité». Du simple point de vue du code, cela prend grosso-modo le même temps de faire du code propre et maintenable que de faire du code de goret (cette allégation est évidemment très discutable, mais à l’échelle d’un projet, c’est assez vrai).
    Par contre, si on prend en compte tous les aspects d’un projet, on se rend compte qu’un grand nombre de choses sont nécessaires pour assurer la qualité réelle du projet : spécification fonctionnelle, spécification technique, tests unitaires, validation technique, validation fonctionnelle, documentation technique, manuel utilisateur, … En bref, toutes les tâches en amont et en aval de la réalisation proprement dite, qui assurent la qualité du projet, immédiate et dans la durée (adéquation aux besoins du client, ergonomie, performance, évolutivité, maintenabilité).
    Et ces tâches prennent du temps à effectuer. Et là, pour une qualité égale, on doit souvent arbitrer entre augmenter les coûts (affecter plus de personnes, pour réduire les délais) ou augmenter les délais (affecter moins de personnes, ou rendre le projet moins prioritaire que d’autres, ce qui aura tendance à réduire les coûts).

  7. Dites moi : Quelle entreprise a râté son passage à l’euro ou son passage à l’an 2000 ? pourtant beaucoup s’y sont prises tard. 11 ans après je n’ai pas eu beaucoup à intervenir sur des plantages suite à ces projets. La qualité a donc été, globalement, au rendez-vous. Je n’ai pas entendu que les budgets associés à ces opérations aient explosés.

    Je crois que ces opérations ont, dans beaucoup d’entreprises, été rapide, de qualité et pas cher (relativement).

    Alors qu’est ce qui fait que certaines opérations peuvent être optimum et pas d’autres ?

  8. Oui, on peut toujours trouver des exemples et des contre-exemples. Ça ne remet pas en cause le principe général.

    Mais je suis certain que pour certaines entreprises et/ou certaines industries, le passage à l’euro ou à l’an 2000 n’a pas été si smooth que ça. Certains ont dû payer des sommes astronomiques pour gérer cela, alors que ça n’apporte pas de valeur directe.
    Je me souviens ainsi des stations-services qui ont dû fermer parce que ça leur aurait coûté trop cher d’installer des pompes à essence en euros…

    Pour revenir au triangle, tout est question de mesure. Ce n’est pas binaire, les curseurs ne sont pas forcément au minimum ou au maximum. Mais il n’en reste pas moins que, la plupart du temps, quand on joue avec l’un des 3 curseurs, les deux autres sont impactés.

  9. Mais je pense que le passage à l’euro et à l’an 2000 ne sont pas exemples mais des occurences d’un principe général qui est : quand il y a une vraie contrainte alors on fait pas (trop) cher, rapide et de bonne qualité.

    Par exemple dans l’art, on fait pas cher pour une date prévue et bien sûr avec la qualité au rendez vous. On m’a rapporté une discussion d’un chef d’orchestre qui a, entre autres, 3 impératifs :
    – le concert se passe à la date prévue,
    – le coût prévu (quelqu’il soit) ne doit pas être dépassé,
    – et bien sûr, le concert doit être de qualité
    Et bien ce chef d’orchestre s’est posé la question suivant. Qu’est ce qu’il faut faire d’abord pour garantir ces 3 impératifs ? Eh bien sa réponse fût : garantir la synergie dans l’orchestre (intéressant, non). Ensuite il décida de gérer la partition et enfin le fignolage. Ce chef d’orchestre découpe le temps en trois, traite le nécessaire au plus tôt, et dans ce cas c’est la gestion par le temps qui génère la qualité. C’est pas beau ça ?

  10. @dcnfurter: est-ce que tu veux dire qu’il est possible de tout faire et que tout n’est qu’une question d’organisation ?
    Pour reprendre l’exemple de ton chef d’orchestre: imagine qu’on lui impose maintenant de faire 2 concerts dans le même temps qu’il a mis pour en préparer 1 seul.
    Est-ce qu’il arrivera encore à tenir les dates avec la même qualité ?

  11. @dcnfurter: est-ce que tu veux dire qu’il est possible de tout faire et que tout n’est qu’une question d’organisation ?
    ça fait 20 ans que je fais comme ça ! à condition bien sûr que l’organisation traite réellement le temps au plus haut niveau et que les patrons aient de vrais objectifs.

    Dans l’exemple du chef d’orchestre il suffit d’élaborer (donc beaucoup de jus de cerveau) une organisation intégrant la nouvelle contrainte et d’expliquer au producteur les conséquences de sa décision et les conditions à mettre en oeuvre. Si le producteur tient vraiment à sa décision et que les conditions sont légitimes, il acceptera celles ci sans problème

  12. Le fait de devoir élaborer un organisation en fonction de contraintes − à plus forte raison lorsqu’il faut l’expliquer à quelqu’un − revient à utiliser le triangle pour visualiser l’articulation des contraintes les unes par rapport aux autres. C’est peut-être inconscient, c’est peut-être naturel ou implicite, mais ç revient grandement au même.

  13. Absolument pas d’accord. L’utilisation du triangle implique que dès que l’on contraint une branche, il y a un impact sur les 2 autres. Ce que je pratique, c’est de sortir de ce cadre et de chercher une solution sans impact Et en général, quand on cherche, on trouve.
    En gros ça veut dire, quand un client dit : je le veut en 1 mois de moi, je ne dis jamais : ça vous couteras 800€ en plus. Je creuse, simule, etc … jusqu’à trouver une solution qui lui convienne. Ce qui me gêne dans le triangle, c’est l’aspect automatique.

Laisser un commentaire

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

Notifiez-moi des commentaires à venir via email. Vous pouvez aussi vous abonner sans commenter.