Un périmètre de service clair, sans ambiguïté : 10 éléments pour que le client sache ce qu'il achète

La réglementation fédérale américaine actuelle relative aux services fondés sur les résultats recommande de décrire le travail principalement en termes de résultats attendus plutôt qu'en imposant la manière de l'exécuter ou un simple nombre d'heures. Elle fait aussi référence à des normes de performance mesurables et, dans les déclarations d'objectifs, à des éléments tels que l'objet, le périmètre, la période et le lieu d'exécution, le contexte, les résultats requis et les contraintes opérationnelles. [1]

Le Digital, Data and Technology Playbook du gouvernement britannique promeut lui aussi des spécifications claires orientées vers les résultats. Il recommande explicitement de se concentrer sur l'utilisateur et le problème à résoudre plutôt que d'imposer à l'avance une solution technique. [2]

Les orientations britanniques actuelles sur la répartition des risques et les approches tarifaires indiquent en outre que les indicateurs de performance doivent être mesurables et objectifs, et que le fournisseur doit être responsable des résultats sur lesquels il peut réellement agir. [3]

Ces sources relèvent des marchés publics et ne constituent pas un modèle universel pour tous les services. Elles illustrent toutefois un principe très utile : un bon périmètre doit nommer le résultat attendu, la façon de l'évaluer et les limites de responsabilité.

Une bonne description doit aider à la fois :

Le client - à comprendre ce qu'il recevra, ce qu'il ne recevra pas et ce qui sera attendu de lui.

Le spécialiste - à définir les limites de responsabilité, les hypothèses et le moment où une nouvelle demande devient une modification du périmètre.

Les deux parties - à convenir de la manière dont elles pourront raisonnablement déterminer que le travail prévu a été réalisé.

Si la description ne remplit bien qu'une seule de ces fonctions, elle peut encore laisser beaucoup de place aux litiges ou aux interprétations divergentes.

Commencez par expliquer pourquoi le service est nécessaire.

Ne commencez pas par une liste d'outils ou de tâches si le client ne comprend pas encore l'objectif.

Au lieu de :

« Configuration de l'analyse, des rapports et des événements. »

préférez :

« L'objectif est d'obtenir des données fiables montrant à quelles étapes du formulaire les utilisateurs abandonnent le plus souvent, afin que l'équipe puisse identifier les points à améliorer. »

Cette approche suit le principe consistant à décrire les besoins et les résultats plutôt qu'à imposer une solution, principe promu par le Digital, Data and Technology Playbook britannique. [2]

L'objectif répond à « pourquoi ? », tandis que le résultat répond à « qu'est-ce qui doit exister ou être vrai à la fin du travail ? »

Le résultat peut être, par exemple :

• un document terminé,
• une fonctionnalité opérationnelle,
• une configuration mise en place,
• une étude réalisée avec des conclusions,
• un ensemble de supports préparés,
• une session réalisée avec un compte rendu défini.

Pour les services fondés sur les résultats, la FAR décrit les exigences principalement à travers les résultats attendus plutôt qu'à travers la seule méthode d'exécution. [1]

Cela ne signifie pas que chaque service doit garantir un résultat commercial que le spécialiste ne contrôle pas. Il peut s'engager à lancer une campagne dans le périmètre convenu, mais garantir une hausse des ventes de 30 % peut dépendre de nombreux facteurs hors de son contrôle.

Le périmètre doit nommer les parties concrètes du travail couvertes par l'accord.

Pour un projet de site web, cela peut inclure :

• l'analyse du site actuel,
• la préparation de l'architecture de l'information,
• la conception d'un nombre défini de vues,
• les versions mobiles,
• la mise en oeuvre du design approuvé,
• une documentation de transmission de base.

L'objectif n'est pas de produire la liste la plus longue possible. Il s'agit de nommer les principaux éléments qui influencent l'effort et les attentes avant le début du travail.

Le périmètre décrit le travail, tandis que les éléments livrés décrivent ce que le client recevra réellement.

Par exemple :

• un fichier source,
• un rapport dans un format défini,
• un module fonctionnel,
• un dépôt de code,
• un ensemble de visuels,
• un enregistrement,
• de la documentation,
• une liste de recommandations,
• un accès à un environnement configuré.

Si la forme du résultat est importante, indiquez-la. « Rapport » peut signifier deux pages de texte ou un document détaillé avec analyse, priorités et exemples. Le seul intitulé ne suffit pas toujours.

Les critères d'acceptation répondent à la question : comment déterminer que le résultat convenu a été livré conformément aux exigences ?

Ils peuvent porter, par exemple, sur :

• l'exhaustivité,
• la conformité à la spécification convenue,
• un format défini,
• le fonctionnement sur certains appareils ou environnements,
• un nombre maximal d'erreurs d'une catégorie déterminée,
• le délai de livraison,
• des paramètres de qualité définis.

