Un projet web commence souvent par la phrase : « Nous avons besoin d’un nouveau site web. » La conversation se tourne rapidement vers le CMS, le modèle, les couleurs et la date de lancement. Pourtant, on ne sait toujours pas ce que le nouveau site devrait changer.
C’est une erreur coûteuse. La technologie peut très vite produire quelque chose dont l’entreprise n’a pas besoin.
Commencez par noter la décision que le site doit soutenir
Je ne commence pas par une liste de pages. Je pars de la situation de l’entreprise et du visiteur. Le site doit-il générer des demandes qualifiées, raccourcir les explications commerciales, vendre sans intervention humaine, réduire le travail du support ou faire entrer la marque dans une autre catégorie ?
L’objectif doit conduire à une décision. « Une présentation plus moderne » est un souhait. « Davantage de demandes pertinentes de la part d’entreprises industrielles et moins de questions sur les petits travaux ponctuels » permet déjà de décider du contenu, de la navigation et de la mesure.
- Qui compte pour le site et dans quelle situation arrive-t-il ?
- Que doivent-ils comprendre, comparer ou faire ?
- Quelles preuves l’entreprise peut-elle montrer honnêtement ?
- Quelle prochaine étape correspond à son niveau de préparation ?
- Comment reconnaîtrons-nous l’amélioration après le lancement ?
La carte des contenus vient avant la maquette fonctionnelle
Ce n’est qu’ensuite que je construis l’architecture de l’information. La navigation principale ne doit pas copier la structure organisationnelle de l’entreprise. Elle doit aider les gens à trouver une réponse et à comprendre l’offre.
Pour un site existant, je commence par inventorier les URL, le trafic, les liens et le contenu réel. Je conserve certaines pages, j’en fusionne, redirige ou supprime d’autres. La migration ne doit pas reposer sur des impressions. Une page peu attrayante peut avoir de bons liens ou générer une activité pertinente ; une page très visitée peut attirer des personnes totalement étrangères à l’activité.
Pour le SEO, une structure claire, les liens et un contenu destiné à une audience réelle comptent. Google résume ses questions sur l’utilité dans son guide consacré au contenu pensé pour les utilisateurs. Une base SEO pratique se trouve également dans mon article Le SEO pour débutants.
Un prototype doit vérifier le parcours, pas impressionner en réunion
Je commence par dessiner les parcours clés sans entrer dans les détails du design. Une personne peut-elle comprendre à qui l’entreprise s’adresse ? Trouver un service, une preuve, un prix ou un moyen de contact ? Le parcours fonctionne-t-il sur un écran mobile étroit et avec un clavier uniquement ?
J’intègre dans le prototype de vrais titres et des longueurs de texte à peu près réalistes. Le lorem ipsum dissimule un problème qui réapparaît miraculeusement après la livraison du contenu — généralement le vendredi précédant le lancement.
Choisissez la technologie en fonction de l’exploitation
Un site statique, WordPress, une plateforme e-commerce ou une application sur mesure peuvent tous convenir. Ce qui compte, ce sont les besoins de modification, les intégrations, les autorisations, la vitesse d’évolution, la sécurité, le budget et les personnes qui géreront le site après son lancement.
Le cahier des charges doit au moins inclure :
- la propriété du domaine, des comptes, du code source et des outils d’analyse ;
- les rôles éditoriaux et le processus de publication ;
- les formulaires, la distribution des e-mails et la connexion aux ventes ;
- les redirections des anciennes URL et une page d’erreur personnalisée ;
- les sauvegardes, les mises à jour, la surveillance et la responsabilité en cas d’incident ;
- un budget d’exploitation, pas seulement un budget de production.
La vitesse et l’accessibilité ne sont pas des finitions ajoutées à la fin
Une grande image, des polices externes et dix scripts marketing sont faciles à ajouter. Chaque visiteur en paie ensuite le coût. Les Core Web Vitals suivent le chargement du contenu principal, la réactivité et la stabilité visuelle ; Google tient à jour les mesures et les seuils dans sa documentation Web Vitals.
Je définis donc un budget de performance avant le design : dimensions et formats des médias, nombre de graisses de police, règles applicables aux scripts tiers et comportement cible sur un mobile ordinaire. Les outils d’analyse doivent se charger sans bloquer le contenu et ne recueillir que les données utiles aux décisions.
Je traite l’accessibilité en même temps : HTML sémantique, focus visible, navigation au clavier, contraste, libellés de formulaires et respect de la réduction des animations. Ce n’est pas une version spéciale d’un site web. C’est un site web bien conçu.
Concevez la mesure avant le lancement
Après le lancement, je ne veux pas débattre de la définition du succès. Je liste les événements et leur lien avec les décisions : demande qualifiée envoyée, calculateur utilisé, preuve clé consultée ou commande finalisée. Tous les clics ne méritent pas un événement.
La mesure technique est expliquée dans le guide Google Analytics 4. Une check-list plus large figure dans la check-list d’un projet en ligne.
Un site web n’est pas terminé au lancement
Durant les premières semaines, je surveille les erreurs, la vitesse, l’indexation, les formulaires et les vraies questions des visiteurs. J’améliore ensuite les endroits où le site n’aide pas à prendre une décision. Pas après chaque commentaire ou à partir d’une seule mesure, mais selon une combinaison de données, de retours et d’impact commercial.
Un nouveau site web n’est pas l’objectif. C’est un nouveau système d’exploitation pour l’entreprise. Sans responsable, budget ni règles d’évolution, il commence à vieillir le jour de son lancement.
Si vous avez déjà un site web et devez en repérer les points faibles, commencez par Comment accélérer un site web. Si vous devez aligner les décisions avant la production, découvrez comment fonctionne la collaboration.