Critères d’acceptation : comment un fondateur non technique définit le terminé

Les critères d’acceptation, réécrits pour celui qui paie le logiciel, pas pour celui qui le construit. Une façon en langage simple de définir le « terminé » de chaque fonctionnalité que vous commandez, convenue avant le début du travail, pour que le jour de la livraison soit une inspection et non une dispute.

Une fondatrice avec qui j’ai travaillé l’an dernier dirigeait un cabinet de comptabilité boutique. Elle payait un studio pour construire un portail client, et la spécification disait, en entier : « Les clients peuvent téléverser leurs factures du mois. » Tout le monde a approuvé. Trois semaines plus tard la fonctionnalité était « terminée ». Le client pouvait téléverser un fichier. Un fichier. Aucun moyen de savoir à quel mois il appartenait, aucune confirmation qu’il était arrivé, aucune limite de taille, et un PDF de plus de dix mégaoctets échouait en silence. Elle croyait avoir acheté une boîte de réception de factures. Elle avait acheté un sélecteur de fichiers. Personne n’avait menti. La phrase qu’elle a approuvée n’était tout simplement pas une définition du terminé.

Les critères d’acceptation sont les conditions qu’un logiciel doit remplir avant que vous n’acceptiez qu’il est fini et correct. Ils transforment une demande vague de fonctionnalité en une courte liste de choses vraies ou fausses le jour de la livraison. Dans les équipes agiles, ils sont en général écrits par des product managers dans une syntaxe rigide. Pour un fondateur non technique qui achète un développement sur mesure, ce cadrage est le mauvais. Vous n’écrivez pas des tickets pour une équipe que vous dirigez. Vous définissez ce que vous payez, à des gens que vous ne dirigez pas, pour que « terminé » signifie la même chose pour eux et pour vous.

Pourquoi « terminé » est le mot le plus cher de votre projet

L’écart qui a piégé ma fondatrice en comptabilité, c’est l’écart entre ce qu’une fonctionnalité semble être en réunion et ce qu’elle doit vraiment faire pour une personne réelle. « Les clients peuvent téléverser leurs factures du mois » est un souhait. Cela sonne complet parce que vous pouvez l’imaginer. Mais un développeur ne construit pas une image. Il construit l’instruction littérale, et là où l’instruction s’arrête, il fait une supposition raisonnable. Sa supposition raisonnable est façonnée par ce qui est le plus rapide à livrer, parce qu’il a un délai lui aussi. Votre supposition raisonnable est façonnée par ce dont votre client a besoin. Ces deux suppositions ne sont presque jamais la même, et la différence surgit au pire moment possible : quand le travail est « livré » et le paiement dû.

C’est la dispute du jour de livraison que tout fondateur non technique finit par avoir. Vous dites « ce n’est pas ce que je voulais ». Le studio dit « c’est ce qui était écrit ». Vous avez tous les deux raison, et vous voilà à négocier une reconstruction sans aucun levier, parce que la chose que vous pointez n’a jamais été écrite sous une forme que quiconque pouvait vérifier. Les critères d’acceptation sont la façon d’éviter cette conversation. Ils déplacent le désaccord au début, quand il coûte un courriel au lieu d’un jalon de paiement.

Ce que les critères d’acceptation ne sont pas

Ils ne sont pas le document d’exigences. Le document d’exigences dit quoi construire et pourquoi. Les critères d’acceptation disent comment vous saurez que chaque pièce a été construite correctement. Le premier est la commande ; le second est le reçu contre lequel vous la vérifiez.

Ils ne sont pas non plus les tests d’acceptation utilisateur, même si les deux sont confondus sans arrêt. Les critères d’acceptation s’écrivent avant le développement, comme une définition. Les tests d’acceptation utilisateur sont le processus à la fin, où vous vous asseyez et vérifiez que les critères ont été remplis. Vous écrivez les critères une fois ; vous lancez le test contre eux plus tard. Sans les critères, le test n’est que vous en train de cliquer partout en espérant remarquer ce qui ne va pas, ce qui est la manière dont les fondateurs valident un logiciel qui casse la première semaine où un vrai client le touche.

Et ils ne remplacent pas le fait de décider quoi construire, pour commencer. Si vous n’avez pas fait le travail de priorisation des fonctionnalités, écrire des critères d’acceptation pour quarante fonctionnalités ne produit que quarante choses bien spécifiées que vous ne pouvez pas payer. Les critères viennent après que vous avez décidé qu’une fonctionnalité en vaut la peine, pas à la place de cette décision.

Les quatre questions qui transforment un souhait en critère

