Des propositions comparables commencent par une mission bien décrite : 12 informations utiles à fournir

Le Sourcing Playbook actuel du Royaume-Uni indique qu'une spécification claire doit fournir aux candidats suffisamment d'informations pour décider en connaissance de cause s'ils souhaitent présenter une offre. Il souligne également que, sans compréhension commune des exigences, il devient difficile de relier les prix proposés aux coûts et aux résultats attendus par l'acheteur. [1]

La Government Commercial Function formule le problème encore plus directement : une bonne spécification doit contenir les informations permettant aux fournisseurs d'estimer correctement le coût afin que l'acheteur puisse comparer les offres sur une base équivalente. [2]

Dans le même temps, le Digital, Data and Technology Playbook britannique met en garde contre une définition excessive de la solution. Il recommande de se concentrer sur l'utilisateur, le problème et le résultat attendu, tout en laissant aux fournisseurs la possibilité de proposer une méthode efficace. [3]

La conclusion n'est donc pas « décrivez tout avec le plus de détails possible ». Une meilleure règle est :

décrivez précisément ce qui doit être commun à toutes les propositions, et non ce qu'un spécialiste compétent peut raisonnablement concevoir lui-même.

Deux propositions professionnelles ne seront jamais identiques, et ce n'est pas le but.

La comparabilité signifie que les spécialistes répondent au même problème avec des hypothèses globalement similaires.

Ils devraient donc disposer d'une compréhension comparable de :

• l'objectif,
• le périmètre,
• le point de départ,
• le résultat attendu,
• les contraintes importantes,
• le calendrier,
• les responsabilités du client,
• la manière de présenter le prix,
• les critères selon lesquels la proposition sera évaluée.

Ils peuvent en revanche différer sur :

• l'approche proposée,
• l'ordre des actions,
• la méthode,
• la composition de l'équipe,
• les outils,
• le découpage en étapes,
• la manière de réduire les risques.

Ces différences ont souvent de la valeur et doivent rester visibles.

Commencez par le problème, pas par une liste de fonctionnalités.

Au lieu de :

« J'ai besoin d'une application avec un tableau de bord, des notifications et des rapports. »

essayez :

« Aujourd'hui, cinq personnes gèrent le processus dans des feuilles de calcul et des courriels. Il est difficile de connaître l'état actuel d'un dossier, la personne responsable et la prochaine action. Nous voulons réduire le suivi manuel et disposer d'un seul endroit indiquant l'état à jour. »

La seconde description ne décide pas encore quelle application doit être construite.

Elle permet toutefois au spécialiste de comprendre pourquoi le projet existe.

La Federal Acquisition Regulation relative aux services fondés sur les résultats recommande de décrire le travail principalement par les résultats requis plutôt que par la manière de l'exécuter ou le nombre d'heures. Sa déclaration minimale d'objectifs comprend notamment la finalité, le périmètre, le contexte, les résultats attendus et les contraintes opérationnelles. [4]

Décrivez donc ce qui doit être possible à la fin du travail.

Par exemple :

• un utilisateur peut terminer seul un processus défini,
• l'équipe peut voir l'état actuel de tous les dossiers,
• le client reçoit une analyse avec des priorités,
• le système est déplacé vers un nouvel environnement et fonctionne selon des critères convenus,
• le contenu préparé est prêt à être publié sur un canal défini.

Le résultat doit être suffisamment concret pour que les deux parties comprennent la direction du travail.

Il n'a pas besoin de signifier la garantie d'un résultat commercial dépendant du marché, du comportement des utilisateurs ou d'autres facteurs hors du contrôle du prestataire.

Un même besoin final peut demander des efforts très différents selon le point de départ.

Il est utile d'indiquer :

• ce qui existe déjà,
• ce qui fonctionne et doit être conservé,
• ce qui ne fonctionne pas,
• si des fichiers source existent,
• si une documentation existe,
• si des données doivent être migrées,
• s'il faut travailler sur un système existant,
• quels éléments sont déjà prêts.

