Recette croisée

Recette croisée : Vérification effectuée par une personne qui n’a pas réalisé la fonctionnalité, mieux placée pour repérer les oublis.

Cette entrée du glossaire relève de la famille « Produit et UX ». Elle donne la définition, sa traduction en exigences, et les erreurs vues le plus souvent sur des projets réels.

Où intervient Recette croisée dans un projet

Recette croisée appartient au langage commun du client et de l’équipe de conception. C’est souvent le premier mot qui manque quand une recette tourne au malentendu.

Sur un projet réel, la question ne se pose jamais en théorie : elle arrive dans un devis, dans une réunion de cadrage ou dans un rapport de recette.

Comment l’écrire dans un cahier des charges

Dans un cahier des charges, ce qui relève de « Recette croisée » se décrit par des écrans, des rôles, des règles ou des indicateurs, jamais par une intention. Une phrase sans critère de recette ne se chiffre pas.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les rôles utilisateurs, et ce que chacun a le droit de faire.
• Les écrans concernés, listés, avec leur état vide et leur état d’erreur.
• Ce qui est explicitement hors périmètre de la version 1.
• Les contenus fournis par le client, et la date à laquelle ils arrivent.

Rien n’oblige à tout figer dès le premier jour. Ce qui reste ouvert doit alors être signalé comme tel, avec la date à laquelle la décision sera prise.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Les contrôles à prévoir

Sur « Recette croisée », la recette se fait écran par écran, y compris dans les cas que personne n’aime tester : liste vide, erreur, coupure de réseau.

• Faire dérouler le parcours principal par quelqu’un qui n’a pas participé au projet.
• Relire les textes affichés : fautes, jargon interne, phrases tronquées.
• Contrôler ce que voit un utilisateur qui n’a encore aucun contenu.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Ce qui tourne mal le plus souvent

Sur ce point précis, voici ce qui coûte le plus cher aux porteurs de projet, dans l’ordre où on le rencontre.

• Valider des maquettes sans avoir écrit les critères d’acceptation correspondants.
• Empiler les fonctionnalités en version 1 au lieu de sortir un périmètre défendable.
• Repousser l’accessibilité à plus tard, ce qui revient à refaire les écrans une seconde fois.
• Découper le projet en sprints sans jamais rien mettre entre les mains d’un utilisateur.
• Reprendre la formulation d’un autre projet sans vérifier qu’elle décrit bien celui-ci.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Prototype papier
• remember
• MVP
• Onboarding
• Churn

Questions fréquentes

Recette croisée : de quoi parle-t-on exactement ?

Vérification effectuée par une personne qui n’a pas réalisé la fonctionnalité, mieux placée pour repérer les oublis. Le mot est employé tel quel par les équipes francophones. C’est celui à utiliser dans les échanges avec une agence, y compris quand la traduction française existe.

Faut-il tout traiter dès la version 1 ?

Non, et c’est le principal levier de budget. Ce qui compte est d’écrire ce qui est repoussé, pour que la version 1 reste défendable et que la suite reste chiffrable.

Où placer ce point dans le cahier des charges ?

Dans le chapitre qui correspond à sa nature, jamais dans une ligne fourre-tout. Le modèle de cahier des charges propose les rubriques attendues et l’ordre dans lequel les remplir.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.