Vous n’avez pas besoin de Gherkin, de « Given-When-Then » ni d’aucune syntaxe formelle que les blogs agiles vont vous tendre. Cette syntaxe existe pour aider les ingénieurs à automatiser des tests, et vous n’automatisez pas des tests. Vous avez besoin de critères que vous pouvez lire et vérifier vous-même. Voici le test que je donne à tout fondateur non technique avant qu’il ne valide une fonctionnalité. Passez chaque critère proposé par quatre questions.

Un : porte-t-il sur une personne qui fait quelque chose, et non sur une qualité que le logiciel possède ? « Le portail est convivial » n’est pas vérifiable. « Un client peut téléverser une facture et la retrouver le mois suivant » l’est. Écrivez les critères comme des actions qu’un utilisateur réel accomplit, avec un résultat qu’il peut voir. Des qualités comme rapide, propre et intuitif sont des opinions ; les actions sont des faits.

Deux : pouvez-vous le vérifier vous-même, sans le développeur dans la pièce ? Si vérifier un critère exige que la personne qui l’a construit explique pourquoi cela compte comme terminé, ce n’est pas un critère. C’est son opinion déguisée en critère. Tout l’intérêt, c’est que vous puissiez vous asseoir seul et rendre le verdict : réussi ou non. Si vous ne le pouvez pas, réécrivez-le jusqu’à ce que vous le puissiez.

Trois : est-il binaire ? Un critère a exactement deux issues : réussi ou non. « Ça a l’air bien » a une infinité d’issues et ne vaut donc rien le jour de la livraison. « Une facture téléversée affiche le mois sous lequel elle a été classée, et un fichier de plus de dix mégaoctets affiche une erreur au lieu d’échouer en silence » a lieu ou n’a pas lieu. Dès qu’un critère demande un jugement, découpez-le dans les choses précises que vous étiez en train de juger.

Quatre : a-t-il été convenu avant le développement ? Un critère inventé à la livraison est une renégociation, pas une norme. Tout le levier des critères d’acceptation vient du fait de les convenir en amont et de les attacher à ce que vous payez. Un critère que vous ajoutez après que le travail est fait est une faveur que vous demandez, et vous la paierez comme telle.

La règle de base derrière les quatre : un bon critère d’acceptation est un critère que vous pourriez tendre à un inconnu, et il pourrait vous dire réussi ou non sans poser une seule question. Si un inconnu devait demander « que veut dire terminé ici », votre développeur le devra aussi, et il y répondra pour vous de la façon qui livre le plus vite.

À quoi ressemblent les critères d’acceptation en pratique

Reprenez la fonctionnalité de factures par laquelle tout a commencé. « Les clients peuvent téléverser leurs factures du mois » est le souhait. Passez-le par les quatre questions et il devient une liste courte et vérifiable :

• Un client connecté peut téléverser une facture en PDF ou en image et la rattacher à un mois précis.
• Après le téléversement, le client voit la facture dans une liste de ce mois, avec le nom du fichier et la date.
• Un fichier de plus de dix mégaoctets est refusé avec un message visible, pas avec un échec en silence.
• Le client peut supprimer une facture téléversée par erreur, et elle disparaît de la liste.
• Le personnel du cabinet peut voir les factures de tous les clients d’un mois donné dans une seule vue.

Aucune de ces phrases ne mentionne du code. Chacune est quelque chose que la fondatrice peut s’asseoir et vérifier en cinq minutes, seule, le jour de la livraison. C’est tout le test. Remarquez que la liste a aussi fait quelque chose de plus discret : elle a fait remonter des décisions que personne n’avait encore prises. Le personnel doit-il voir les factures dans une seule vue ? Le client peut-il supprimer ? Ces questions sont bien moins chères à trancher maintenant, par écrit, qu’après qu’un développeur en a deviné les réponses.

Cinq phrases simples ne sont pas du travail en plus. C’est le travail que vous alliez faire de toute façon, déplacé au seul moment du projet où il est encore bon marché.

Là où les critères d’acceptation rencontrent l’argent

Voici la partie que les blogs agiles ne couvrent jamais, parce que leurs lecteurs ne sont pas ceux qui signent la facture. Pour un fondateur, les critères d’acceptation ne sont pas une coquetterie de documentation. Ils sont la définition du moment où un paiement est dû.

Un contrat de développement logiciel bien structuré attache les paiements par jalon à l’acceptation, pas à des dates de calendrier. « La phase deux est payée quand le module de factures passe ses critères d’acceptation » est une phrase nette et applicable. « La phase deux est payée le 30 juin » paie du temps, que la chose marche ou non. Si vos critères sont vagues, vos jalons sont vagues, et vous payez en fait de l’activité au lieu de résultats. Des critères serrés sont ce qui vous laisse payer pour des résultats sans microgérer le développement, qui est toute la raison pour laquelle un fondateur non technique engage un partenaire plutôt qu’une équipe qu’il doit surveiller.

