Observation contextuelle

Observation contextuelle : Méthode consistant à observer l’utilisateur dans son environnement réel plutôt qu’en salle, ce qui révèle les contraintes de terrain.

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.

À quoi sert Observation contextuelle

Observation contextuelle décrit une réalité observable du côté de l’utilisateur. On peut donc s’en assurer autrement qu’à l’intuition, ce qui met une équipe d’accord plus vite qu’un débat d’opinion.

Ce que le mot recouvre exactement dépend du projet. Ce qui suit vaut pour la plupart des applications mobiles françaises, et sert de point de départ à la discussion.

Ce que ça devient dans un cahier des charges

Dans un cahier des charges, ce qui relève de « Observation contextuelle » 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.

Le niveau de détail à viser est celui qui permet à deux prestataires différents de chiffrer la même chose. En dessous, les écarts de prix ne veulent rien dire.

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.

Comment le vérifier à la recette

Le contrôle de « Observation contextuelle » repose sur les critères d’acceptation écrits avant le développement. Sans eux, la recette devient une discussion de goûts.

• Faire dérouler le parcours principal par quelqu’un qui n’a pas participé au projet.
• Vérifier chaque état vide et chaque message d’erreur, écran par écran.
• Contrôler ce que voit un utilisateur qui n’a encore aucun contenu.

Un prestataire sérieux propose ces contrôles de lui-même. Quand ce n’est pas le cas, c’est au client de les inscrire au cahier de recette.

Ce qui tourne mal le plus souvent

Aucune de ces erreurs ne se voit le jour où elle est commise. Toutes se paient plus tard, au moment le moins commode.

• Décrire une fonctionnalité par une intention plutôt que par des écrans et des règles.
• Oublier les cas qui vont mal : liste vide, erreur réseau, droits insuffisants.
• Confondre l’avis de trois collègues et un test auprès de vrais utilisateurs.
• Laisser le back-office hors du cahier des charges, alors qu’il pèse lourd dans le chiffrage.
• Se contenter d’une réponse orale en réunion, jamais reprise dans le document contractuel.

Termes liés

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

• Conception éthique
• Rôle accessible
• Trafic de recherche

Questions fréquentes

Que signifie « Observation contextuelle » ?

Méthode consistant à observer l’utilisateur dans son environnement réel plutôt qu’en salle, ce qui révèle les contraintes de terrain. 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.

Qui décide, le client ou l’agence ?

Le client tranche le quoi, l’agence propose le comment. Une agence qui décide seule du périmètre livre son produit ; un client qui impose la solution technique paie deux fois.

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.