Les erreurs de conception et de développement web semblent rarement dramatiques. Elles se manifestent par un projet qui a deux mois de retard, une page d’accueil qui met cinq secondes à charger sur un téléphone, un formulaire de contact qui échoue silencieusement ou une refonte qui perd la moitié de son trafic de recherche. La plupart d’entre elles remontent à des décisions prises avant même qu’une ligne de code ne soit écrite : portée vague, absence de plan de contenu et absence d’accord sur la manière dont le succès sera mesuré.
Pourquoi commencer la conception avant que le contenu n’existe est-il contre-productif ?
De nombreux projets commencent par une maquette visuelle remplie de texte de remplacement. Ensuite, le texte réel arrive, il est trois fois plus long que la case prévue, et les mises en page doivent être reconstruites. Les concepteurs et les développeurs finissent par payer deux fois pour les décisions de contenu.
La solution est un flux de travail axé sur le contenu. Rédigez les pages clés (accueil, pages principales de services ou de produits, à propos, contact) au moins sous forme de brouillon avant le début de la conception. Construisez des wireframes basés sur des titres réels et des longueurs réelles. Même un brouillon imparfait donne au concepteur quelque chose de concret sur lequel travailler.
Une portée que personne n’a écrite
“Un site web moderne avec un blog et une boutique” peut signifier une construction de trois semaines ou de six mois. Lorsque la portée est vague, chaque nouvelle idée devient une dispute sur le fait de savoir si elle était incluse ou non.
Un bref document de portée évite cela. Il devrait lister :
- Modèles de page nécessaires (pas chaque page, les modèles : accueil, service, article, produit, catégorie, contact).
- Fonctionnalités avec des limites claires, par exemple “filtres de produits par taille et couleur, pas de listes de souhaits enregistrées”.
- Intégrations : passerelle de paiement, CRM, plateforme d’e-mail, analyses, outils de réservation.
- Responsabilités de contenu : qui écrit, qui fournit les images, qui saisit les produits.
- Nombre de cycles de révision par étape et qui donne l’approbation finale.
- Critères de lancement : ce qui doit être vrai avant que le site ne soit en ligne.
Pourquoi les pages lentes coûtent-elles si cher ?
La vitesse est un problème commercial, pas une mesure de vanité technique. Les pages lentes augmentent les taux de rebond, diminuent les conversions et peuvent affecter la visibilité de recherche via les signaux d’expérience de page de Google. Les Core Web Vitals de Google donnent des objectifs clairs : Largest Contentful Paint en 2,5 secondes, Interaction to Next Paint en dessous de 200 millisecondes et Cumulative Layout Shift en dessous de 0,1, mesuré au 75e centile des visites réelles.
Les causes habituelles sont prévisibles :
- Images surdimensionnées téléchargées directement depuis un appareil photo ou un site de stock. Servez des formats modernes comme WebP ou AVIF à la taille réellement affichée.
- Trop de plugins ou de scripts tiers : widgets de chat, cartes thermiques, multiples gestionnaires de balises et intégrations sociales rivalisent pour le thread principal.
- Constructeurs de pages qui génèrent un balisage lourd et chargent le CSS de chaque module sur chaque page.
- Pas de mise en cache ni de CDN, donc chaque visite reconstruit la page à partir de zéro.
- Polices web chargées à partir de plusieurs familles et poids. Deux familles avec quelques poids suffisent généralement.
Testez avec PageSpeed Insights et le rapport Core Web Vitals dans la Google Search Console, qui affiche des données de terrain provenant d’utilisateurs réels plutôt qu’un seul test en laboratoire.
Concevoir pour le bureau et vérifier le mobile en dernier
Pour la plupart des sites de consommation, la majorité des visites proviennent de téléphones, pourtant les revues de conception ont souvent lieu sur de grands moniteurs. Le résultat est des cibles tactiles minuscules, des menus qui couvrent l’écran, des tableaux qui défilent latéralement et des fenêtres contextuelles qui ne peuvent pas être fermées.
Examinez chaque modèle à environ 390 pixels de large avant de l’approuver. Vérifiez que les boutons sont assez grands pour être tapés avec le pouce, que le texte fait au moins 16 pixels pour le corps du texte et que rien ne défile horizontalement. Testez sur un vrai téléphone Android de milieu de gamme, pas seulement sur un nouvel iPhone.
Les formulaires et le paiement sont-ils vraiment si importants ?
Oui. Les formulaires sont l’endroit où les visiteurs deviennent des prospects ou des clients, et ils tombent en panne plus souvent que toute autre partie d’un site. Un formulaire peut sembler parfait et envoyer quand même ses e-mails dans un dossier spam ou à une ancienne adresse.
Les erreurs courantes de formulaire incluent la demande de trop de champs, l’obligation de créer un compte avant le paiement, des messages d’erreur flous et aucune confirmation que le message a été reçu. Des solutions qui coûtent peu :
- Supprimez chaque champ que vous n’utilisez pas lors de la première conversation de vente.
- Proposez le paiement en tant qu’invité et ajoutez la création de compte après l’achat.
- Affichez les erreurs à côté du champ, en mots clairs, sans effacer ce que l’utilisateur a tapé.
- Envoyez les notifications de formulaire via un service SMTP authentifié afin qu’elles n’atterrissent pas dans les spams.
- Soumettez une entrée de test sur chaque formulaire chaque mois et après chaque mise à jour de plugin.
Refonte sans plan de migration SEO
Une refonte qui modifie les URL sans redirections peut effacer des années de visibilité de recherche en quelques semaines. Les anciens liens provenant d’autres sites pointent vers des pages qui n’existent plus, et Google doit tout redécouvrir.
Avant le lancement, explorez l’ancien site avec un outil comme Screaming Frog, exportez chaque URL qui reçoit du trafic ou des backlinks, et mappez chacune vers sa nouvelle adresse. Configurez des redirections 301, conservez les balises de titre et les titres pour les pages qui sont bien classées, et soumettez le nouveau plan de site XML dans la Search Console. Après le lancement, surveillez le rapport sur les pages pour détecter les pics de 404 pendant au moins un mois.
Que devrait-il être en place avant et après le lancement ?
Lancement sans analyses et objectifs
Si vous ne pouvez pas voir ce que font les visiteurs, vous ne pouvez pas dire si le nouveau site est meilleur que l’ancien. Pourtant, de nombreux sites sont lancés avec des analyses ajoutées “plus tard”, ou avec un code de suivi qui compte les pages vues mais pas les conversions.
Configurez Google Analytics 4 (ou une alternative comme Matomo ou Plausible) avant le lancement, définissez des événements clés tels que les soumissions de formulaires, les achats, les clics téléphoniques et les finalisations de réservation, et vérifiez que chacun se déclenche. Enregistrez les chiffres de référence de l’ancien site afin d’avoir quelque chose à comparer.
Pas de plan pour après le lancement
Un site web est un logiciel. Les plugins, thèmes, frameworks et logiciels de serveur ont besoin de mises à jour, et des problèmes de sécurité apparaissent régulièrement. Les sites laissés intacts pendant un an tombent souvent en panne lors d’une mise à jour forcée ou sont compromis.
Convenez d’un plan de maintenance avant le lancement : qui met à jour quoi, à quelle fréquence les sauvegardes sont exécutées et où elles sont stockées, à quelle vitesse les correctifs de sécurité sont appliqués et qui vérifie la disponibilité. Gardez une copie de test du site pour tester les mises à jour.
Un audit rapide que vous pouvez exécuter sur votre site actuel
Utilisez cette liste pour trouver d’abord les problèmes les plus coûteux :
- Exécutez PageSpeed Insights sur la page d’accueil et votre page de destination principale sur mobile.
- Soumettez chaque formulaire et confirmez que la notification arrive.
- Ouvrez le site sur un téléphone et essayez de terminer votre conversion principale.
- Vérifiez la Search Console pour les erreurs 404 et les problèmes de Core Web Vitals.
- Confirmez que les analyses enregistrent vos conversions clés.
- Vérifiez quand les sauvegardes ont été exécutées pour la dernière fois et si une restauration a déjà été testée.
Par où commencer cette semaine
Choisissez l’élément de l’audit qui touche le plus directement aux revenus, généralement le formulaire principal ou le paiement, et corrigez-le avant toute chose cosmétique. Ensuite, mesurez la vitesse de la page sur mobile et supprimez le script ou plugin inutilisé le plus lourd. Si une refonte est prévue, rédigez le document de portée et la carte de redirection d’URL maintenant, avant la première réunion de conception, car ces deux documents évitent la plupart des erreurs coûteuses de cette liste.
Continuez à lire : Conception et développement web · Conception web