Les erreurs de
création de sites web

Quelles erreurs nuisent vraiment au site ?

Un détail inhabituel de l'interface n'est pas forcément une erreur. Il y a un problème lorsque le visiteur ne comprend pas l'offre, ne peut pas effectuer une action ou obtenir le résultat annoncé, ou lorsque l'équipe ne peut pas entretenir le site de manière fiable. L'analyse commence donc par les parcours et les faits, plutôt que par une liste de tendances graphiques.

Cet article traite des erreurs de cadrage, de conception, de développement et de lancement. Chaque problème est accompagné de signes à repérer et d'une méthode de vérification. Vous pourrez ainsi décider quoi corriger immédiatement, quoi planifier ensuite et où recueillir d'abord des données. Les instructions détaillées sur les outils figurent dans notre guide de recette d’un site web.

Erreur : commencer par l'apparence sans définir le besoin métier

Symptôme : les réunions portent sur les couleurs et les animations, mais personne ne peut expliquer qui visite la page ni ce que cette personne doit y faire. Après le lancement, un désaccord apparaît : le site est beau, mais ne répond pas aux attentes commerciales, de recrutement ou d'assistance.

Cause : l'objectif se résume à « un site moderne » et les exigences à une liste de blocs. Un bloc n'indique pas, à lui seul, quelle incertitude il lève pour le client. Pour un fabricant, présenter les tolérances et la procédure de demande de devis peut être plus utile qu'un long récit sur ses valeurs.

Comment corriger avant le développement

1. Identifiez les principaux groupes de visiteurs et leurs tâches.
2. Pour chaque groupe, définissez la page d'entrée, les informations nécessaires et l'action suivante.
3. Désignez un responsable du résultat au sein de l'entreprise.
4. Décrivez la mesure du résultat : réception d'une demande qualifiée, commande effectuée ou téléchargement de la documentation recherchée.

Critère de validation : l'équipe peut suivre le parcours dans le prototype et expliquer le rôle de chaque étape. Un prototype ne permet pas, à lui seul, de garantir les ventes futures ; il permet de vérifier que le parcours existe et contient assez d'informations.

Erreur : organiser le menu selon les services internes

Les noms des services internes parlent aux salariés, mais sont souvent obscurs pour les clients. Le visiteur cherche une solution à sa tâche, pas l'organigramme du fournisseur. Un menu surchargé, des intitulés identiques et des pages aux contenus différents sous un même titre compliquent le choix.

Comment vérifier : donnez une tâche précise à une personne du public visé, sans lui indiquer la bonne rubrique. Demandez-lui où elle chercherait les conditions et comment elle contacterait l'entreprise. Notez les détours et les questions. Un seul entretien ne démontre pas la fréquence d'un problème, mais peut révéler des intitulés peu clairs à examiner davantage.

Que modifier

Séparez les pages selon les tâches réelles et les offres distinctes. Ajoutez des catégories claires, un fil d'Ariane et des liens vers l'étape suivante. Comparez les libellés du menu aux titres des pages d'arrivée : la personne doit savoir qu'elle est au bon endroit. Sur un grand site, prévoyez une recherche avec une réponse utile même sans résultat.

Erreur associée : le design d'abord, les textes ensuite

Une maquette remplie de courts textes provisoires ne montre pas le comportement du vrai contenu. Un nom de produit long casse une carte, un tableau technique déborde et la rubrique « cas client » reste vide faute de matière. Utilisez dès le prototype de vrais titres et au moins un exemple complet de chaque type de page. Testez des valeurs longues, courtes et absentes.

Critère de validation : les tâches principales sont réalisables sans connaître l'organisation interne, et les modèles supportent le contenu réel. Le lien entre l'offre, la structure et la demande est expliqué dans l'article « Créer un site qui génère des demandes ».

Erreur : conserver des promesses génériques et des contenus étrangers à l'entreprise

« Haute qualité » et « approche personnalisée » n'expliquent pas comment l'entreprise travaille. Plus gênant encore : un modèle finalisé peut conserver le téléphone d'une autre société, un prix erroné ou une image sans rapport avec le service. Par exemple, le téléphone illustrant une page de garage affiche une réservation de massage. Ces incohérences se voient même sans audit technique.

Comment vérifier le contenu

