Amomenti

Blog Livres Ebooks A propos

Stratégies web, permission marketing, marketing 2.0, promotion interactive, Référencement, SEO, Performance Marketing, expérience utilisateur, conception web

3 juillet 2006

Validation client

De part les commentaires et les emails reçus à propos de ce blog, je sais qu’un certain nombre de lecteurs sont des professionnels en agence ou en studio. J’aimerais lancer auprès d’eux une discussion autour de la difficulté souvent rencontrée de garder un client “dans la ligne” de ce qui a été décidé.

Vous avez sans doute déjà vécu des cas identique : un client qui dit blanc, qui y revient 6 mois plus tard (alors que le dossier n’avance pas…) et dit noir. Vous êtes obligé de revoir certains éléments de design, voire de contenu, voire du scénario…

Dans la communication traditionnelle, nous faisons signer au client une maquette, un Bon A Graver (BAG) et un Bon A Tirer (BAT), une copie conforme de ce qui sera imprimé (étape finale après les validation de maquette). Pour le Web, nous faisons signer nos clients sur des maquettes (une sortie imprimée : ( ) pour lancer le webdesign. Mais la phase éditoriale , importante s’il en est, reste soumise aux dangers du suivi de dossier.

Cas classique, vous développez un site Web, lequel est travaillé (design et contenu), pour une raison X ou Y, le projet tarde à être publié et lorsqu’enfin le client se penche à nouveau sur son projet, il remet tout en cause (sauf le devis bien sûr). Au delà du désagrément financier évident, c’est la qualité finale même qui est malmenée.

Et vous ? Nous pensons depuis longtemps à la possibilité de prendre une photo du site Web à certains moments de la conception, l’idéal serait de pouvoir faire un PDF de pages Web (en incluant le design), les technos ne semblent malheureusement pas au point de ce côté là. Et vous, des idées, des expériences à partager ?

Catégorie : Conception Web |

5 réponses

  1. Ben S. :

    Bonjour,
    C’est la première fois que je poste un commentaire, mais je suis depuis plusieurs mois un lecteur assidu de ton blog…

    Pour le cas de l’agence de com où je travaille en tant que chef de proojet et développeur Web, agence de communication on et offline, nous procédons comme beaucoup par maquettes imprimées qui permettent au client de valider un design graphique et une ergonomie proposée.

    Pour le suivi, il est vrai que la question se pose moins souvent.
    Pour l’instant, tous les contenus du site sont travaillés à part et soumis à la validation des clients au moyen de fichiers PDF. Il sont ensuite intégrés facilement aux sites codés en XHTML/CSS.
    Pour faire le point sur l’avancement du site, des versions intermédiaires sont mises à disposition du client de façon sécurisée afin qu’il puisse tester une version en cours du projet en développement.

    Concernant ton idée de capture, je viens tout juste d’installer (hier) une extension de firefox intéressante : Pearl Crescent Page Saver (pearlcrescent.com/product… ) permettant de générer un fichier PNG à partir d’une page Web "complète", c’est-à-dire comprenant la partie non visible à l’écran de la page.

    Pour finir, nous avons fait l’expérience de donner à un client (à sa demande) l’accès permanent à l’environnement de dev accessible en ligne. Expérience que je vous déconseille pour la principale raison que ça a pour effet de faire stresser encore plus le client s’il n’est pas habitué à suivre le développement d’un projet Web.
    En effet, une simple modification de la CSS peut détruire tout le design graphique temporairement ou des fonctionnalités ont besoin d’être désactivées pour tester d’autres parties de site ou débuguer certains algorithmes. Pour un client non initié et même averti de ne pas prendre peur à ces changements brutaux, c’est beaucoup plus de stress qu’il communique forcément à l’équipe projet.

    L’idée de ne montrer que des phases intermédiaires "stables" est franchement la meilleure expérience client et chef de projet que je puisse conseiller aujourd’hui.

    En espérant que mon témoignage permettra de faire avancer le débat très intéressant lancé par Stéphane.

    A quand le guide des bonnes pratiques pour un bon suivi de projet Web à la opquast ?

  2. Stéphane Brossard :

    Merci pour le addon de Firefox, je vais tester ça tout de suite et merci pour ce commentaire.

    C’est vrai ça, à quand un outil de gestion de projet ?

  3. Ziel :

    Je travail, en tant que QA (Analyste en assurance et contrôle de qualité), dans une boîte qui se spécialise en conception et maintenance de site web.

    Je ne suis pas au faîte de toutes les étapes, mais je peux parler de ce que j’ai vu.

    Un analyste fonctionnel prépare un document avec description de toutes les fonctionnalités du site présenté avec des maquettes fonctionnelles fait à partir du design du site (afin d’éviter que le client se bloque sur des détails du genre : pas la bonne couleur). Il contient aussi tous les contenus du site.
    Ce document est signé par le client qui en accepte le contenu (ce document est malheureusement, rarement lu en entier par le client…).

    Je sais aussi que les maquettes.psd sont importer en .jpg et envoyer au client pour acceptation. Je crois qu’un simple courriel prouve cette acceptation, mais il est possible que ce soit inclus dans un document et signé sur papier aussi.

    Une fois le développement « fini », le site passe au QA (généralement moins de 2 semaines). Une fois qu’une version du site est jugée suffisamment stable, le site est mis dans un environnement d’acceptation que le client peut accéder en tout temps. Avec une liste des anomalies encore en cours de correction, s’il y a lieu.

    Le client peut alors voir si son site lui convient. Sinon, les personnes en charge cotée QA, analystes et chargés de projet, décident si les « problèmes » soulevés par le client sont des anomalies que l’on doit corriger gratuitement (manquement à l’analyse, petits bugs, bêtes oublis, vraie anomalie, etc.). Sinon, ce sont des demandes de changement avec évaluation de coût, surtout si ce sont des gros changements qui vont à la rencontre de ce que le client a signé dans l’analyse.

    Cela passe bien, si on leur donne des petits « cadeaux » sur les autres « anomalies » précisées plus haut.

  4. AW :

    Bonjour,

    moi aussi "C’est la première fois que je poste un commentaire, mais je suis depuis plusieurs mois un lecteur assidu de ton blog…"

    Je n’ai pas grand chose à rajouter , et je ne peux qu’appuyer ce que vous avez dit tous les 2 :
    "L’idée de ne montrer que des phases intermédiaires "stables" est franchement la meilleure expérience client et chef de projet que je puisse conseiller aujourd’hui."

    Mais si quelqu’un à la réponse à cette problématique, je suis preneur!

    En tout cas ça me rassure quelque part de savoir que je ne suis pas le suel dans ce cas. Félicitation pour ce blog et Merci pour le plugin FF

  5. Denis :

    Personnellement, toutes les pistes abordées sont bonnes, j’en ai testé pas mal. Bien entendu, l’acces 100% au dev n’est pas une bonne idée, car on risque d’avoir le client toutes les minutes au téléphone pour expliquer des choses temporaires qu’il ne peut comprendre.
    Une de mes solutions et cela n’engage que moi est la formule BAT/BAG, bref un document validé et signé. La clé est que toute modification entraine une nouvelle facturation. On peut aussi demander une partie du règlement lors de cette validation. Ensuite, il faut bien entendu s’adapter au client…Si il représente 60% de mon C.A., je vais pas être trop difficile. L’argent est un bon moyen, d’autant que si un directeur MKT s’engage sur des éléments sans le consentement de sa direction, on fait comment? Budget bloqué, temps perdu…. Enfin, la touche qui peut aider est la notion graph/artistique, ou là on peut trouver des justifications qui dissuaderont le client de changer en y associant des justifications autour de couleur, symbole + et des notions de MKT.

    De nombreuses pistes sont à approfondir qui ne sont pas forcément des outils techniques. Un shoot d’ecran reste une image que de nombreux outils peuvent générer. On aura moins de difficulté quand un client aura de meilleurs notions de web! Car en génral, on fait des sites pour des entreprises dont ce n’est qu’un outil, mais pas le coeur de métier!! Le décalage est fort entre les intervenants d’un projet, c’est donc au chef de projet de faire le "traducteur" et les risques seront réduits sur ce point!

Publiez votre commentaire