Un nouveau site web d'entreprise coûte aujourd'hui entre 15'000 et 60'000 francs à une PME suisse. Pour des projets plus complexes, la facture peut être nettement plus élevée. Ce chiffre figure dans chaque offre. Ce qui figure rarement dans l'offre : ce qui, dans deux ans, produira encore un effet. Leads, candidatures, demandes d'offres, produits vendus.
La désillusion arrive souvent dès les six premiers mois. Le site est en ligne. Il a fière allure. Il plaît en interne. Sauf qu'il ne livre pas de résultats.
Cela tient rarement au design. Rarement à la technique. La plupart du temps, cela tient à des hypothèses que personne n'a remises en question durant le projet.
Au kickoff, tout le monde est réuni. Le directeur sait ce que veulent ses clients. La responsable marketing sait comment la navigation devrait être structurée. L'agence acquiesce, réalise, livre. Ce qui manque, c'est le moment intermédiaire : celui où quelqu'un dit «Attendez, en sommes-nous vraiment sûrs?» et va effectivement vérifier.
Dans le jargon spécialisé, ce moment s'appelle le User Testing. Le terme fait peur. Trop lourd, trop laboratoire de recherche. La réalité est différente. La plupart des tests utiles ne nécessitent aucun logiciel spécialisé et peuvent être réalisés en peu de temps.
Voici cinq hypothèses présentes, tacitement, dans pratiquement chaque projet de site web de PME. Clarifier ne serait-ce que deux d'entre elles avant le lancement du prochain projet permet d'éviter, plus tard, un relaunch non planifié.
Pourquoi la vérification des hypothèses est rentable
Une hypothèse qui s'avère fausse en exploitation coûte en général cinq à dix fois plus que sa vérification en amont. Une navigation mal construite, qui n'apparaît dans les analytics qu'après six mois, signifie : nouvel atelier de concept, nouvelle sitemap, adaptation des templates, nouveau déploiement. Selon la complexité, cela représente vite 5'000 à 20'000 francs. La même question peut être clarifiée avant même le sprint de design, avec un simple tree test en quelques heures.
Le business case du User Testing n'est donc pas «rendre le site plus joli». Il consiste à éviter des corrections coûteuses.
Les méthodes se répartissent globalement en trois catégories de charge de travail :
Guerilla-testing (0 à 500 CHF). L'équipe réalise elle-même le test, avec des outils existants et des personnes de son entourage. Pas de recrutement professionnel, pas de modérateur externe. Rapide, économique, et livre généralement 60 à 70% des enseignements des variantes plus coûteuses.
Remote-testing structuré (500 à 2'500 CHF). Mise en place rapide avec des outils comme UXtweak ou Useberry. Si nécessaire, avec recrutement externe de testeurs, tâches définies, setup standardisé. Nettement plus fiable.
Testing modéré (2'500 à 6'000 CHF par session). Tests classiques avec de vrais clients cibles, modérés, généralement à distance via Zoom ou Lookback, avec protocole «Think-Aloud». Livre les enseignements les plus approfondis, mais nécessite une planification et généralement un accompagnement externe.
Pour la plupart des projets de PME, un mix des catégories un et deux suffit. Le testing modéré ne vaut typiquement la peine que pour des parcours critiques pour l'activité tels que le checkout, le formulaire de leads ou le portail de candidature, ou lorsque le groupe cible est difficile à atteindre.
Hypothèse 1 : «Nos visiteurs savent ce qu'ils cherchent chez nous»
C'est la plus dangereuse des cinq hypothèses, car elle paraît de l'intérieur tellement plausible. Bien sûr que les visiteurs savent ce qu'ils cherchent. Ils viennent volontairement sur le site. Ils vous ont googlé ou tiennent votre carte de visite en main.
La réalité est la suivante : les visiteurs ont effectivement un objectif. Simplement, ce n'est pas forcément celui que l'entreprise imagine pour eux.
Les entreprises construisent en général leur navigation et leur page d'accueil de manière intuitive, selon la logique de leur propre offre. L'hypothèse sous-jacente : qui vient sur notre site cherche nos prestations. Or, les visiteurs ne cherchent souvent pas des offres toutes faites. Ils cherchent des réponses à des questions concrètes, personnelles ou professionnelles. «Combien de temps cela prend-il?», «De quoi ai-je besoin pour cela?», «Est-ce que cela correspond vraiment à ma situation?». Ce n'est qu'une fois ces questions clarifiées que l'offre devient intéressante pour eux.
Les sites qui reflètent avant tout la logique propre du prestataire forcent les visiteurs à traduire eux-mêmes leurs questions concrètes en catégories d'offres. Cela fonctionne pour les connaisseurs de la branche, mais pas pour la grande majorité des primo-visiteurs. L'écart entre la perception que l'entreprise a d'elle-même et la réalité des utilisateurs détermine si un site informe, convertit ou frustre avant tout.
Comment vérifier ce que vos visiteurs recherchent vraiment
Analyse de la recherche interne et des données analytics. Si le site existant dispose d'un champ de recherche, c'est une mine d'or. L'analyse web permet aussi de voir non seulement ce qui est recherché, mais aussi où les gens abandonnent, sur quelles pages ils restent le plus longtemps et de quelles pages ils repartent sans cliquer davantage. Ces données existent depuis longtemps dans la plupart des PME. Elles ne sont simplement pas exploitées systématiquement.
Trois à cinq entretiens qualitatifs avec des personnes du groupe cible. Pas avec des clients déjà acquis. Avec ceux que l'entreprise aimerait avoir. 30 minutes par entretien, questions ouvertes : quelle a été la dernière situation où ils ont cherché une entreprise comme celle-ci? Comment ont-ils procédé? Qu'est-ce qui les a convaincus, qu'est-ce qui les a fait fuir? Ce qu'il faut, c'est une posture d'écoute et un catalogue de questions ouvertes, pas un logiciel.
Un test d'utilisabilité modéré avec une version existante ou un prototype. Cinq personnes du groupe cible, une heure chacune, avec des tâches concrètes. L'enseignement principal vient du protocole «Think-Aloud» : les testeurs commentent à voix haute ce qu'ils font et pourquoi. On entend non seulement s'ils atteignent leur but, mais aussi pourquoi ils cliquent où ils cliquent, où ils hésitent et ce qui leur manque.
Souvent, quelques entretiens suffisent à révéler un schéma longuement débattu en interne. Les visiteurs se répartissent grossièrement en deux profils de recherche : les visiteurs orientés tâche savent exactement ce qu'ils veulent et échouent sur la navigation. Les visiteurs en quête d'orientation ne savent pas encore ce qu'ils veulent et échouent sur le contenu. Les deux groupes ont besoin de réponses différentes. Et on ne les identifie qu'en observant systématiquement.
Résultat de cette vérification d'hypothèse : une liste des véritables questions des utilisateurs. Elle devient la base de la stratégie de contenu, de la navigation et de la page d'accueil.
Hypothèse 2 : «Notre navigation est construite de manière logique»
La navigation d'un site web reflète presque toujours l'une de ces deux choses : l'organigramme de l'entreprise ou la vision du monde de la direction. Rarement le modèle mental des visiteurs.
Un schéma typique : une entreprise a trois domaines d'activité et en fait trois points de navigation. Correct sur le plan technique, compréhensible en interne. Souvent inutilisable du point de vue d'un visiteur externe, car les domaines d'activité contiennent des termes que les personnes extérieures ne connaissent pas ou classent différemment. Ou parce que ce que le visiteur cherche est réparti sur plusieurs domaines à la fois.
Un autre schéma : la navigation principale s'appelle «Solutions», «Services», «Compétences» et «Produits». Quatre termes clairement distincts pour les initiés. Pas pour les personnes extérieures. Le visiteur clique sur le mauvais point, ne trouve pas ce qu'il cherche, quitte le site. On ne le voit que dans les analytics, pas en réunion de design.
Comment vérifier votre navigation : Card Sorting et Tree Testing
Pour les questions de navigation, ces méthodes se sont imposées :
Le Card Sorting répond à la question «Comment les utilisateurs regrouperaient-ils mes contenus?». Toutes les sous-pages importantes sont écrites sur des cartes individuelles (numériques ou physiques), et plusieurs personnes sont invitées, indépendamment les unes des autres, à les regrouper et à nommer chaque groupe. Après 10 à 15 participants, des schémas clairs se dessinent. La méthode peut être menée en ligne de manière structurée ou en version guerilla avec des collègues et connaissances du groupe cible. Quelques essais suffisent déjà pour dégager une tendance fiable.
Le Tree Testing répond à la question inverse : «Les utilisateurs trouvent-ils les contenus dans ma navigation prévue?». Des tâches sont données aux participants, du type «Où trouvez-vous des informations sur XY?», et ils naviguent dans l'arborescence. Résultat : un chiffre concret, discutable, indiquant combien d'utilisateurs trouvent le bon chemin. Tout ce qui est en dessous de 70% de findability constitue un problème sérieux. La vraie valeur ajoutée : on ne dit plus «mon instinct me dit que c'est intuitif», mais «62% des testeurs ont trouvé le bon chemin». Cela change la façon dont les décisions sont discutées en équipe.
Test des 5 secondes. Le check le plus rapide : montrer la page d'accueil à quelqu'un pendant exactement cinq secondes, puis la masquer et demander «Que fait cette entreprise? Où cliqueriez-vous si vous aviez besoin de XY?». Les réponses sont souvent édifiantes. Le test peut être formalisé avec des outils en ligne ou réalisé de manière tout à fait informelle entre collègues. Les deux approches livrent rapidement une image honnête.
Idéalement, le Card Sorting et le Tree Testing devraient être réalisés avant le design, pas après. Ils ne nécessitent pas de page finalisée. Seulement une liste de contenus et une ébauche de navigation. Cela en fait des tests économiques et efficaces, utilisables dès la phase de conception.
Hypothèse 3 : «Nos textes sont clairs et compréhensibles»
Cette hypothèse échoue particulièrement souvent sur trois points : le jargon technique, les formules marketing et la perspective «nous». Les PME aiment se décrire depuis leur propre point de vue interne : «Nous sommes établis depuis 30 ans», «Notre approche intégrée combine…», «Grâce à notre expertise en…». Ce que le visiteur retient concrètement pour lui-même reste souvent flou.
Particulièrement répandues sont les descriptions de prestations abstraites, qui n'ont presque aucune portée vers l'extérieur : «Solutions de conseil globales pour des situations exigeantes», «Concepts intégrés au plus haut niveau», «Accompagnement sur mesure d'égal à égal». Chacune de ces phrases pourrait figurer sur le site d'une fiduciaire, d'une agence marketing ou d'un bureau d'ingénieurs. Les phrases qui vont partout ne disent rien de précis nulle part.
L'ampleur de ce problème se révèle rapidement dans un test simple : cinq personnes du groupe cible lisent la page d'accueil et résument en une phrase ce que fait l'entreprise. Il n'est pas rare d'obtenir cinq interprétations différentes. Parfois, trois ou quatre personnes se trompent tellement que l'intention initiale de la page n'est plus du tout reconnaissable. Corriger ce constat ne nécessite dans la plupart des cas aucun développement supplémentaire, juste un après-midi de copywriting concentré.
Comment vérifier si vos textes sont compréhensibles
Test des 5 secondes sur la page d'accueil. Même principe que pour la navigation. Cinq secondes de regard sur la page d'accueil, puis trois questions : Que fait cette entreprise? Pour qui est-elle? Quelle est son offre principale? Si les réponses restent floues, le texte n'est pas clair. Il est frappant de constater à quel point cinq tests donnent souvent cinq interprétations différentes de ce que l'entreprise propose réellement.
Test de closure (Cloze-Test) pour les passages de texte importants. Une astuce éprouvée issue de la recherche sur la lisibilité. On supprime un mot sur cinq et on demande aux testeurs de le reconstituer. Plus le taux de réussite est élevé, plus le texte est compréhensible. Les textes bien écrits pour le grand public atteignent 60% et plus. Les textes techniques prévus comme textes grand public n'atteignent souvent que 30 à 40%.
Entretiens de lecture qualitatifs. Donner à une personne du groupe cible une version imprimée ou numérique d'une page et lui demander de la lire à voix haute en commentant. Où trébuche-t-elle? Où doit-elle relire? Quels termes ne comprend-elle pas? Un seul entretien court révèle souvent plusieurs problèmes de formulation concrets.
Pour le travail de rédaction proprement dit, une remarque supplémentaire s'impose, notamment en Suisse : le plurilinguisme n'est pas une affaire de copier-coller. Qui s'adresse à toutes les régions linguistiques devrait vérifier chaque langue séparément. La même logique de contenu peut produire un effet tout différent en version française, car les registres de langue et les attentes rhétoriques divergent. Une erreur fréquente consiste à ne tester que la version allemande et à supposer que les traductions fonctionnent automatiquement.
Hypothèse 4 : «Notre formulaire fonctionne déjà»
Les formulaires, checkouts et parcours de contact sont les points les plus critiques pour l'activité de tout site de PME. C'est là que se décide si un visiteur intéressé devient un lead, une candidature ou une commande.
L'hypothèse selon laquelle un formulaire «fonctionne déjà» repose presque toujours sur le test interne effectué après le lancement. Quelqu'un l'a rempli, l'e-mail est arrivé, donc ça marche. Ce que ce test ne montre pas : combien d'utilisateurs réels ont essayé et abandonné, où exactement ils sont sortis, quel champ les a rebutés.
Comment vérifier votre formulaire au niveau des abandons
Session Recording et heatmaps. Des outils spécialisés enregistrent de manière anonymisée les interactions réelles des utilisateurs. On voit où les gens cliquent, où ils hésitent, où ils quittent le formulaire. Il existe sur le marché des solutions gratuites comme payantes. Pour débuter, une variante gratuite suffit presque toujours. L'essentiel n'est pas tant le choix de l'outil que l'analyse systématique des enregistrements et la reconnaissance des schémas récurrents.
Analyse d'entonnoir dans l'outil d'analyse web. Dans l'outil analytics, il est possible de définir des entonnoirs (accès au formulaire, premier clic dans un champ, envoi). On voit les taux d'abandon entre chaque étape. Là où ils sont les plus élevés se trouve le plus grand potentiel d'optimisation.
Tests de tâches modérés. La voie royale pour les formulaires critiques pour l'activité. Cinq personnes du groupe cible reçoivent la tâche de faire une demande ou de s'inscrire. On observe et on écoute leurs réflexions. Après cinq tests, on sait avec une grande certitude où se situent les obstacles. La valeur méthodologique ajoutée par rapport au simple Session Recording : on ne voit pas seulement le point d'abandon, mais on entend les réflexions qui le précèdent. Cela fait une énorme différence dans l'analyse des causes.
Pour les PME à trafic moyen, la combinaison d'un outil simple de session recording et d'un entonnoir bien configuré dans l'analytics suffit généralement. Trois mois de collecte de données mettent en lumière de manière fiable les principaux problèmes de formulaire. Pour les parcours critiques pour l'activité comme le portail de candidature, le configurateur ou le checkout, un test modéré supplémentaire vaut la peine. Il devient rentable dès quelques points de pourcentage d'augmentation de la conversion.
Hypothèse 5 : «Le mobile fonctionne déjà»
La part du trafic mobile sur les sites de PME suisses a dépassé depuis longtemps, dans de nombreux secteurs, la part du desktop. Selon le groupe cible, des parts mobiles de 60 à 90% sont monnaie courante. Pourtant, les sites sont encore souvent conçus, présentés et validés en priorité sur desktop. Dans de tels projets, l'expérience mobile est un dérivé, pas un développement à part entière.
Et même si le site est techniquement «responsive», cela ne signifie pas qu'il soit agréable à utiliser sur smartphone. Ce sont deux choses différentes. Responsive signifie : le site s'adapte à la taille de l'écran. Optimisé pour le mobile signifie : le site est conçu spécifiquement pour la manière dont les gens interagissent avec leur smartphone.
Comment vérifier l'expérience utilisateur mobile
De vrais tests mobiles, pas de l'émulation navigateur. Chrome DevTools et outils similaires simulent le mobile, mais ne montrent pas ce que cela fait d'utiliser une page avec le pouce. Il suffit de s'asseoir avec trois personnes et différents appareils (ancien iPhone, Android intermédiaire, grand flagship) et de leur faire réaliser des tâches concrètes. On voit plus en 30 minutes qu'en deux semaines d'analyse DevTools. La raison : la prise en main, le rayon d'action du pouce, l'imprécision tactile et les distractions du quotidien ne sont représentés dans aucun émulateur.
Core Web Vitals sur mobile. Depuis un certain temps, Google évalue en priorité la performance mobile d'une page pour le classement. De mauvais résultats ici signifient un moins bon référencement, des temps de chargement ressentis comme plus lents et des taux de rebond plus élevés. Cela se vérifie avec des outils Google gratuits. De nombreux sites de PME suisses n'atteignent même pas le seuil «Good» sur mobile. C'est de la visibilité perdue au profit de Google.
Vérification de la zone du pouce. Lorsqu'on tient un smartphone d'une main, le pouce n'atteint confortablement qu'environ deux tiers de l'écran. La navigation, les CTA importants et les éléments de formulaire devraient se trouver dans cette zone, pas dans le coin supérieur. Qui conçoit avant tout sur écran de bureau place instinctivement les éléments là où ils créent un équilibre visuel. Ce n'est pas la même chose que là où ils sont atteignables d'une seule main. Simple à vérifier, rarement pris en compte.
Pour des tests mobiles structurés avec de vrais utilisateurs, les mêmes catégories de méthodes s'appliquent que précédemment, simplement réalisées systématiquement sur mobile. Les résultats divergent typiquement fortement de ceux des tests desktop. Rendre cet écart visible est souvent, à lui seul, l'enseignement le plus pertinent d'un tel projet.
Une règle simple pour les PME à budget limité : si un seul test est possible, faites-le sur mobile. Cela reflète mieux la réalité du trafic que n'importe quelle analyse desktop.
Les objections les plus fréquentes des décideurs de PME
Lorsque le User Testing est abordé pour la première fois dans une PME, ce sont presque toujours les mêmes objections qui surgissent. Elles semblent légitimes, mais résistent rarement à un examen approfondi.
«Notre site est trop petit pour du User Testing»
C'est l'objection la plus fréquente. Et c'est un malentendu. Le User Testing s'adapte vers le bas, il ne devient pas pertinent seulement à partir d'une certaine taille d'entreprise. Une entreprise individuelle avec un site de dix pages a exactement le même problème de fond qu'un grand groupe : le site fonctionne-t-il pour mon groupe cible ou non? La réponse à cette question, l'entreprise individuelle l'obtient avec trois entretiens et un test des 5 secondes, pour quelques centaines de francs. Le grand groupe a besoin pour cela d'un budget de recherche à quatre ou cinq chiffres. Plus une entreprise est petite, moins le test coûte cher. Pas moins il en a besoin.
«Nous n'avons pas le temps pour ça»
Un guerilla-test avec trois personnes de l'entourage dure 30 minutes par personne. Un test des 5 secondes avec un outil à distance est mis en place en deux heures et évalué 24 heures plus tard. Un tree test peut être réalisé en une semaine. La vraie question n'est pas de savoir si l'on a le temps pour cela. Mais si l'on a le temps de constater, six mois après le lancement, que la navigation ne fonctionne pas et que le concept doit être refait. Le temps investi en phase de test s'économise au carré en exploitation.
«Nos clients nous disent bien ce qu'ils veulent»
C'est vrai, et cela induit en erreur. Ce que les clients disent et ce qu'ils font sont deux choses différentes. Ce n'est pas de la mauvaise foi, simplement de la psychologie. Les clients rationalisent leur comportement, se souviennent de manière sélective, répondent poliment aux questions qui leur sont posées directement. Un test, en revanche, observe directement ce qu'ils font lorsqu'ils ne réfléchissent pas à eux-mêmes. Ces deux sources de données se contredisent étonnamment souvent. L'observation l'emporte en général, car elle montre le comportement réel, pas le témoignage a posteriori.
«Notre budget ne le permet pas»
Cette objection est la seule qui soit parfois justifiée, et pourtant presque toujours mal posée. Qui argumente avec le budget le fait généralement par prudence. Il ne veut pas dépenser de l'argent à la légère. C'est justement cette prudence qui plaide pour, et non contre, la vérification des hypothèses. Elle n'est pas l'investissement supplémentaire qui renchérit le projet. Elle est la petite assurance qui empêche que le reste du budget ne soit dépensé en pure perte. Dès qu'on pose la question ainsi, ce n'est plus une question de budget, mais une question de risque.
Par où commencer
Cinq hypothèses, cinq méthodes. En pratique, il n'est pas nécessaire de toutes les vérifier en même temps. La question à traiter en priorité dépend du stade où en est le projet.
Pour un nouveau site en projet, le plus grand levier se situe tout au début. Que cherchent réellement mes visiteurs, et mon architecture de l'information tient-elle la route? Ce sont les hypothèses une et deux. Les vérifier en amont évite de devoir refaire tout le concept, à grands frais, après le lancement. Et les vérifier avant même qu'un pixel ne soit dessiné simplifie toutes les décisions de design qui suivront.
Si le site existant sous-performe, le plus grand levier se situe en fin d'entonnoir de visiteurs. Les visiteurs comprennent-ils seulement ce qui est proposé, et où sont-ils perdus dans les parcours de conclusion? Ce sont les hypothèses trois et quatre. Toutes deux peuvent être clarifiées avec les données analytics existantes et des tests complémentaires ciblés.
Si l'on ne sait pas encore où l'on en est, il vaut mieux commencer large et simple : une analyse mobile honnête, combinée à quatre semaines de session recording. Deux méthodes, deux perspectives sur l'état des lieux. Les résultats indiquent presque automatiquement quelle hypothèse traiter ensuite.
Le moment le plus important d'un projet de site web n'est pas le kickoff. Ni la revue de design. Ni la mise en ligne. C'est le moment où, en tant que décideur, on cesse de dire «je pense que» et où l'on commence à dire «j'ai vérifié que». La différence entre ces deux phrases détermine si, dans deux ans, le projet de site web figurera dans les comptes comme un investissement ou comme une dépense.