« Un nouveau site » peut signifier une création depuis zéro ou une refonte d'un site existant en conservant le contenu, les adresses, l'analyse, les intégrations et les données.

Ce sont des travaux différents, même si le résultat visuel final peut sembler similaire.

Le périmètre ne doit pas obliger les spécialistes à deviner quelles parties du problème ils doivent chiffrer.

Par exemple :

Inclus :

• analyse de la solution actuelle,
• conception de nouvelles vues,
• mise en oeuvre,
• migration d'une partie définie des données.

Hors périmètre :

• création de nouveaux contenus,
• achat de licences,
• maintenance après le premier mois,
• refonte du système de paiement.

L'exemple de Terms of Reference de la Banque mondiale souligne que les exigences et attentes relatives aux services doivent être exprimées clairement et adaptées au projet concerné. [5]

Les limites sont particulièrement importantes lorsque deux tâches sont naturellement liées et qu'il serait facile de supposer que l'une comprend l'autre.

Si vous attendez des éléments ou résultats précis, nommez-les.

Il peut s'agir de :

• une solution fonctionnelle,
• des fichiers source,
• un rapport,
• de la documentation,
• une conception visuelle,
• un ensemble de supports,
• une configuration d'environnement,
• une formation,
• un enregistrement,
• un transfert du code et des accès.

Des mots comme « conception », « analyse » ou « mise en oeuvre » peuvent être compris différemment.

Une liste commune des principaux éléments livrés évite qu'une proposition contienne beaucoup plus qu'une autre sans que la différence soit visible derrière des intitulés similaires.

Toutes les contraintes ne sont pas des détails techniques.

Peuvent être importants, par exemple :

• un système ou environnement imposé,
• une intégration obligatoire avec un service précis,
• des exigences d'accessibilité,
• une réglementation sectorielle,
• des restrictions de stockage des données,
• la nécessité de conserver l'infrastructure existante,
• certains appareils ou navigateurs,
• un travail à des horaires définis,
• des restrictions d'accès aux données.

La FAR inclut explicitement les contraintes opérationnelles dans la déclaration d'objectifs, tandis que le Digital, Data and Technology Playbook britannique montre qu'il ne faut pas imposer une solution lorsqu'aucune contrainte réelle ne l'exige. [4] [3]

Une bonne règle :

indiquez ce que le spécialiste ne peut pas changer, mais n'inventez pas une contrainte simplement parce que vous êtes habitué à une solution particulière.

Le spécialiste doit savoir sur quel niveau de coopération il peut fonder sa proposition.

Indiquez si vous fournirez :

• une personne décisionnaire,
• l'accès aux systèmes,
• les éléments existants,
• les données,
• des comptes de test,
• des informations de l'équipe,
• l'accès à des utilisateurs,
• le contenu,
• des réunions régulières,
• des réponses dans un délai défini.

Si vous ne savez pas encore ce que vous pourrez fournir, il est également utile de le dire.

Le manque d'accès aux données, aux éléments ou aux personnes peut modifier la méthode, le coût et le calendrier. Ce n'est pas un détail administratif mineur. Cela fait partie des conditions sur lesquelles la proposition est construite.

Toutes les dates n'ont pas le même caractère.

Distinguez :

• la date de début préférée,
• la date limite non négociable,
• une date liée à un événement externe,
• une date indicative,
• les étapes qui doivent se dérouler dans un ordre précis.

Si une date ne peut réellement pas bouger, expliquez pourquoi.

Si elle est flexible, indiquez-le aussi.

Le spécialiste peut ainsi proposer un autre périmètre, un autre ordre ou un découpage par étapes au lieu de supposer que chaque date est une exigence absolue.

Il n'existe pas de règle unique imposant au client de toujours révéler l'intégralité de son budget.

Selon la situation, vous pouvez indiquer :

• un budget maximal,
• une fourchette budgétaire,
• le budget de la première étape,
• que vous souhaitez d'abord une proposition de périmètre puis le prix,
• la structure attendue pour le détail du prix.

