Un prototype avant le développement plutôt qu’un cahier des charges : pourquoi cent pages de spécifications ne sauveront pas votre projet

Une entreprise passe plusieurs mois à préparer son cahier des charges. Le document fait plus de cent pages et a été relu et commenté par les équipes commerciales, les opérations, la finance et l’informatique. Après la signature du contrat avec le prestataire, des mois de développement s’enchaînent, et lors de la première démonstration, on entend : « Ce n’est pas ce que nous avions en tête. »

Ce scénario est un cas d’école, mais le problème qu’il illustre est bien réel. Dans l’enquête internationale NaPiRE, dont le questionnaire a été complété par 228 organisations de 10 pays, les répondants ont désigné les problèmes les plus critiques de l’ingénierie des exigences. Le problème le plus fréquemment cité : des exigences incomplètes ou non exprimées (48 % des répondants). Les lacunes de communication entre l’équipe et le client ont été citées par 41 % d’entre eux, et parmi les dix premiers problèmes, ce sont elles que les répondants ont le plus souvent désignées comme une cause majeure d’échec de projet.

Un cahier des charges volumineux donne un sentiment de sécurité, mais il ne permet pas de tester l’essentiel : les utilisateurs comprendront-ils la solution et sauront-ils s’en servir pour faire leur travail ? Un prototype logiciel apporte la réponse en quelques jours à quelques semaines, quand une correction coûte encore peu, et non après des mois de développement.

Pourquoi signer un cahier des charges ne met pas à l’abri des malentendus

Une signature confirme l’accord sur un texte, pas le fait que les deux parties se représentent la même chose derrière les mots. Dans son essai No Silver Bullet, publié en 1987, Frederick P. Brooks Jr. écrivait que la partie la plus difficile de la construction d’un logiciel consiste à décider précisément ce qu’il faut construire, et qu’aucune autre partie n’est plus difficile à rectifier par la suite. Selon lui, il est en réalité impossible pour un client de spécifier de manière complète, précise et correcte les exigences d’un logiciel moderne avant d’en avoir essayé plusieurs versions.

Selon nous, un document épais tend plutôt à masquer ce problème. À chaque page, l’impression d’exhaustivité grandit, mais chaque service lit surtout son propre chapitre et personne ne met par écrit ce qui va de soi. L’entreprise n’obtient un premier retour sur quelque chose de tangible qu’une fois que du code repose déjà sur le malentendu. Dans le même essai, Brooks qualifiait de fondamentalement erronée une hypothèse qui sous-tendait les achats de logiciels de l’époque : l’idée qu’un système puisse être spécifié à l’avance de manière satisfaisante, mis en concurrence par appel d’offres, construit puis installé.

Une même phrase, des écrans différents

Un texte ne s’utilise pas, et vous ne pouvez donc pas vérifier à travers lui que tout le monde le comprend de la même façon. Prenons une exigence type : « les commandes dépassant le plafond sont approuvées par le responsable ». La directrice financière imagine un récapitulatif matinal pour une approbation groupée, le responsable d’entrepôt une notification sur son mobile, le développeur un champ de statut dans une table. Toutes ces représentations sont conformes à la phrase, et chacune entraîne une charge de travail et un coût différents.

Les exceptions n’apparaissent que lorsque la tâche est réellement effectuée. Qui approuve lorsque le responsable est en congé ? L’approbation reste-t-elle valable après une modification de la quantité ?

Un quart des répondants à l’enquête NaPiRE ont en outre classé parmi les problèmes les plus critiques la difficulté des parties prenantes à distinguer les exigences des solutions qu’elles connaissent déjà. Le guide du gouvernement britannique GOV.UK Service Manual recommande, en phase de discovery, c’est-à-dire lors de l’exploration du problème avant toute construction, de reformuler une solution fixée d’avance en problème : non pas « construire une carte interactive des centres d’accueil », mais « comment aider les gens à trouver plus facilement le centre le plus proche ».

