Retour vague sur un projet : trouver le problème derrière.

Un vendredi soir, un mail de validation arrive. « C'est bien, mais je ne sais pas, ça fait un peu froid. On peut voir autre chose ? » Trois lignes, envoyées vite, avec la meilleure intention du monde. Et un projet qui, à cet instant précis, cesse d'avancer.

Le problème n'est pas que le client ait un avis. Il en a le droit, c'est son projet. Le problème, c'est la forme de l'avis. « Ça fait froid » ne dit pas quoi changer. « Voir autre chose » ne dit pas dans quelle direction. On repart, on devine, on propose au hasard, et souvent le deuxième essai est jugé aussi vaguement que le premier. C'est comme ça qu'un projet qui devait durer trois semaines en prend huit, sans que personne ait mal travaillé.

Un goût n'est pas une instruction

La plupart des retours de validation arrivent sous deux formes, et aucune des deux n'est directement exploitable.

La première, c'est le verdict : « bof », « ça fait pas assez pro », « je n'accroche pas ». C'est une émotion, pas une consigne. Elle est vraie, elle compte, mais elle ne se traduit en rien de concret tant qu'on n'a pas creusé.

La seconde, c'est la solution déguisée : « mettez le logo plus gros », « il faudrait du rouge », « on pourrait ajouter un carrousel comme sur le site de X ». Là, le client ne décrit pas ce qui le gêne, il propose déjà une réponse. Et si on l'applique telle quelle, on corrige parfois un problème qui n'existait pas, tout en laissant intact celui qui l'a fait réagir.

Derrière chaque retour, il y a un problème

C'est le principe le plus utile que je connaisse en conduite de projet, et il n'a rien de propre au web. Le Nielsen Norman Group, une référence en ergonomie, le résume d'une phrase : il faut séparer la suggestion du problème. Quand quelqu'un propose une solution, on lui demande ce qu'il cherche à obtenir, et on continue à demander « quoi ? » et « pourquoi ? » jusqu'à toucher le vrai besoin.

« Mettez le logo plus gros » cache souvent « je ne me sens pas assez rassuré sur qui vous êtes en arrivant sur la page ». Ce sont deux choses différentes. La première est une consigne de taille. La seconde est un problème de réassurance, qui peut se régler par le logo, mais aussi par une phrase claire, un témoignage, une photo réelle. Tant qu'on discute de la taille du logo, on ne parle pas du vrai sujet.

Le rôle de celui qui conduit le projet, ce n'est pas d'exécuter la solution, ni de la rejeter. C'est de remonter jusqu'au problème, puis de proposer la meilleure réponse à ce problème, qui n'est pas toujours celle qui a été suggérée.

Les questions qui transforment un « bof » en décision

Face à un retour flou, je conseille de ne rien changer tout de suite, et de répondre d'abord par trois questions simples.

• Sur quoi porte la gêne, précisément ? Une couleur, un mot, un espace, l'ordre des éléments. On cherche l'endroit, pas l'impression générale.
• Qu'est-ce que ça devrait provoquer chez la personne qui arrive ? « Se sentir en confiance », « comprendre en cinq secondes ce que je vends », « avoir envie d'appeler ». C'est l'objectif, et c'est lui qui tranche.
• À quoi saura-t-on que c'est réglé ? Sans ce critère, la correction suivante sera jugée à l'humeur du moment, et on retombe dans la boucle.

Ces trois questions ne servent pas à piéger le client ni à lui faire faire mon travail. Elles servent à remplacer un jugement par une intention. Une fois l'intention posée, la décision technique devient presque évidente, et surtout elle se vérifie : soit la nouvelle version répond à l'objectif, soit elle n'y répond pas, et ça ne se débat plus sur un goût.

Le retour qui arrive trop tard

Il y a une autre raison, plus silencieuse, pour laquelle les allers-retours dérapent : le premier vrai retour arrive à la fin, quand tout est déjà construit. À ce stade, la moindre remarque coûte cher, parce que défaire est plus long que faire.

La bonne pratique consiste à provoquer les avis tôt, sur des choses volontairement incomplètes. Un plan de page griffonné, une maquette en gris sans les vraies couleurs, une seule section aboutie plutôt que le site entier. Plus ce qu'on montre est simple, plus le retour est libre, parce que personne n'ose demander de tout refaire quand ça a l'air terminé et léché. Montrer tôt et volontairement rugueux, c'est inviter le désaccord au moment où il ne coûte presque rien.

Cela vaut d'ailleurs bien au-delà d'un site. C'est vrai d'un devis, d'un document, d'une décision d'organisation : le retour donné sur une esquisse répare un projet, le même retour donné sur le produit fini le fait dérailler.

Ce que cette méthode ne règle pas

Je ne veux pas laisser croire qu'une bonne question suffit à tout. Séparer le problème de la solution demande du temps et un minimum de confiance des deux côtés. Un client pressé qui veut juste « que ce soit fait » vivra parfois ces questions comme une lenteur, et c'est au prestataire d'expliquer pourquoi elles font gagner du temps plus loin.

Cette méthode ne transforme pas non plus le client en designer, et ce n'est pas le but. Certaines décisions restent celles du métier, et une partie du travail consiste à assumer un choix que le client n'aurait pas fait spontanément, en expliquant pourquoi. Enfin, aucune question ne débloque un projet où personne n'a le pouvoir de trancher : quand les retours viennent d'un comité sans décideur, le sujet n'est plus la méthode, c'est de désigner la personne qui dit oui.

Au fond, un bon aller-retour n'est pas une négociation de goûts. C'est une enquête menée à deux pour trouver le vrai problème, puis un accord sur ce à quoi ressemble la solution. Le reste, la couleur, la taille, le mot exact, se décide ensuite, et se décide vite. C'est aussi ce qui se joue en amont, au moment du cadrage : la page devis sert d'abord à poser les bonnes questions, le déroulé d'un accompagnement est décrit sur la page offres, et ma façon de travailler tient sur la page à propos.

Sources

• How to Deal With Bad Design Suggestions, Nielsen Norman Group (Kara Pernice et Kathryn Whitenton, 10 décembre 2017) : principe de séparation entre la suggestion et le problème, remonter au besoin réel en demandant « quoi » et « pourquoi », et provoquer les retours tôt plutôt que trop tard. Consulté le 30 septembre 2026.

Questions fréquentes

Pourquoi un retour de validation vague bloque-t-il un projet ?

Parce qu'un jugement (« bof », « ça fait froid ») ou une solution toute faite (« le logo plus gros ») ne dit pas quel problème corriger. Sans problème identifié, on modifie au hasard, et la version suivante est jugée aussi vaguement que la première. Le projet tourne en rond au lieu d'avancer.

Comment transformer un retour flou en consigne claire ?

En séparant la suggestion du vrai problème. Avant de rien changer, on pose trois questions : sur quoi porte la gêne précisément, que devrait ressentir la personne qui arrive sur la page, et à quoi on saura que c'est réglé. On remplace ainsi un goût par une intention, qui elle se vérifie.

Faut-il appliquer une demande client même quand elle semble une mauvaise idée ?

Pas telle quelle. Une demande formulée en solution cache souvent un besoin réel. Le rôle du prestataire est de remonter à ce besoin, puis de proposer la meilleure réponse, qui n'est pas toujours celle qui a été suggérée. Certaines décisions restent du ressort du métier, en l'expliquant.

Sur le même sujet : la page qui a servi de terrain d'essai, et la méthode éditoriale de l'agence.