La FAR exige que les normes de performance des contrats de services fondés sur les résultats soient mesurables et structurées de façon à permettre l'évaluation de l'exécution. [1]

Les orientations britanniques sur les risques ajoutent que les indicateurs doivent être objectifs et concerner des résultats sur lesquels le fournisseur peut agir. [3]

C'est pourquoi « le client sera satisfait » est beaucoup moins utile qu'un critère lié à un résultat précis et observable.

Un service dépend souvent d'actions de l'autre partie.

Il est utile d'indiquer si le client doit fournir :

• des accès aux systèmes,
• du contenu ou des supports,
• des données,
• des informations sur la marque,
• des décisions et validations,
• une personne de contact,
• un environnement de test,
• des réponses dans un délai défini.

Si l'absence d'éléments fournis par le client peut bloquer le travail, cela doit être clair.

La responsabilité du calendrier ne doit pas être formulée comme si le spécialiste contrôlait des actions qu'il ne contrôle pas réellement.

Le prix et le délai ne sont souvent valables que sous certaines hypothèses.

Exemples :

• la base de données existante est disponible et fonctionne correctement,
• le client détient les droits sur les éléments qu'il fournit,
• un système externe dispose d'une interface fonctionnelle,
• le projet ne nécessite pas de migration de données historiques,
• le nombre de versions linguistiques est fixé à l'avance,
• les décisions seront prises par une personne désignée.

Le guide du GAO sur l'estimation fiable des coûts considère comme importants la définition claire du périmètre, des bases techniques, des règles et hypothèses ainsi que l'analyse des risques et de l'incertitude. [7]

Un petit service n'a pas besoin de reproduire un processus conçu pour de grands programmes. Le principe reste néanmoins précieux : si l'estimation dépend d'un élément qui peut s'avérer faux, indiquez-le.

Les exclusions ne sont pas le signe d'une mauvaise offre. Elles montrent souvent que l'engagement est bien défini.

Si un élément peut facilement être confondu avec ce qui est inclus, il peut être utile d'indiquer explicitement qu'il ne l'est pas.

Par exemple :

• achat de licences,
• création de contenu,
• images payantes,
• traductions,
• maintenance après mise en ligne,
• travaux sur un autre système,
• nombre illimité de corrections,
• coûts de services tiers.

Il n'est pas nécessaire de lister tout ce que le spécialiste ne fera pas. Les exclusions les plus utiles sont celles que le client pourrait raisonnablement penser incluses.

Un délai devrait être plus précis que « environ deux semaines » lorsque l'avancement dépend de validations ou de contenus fournis par le client.

Il peut préciser :

• ce qui déclenche le début du délai,
• s'il existe des étapes intermédiaires,
• quelles décisions clôturent chaque étape,
• combien de temps le client dispose pour répondre lorsque cela influence le calendrier,
• comment les retards sont communiqués,
• comment fonctionne l'acceptation finale.

Pour un service simple, quelques phrases suffisent. Dans une collaboration plus importante, les étapes aident les deux parties à comprendre ce qui est déjà terminé et ce qui doit se produire ensuite.

Une bonne description du service doit expliquer ce qui se passe lorsqu'une nouvelle exigence apparaît après le début du travail.

Un mécanisme pratique peut être très simple :

« Tout travail en dehors du périmètre décrit nécessite la confirmation du nouveau périmètre, de son impact sur le calendrier et de tout prix supplémentaire avant le début de ce travail. »

Il est également utile d'indiquer clairement :

• le modèle de facturation,
• le prix ou sa méthode de calcul,
• les règles de paiement,
• les coûts supplémentaires éventuels,
• les règles concernant les cycles de corrections supplémentaires.

Cela n'empêche pas les changements. Cela transforme le changement en décision consciente plutôt qu'en extension cachée de l'engagement initial.

Un périmètre clair n'exige pas de contrôler chaque étape du travail du spécialiste.

Le Digital, Data and Technology Playbook britannique met en garde contre la sur-spécification de la solution et souligne que des spécifications orientées vers les résultats peuvent laisser au fournisseur la possibilité de proposer une façon plus efficace de résoudre le problème. [2]

La FAR privilégie elle aussi la description des résultats attendus plutôt que l'imposition détaillée de la manière d'exécuter le travail. [1]

Ainsi :

« le site doit prendre correctement en charge les scénarios convenus sur les appareils indiqués »

peut être une meilleure exigence que la prescription de chaque détail d'implémentation lorsque la technologie elle-même n'est pas une contrainte essentielle.

Bien entendu, la méthode peut être importante pour des raisons de sécurité, de conformité, d'intégration ou de normes techniques. Dans ces cas, elle doit être précisée.

