Les critères d'acceptation, ce sont les conditions qui doivent être vraies pour que vous puissiez dire « oui, c'est bien ce que j'ai demandé ». On les écrit avant le début du travail, en langage courant, et chacun se vérifie par oui ou par non. « Le champ code promo accepte les codes en majuscules comme en minuscules » est un critère d'acceptation. « Le checkout est fluide » n'en est pas un.

Ils concernent toute personne qui demande à quelqu'un d'autre de construire quelque chose : une fondatrice qui briefe un développeur, une marque qui confie la refonte de sa boutique en ligne à une agence, une équipe produit dans un éditeur de logiciel. Si vous avez déjà payé une prestation puis discuté pour savoir si elle était vraiment terminée, les critères d'acceptation sont l'outil qui aurait évité cette discussion.

Que sont les critères d'acceptation ?

Les critères d'acceptation sont une liste d'énoncés précis et testables rattachés à une unité de travail, en général une user story ou une fonctionnalité. Ils décrivent le comportement attendu du point de vue de l'utilisateur : ce qui entre, ce qui sort et ce qui se passe dans les cas délicats. Quand tous les critères sont validés, le travail est accepté. Si l'un échoue, le travail repart en correction.

Ce n'est pas une spécification technique. Ils disent ce qui doit se passer, pas comment le développeur doit le coder. Ce n'est pas non plus la « définition de terminé » (definition of done). Celle-ci est une checklist générale qui s'applique à toutes les tâches d'une équipe, du type « code relu, tests écrits, déployé en préproduction ». Les critères d'acceptation, eux, sont propres à un travail donné.

Le vocabulaire voisin :

  • User story : un besoin en une ligne, par exemple « en tant que cliente, je veux appliquer un code promo afin de payer moins cher ».
  • Étant donné, quand, alors (given, when, then) : un format courant pour rédiger les critères. Étant donné une situation de départ, quand l'utilisateur fait quelque chose, alors un résultat suit.
  • Cas limite : une situation inhabituelle que le travail doit quand même gérer, comme un code expiré ou un panier vide.
  • Recette : le moment où la personne qui a commandé le travail le vérifie au regard des critères.

Pourquoi c'est important

Les demandes floues sont la première cause de dépassement de budget dans les projets logiciels. Le développeur construit ce qu'il a compris, vous attendiez autre chose, et l'écart se paie en jours supplémentaires.

Imaginez une marque de compléments alimentaires qui traite 800 commandes par mois. Elle confie à un freelance, pour 6 000 €, l'ajout d'une option « abonnement avec remise » à sa boutique sur mesure. Le brief dit : « les clients peuvent s'abonner pour obtenir une remise ». Le freelance livre une case à cocher qui applique 10 % sur la première commande. La marque attendait 10 % sur chaque commande récurrente, la possibilité de sauter un mois et un email de rappel trois jours avant chaque prélèvement. Ces trois éléments demandent huit jours de plus à 450 € par jour, soit 3 600 € supplémentaires, et le lancement glisse de deux semaines.

Rédigées en critères d'acceptation dès le départ, ces attentes auraient figuré dans le devis. Le freelance aurait pu les chiffrer ou signaler leur complexité, et la marque aurait pu choisir de lancer sans l'option de report. Le coût final aurait peut-être été le même, mais il aurait résulté d'une décision plutôt que d'une surprise.

Comment ça marche

Rédiger de bons critères d'acceptation suit une routine simple :

  • Partez de la user story. Écrivez en une phrase qui est l'utilisateur, ce qu'il veut et pourquoi.
  • Décrivez le parcours principal. Racontez ce qui se passe quand tout va bien, étape par étape, en termes observables.
  • Ajoutez les cas limites. Posez-vous des questions du type « et si » : et si le code a expiré, si le produit est en rupture, si la cliente est sur mobile, si le paiement échoue.
  • Rendez chaque critère vérifiable. Remplacez « rapide », « joli » ou « intuitif » par quelque chose que l'on peut contrôler, comme « la page affiche le nouveau total sans se recharger ».
  • Gardez-les indépendants. Chaque critère doit pouvoir se vérifier seul, pour qu'un échec désigne un problème précis.
  • Relisez-les à deux. Parcourez la liste avec la personne qui va réaliser le travail, avant qu'elle commence. Ses questions révèlent les trous.
  • Testez-les à la livraison. Reprenez la liste point par point et notez ce qui passe et ce qui échoue.

Au format « étant donné, quand, alors », un critère ressemble à ceci : étant donné qu'une cliente a un produit à 40 € dans son panier, quand elle saisit le code PRINTEMPS15, alors le total du panier affiche 34 € et le code apparaît dans le récapitulatif de commande.

Repères et exemples