Ce qu’est un prototype et ce qu’il n’est pas

Un prototype est une forme simplifiée du futur produit, qui permet d’essayer une solution avant de la programmer. Kara Pernice, de Nielsen Norman Group, le décrit comme une hypothèse, c’est-à-dire une solution candidate dont la vérification la plus directe consiste à observer des personnes qui l’utilisent. Ce n’est pas un produit minimum viable (MVP), soit, selon Eric Ries, la version d’un nouveau produit qui permet à une équipe de recueillir le maximum d’apprentissage validé sur ses clients avec le moins d’effort possible. Le prototype est un outil plus ciblé : il vérifie la solution envisagée avant même qu’elle ne soit construite.

Selon Pernice, la fidélité d’un prototype est son degré de ressemblance avec le système final, sur le plan de l’interactivité, du visuel, mais aussi du contenu et des commandes. Pour une décision à prendre avant le développement, nous distinguons en pratique trois niveaux :

• Esquisse ou prototype papier. Ce n’est pas un système qui réagit, mais une personne qui connaît la maquette et présente à l’utilisateur les écrans dessinés suivants. Dans la méthode voisine dite du Magicien d’Oz (Wizard of Oz), une personne pilote l’écran depuis une autre pièce, ce qui permet de tester même des comportements que personne n’a encore programmés. Jakob Nielsen range le prototypage papier parmi les techniques les plus rapides et les moins coûteuses. Il se prête à la validation de l’approche de base et du parcours.
• Prototype cliquable. Des écrans reliés entre eux, qui réagissent comme une application alors que rien ne tourne derrière. Il permet de vérifier si les utilisateurs accomplissent les tâches clés sans aide.
• Prototype fonctionnel sur données réelles. Une portion limitée de vrai code, connectée à un échantillon de données ou à une intégration risquée. Il est utile lorsque l’incertitude ne porte pas sur l’interface, mais sur les données ou la technologie.

Notre règle de choix : la fidélité la plus basse qui permet encore de répondre à la question du moment. Selon Nielsen, l’avance d’un test précoce sur un test tardif est telle qu’elle l’emporte même sur l’écart de qualité entre les prototypes. Le Design Kit d’IDEO.org compte, pour le prototypage rapide, de quelques jours à quelques semaines selon ce qui est testé.

Ce qu’un prototype logiciel doit démontrer

Un prototype est un test, pas une présentation. Selon le guide GOV.UK, il n’est pas nécessaire de prototyper l’ensemble du parcours utilisateur : il suffit souvent de se concentrer sur les parties les plus complexes et de tester les hypothèses les plus risquées. Avant le développement, le prototype devrait répondre aux questions suivantes :

1. Les utilisateurs comprennent-ils le parcours ? Une personne qui n’a pas participé à la conception parvient-elle à mener la tâche de bout en bout ? Chaque hésitation pendant le test peut devenir, une fois le système en service, un appel au support ou une erreur de commande.
2. Les décisions clés ont-elles été prises ? Un texte permet de reporter un désaccord, un écran non. Ce qui est tranché maintenant ne restera pas une incertitude dans l’offre chiffrée.
3. La conception résiste-t-elle aux données réelles ? Les vrais noms sont souvent plus longs que dans les exemples, des champs restent vides et des enregistrements sont en double.
4. L’intégration la plus risquée fonctionne-t-elle ? Une intégration est une connexion avec un autre système, par exemple la comptabilité. Le service britannique Register to vote ne fonctionnerait pas sans une API, c’est-à-dire une interface d’échange de données, connectée aux systèmes d’inscription de plus de 400 collectivités locales. L’équipe s’y est donc consacrée dès la phase alpha, dédiée aux prototypes.
5. Les utilisateurs l’adopteront-ils ? Un prototype ne garantit pas l’adoption, mais il indique si les gens préféreraient la nouvelle façon de faire à leurs solutions de contournement actuelles. L’article Le système le plus cher est celui que vos équipes n’utilisent pas explique pourquoi c’est important.

