Les quatre valeurs

La collaboration avec les clients

La troisième valeur du Manifeste préfère la collaboration avec les clients à la négociation contractuelle. Le contrat garde sa place, à condition que la relation ne se réduise pas à lui. Cet article montre ce que le contrat au forfait suppose, comment les méthodes agiles organisent la présence du client et quels contrats peuvent soutenir cette collaboration.

Un contrat respecté et un client déçu

Une association d'aide alimentaire commande à une agence un site de collecte de dons. Le cahier des charges fait trente-cinq pages, et le contrat fixe un prix de 24 000 euros et un délai de cinq mois. Au troisième mois, la trésorière s'aperçoit en discutant avec des donateurs que la plupart voudraient donner un peu chaque mois par prélèvement, ce que le cahier des charges ne prévoit pas. L'agence répond que cette demande sort du contrat. Elle propose un avenant, c'est-à-dire une modification du contrat, de 4 500 euros et trois semaines de délai. L'association juge le prix excessif. Trois semaines passent en échanges de courriels où chacun relit le cahier des charges pour prouver qu'il a raison.

L'association finit par renoncer au don mensuel. Le site est livré à la date prévue, conforme au contrat, et il ne permet pas ce que les donateurs demandent le plus. Personne n'a été malhonnête dans cette histoire. L'agence a protégé sa marge, l'association a protégé son budget, et l'énergie des deux parties est allée à la discussion du contrat plutôt qu'au site. La troisième valeur du Manifeste décrit cette situation.

La collaboration avec les clients plus que la négociation contractuelle

Manifeste pour le développement Agile de logiciels (2001), texte intégral

Ce que le contrat au forfait suppose

Un contrat au forfait fixe à la signature le contenu, le prix et le délai. Il rassure l'acheteur, qui sait ce qu'il paiera. Il repose sur une hypothèse forte : le client sait décrire à l'avance, par écrit et complètement, ce dont il aura besoin plusieurs mois plus tard.

Quand cette hypothèse est fausse, le forfait oriente les comportements dans un sens fâcheux. Le client a intérêt à tout demander dès le départ, par précaution, puisque chaque ajout ultérieur sera facturé. Le fournisseur a intérêt à interpréter le cahier des charges au plus juste. Chaque découverte faite en cours de route devient un sujet de négociation, et les deux parties se retrouvent face à face au lieu de travailler au même résultat.

L'autre forme classique est la régie, où le client paie le temps passé. Elle laisse toute liberté de changer d'avis, mais elle reporte tout le risque sur le client, qui ne sait pas ce qu'il obtiendra pour son argent. Aucune des deux formes n'organise le travail en commun.

D'après Robert C. Martin, l'un des signataires, Kent Beck aurait dit à Snowbird que le but de l'agilité était de réparer la fracture entre les gens du métier et les développeurs. Martin rapporte ce propos dans Clean Agile (2019), près de vingt ans après la réunion. Il éclaire en tout cas l'intention de cette valeur.

Collaborer en pratique

Le quatrième principe du Manifeste dit ce que la collaboration exige :

Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

Principes sous-jacents au Manifeste (2001), principe 4

L'original anglais commence par « Business people and developers », c'est-à-dire les gens du métier et les développeurs. Le mot important est « quotidiennement ». Le client n'intervient plus seulement au début, pour exprimer son besoin, et à la fin, pour vérifier la livraison. Il participe tout au long du travail. Les méthodes agiles ont donné plusieurs formes à cette présence.

Le client sur site d'Extreme Programming

Dans Extreme Programming Explained (1999), Kent Beck demande qu'un utilisateur réel soit installé avec l'équipe et disponible à plein temps. Cette personne répond aux questions des développeurs, choisit ce qui sera fait en priorité et précise comment on vérifiera que chaque fonction convient. Les besoins sont notés sous forme de user stories, de courts récits écrits du point de vue de l'utilisateur, qui servent surtout de point de départ à une conversation (voir User stories, backlog et estimation).

Cette pratique est exigeante. Peu d'organisations acceptent de détacher à plein temps un bon connaisseur du métier, et la personne choisie porte une lourde charge. Une étude de terrain d'Angela Martin, Robert Biddle et James Noble, publiée en 2004 à partir de trois projets, décrit un rôle beaucoup plus prenant que ne le laissaient penser les textes de la méthode.

