+200 Cours vidéos, études de cas, templates...
Accéder gratuitement 👉
5 cours vidéos
3 check-lists UX/CRO
1 guide CRO chaque vendredi
+200 Cours vidéos, études de cas, templates...
Accéder gratuitement 👉
🎁 Formez-vous en continu à l'UX Design et au CRO (Optimisation des conversions)
Florent Kiecken
22/9/2026
Dernière MAJ :
22/9/2026
Besoin d'un expert CRO ?
Faites vous accompagner pour booster vos conversions.
+6 ans à accompagner les marques dans leurs stratégies CRO
+4000 abonnés à la plus grosse newsletter CRO francophone
+130 marques accompagnées
+1200 inscrits aux formations
Certifié CXL
Une refonte UX ne devrait pas commencer par une nouvelle maquette.
Elle devrait commencer par une question beaucoup moins séduisante :
Qu'est-ce qui pose réellement problème sur le site actuel ?
C'est pourtant rarement comme cela que les projets commencent.
On change l'identité visuelle. On modernise les pages. On simplifie les menus. On déplace les CTA. On réduit les formulaires. Puis le nouveau site est mis en ligne.
Et quelques semaines plus tard, une question arrive :
Pourquoi le site est plus moderne, mais ne convertit pas mieux ?
Le problème n'est pas forcément le design.
Une refonte UX peut échouer parce que les mauvaises décisions ont été prises avant même de commencer à designer.
Les résultats actuels sur les requêtes liées aux erreurs de refonte reviennent d'ailleurs régulièrement sur les mêmes sujets : audit de l'existant, données, préférences internes, tests, navigation, conversion et mesure avant/après.
Chez SDLV, notre approche CRO part du principe inverse : on cherche d'abord à comprendre les problèmes, puis on formule des hypothèses, on les priorise et on les teste.
Une refonte UX devrait suivre la même logique.
La principale erreur d'une refonte UX est de décider quoi changer avant de comprendre pourquoi le site actuel fonctionne ou dysfonctionne.
Une bonne refonte ne consiste donc pas à remplacer un ancien site par un nouveau.
Elle consiste à identifier les problèmes réels, comprendre leurs causes, préserver ce qui fonctionne et tester les changements importants.
Autrement dit :
Données → recherche → problème → hypothèse → prototype → test → expérimentation → mesure → itération.
C'est cette logique qui permet de transformer une refonte en véritable démarche d'amélioration de l'expérience utilisateur et de la conversion.
C'est probablement l'erreur la plus structurante.
Le projet démarre avec un brief design :
« Il faut moderniser le site. »
Puis viennent les wireframes, les maquettes et les premières propositions graphiques.
Le problème est simple : on cherche déjà une solution alors que le problème n'a pas encore été correctement identifié.
Une liste de bonnes pratiques UX ne remplace pas un diagnostic.
Oui, certains patterns peuvent être pertinents.
Oui, certains éléments peuvent objectivement être améliorés.
Mais appliquer une bonne pratique au mauvais endroit ne résout rien.
Avant de modifier une page, il faut donc observer ce qui se passe réellement.
Les données quantitatives permettent par exemple d'identifier :
Les heatmaps et les enregistrements de sessions permettent ensuite de comprendre ce comportement plus concrètement.
La recherche qualitative apporte une autre pièce du puzzle : pourquoi l'utilisateur agit-il ainsi ?
C'est cette combinaison entre données et recherche qui permet de passer d'un constat à une hypothèse.
Supposons qu'un bouton principal soit peu cliqué.
La réaction classique consiste à le rendre plus gros, à changer sa couleur ou à le déplacer plus haut dans la page.
Mais le problème peut être ailleurs.
L'utilisateur voit peut-être parfaitement le bouton.
Il ne clique simplement pas parce qu'il ne comprend pas suffisamment ce qu'il va obtenir.
Dans ce cas, le problème n'est pas nécessairement la visibilité du CTA.
Il peut être lié à la proposition de valeur, au message ou au moment où l'action est proposée.
Une refonte UX ne devrait pas commencer par « qu'est-ce qu'on pourrait améliorer ? », mais par « qu'est-ce qui pose réellement problème ? ».
« C'est plus moderne. »
« Ça fait plus premium. »
« Je préfère ce bouton ici. »
« Cette version est plus élégante. »
Ces phrases peuvent parfaitement être entendues pendant une refonte.
Mais elles ne constituent pas une preuve UX.
Le problème n'est pas d'avoir des préférences.
Le problème est de les utiliser pour prendre des décisions qui devraient reposer sur des observations.
Une équipe connaît son entreprise.
Elle connaît ses produits, ses clients, son marché et son organisation.
Mais elle n'utilise pas nécessairement le site comme un nouveau visiteur.
Elle connaît aussi tellement bien son propre vocabulaire qu'elle peut sous-estimer les incompréhensions d'un utilisateur.
C'est pour cela qu'une décision de refonte doit pouvoir être reliée à une observation.
Par exemple :
La question n'est donc pas :
« Est-ce que cette interface plaît à l'équipe ? »
Mais :
« Quel problème utilisateur cette modification cherche-t-elle à résoudre ? »
Cette distinction paraît simple.
Elle change pourtant complètement la manière de conduire une refonte.
Une refonte UX n'a pas pour objectif de produire une interface que l'équipe préfère. Elle doit résoudre des problèmes utilisateurs identifiés par la recherche et les données.
Une refonte donne souvent envie de repartir d'une page blanche.
C'est compréhensible.
Le site actuel paraît ancien. L'identité visuelle doit changer. L'équipe veut repartir sur des bases propres.
Mais ancien ne signifie pas inefficace.
Certains éléments peuvent fonctionner correctement malgré une interface datée.
Une page peut générer des conversions.
Une navigation peut être très utilisée.
Un bloc peut répondre efficacement à une objection.
Un formulaire peut générer moins de volume mais davantage de prospects qualifiés.
Tout remplacer revient donc à prendre le risque de perdre des performances que l'on n'avait même pas identifiées.
Avant une refonte, il faut établir une sorte de carte de l'existant :
Qu'est-ce qui fonctionne ?
Qu'est-ce qui fonctionne moins bien ?
Qu'est-ce qu'on ne sait pas encore ?
Cette analyse peut s'appuyer sur les funnels, les heatmaps, les enregistrements de sessions, les données de conversion et la recherche utilisateur.
L'objectif n'est pas de défendre l'ancien site.
Il s'agit de savoir ce qu'il faut conserver avant de décider ce qu'il faut changer.
Imaginez une page produit qui semble visuellement dépassée.
L'équipe souhaite donc la refaire entièrement.
Mais l'analyse montre que cette page contribue correctement au parcours de conversion.
Le problème n'est alors peut-être pas la page dans son ensemble.
Il peut être limité à quelques éléments : hiérarchie de l'information, compréhension de l'offre, navigation secondaire ou présentation mobile.
Refaire toute la page uniquement parce qu'elle semble datée augmente inutilement le périmètre du projet.
L'objectif d'une refonte UX n'est pas de rendre l'ancien site méconnaissable. L'objectif est d'améliorer l'expérience là où elle pose réellement problème, sans casser ce qui fonctionne déjà.
L'UX et la conversion sont fortement liées.
Un utilisateur qui ne comprend pas une offre, ne trouve pas une information, ne sait pas quoi faire ou rencontre une friction inutile peut effectivement être empêché de convertir.
Mais cela ne signifie pas que chaque problème de conversion est un problème UX.
Une mauvaise conversion est un symptôme.
Ce n'est pas un diagnostic.
Une page peut convertir peu pour différentes raisons :
La première étape consiste donc à identifier où se trouve le problème.
La seconde consiste à comprendre pourquoi il existe.
C'est précisément là que la démarche CRO devient utile : analyse quantitative, recherche qualitative, formulation d'hypothèses puis expérimentation.
Une maquette n'est pas une preuve.
Même lorsqu'une nouvelle interface semble évidente, elle reste une hypothèse.
C'est particulièrement important pendant une refonte parce que les changements sont souvent nombreux et interdépendants.
Une nouvelle navigation.
Un nouveau parcours.
Une nouvelle hiérarchie de contenu.
De nouveaux CTA.
Un nouveau formulaire.
Une nouvelle présentation de l'offre.
Chacun de ces changements peut modifier le comportement des utilisateurs.
Il faut donc tester les changements qui présentent le plus d'incertitude ou le plus d'impact potentiel.
Selon le contexte, cela peut passer par :
L'objectif n'est pas de tout tester systématiquement.
Ce serait contre-productif.
L'objectif est de réduire l'incertitude sur les décisions importantes.
Une bonne séquence ressemble à ceci :
Hypothèse :
« Les utilisateurs abandonnent parce que le formulaire demande trop d'informations trop tôt. »
Une réponse possible consiste à réduire le formulaire.
Mais avant de conclure, il faut aussi définir ce que signifie « améliorer ».
Est-ce davantage de formulaires envoyés ?
Davantage de prospects qualifiés ?
Un meilleur taux de transformation commercial ?
Une réduction de l'abandon sans dégradation de la qualité des leads ?
Sans critère de succès défini à l'avance, le test risque de devenir une simple comparaison esthétique.
Une maquette n'est pas une preuve qu'une nouvelle expérience fonctionnera. C'est une hypothèse qu'il faut confronter aux utilisateurs et aux données.
« Il faut simplifier le parcours. »
Oui.
Mais simplifier ne signifie pas supprimer systématiquement toutes les étapes.
Certaines frictions sont inutiles.
D'autres ont une fonction.
Un formulaire demande peut-être quelques informations supplémentaires pour qualifier correctement un prospect.
Une fiche produit présente peut-être plusieurs détails parce que le produit nécessite une décision réfléchie.
Une étape de réassurance peut sembler ralentir le parcours tout en répondant à une objection importante.
Le véritable objectif est donc de supprimer la friction inutile, pas toute friction.
La navigation est un autre grand classique des refontes.
L'entreprise réorganise ses catégories.
Le menu devient plus minimaliste.
Les intitulés sont harmonisés.
Tout paraît plus propre.
Mais la logique de l'entreprise n'est pas forcément celle de l'utilisateur.
Une équipe peut penser en catégories internes :
L'utilisateur peut, lui, chercher :
La navigation doit donc être pensée à partir des usages.
Avant de modifier l'arborescence, il est utile d'analyser :
Un menu hamburger sur desktop peut donner une interface plus minimaliste.
Mais si les catégories principales deviennent moins visibles, l'utilisateur doit faire un effort supplémentaire pour découvrir le contenu.
La question n'est donc pas de savoir si le menu est plus élégant.
Il faut savoir si les utilisateurs trouvent plus facilement ce qu'ils cherchent.
Une navigation n'est pas bonne parce qu'elle paraît logique à l'équipe. Elle est bonne lorsqu'elle permet aux utilisateurs de trouver ce qu'ils cherchent.
Une autre erreur consiste à attendre la mise en ligne pour commencer à mesurer.
À ce moment-là, il est trop tard pour savoir précisément ce qui a changé.
Une refonte devrait avoir une baseline.
Avant de modifier le site, il faut donc identifier les indicateurs qui permettent de décrire la situation actuelle.
Selon le modèle économique, cela peut inclure :
Le choix des indicateurs dépend de l'objectif de la refonte.
Pour un site lead generation, regarder uniquement le nombre de formulaires envoyés peut être insuffisant.
Pour un e-commerce, regarder uniquement le taux de conversion peut également masquer des évolutions importantes.
Le nouveau site convertit davantage.
Mais est-ce nécessairement une réussite ?
Il faut regarder ce qui se passe derrière ce chiffre.
Les utilisateurs convertissent-ils davantage mais avec un panier moyen inférieur ?
Les leads sont-ils plus nombreux mais moins qualifiés ?
Le résultat est-il identique sur mobile ?
Certaines étapes du tunnel se sont-elles dégradées ?
Une refonte ne doit donc pas être évaluée avec un seul KPI isolé.
Une refonte UX sans baseline transforme l'avant/après en impression. Avec une baseline, on peut réellement mesurer un changement.
Le jour de la mise en ligne est souvent présenté comme l'aboutissement du projet.
En CRO, c'est plutôt le début d'un nouveau cycle.
Une nouvelle interface produit de nouvelles données.
Les utilisateurs vont interagir avec des parcours qui n'existaient pas auparavant.
Certaines hypothèses vont être confirmées.
D'autres seront invalidées.
De nouveaux problèmes vont apparaître.
Il faut donc continuer à observer après le lancement.
Le cycle devient :
analyse → recherche → hypothèse → priorisation → expérimentation → mesure → itération.
Cette logique est au cœur d'une démarche CRO structurée : les données quantitatives permettent d'identifier les zones à investiguer, la recherche qualitative aide à comprendre les causes, puis les hypothèses sont priorisées et testées.
Cela implique également de ne pas promettre des résultats immédiats.
Une refonte peut créer des apprentissages rapidement, mais les améliorations durables se construisent dans le temps.
Dans une démarche CRO structurée, les premiers apprentissages peuvent émerger autour des mois 2 à 4, tandis que les améliorations durables se travaillent plutôt sur une période de 6 à 12 mois.
Le lancement d'une refonte n'est pas la fin du travail UX. C'est le début d'un nouveau cycle d'apprentissage.
Si l'on devait résumer les neuf erreurs précédentes en une seule idée, ce serait celle-ci :
Ne changez pas une interface parce qu'elle peut être améliorée. Changez-la parce que vous avez identifié un problème qui mérite d'être résolu.
Cela implique une méthode différente.
Au lieu de :
Ancien site → nouvelle maquette → développement → mise en ligne → analyse
Il faut chercher à aller vers :
Données → recherche → problème → hypothèse → prototype → test → expérimentation → mesure → itération.
Cette différence paraît théorique.
Elle change pourtant complètement le risque du projet.
Une refonte devient alors moins un grand pari qu'une succession de décisions documentées.
Toutes les entreprises n'ont pas nécessairement besoin de tout refaire.
Parfois, les problèmes sont concentrés sur quelques pages.
Une fiche produit.
Une landing page.
Un formulaire.
Une étape du checkout.
La navigation.
Dans ce cas, une optimisation ciblée peut être plus pertinente qu'une refonte globale.
La première question à poser n'est donc pas :
« Faut-il refaire le site ? »
Mais :
« Quel problème voulons-nous résoudre, et quel niveau de changement est nécessaire pour le résoudre ? »
Si le problème est localisé, il peut être possible de travailler progressivement.
Si le problème est structurel, une refonte plus importante peut se justifier.
Dans les deux cas, la logique reste la même :
diagnostiquer avant de concevoir.
Une démarche solide commence par l'existant.
Commencez par comprendre les parcours.
Quelles pages reçoivent du trafic ?
Où les utilisateurs abandonnent-ils ?
Quels parcours convertissent ?
Quelles différences observez-vous entre les devices ?
Les heatmaps, enregistrements de sessions et autres outils comportementaux permettent d'aller plus loin.
Vous cherchez les comportements récurrents.
Pas les anomalies isolées.
Les utilisateurs peuvent révéler des problèmes que les analytics ne montrent pas directement.
Ils peuvent ne pas comprendre un terme.
Chercher une information au mauvais endroit.
Interpréter différemment un CTA.
Ou simplement ne pas avoir confiance au moment où vous leur demandez d'agir.
Une observation ne doit pas automatiquement devenir une recommandation design.
Elle doit mener à une hypothèse.
Par exemple :
« Les utilisateurs abandonnent cette étape parce qu'ils ne comprennent pas suffisamment ce qui est inclus dans l'offre. »
Cette formulation est plus utile que :
« Il faut refaire cette page. »
Toutes les améliorations ne méritent pas le même niveau d'investissement.
Il faut tenir compte de l'impact potentiel, de l'effort nécessaire et du niveau d'incertitude.
Prototype, test utilisateur ou A/B test selon le contexte.
L'objectif est toujours le même :
réduire l'incertitude avant d'investir davantage.
L'une des erreurs les plus structurantes consiste à commencer par le design sans avoir identifié les problèmes de l'expérience actuelle.
Cela pousse l'équipe à chercher des améliorations visuelles avant de comprendre les comportements utilisateurs.
Une refonte devrait commencer par les données, la recherche et le diagnostic.
Parce qu'elle peut modifier des éléments qui fonctionnaient déjà.
Une nouvelle navigation peut rendre certaines informations moins accessibles.
Un formulaire simplifié peut générer davantage de demandes mais moins qualifiées.
Une fiche produit plus épurée peut supprimer des informations utiles à la décision.
Une nouvelle hiérarchie visuelle peut également modifier le parcours.
C'est pour cela qu'il est important de mesurer l'existant avant la refonte et de surveiller les performances après le lancement.
Pas nécessairement.
Si les problèmes sont concentrés sur quelques pages ou étapes du parcours, des optimisations ciblées peuvent suffire.
Une refonte globale se justifie davantage lorsque les problèmes sont structurels et touchent plusieurs dimensions de l'expérience.
Le bon périmètre dépend donc du diagnostic, pas du souhait de repartir de zéro.
Commencez par identifier les problèmes.
Analysez les données de navigation et de conversion. Observez les comportements avec des outils comme les heatmaps et les enregistrements de sessions. Complétez avec de la recherche qualitative et des tests utilisateurs.
Vous pourrez ensuite formuler des hypothèses et prioriser les changements.
Oui, lorsque l'objectif est de prendre des décisions fondées sur l'existant.
L'audit permet notamment d'identifier les problèmes à traiter, mais aussi les éléments à préserver.
Il évite de considérer l'ancien site comme un problème dans son ensemble alors que certaines parties peuvent déjà fonctionner correctement.
Il faut définir les indicateurs avant la mise en ligne.
Le choix dépend du business model et des objectifs du projet.
Il peut s'agir de conversion, d'abandon dans un funnel, de chiffre d'affaires, de panier moyen, de génération de leads ou encore de qualité des leads.
Le taux de conversion seul ne suffit pas toujours à décrire l'impact business d'une refonte.
Une refonte UX réussie n'est pas celle qui produit le site le plus différent.
C'est celle qui résout les bons problèmes sans détruire ce qui fonctionne.
Les erreurs les plus fréquentes ne sont donc pas uniquement des erreurs de design.
Elles viennent surtout de la méthode de décision :
La bonne approche est l'inverse.
Observer. Comprendre. Formuler une hypothèse. Tester. Mesurer. Itérer.
C'est également la logique d'une démarche CRO structurée : partir de l'analyse quantitative, compléter par la recherche qualitative, transformer les observations en hypothèses puis expérimenter avec des critères de succès définis à l'avance.
Une refonte UX ne devrait donc pas être un grand pari de plusieurs mois.
Elle devrait être l'aboutissement d'une série de décisions basées sur des problèmes identifiés et des hypothèses testées.
Avant de lancer les premières maquettes, commencez par comprendre ce que votre site fait déjà bien, ce qui bloque vos utilisateurs et ce qui freine réellement votre conversion.
C'est là que l'analyse CRO et la recherche utilisateur prennent tout leur sens.
Découvre notre offre : La cargaison
%20(1).png)
« LE contenu CRO francophone de référence »
.svg)
.png)
+130 marques accompagnés
.png)