Tests utilisateurs : observer, pas interroger

Un test utilisateur consiste à confier à une personne du public cible une tâche réelle à réaliser sur le prototype, par exemple la consigne type « émettez un avoir pour cette facture », pendant que vous observez où elle hésite et ce qu’elle interprète différemment. Un questionnaire recueille ce que les gens pensent qu’ils feraient. L’observation montre ce qu’ils font réellement.

Jakob Nielsen s’appuie sur un modèle selon lequel une première étude avec cinq participants met au jour environ 85 % des problèmes d’utilisabilité, c’est-à-dire des points où les utilisateurs bloquent ou se trompent. Plutôt qu’une seule étude avec 15 personnes, il recommande trois séries de cinq, car chaque nouvelle série vérifie les corrections et révèle des problèmes plus profonds. Cela vaut pour des utilisateurs comparables : pour deux groupes nettement différents, il recommande trois à quatre personnes par groupe.

Quand un changement tardif coûte vraiment cher

Le coût du changement correspond au prix de la modification d’une décision à une phase donnée du projet. Dans un article de 2001, Barry Boehm et Victor Basili indiquaient que trouver et corriger un problème logiciel après la livraison coûte souvent 100 fois plus cher qu’en phase d’exigences et de conception. Ils ont ajouté le mot « souvent » à dessein : pour les petits systèmes non critiques, le rapport est selon eux plutôt de 5:1. Ils indiquaient également que les projets de l’époque consacraient environ 40 à 50 % de leur effort à des reprises évitables, et comptaient les exigences spécifiées à la hâte parmi les deux principales sources de ces reprises.

Cette hausse du coût dans le temps n’est cependant pas universelle. Sur 171 projets, Tim Menzies et ses coauteurs n’ont trouvé aucune preuve que résoudre un problème à une phase ultérieure demande systématiquement ou sensiblement plus d’effort que peu après son apparition. Précisons qu’il s’agissait surtout de projets de petite et moyenne taille menés selon la méthode Team Software Process, sans données sur la période postérieure à la livraison. Les auteurs soulignent eux-mêmes que l’effet pourrait n’apparaître que dans certains types de projets.

Selon nous, ce n’est pas le calendrier qui renchérit un changement tardif, mais tout ce qui s’est construit entre-temps sur la décision erronée : code, intégrations, documentation, formations et modèle de données. Kara Pernice rappelle que jeter du code coûte très cher, et jeter un prototype, non. Après la mise en service, l’entreprise paie en outre chaque jour un malentendu non corrigé sous forme de frictions dans le travail quotidien, dont l’article Le bon design n’est pas une décoration détaille le calcul.

Un prototype est donc surtout rentable là où le plus de choses se bâtiraient sur une décision erronée : nombreux utilisateurs, intégrations multiples et développement long. Son périmètre comme son coût peuvent être bornés à l’avance, le coût d’une erreur, non.

Le prototype comme base de l’offre et de l’estimation

Lorsque des prestataires chiffrent un texte de cent pages, chacun chiffre sa propre interprétation et sa propre provision pour aléas. Le plus prudent surévalue le prix, le moins prudent le sous-évalue, et l’écart ressurgit plus tard dans les demandes de modification, c’est-à-dire les travaux hors du périmètre convenu au départ, facturés en sus.

Un prototype cliquable assorti de critères d’acceptation change le point de départ. Selon le guide GOV.UK, les critères d’acceptation sont un ensemble de résultats qui sert de liste de contrôle pour confirmer que le service a rempli sa mission et répondu au besoin de l’utilisateur. Ils sont souvent rédigés sous la forme « c’est terminé quand… », par exemple pour le service Register to vote : l’utilisateur sait comment s’inscrire en ligne. Le prototype montre comment cela doit fonctionner, les critères fixent quand c’est terminé, et les prestataires chiffrent ainsi la même chose.