• Comparez les coordonnées, le nom de l'entreprise, les prix et les délais aux données validées.
• Lisez les textes intégrés aux illustrations et aux écrans, pas seulement ceux qui les accompagnent.
• Ouvrez les fichiers liés aux boutons : le libellé « Présentation » ne garantit pas le bon document.
• Vérifiez les cas clients, témoignages et chiffres : la source et la portée de chaque affirmation sont-elles claires ?
• Assurez-vous que les photos des équipes et des projets concernent bien l'entreprise.

Une illustration peut expliquer un processus, mais ne doit pas être présentée comme la photo d'une réalisation ou un résultat réel obtenu pour un client. Signalez les exemples chiffrés comme pédagogiques. Sans cas vérifié, présentez la démarche, le périmètre et les critères de résultat plutôt que d'inventer des preuves.

Critère de validation : les affirmations importantes reposent sur des éléments vérifiables, les images correspondent au sujet et les actions de contact atteignent le bon destinataire.

Erreur : ne vérifier qu'un premier écran réduit

L'adaptation mobile ne se limite pas à une jolie capture de l'en-tête. Il faut aussi vérifier les menus longs, les réponses dépliées, les tableaux, le clavier, les erreurs et le retour en arrière. Un élément peut tenir à l'écran tout en restant difficile à utiliser ou inaccessible.

Dans Chrome, vous pouvez commencer par le mode appareil : testez plusieurs largeurs et faites défiler toute la page. Rejouez ensuite le parcours principal sur de vrais appareils utilisés par votre public. L'émulation ne reproduit pas toutes les particularités du navigateur, du clavier et des gestes.

Critère de validation : le visiteur réalise l'action du début à la fin, au lieu de voir seulement un premier écran soigné. Après une correction commune, vérifiez les autres pages utilisant le même modèle.

Erreur : prendre un message de remerciement pour une intégration réussie

L'interface affiche parfois un succès quelle que soit la réponse du serveur. Ailleurs, l'e-mail arrive, mais le commentaire ou la pièce jointe manque. Ou la demande atteint le CRM, mais entre dans le mauvais pipeline. Pour le client, il s'agit d'un seul parcours : testez-le de bout en bout.

Comment reproduire le problème

1. Convenez d'un contact de test et d'un identifiant de test reconnaissable.
2. Saisissez des valeurs distinctes pour repérer les données perdues ou interverties.
3. Envoyez le formulaire une seule fois et notez l'heure.
4. Vérifiez la demande enregistrée et sa réception par la personne responsable.
5. Comparez les champs, le fichier, la source et le service choisi aux données envoyées.

Testez séparément les champs obligatoires vides et les coordonnées au format invalide. En cas d'erreur, la personne doit savoir quoi corriger sans perdre toutes ses saisies. Les principes d'une validation accessible sont décrits dans le guide du W3C ; ne signalez pas une erreur uniquement par la couleur.

À prévoir lors du développement

Définissez ce qui constitue une demande enregistrée, où se trouve son enregistrement de référence et ce qui se passe si un système externe est indisponible. Prévoyez des états d'envoi et d'erreur clairs, la gestion des doublons et des diagnostics pour le responsable. La solution dépend de l'architecture, mais « toujours afficher un succès » n'est pas une gestion des pannes.

Si le problème concerne l'acheminement et les données, examinez-le avec la configuration du CRM, au lieu de modifier seulement le design du formulaire.

Erreur : tout charger d'un coup et ne regarder qu'un score

Les images lourdes, les widgets superflus et les gestionnaires d'événements peuvent retarder le contenu essentiel. Une tentative fréquente consiste à forcer le chargement immédiat de toutes les images. Les ressources du premier écran entrent alors en concurrence avec du contenu que le visiteur n'a pas encore atteint.

Points à vérifier

Ouvrez PageSpeed Insights, saisissez l'URL publique et examinez séparément le mobile et l'ordinateur. Conservez le lien du rapport et la date. Commencez par l'élément à l'origine du principal retard et les recommandations précises du rapport, plutôt que de supprimer tout ce qui semble lourd.

Vérifiez les dimensions et formats des images, le fichier choisi selon l'appareil, la priorité de l'image principale et le chargement différé plus bas dans la page. Réservez de l'espace pour les polices et médias afin que textes et boutons ne sautent pas à leur arrivée.

Core Web Vitals mesurent le chargement du contenu principal, la réactivité aux interactions et la stabilité visuelle. Un score de laboratoire aide au diagnostic, mais ne remplace ni les données des visiteurs réels ni les tests de parcours. L'absence de données terrain ne signifie pas l'absence de problèmes.