C’est pourquoi, aussi, un studio compétent accueillera vos critères au lieu d’y résister. Une acceptation vague est aussi dangereuse pour celui qui construit que pour vous : il ne sait jamais quand il a fini, et le « terminé » ne cesse de bouger. Des critères clairs protègent les deux côtés. Un partenaire qui rechigne à écrire ce que « terminé » veut dire vous dit quelque chose sur la façon dont il compte le définir plus tard.

Là où les fondateurs se trompent sur les critères d’acceptation

La première erreur est d’en écrire trop. Vous n’avez pas besoin de critères pour tout comportement concevable. Vous en avez besoin pour la poignée de choses qui, si elles sortaient mal, rendraient la fonctionnalité inutile ou embarrassante. Cinq critères affûtés sur le module de factures valent mieux que cinquante que personne ne vérifiera. Des critères d’acceptation que vous ne vérifiez pas ne sont pas des critères ; ce sont des décorations.

La deuxième erreur est d’y cacher des exigences. Un critère décrit une condition que la fonctionnalité convenue doit remplir. Ce n’est pas l’endroit pour faire passer en douce une fonctionnalité nouvelle que vous avez oublié de demander. Si « les clients reçoivent un courriel quand leur facture est approuvée » n’a jamais été dans le périmètre, c’est un changement, et cela relève d’une conversation sur le périmètre, pas d’une liste d’acceptation présentée à la livraison.

La troisième, et la plus courante, est d’accepter « ça a l’air bien » de vous-même. Le fondateur qui survole une démo, voit le chemin heureux marcher une fois et valide est le fondateur qui découvre l’échec silencieux de dix mégaoctets quand un vrai client le heurte. L’acceptation est une inspection. Passez chaque critère, y compris les vilains, sur ce qui arrive quand quelque chose tourne mal. Les critères sur l’échec sont souvent ceux qui séparent un logiciel que vous pouvez mettre devant un client payant d’un logiciel qui ne fait que bien paraître en démo.

Questions fréquentes

Quel est un exemple de critère d’acceptation ?

Pour une fonctionnalité comme « les clients peuvent téléverser des factures », un critère d’acceptation utile est : « Un client connecté peut téléverser un PDF, le rattacher à un mois et le voir dans la liste de ce mois ensuite ; un fichier de plus de dix mégaoctets est refusé avec un message visible. » Il nomme une action réelle d’utilisateur et un résultat que vous vérifiez vous-même, avec deux issues claires : ça marche ou ça ne marche pas.

Quels sont des exemples de critères d’acceptation pour un fondateur non technique ?

Les bons exemples sont toujours des phrases simples sur une personne qui fait quelque chose et voit un résultat : un utilisateur peut réinitialiser un mot de passe oublié et se connecter avec le nouveau ; un admin peut exporter les commandes du mois vers un tableur ; un client qui saisit une carte invalide voit une erreur et n’est pas débité. Évitez les exemples écrits en syntaxe de code. Vous avez besoin de critères que vous pouvez lire et vérifier, pas de critères faits pour l’automatisation des tests.

Quels sont les trois C des critères d’acceptation ?

Dans la pratique agile, les trois C sont Card, Conversation et Confirmation (carte, conversation et confirmation) : la fonctionnalité sur une carte, la discussion sur ce qu’elle signifie et la confirmation qu’elle marche. Pour un fondateur qui achète un développement, la traduction utile est : écrivez la fonctionnalité, parlez de ce que « terminé » veut dire avant le début du travail et confirmez-le contre cette définition à la livraison. L’étape de confirmation est celle que les fondateurs sautent, et c’est celle qui leur coûte.

Qui écrit les critères d’acceptation, le fondateur ou le développeur ?

Rédigez-les vous-même, avec vos propres mots, parce qu’ils encodent ce dont votre client a besoin et vous seul le savez. Puis tendez-les à votre partenaire de développement et laissez-le affiner les bords techniques et signaler toute ambiguïté. Des critères écrits seulement par celui qui construit tendent à décrire ce qui est facile à construire ; des critères écrits seulement par le fondateur tendent à manquer les cas limites. La version convenue, arrêtée avant le développement, est celle qui vous protège.

Les critères d’acceptation sont l’assurance la moins chère d’un développement sur mesure. Une poignée de phrases simples, convenue avant que quiconque écrive du code, est ce qui se tient entre vous et la dispute du jour de livraison où vous avez déjà payé et perdu votre levier. Définissez le « terminé » tant qu’il coûte encore un courriel. Le studio qui prend vos critères au sérieux est celui qui vaut la peine d’être gardé.