Former un client non technique à un CMS en dix minutes
La passation décide si un CMS se rembourse ou devient un canal de support. Ce qu'il faut montrer, ce qu'il faut cacher, ce qu'il faut écrire, et la mesure qui révèle que votre configuration est mauvaise.
Vous avez construit le site, configuré le CMS, et vous avez maintenant vingt minutes avec le client pour lui montrer comment s’en servir. Que ce CMS se rembourse ou devienne un canal de support récurrent se décide presque entièrement pendant ces vingt minutes.
La plupart des développeurs les utilisent mal, et toujours de la même façon. Voici ce qui marche à la place, tiré de passations répétées avec des gens qui ne pensent pas aux sites web.
L’erreur que presque tout le monde commet
Le réflexe est de faire visiter : voici le tableau de bord, voici vos collections, voici la médiathèque, voici les réglages, voici où publier.
Le client hoche la tête du début à la fin et ne retient rien. Non pas par inattention, mais parce qu’une visite est organisée autour de la structure de l’outil plutôt qu’autour de quelque chose qu’il veut faire. Rien ne s’accroche à un objectif, donc rien ne reste.
Trois semaines plus tard, il doit changer un tarif, ne se souvient plus laquelle des six choses que vous lui avez montrées contient les tarifs, et vous envoie un mail. Vous avez désormais payé le CMS et conservé la charge de support.
Ce qui marche : faire son vrai travail devant lui
Avant le rendez-vous, posez une question : qu’est-ce que vous allez modifier le plus souvent ?
La réponse est toujours concrète et toujours petite. Les tarifs. Les horaires. La photo de la page d’accueil. Un nouveau plat sur la carte. Cette réponse est tout votre programme.
Puis, pendant la séance :
- Faites cette tâche vous-même, lentement, en commentant. « Vous voulez changer le tarif de cette prestation. Vous cliquez ici, ce champ, vous tapez, vous cliquez sur Publier. » Trente secondes.
- Refaites-la, en silence, pour qu’il voie la forme sans le commentaire.
- Donnez-lui la souris et faites-la-lui faire, sur une vraie page, avec une vraie modification que vous annulerez ensuite. C’est la seule partie qui compte. Regarder quelqu’un faire une fois est la différence entre retenir et ne pas retenir.
- Montrez-lui à quoi ressemble « publié », attente comprise. Restez avec lui pendant la minute ou deux, pour que la première fois où il vit ça, il ne soit ni seul ni inquiet.
- Montrez-lui comment revenir en arrière. Pour la plupart des clients, c’est la chose la plus rassurante de la séance. On modifie timidement quand on croit les erreurs définitives, et avec assurance quand on sait qu’elles ne le sont pas.
Cela fait dix minutes. Tout le reste est optionnel.
Ce qu’il ne faut volontairement pas montrer
Les réglages. Si le client peut atteindre les réglages, l’un d’eux finira par y aller. Tout ce qui est structurel doit être derrière un rôle qu’il n’a pas. Ce n’est pas de la défiance : c’est la même raison qui fait qu’on ne se donne pas un accès permanent à la base de production.
La médiathèque comme destination. Montrez l’envoi d’une photo à l’intérieur de la tâche qui en a besoin. Une médiathèque visitée pour elle-même est un endroit où l’on supprime des choses par accident.
Tout ce qu’il utilisera moins de deux fois par an. Ce ne sera pas retenu, et le mentionner dilue les cinq choses qui comptent.
Votre admiration pour l’architecture. Il se moque de savoir que le contenu est récupéré au moment de la construction. Il veut que ses tarifs soient justes.
La fiche d’une page
Laissez quelque chose d’écrit, sur une page, dans sa langue, avec des captures. Pas un manuel : un pense-bête.
Ce qu’elle doit contenir :
- L’adresse pour se connecter, et comment récupérer un mot de passe.
- Les trois tâches qu’il fera réellement, une capture chacune.
- Ce que fait Publier et combien de temps ça prend à peu près.
- Comment revenir en arrière.
- Qui contacter et quoi mettre dans le message.
Ce qu’elle ne doit pas contenir : tout le reste. Un manuel de douze pages n’est lu par personne et signale que l’outil est compliqué.
Si votre CMS a une documentation utilisateur correcte, faites un lien plutôt que de la réécrire, et gardez votre page pour ce qui est propre à son site.
La mesure qui révèle une mauvaise configuration
Voici une règle à adopter : si un client bloque plus de dix minutes sur une modification de routine, c’est un défaut de votre configuration, pas un échec de formation.
Chaque fois que nous avons creusé un de ces moments, la cause était de notre côté :
- Un champ nommé avec un identifiant interne plutôt qu’avec le mot du client.
hero_subtitlene veut rien dire pour une fleuriste. - Un champ obligatoire dont il n’avait aucun moyen de savoir qu’il l’était avant que la publication n’échoue.
- Deux collections voisines sans différence visible entre elles.
- Une photo qui rendait mal parce que le recadrage était centré et que son sujet ne l’était pas.
Rien de tout cela n’est de la lenteur du client. Tout est corrigeable dans le schéma, et la correction prend quelques minutes. Traitez le seuil des dix minutes comme un signal pour changer votre configuration plutôt que pour expliquer plus fort.
Les libellés sont ce qui a le plus d’effet
Ce qui détermine le plus si un client sait utiliser un CMS, c’est de savoir si les champs portent son vocabulaire.
Pas sous-titre mais « Phrase sous le titre ». Pas extrait mais « Résumé court affiché sur la page de liste ». Pas libellé_cta mais « Texte du bouton ».
Le texte d’aide compte autant : une ligne sous le champ disant où il apparaît. « Affiché sur les cartes de la page prestations » supprime toute une catégorie de questions, parce que la vraie incertitude du client n’est en général pas comment taper, c’est où ce texte va atterrir.
Cela coûte dix minutes au moment d’écrire le schéma et fait gagner des heures sur la vie du site. C’est l’investissement le moins cher de tout le projet, et le plus souvent négligé parce que le développeur, lui, sait ce que veut dire extrait.
Poser les attentes sur la publication
Une chose surprend réellement les clients sur un site statique, et il vaut mieux la dire que de la laisser découvrir : il y a un court délai entre la publication et la mise en ligne de la page.
Dites-le simplement : « Quand vous cliquez sur Publier, le site se reconstruit. Ça prend une minute ou deux, et l’écran vous dit quand c’est réellement en ligne. Si vous rafraîchissez votre site tout de suite, vous verrez peut-être encore l’ancienne version. »
Les clients acceptent cela sans difficulté quand on les prévient. Quand ils le découvrent seuls, à 20 h, avec un client qui attend, ils concluent que l’outil est cassé et vous appellent.
Le corollaire est que votre CMS doit réellement afficher cet état. Un outil qui dit « publié » à l’instant où il enregistre prépare votre client à croire quelque chose de faux.
La relance qui ne coûte rien
Deux semaines plus tard, envoyez un message : « Vous avez eu l’occasion de modifier quelque chose ? Quelque chose n’est pas clair ? »
La plupart répondent que oui et que tout va bien. Ceux qui répondent « je n’ai pas osé » vous disent quelque chose d’important, et c’est presque toujours réparable : un libellé obscur, la peur de casser le site, ou personne ne leur ayant montré comment revenir en arrière.
Ce seul message est le support le moins cher que vous fournirez jamais, et il transforme le CMS d’une chose que vous leur avez vendue en une chose dont ils se servent.
Passer la main à un client qui n’a pas choisi l’outil
Un cas précis et fréquent : le client n’a pas choisi ce CMS, c’est vous, et il utilisait autre chose avant, en général WordPress.
Il arrive avec des attentes façonnées par cet outil, et les deux qui frottent méritent d’être devancées.
« Où est le constructeur de pages ? » Il s’attend à déplacer des blocs. Sur un CMS à champs, il ne peut pas, et la formulation compte énormément. La bonne formulation n’est pas « c’est plus simple », qui sonne comme moins ; c’est « vous ne pouvez pas casser la maquette, parce que la mise en page est fixe et que vous remplissez le contenu ». Les clients qui ont déjà cassé une mise en page WordPress trouvent ça rassurant plutôt que limitant.
« Pourquoi je ne peux pas ajouter une page ? » Sur un site vitrine à la structure dessinée, ajouter une page arbitraire n’est en général pas quelque chose qu’on veut à un clic. Expliquez qu’une nouvelle page est un petit chantier qu’on fait ensemble, pas une action en libre-service, et que c’est ce qui garde son site cohérent. Presque personne n’objecte.
Le principe général : présentez chaque contrainte comme protégeant quelque chose qui compte pour lui, parce que c’est ce qu’elle fait. Une contrainte expliquée comme une fonctionnalité manquante se lit comme une régression ; la même contrainte expliquée comme une garantie se lit comme du soin.
Pourquoi tout ça compte commercialement
Le vrai coût d’une agence sur un parc n’est pas l’abonnement. C’est le flux de petites interruptions : un mot de passe oublié, une photo qui ne passe pas, une modification qui « ne s’est pas enregistrée », une page qui n’est pas en ligne parce qu’une construction a échoué en silence.
Quarante éditeurs à une interruption par trimestre font cent soixante interruptions par an, à dix minutes et un changement de contexte chacune. Cela fait plusieurs semaines de travail, et c’est invisible sur tous les tableaux comparatifs.
De bons libellés, une fiche écrite, une passation où le client fait vraiment le geste, et un message de relance réduisent nettement ce flux. L’outil compte moins que la plupart des éditeurs ne voudraient le faire croire, mais la configuration compte énormément, et la configuration est entièrement la vôtre.
Pour le versant produit du même argument, ce qu’un CMS multi-sites doit savoir faire traite l’économie du parc, et nos propres pages d’aide sont écrites pour le client final plutôt que pour le développeur, donc vous pouvez les transmettre telles quelles.