Lors de la définition du périmètre, il est important de distinguer :

le résultat direct du travail du spécialiste et un résultat commercial qui dépend aussi d'autres facteurs.

Un spécialiste peut s'engager à :

• préparer et lancer une campagne dans le périmètre convenu,
• réaliser une analyse,
• livrer un nombre défini de supports,
• mettre en oeuvre une fonctionnalité répondant à des critères définis.

Il faut être beaucoup plus prudent avec les garanties portant sur les ventes, le nombre de clients, le classement dans les moteurs de recherche ou d'autres résultats dépendant du marché, du budget, du produit, des actions du client ou de systèmes externes.

Les orientations britanniques actuelles sur la répartition des risques indiquent explicitement que les fournisseurs doivent être responsables des résultats sur lesquels ils peuvent agir. [3]

Une bonne description n'affaiblit pas la responsabilité. Elle place la responsabilité là où le contrôle existe réellement.

Tous les services n'ont pas besoin d'un document de plusieurs pages.

Pour une tâche simple, les informations essentielles peuvent tenir en quelques paragraphes. Pour un projet plus important, le même raisonnement peut devenir une spécification détaillée, un calendrier, des critères d'acceptation et un processus formel de changement.

Un exemple de Terms of Reference publié par la Banque mondiale indique qu'un tel document doit exprimer clairement les exigences relatives aux services de conseil et les attentes de l'autorité contractante, et qu'il doit être adapté au projet concret et au contexte local. [4]

La longueur n'est pas l'essentiel. La vraie question est de savoir si une information manquante pourrait raisonnablement modifier le prix, le délai, la responsabilité ou le résultat attendu.

La description d'un service sur un site ou un profil peut n'être qu'une partie du processus contractuel. Les obligations juridiques précises dépendent du pays, du type de transaction, du statut des parties et du mode de vente.

Dans les relations entre professionnels et consommateurs dans l'UE, le portail officiel Your Europe identifie parmi les informations précontractuelles les principales caractéristiques du service, le prix total frais compris, les modalités de paiement et d'exécution et, le cas échéant, la durée du contrat. [5]

Les orientations de l'UE destinées aux entreprises précisent également que les clauses standard des contrats avec les consommateurs doivent être équitables et rédigées dans un langage clair et compréhensible, afin que le consommateur puisse comprendre leurs conséquences économiques. [6]

Ces exigences concernent certaines relations de consommation dans l'UE. Elles ne doivent pas être étendues automatiquement à toutes les transactions entre entreprises ni à d'autres juridictions.

Cet article est un guide éditorial sur la description des services, pas un modèle de contrat ni un conseil juridique.

1. Le client comprend-il le problème ou l'objectif auquel répond le service ?
2. Le résultat final est-il nommé ?
3. Ce qui est inclus dans le périmètre est-il clair ?
4. Le client sait-il quels éléments concrets il recevra ?
5. Existe-t-il une manière raisonnable d'évaluer l'achèvement ?
6. Est-il clair ce que le client doit fournir ou gérer ?
7. Les hypothèses les plus importantes sont-elles visibles ?
8. Les exclusions évidentes pouvant créer de la confusion sont-elles indiquées ?
9. Le calendrier et les étapes reflètent-ils les dépendances des deux parties ?
10. Est-il clair ce qui se passe lorsque le périmètre change ?
11. Le prix, le modèle de facturation et les coûts supplémentaires sont-ils présentés au bon moment ?
12. La description évite-t-elle de promettre un résultat que le spécialiste ne contrôle pas ?

Le meilleur test d'une bonne description est simple.

Après l'avoir lue, le client et le spécialiste devraient répondre de façon similaire aux questions suivantes :

Que doit-on atteindre ? Que sera-t-il fait ? Que recevra le client ? Qu'est-ce qui n'est pas inclus ? Que doit faire le client ? Comment saurons-nous que le travail est terminé ? Que se passe-t-il si le périmètre change ?

Si les réponses concordent, le prix et le calendrier disposent d'un bien meilleur contexte.

Si les réponses divergent, le problème ne commence souvent pas pendant l'exécution. Il commence dès la description du service.

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

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

[3] UK Government - Risk Allocation and Pricing Approaches Guidance Note
Ouvrir la source

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

[5] Your Europe - Contract information: what you should know before buying
Ouvrir la source

[6] Your Europe - Contracts with consumers
Ouvrir la source

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

Note méthodologique : les sources ont des portées différentes et ne constituent pas une norme unique de description des services. Cet article utilise uniquement les principes qu'elles étayent réellement : orientation vers les résultats, mesure, périmètre clair, hypothèses, responsabilité sur les facteurs contrôlables par le fournisseur et transparence de l'information pour le client.