Le Product Owner de Scrum

Scrum confie ce rôle à un Product Owner. D'après le Guide Scrum, cette personne est responsable de la valeur du produit et de l'ordre du backlog, la liste ordonnée de tout ce qui reste à faire. Elle doit être une seule personne et non un comité. Le corpus Scrum lui consacre l'article Le Product Owner. Le risque de cette solution est connu : quand le Product Owner n'est pas lui-même un utilisateur, il peut devenir un écran entre l'équipe et les utilisateurs réels.

Les démonstrations régulières

À la fin de chaque itération, c'est-à-dire de chaque période de travail de quelques semaines, l'équipe montre au client ce qui fonctionne. Le client réagit, et les priorités de l'itération suivante sont ajustées. La collaboration s'appuie ainsi sur un objet réel et non sur l'interprétation d'un document.

Des contrats qui organisent la collaboration

La valeur dit « plus que », et le contrat reste nécessaire. La question devient donc de rédiger des contrats qui soutiennent le travail en commun. Mary et Tom Poppendieck passent en revue plusieurs formes dans Lean Software Development (2003), parmi lesquelles le contrat par étapes, où l'on s'engage sur une courte période à la fois, et le contrat à coût cible, où le client et le fournisseur partagent les dépassements comme les économies. La méthode DSDM propose de son côté de fixer le délai et le budget et de laisser varier le contenu, en classant les demandes en quatre catégories, de l'indispensable à ce qui ne sera pas fait cette fois.

Jeff Sutherland, cocréateur de Scrum, a présenté en 2008 un modèle de contrat résumé par la formule « Money for Nothing and Your Change for Free ». Il comporte deux clauses. La première permet au client de remplacer gratuitement une demande par une autre de taille équivalente, à la fin d'une itération, à condition qu'il participe au travail de l'équipe. La seconde lui permet d'arrêter le projet quand ce qui reste à faire ne vaut plus son coût, en versant au fournisseur 20 % du montant restant.

Ces modèles sont des propositions de praticiens. Ils supposent une confiance déjà établie et un client capable de juger ce qui lui est livré, et ils ne conviennent pas à toutes les situations.

Hors du logiciel : la cuisine de Claire et Thomas

La même logique vaut pour toute commande où le client découvre son besoin en voyant le résultat. Les travaux dans une maison en sont un cas courant.

Limites et pièges

La collaboration demande un client disponible et autorisé à décider. Ces deux conditions sont rarement réunies. Un client qui délègue un représentant sans pouvoir, ou qui ne vient pas aux démonstrations, rend la valeur inapplicable, quelle que soit la bonne volonté de l'équipe.

Le mot « client » est lui-même ambigu. Il peut désigner celui qui paie, celui qui utilisera le produit ou celui qui a passé commande, et ces personnes n'ont pas toujours les mêmes intérêts. La trésorière de notre exemple n'est pas un donateur. Collaborer avec le payeur ne garantit pas que l'on réponde au besoin de l'utilisateur.

La collaboration sans cadre a aussi ses dangers. Si le contenu peut changer sans que le budget ou le délai soient revus, le fournisseur supporte seul le coût des changements. À l'inverse, en régie pure, le client paie sans fin. Un donneur d'ordre puissant peut invoquer l'agilité pour obtenir à la fois un prix fixe et un contenu variable, ce qui détourne la valeur de son sens (voir Être agile ou faire de l'agile). La confiance ne dispense pas d'écrire ce qui est convenu, car c'est en cas de désaccord que l'écrit sert.

Certains contextes laissent peu de marge. Les règles d'achat des administrations et des grandes entreprises exigent souvent de décrire le besoin et de comparer des offres avant de choisir, ce qui pousse vers le forfait. Des contrats par étapes y sont possibles, mais ils demandent plus de travail aux acheteurs.

Enfin, cette valeur repose sur l'expérience des praticiens et sur le raisonnement. Nous ne connaissons pas d'étude solide qui compare les résultats des différentes formes de contrat, et l'article Que valent les preuves ? rappelle la prudence nécessaire.