Pour comparer, l'important est que les spécialistes présentent les coûts avec une structure similaire.

Par exemple :

« Indiquez séparément le prix de l'analyse, de la conception, de la mise en oeuvre et de la maintenance mensuelle. Précisez également les coûts de services externes non inclus. »

Ce format est bien plus facile à comparer que quatre montants différents couvrant chacun des éléments différents.

L'incertitude ne disparaît pas parce qu'elle n'est pas écrite.

Si vous ne savez pas :

• quelle quantité de données devra être migrée,
• si une interface externe permet l'opération nécessaire,
• si tout le contenu sera prêt,
• si le code actuel peut être raisonnablement développé,
• si une autorisation nécessaire sera obtenue à temps,

dites-le.

Le guide du GAO sur les estimations fiables de coûts souligne l'importance des hypothèses explicites et de l'analyse des risques et incertitudes. [6]

Un bon spécialiste peut alors :

• prévoir une réserve,
• proposer une étape de diagnostic,
• chiffrer plusieurs variantes,
• indiquer une condition de modification du prix,
• refuser de prétendre à une précision qu'il est encore impossible d'atteindre honnêtement.

Une inconnue explicite vaut mieux qu'une hypothèse cachée.

Si vous savez déjà ce qui comptera dans la décision, dites-le avant la préparation des propositions.

Vous pouvez évaluer :

• la pertinence de l'approche proposée,
• l'expérience de problèmes similaires,
• la qualité des preuves de travaux antérieurs,
• le réalisme du calendrier,
• la disponibilité,
• la gestion des risques,
• les compétences des personnes qui travailleront réellement sur le projet,
• le prix,
• le coût de maintenance,
• la qualité de la communication.

Les orientations actuelles de la Banque mondiale sur les Rated Criteria indiquent que les critères hors prix peuvent inclure la qualité de la méthode et du plan de travail, la gestion des risques, la capacité d'exécution et le personnel clé. Les critères sont adaptés au marché concerné et pondérés selon leur importance relative. [7]

Cela ne signifie pas qu'une petite mission ait besoin d'une notation formelle.

Il suffit de pouvoir répondre avant d'envoyer la demande :

« Qu'est-ce qui, en dehors du prix, rendrait une proposition meilleure pour moi qu'une autre ? »

Si vous voulez réellement comparer les propositions, demandez à tous de répondre au même ensemble de questions de base.

Par exemple :

1. Comment comprenez-vous le problème et le résultat attendu ?
2. Quelle approche proposez-vous ?
3. Que comprend exactement votre proposition ?
4. Qu'est-ce qui est exclu ?
5. Quelles hypothèses faites-vous ?
6. Quel est le calendrier ?
7. De quoi avez-vous besoin de la part du client ?
8. Quels sont les principaux risques ?
9. Quel est le prix et que comprend-il exactement ?
10. Quelle expérience ou quelles preuves de travaux similaires sont pertinentes pour cette mission ?

Dans les marchés publics, la standardisation des réponses, des critères et des formats de prix sert précisément à permettre une évaluation sur une base commune. La Government Commercial Function insiste sur la nécessité de fournir assez d'informations pour un chiffrage correct et une comparaison équivalente. [2]

Un format commun ne doit pas effacer les différences entre spécialistes. Il doit simplement rendre ces différences visibles aux mêmes endroits.

Cela dépend de l'objectif de la demande.

Indiquer le budget peut aider lorsque :

• le périmètre peut être adapté aux moyens disponibles,
• vous voulez une recommandation du meilleur choix dans une limite donnée,
• vous souhaitez écarter rapidement les propositions incompatibles avec la réalité financière du projet.

Ne pas donner tout le budget peut être pertinent lorsque :

• vous voulez d'abord une vision indépendante du périmètre approprié,
• vous ne connaissez pas encore le coût réaliste,
• vous comparez différents modèles de solution,
• le processus exige une autre façon de recueillir les prix.

La pire situation n'est pas forcément l'absence de budget, mais l'absence d'information sur le type de réponse tarifaire attendu.