Le guide conseille également de reconsidérer la raison pour laquelle vous avez besoin d’une fonctionnalité si vous ne parvenez pas à en formuler l’objectif. Une fonctionnalité non construite ne coûte rien, ni en développement ni en maintenance.

Les risques du prototype

• La confusion avec un produit fini. Un prototype cliquable a l’air terminé, mais il lui manque la sécurité, la gestion des données et le traitement des erreurs. Pernice prévient qu’avec un design très abouti, la direction cède facilement à la tentation de le mettre directement en production.
• Le peaufinage excessif du visuel. Selon Pernice, en basse fidélité, les utilisateurs expriment plus volontiers des réactions négatives, les designers s’attachent moins à leur proposition et les parties prenantes voient que le travail n’est pas terminé. Le peaufinage tend donc plutôt à étouffer les retours sincères.
• Le sort incertain du prototype. GOV.UK recommande de ne construire en phase alpha que le nécessaire pour tester les idées, sans viser un code de qualité production, et de prévoir de jeter ce code à la fin de cette phase. Il faut décider avant la construction du prototype s’il sera jeté ou développé. Sinon, par inertie, il peut devenir la base du produit, dette technique comprise, c’est-à-dire les raccourcis qui alourdissent le coût de chaque modification ultérieure.

Quand se passer de prototype

Un prototype réduit l’incertitude. Là où il n’y en a pas, ou lorsqu’on peut la réduire à moindre coût, il devient une dépense inutile.

• Vous achetez un logiciel standard sans adaptation. Une version d’essai ou une démo sur laquelle les utilisateurs testent leurs tâches réelles remplit alors le rôle du prototype.
• Le système est petit et non critique. Boehm et Basili écrivent que ce type de système peut être développé plus efficacement selon un mode moins formel de prototypage continu. Le produit lui-même, développé par courtes itérations, remplace alors un prototype distinct.
• La question n’est pas de savoir comment, mais si quelqu’un en veut. Un smoke test peut alors suffire, c’est-à-dire une vérification de l’intérêt avant même que la solution n’existe. Eric Ries raconte que son équipe a passé deux semaines à développer une fonctionnalité dont personne ne voulait, alors qu’un simple smoke test via une publicité AdWords aurait selon lui suffi à le révéler.
• Le problème ne vient pas du logiciel. Si un processus comporte une étape inutile, un prototype logiciel ne fera que la transposer à l’écran. Il faut d’abord supprimer cette étape. L’article Un bon système interne peut se rentabiliser plus vite qu’un nouveau salarié examine si un système sur mesure vaut vraiment l’investissement.

Selon GOV.UK, arrêter un projet à la fin de la phase de discovery n’est pas un échec si la recherche montre que c’est la meilleure décision : on économise ainsi du temps et de l’argent. Décidez donc de l’opportunité d’un prototype en fonction de l’endroit où se situe la plus grande incertitude du projet et de ce que coûterait une erreur.

Ce qu’il faut retenir

• Avant de signer un cahier des charges volumineux, validez par un prototype la partie la plus risquée : le parcours le plus fréquent, une exception qui fait débat ou une intégration non vérifiée.
• Fixez à chaque prototype, dès le départ, une question et un critère de réussite, faute de quoi le test se réduit à une présentation.
• Testez avec cinq personnes comparables sur des tâches réelles, puis menez une nouvelle série après les corrections.
• Fondez le cahier des charges et le choix du prestataire sur un prototype testé et des critères d’acceptation, afin que tous chiffrent la même chose.
• Commencez par nommer l’incertitude que vous cherchez à lever. Parfois, une version d’essai d’un logiciel standard, un smoke test ou un ajustement du processus l’élimine à moindre coût.