Critère de validation : la cause confirmée du retard est corrigée, les images nécessaires restent visibles, l'interface fonctionne et la nouvelle mesure se fait dans des conditions comparables. Un score qui change sans modification du site peut simplement refléter une variation de mesure.

Erreur : remettre le SEO à après la publication

Si la structure ne prévoit pas les services nécessaires et que les URL changent sans table de correspondance, les corrections après lancement deviennent plus difficiles. Les réglages d'accès des moteurs doivent faire partie de la préparation, sans dépendre d'un rappel de dernière minute.

Pour explorer le site, vous pouvez utiliser Screaming Frog ; pour vérifier l'état des pages dans les moteurs, utilisez Yandex Webmaster et Search Console. Interprétez les rapports automatiques selon la fonction de chaque URL : un espace privé et une page de service publique n'ont pas les mêmes exigences.

Comparez votre plan de migration des URL au guide de migration de Google. La préparation technique permet l'exploration du site, sans garantir son classement. Le travail de SEO demande une démarche distincte sur la demande et le contenu.

Erreur : compter les clics comme des demandes

Un clic sur un bouton, une tentative d'envoi et une demande effectivement enregistrée sont des événements distincts. Si la mesure compte une demande dès le clic, les rapports contiendront des demandes jamais reçues par l'équipe commerciale. Le problème inverse existe aussi : le formulaire fonctionne, mais l'objectif ne se déclenche pas ou est compté deux fois.

Comment vérifier la mesure

1. Décrivez simplement les événements : que s'est-il passé et à quel moment considère-t-on l'action réussie ?
2. Vérifiez la balise de mesure sur les différents modèles et l'absence de doublons accidentels.
3. Effectuez un parcours de test et rapprochez l'heure, l'événement et la demande enregistrée.
4. Testez séparément un envoi échoué : il ne doit pas compter comme une demande confirmée.
5. Assurez-vous que le responsable comprend le nom des objectifs et les limites des rapports.

Pour Yandex Metrica, utilisez la documentation officielle de vérification des objectifs. Suivez les instructions du service pour vérifier l'événement dans le navigateur et sa présence dans les rapports. Les bloqueurs, les réglages de consentement et d'autres conditions peuvent affecter la collecte ; tenez-en compte lors du rapprochement.

Critère de validation : l'indicateur est défini, les tests confirment le bon moment d'enregistrement et les limites de mesure sont documentées. Un faible volume de données ne justifie pas une conclusion certaine sur la qualité du nouveau design.

Erreur : lancer sans responsable de la suite

Le site peut fonctionner le jour de la livraison tout en dépendant d'un compte non identifié ou d'un module qui n'est plus maintenu. Sans organisation des renouvellements, mises à jour et restaurations, le prochain incident se transforme en recherche de la personne qui possède encore les accès.

• Vérifiez que le client peut se connecter seul aux systèmes prévus par le contrat.
• Notez les propriétaires du domaine, de l'infrastructure et des licences, les dates de renouvellement et les responsables.
• Demandez une démonstration pour modifier un texte, une image et une page type.
• Précisez ce que contient la sauvegarde et comment la restauration a été testée dans un environnement séparé.
• Distinguez correction des défauts, maintenance courante et nouvelles fonctionnalités.

Un fichier nommé « backup » ne prouve pas que le projet peut être restauré. Il faut une procédure vérifiable et le résultat d'un test. Conservez les identifiants dans un emplacement sécurisé convenu ; dans le registre de travail, indiquez son lien et son responsable, sans publier les mots de passe.

Critère de validation : l'entreprise peut poursuivre l'exploitation avec des instructions claires, connaît ses dépendances et dispose d'une procédure convenue pour demander une assistance technique.

Transformer l'audit en liste de tâches concrètes

Une longue liste sans priorités conduit souvent à régler d'abord les espacements, alors que des demandes continuent de se perdre. Chaque point doit préciser l'URL, les conditions, les résultats attendu et réel, les preuves, le responsable et le critère de nouveau test.

Après une modification, ne vérifiez pas seulement l'endroit retouché. Un style de bouton partagé concerne plusieurs pages ; un nouveau traitement de formulaire affecte tous les formulaires qui l'utilisent. À l'inverse, répéter indéfiniment les mêmes tests sans changement n'apporte guère : étendez les vérifications selon le périmètre touché et les risques observés.

Questions fréquentes sur les erreurs d'un site