Le spécialiste doit savoir s'il doit fournir un montant unique, une fourchette, des variantes, un prix par étape ou les hypothèses nécessaires à une estimation plus précise.

Une bonne description de mission n'a pas besoin de répondre à toutes les questions.

Elle peut dire honnêtement :

• « Nous ne savons pas encore si le système actuel peut être étendu en toute sécurité. »
• « Nous ne connaissons pas le nombre exact d'enregistrements à migrer. »
• « Nous n'avons pas encore décidé si la deuxième version linguistique fera partie de la première étape. »
• « Nous avons besoin d'aide pour choisir la meilleure option. »

C'est une information utile.

L'incertitude doit influencer la manière de préparer la proposition, pas disparaître du document.

Dans certaines situations, le meilleur premier service n'est pas la réalisation complète mais une courte phase de diagnostic débouchant sur une décision, un périmètre plus précis ou une estimation plus fiable.

1. Donner à chaque spécialiste un ensemble d'informations différent.

2. Lister des fonctions sans expliquer le problème et l'objectif.

3. Ne pas indiquer ce qui existe déjà.

4. Cacher des contraintes qui modifieront ensuite la manière de réaliser le travail.

5. Demander un prix final unique sans préciser ce qu'il doit inclure.

6. Évaluer les propositions selon des critères que vous n'aviez pas définis vous-même à l'avance.

7. Confondre une description détaillée du problème avec l'imposition détaillée d'une solution.

1. Ai-je clairement décrit le problème, et pas seulement la solution que j'ai imaginée ?
2. Le résultat que je veux atteindre est-il clair ?
3. Le spécialiste comprend-il la situation actuelle ?
4. Sait-on ce qui doit être conservé ?
5. Les limites du premier périmètre sont-elles claires ?
6. Ai-je nommé les principaux éléments à livrer ?
7. Ai-je indiqué les contraintes réelles ?
8. Est-il clair ce que je fournirai de mon côté ?
9. Le calendrier est-il décrit avec son niveau de flexibilité ?
10. Le format des prix permettra-t-il de comparer les propositions ?
11. Ai-je décrit ouvertement les principales inconnues ?
12. Sais-je ce que j'évaluerai en plus du prix ?
13. Tous les spécialistes répondront-ils à un ensemble de questions similaire ?
14. Ai-je laissé de la place à une solution meilleure que celle que j'avais imaginée ?

Une bonne description de mission poursuit deux objectifs apparemment contradictoires.

Elle doit être assez précise pour que plusieurs spécialistes chiffrent le même problème.

Elle doit aussi être assez ouverte pour que chacun puisse proposer sa propre approche, potentiellement meilleure.

Un ordre utile est :

problème -> résultat -> situation actuelle -> périmètre -> éléments livrés -> contraintes -> responsabilités du client -> calendrier -> format du prix -> inconnues et risques -> critères de choix -> format commun de réponse.

Si, après réception des propositions, vous découvrez qu'une personne a chiffré tout le projet, une autre uniquement l'analyse et une troisième a supposé des intégrations supplémentaires, le problème ne vient peut-être pas des devis.

Chacune a peut-être reçu une mission différente, même si tout le monde a reçu le même texte.

[1] UK Government - The Sourcing Playbook
Ouvrir la source

[2] Government Commercial Function - How to write a procurement specification
Ouvrir la source

[3] UK Government - The Digital, Data and Technology Playbook
Ouvrir la source

[4] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Ouvrir la source

[5] World Bank - Sample Consultants Terms of Reference
Ouvrir la source

[6] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Ouvrir la source

[7] World Bank - Rated Criteria
Ouvrir la source

Note méthodologique : les sources proviennent principalement des marchés publics et de la gestion des coûts. Elles ne sont pas présentées comme des règles directement applicables à un marché privé de spécialistes. L’article utilise uniquement les principes qu’elles étayent réellement : clarté des exigences, orientation vers les résultats, hypothèses et risques explicites, informations tarifaires comparables et évaluation de la qualité selon des critères autres que le seul prix.