Il n'y a pas de nombre imposé, mais ces fourchettes sont courantes :

  • Trois à huit critères par story est la norme. Moins, c'est souvent que des cas limites manquent. Plus de dix, c'est souvent que la story est trop grosse et mérite d'être découpée.
  • Un petit projet de boutique, comme la refonte de la page produit, peut compter 30 à 60 critères sur l'ensemble de ses stories.
  • Les cas limites représentent souvent entre un tiers et la moitié de la liste. C'est là que se cachent la plupart des bugs.

Des exemples tirés de situations de vendeurs :

  • Code promo : un code expiré la veille affiche le message « Ce code a expiré » et le total ne change pas.
  • Stock : quand la dernière unité d'une variante est vendue, la variante affiche « Épuisé » sur la page produit et ne peut plus être ajoutée au panier.
  • Livraison digitale : moins d'une minute après un paiement réussi, l'acheteur reçoit un email avec un lien de téléchargement qui fonctionne.
  • Checkout sur mobile : sur un écran de 375 pixels de large, le bouton Payer est visible sans défilement horizontal.

Erreurs fréquentes

  • Écrire des opinions au lieu de conditions. « Le design doit être moderne » ne se teste pas. Renvoyez plutôt vers une maquette ou un détail mesurable.
  • Oublier les parcours d'échec. La plupart des listes ne couvrent que le cas où tout va bien. Cartes refusées, champs vides et connexions lentes, c'est là que les clients restent bloqués.
  • Imposer la solution technique. « Utiliser telle bibliothèque de popups » contraint le développeur sans lui donner l'objectif. Décrivez le résultat attendu.
  • Ajouter des critères en cours de route. Un nouveau critère en plein projet, c'est du périmètre en plus. C'est légitime, mais cela se chiffre et se planifie, cela ne se glisse pas discrètement.
  • Ne jamais s'en servir à la recette. Une liste que personne ne vérifie à la livraison ne sert à rien. Parcourez-la à chaque fois.

Bonnes pratiques

  • Rédigez-les avant de demander un devis. Un développeur chiffre une liste claire bien plus justement qu'un paragraphe d'intentions.
  • Utilisez des chiffres et des exemples réels. « Un produit à 40 € avec un code de 15 % affiche 34 € » ne laisse aucune place à l'interprétation.
  • Prévoyez un critère pour chaque cas limite qui vous inquiète. Si un problème vous a déjà fait perdre des commandes, écrivez-le pour qu'il soit testé.
  • Décidez qui fait la recette. Vous, un product owner ou un testeur : fixez qui vérifie les critères, et à quel moment.
  • Rangez-les avec la tâche. Joignez-les au ticket ou au brief, pour que la liste et le travail ne se séparent jamais.
  • Découpez les grosses stories. Si une story demande quinze critères, scindez-la en deux ou trois stories plus petites qui peuvent être livrées séparément.

Dans Roctify

Sur Roctify, les comportements e-commerce de base pour lesquels vous écririez sinon des critères, comme le panier, le checkout sur une seule page, les codes promo, le stock mis à jour sur tous les canaux, les taxes et la livraison automatique des produits digitaux, sont déjà construits et maintenus par l'équipe Roctify. Vous les testez en utilisant votre propre boutique, sans avoir à les commander ni à les recetter.

Les critères d'acceptation restent utiles au moment du paramétrage. Avant un lancement, écrivez une courte liste pour votre boutique et vérifiez-la : une commande test avec un code promo affiche le bon total, un produit digital arrive par email après le paiement, la vitrine se lit bien sur téléphone. C'est la même discipline, appliquée à la configuration plutôt qu'au code, et elle repère les erreurs avant vos clients. Pour les intégrations sur mesure de l'offre Enterprise, des critères clairs facilitent l'accord sur le périmètre.

FAQ

Qui rédige les critères d'acceptation ?

En général, la personne qui porte le besoin, fondatrice, product owner ou client, en écrit une première version. Le développeur et le testeur la relisent ensuite et ajoutent les cas qu'ils repèrent. Les meilleures listes naissent de cet échange plutôt que d'une seule personne.

Quelle différence avec la définition de terminé ?

Les critères d'acceptation sont propres à une fonctionnalité et décrivent son comportement. La définition de terminé est une checklist générale valable pour toutes les tâches, comme la relecture du code et les tests. Un travail doit satisfaire les deux pour être fini.

Les critères d'acceptation peuvent-ils changer pendant un projet ?

Oui, mais un changement de critère est un changement de périmètre. Discutez-en ouvertement, mettez-vous d'accord sur l'effet sur le coût et le délai, puis mettez la liste écrite à jour. Les changements tacites sont à l'origine de la plupart des litiges.