Création de site Internet vitrine sur Paris (75)

Il existe des refontes qui se décident pour des motifs parfaitement compréhensibles sur le plan humain et parfaitement destructeurs sur le plan économique. La plus courante est la lassitude. Un dirigeant regarde son site tous les jours depuis six ans, il en connaît chaque défaut par cœur, il ne voit plus que ce qui l'agace, et il finit par le trouver insupportable. Le visiteur, lui, découvre ce site pour la première fois, ne le comparera jamais à sa version précédente, et juge simplement s'il trouve l'information qu'il cherche. Le décalage entre ces deux regards explique une quantité considérable de projets engagés sans nécessité. Nous ne disons pas qu'il ne faut jamais rafraîchir un site par confort : nous disons qu'il faut le savoir, l'assumer comme un choix esthétique, et ne pas se raconter que le trafic va doubler parce que les boutons auront des angles arrondis.

La deuxième mauvaise raison est l'arrivée d'un nouveau responsable. Un directeur marketing prend son poste, un associé entre au capital, un successeur reprend l'entreprise familiale, et le site devient le terrain naturel où marquer son empreinte. Le projet est alors piloté par un besoin de rupture visible, ce qui conduit presque mécaniquement à jeter l'existant plutôt qu'à l'examiner. Nous avons vu disparaître dans ces circonstances des blogs de deux cents articles qui apportaient la majorité du trafic, au motif qu'ils « ne correspondaient plus à la nouvelle image ». La nouvelle image est arrivée, le trafic est parti, et il a fallu trois ans pour reconstruire ce qui avait été effacé en une nuit.

La refonte prescrite sans diagnostic

La troisième est plus insidieuse parce qu'elle vient d'un professionnel. Une entreprise constate une baisse de visibilité, consulte une agence, et s'entend proposer une refonte complète comme réponse. Dans une majorité de cas, personne n'a ouvert la Search Console, personne n'a regardé les journaux du serveur, personne n'a vérifié si la baisse provenait d'une désindexation, d'une pénalité, d'un changement d'algorithme, d'un concurrent qui a beaucoup publié ou simplement d'une saisonnalité. Refaire un site sans avoir établi la cause de la baisse revient à changer de voiture parce qu'un pneu est crevé, avec cette différence qu'on repart en général avec le pneu crevé. Si le problème était une architecture de contenu trop mince, elle le restera ; s'il venait de liens perdus, ils ne reviendront pas ; s'il venait d'un rendu par script que Google n'exécute pas, la refonte a une chance sur deux de l'aggraver.

La quatrième mauvaise raison est la comparaison avec un concurrent. Un site voisin fait meilleure impression, on veut le même, et on demande à une agence de s'en inspirer. Le résultat est un site qui ressemble au marché, ce qui est exactement l'inverse de ce qu'un site devrait faire, et qui perd au passage les particularités qui vous distinguaient. La cinquième, enfin, est le changement de prestataire : une agence nouvellement retenue propose de tout reprendre parce qu'il lui est plus confortable de travailler sur son propre socle que de comprendre celui d'un autre. C'est un argument de confort interne présenté comme un impératif technique, et il mérite d'être questionné frontalement, devis à l'appui.

Une fois la liste établie, la première colonne à remplir est celle du trafic réel. Elle produit à peu près toujours le même effet de surprise, et cet effet est utile : il désamorce une bonne partie des décisions arbitraires qui allaient être prises. La distribution du trafic sur un site est extrêmement déséquilibrée. Sur une vitrine ordinaire, une poignée de pages concentre l'essentiel des visites, et l'immense majorité des autres en reçoit trois par mois ou zéro. Ce qui compte, ce n'est pas de découvrir ce déséquilibre — il est universel — mais d'identifier précisément quelles pages occupent la tête, parce que ce ne sont presque jamais celles que l'entreprise cite spontanément.

Nous relevons ce trafic sur douze mois glissants au minimum, et sur seize à dix-huit mois quand l'activité est saisonnière. Une page de service qui ne reçoit rien en juillet peut être la première du site en janvier ; la juger sur un trimestre reviendrait à la condamner sur un échantillon biaisé. Nous distinguons également deux sources qui n'ont pas la même signification. Les visites issues de la recherche de marque — les gens qui tapent votre nom — mesurent votre notoriété et se reporteront sur n'importe quelle page d'accueil, quelle que soit sa forme. Les visites issues de requêtes non liées à la marque mesurent la capacité de vos pages à capter des gens qui ne vous connaissaient pas, et celles-là sont directement liées à l'adresse, au contenu et à la position de la page précise qui les reçoit. Ce sont elles qui disparaissent quand on se trompe.

Les pages à fort potentiel qu'on ne voit pas dans les visites

Un second relevé est indispensable, et il est plus rarement fait : celui des impressions. Une page peut apparaître des milliers de fois dans les résultats et ne recevoir presque aucun clic, parce qu'elle se situe en onzième à vingtième position, c'est-à-dire juste sous la première page. Dans un tableau de trafic, elle ressemble à une page morte ; dans la réalité, elle est un actif dormant que Google juge déjà pertinent et qui ne demande qu'une poussée. Supprimer une telle page lors d'une refonte, parce qu'elle « ne fait pas de visites », revient à jeter un terrain constructible sous prétexte qu'il n'y a pas encore de maison dessus. Nous relevons donc, pour chaque adresse, impressions, clics, position moyenne et taux de clic, et nous marquons d'une couleur particulière tout ce qui apparaît beaucoup sans être cliqué.

Reste le cas des pages qui ne reçoivent effectivement rien, ni visite ni impression, et qui constituent souvent le tiers ou la moitié d'un site ancien. Leur sort ne se décide pas encore à ce stade : une page sans trafic peut porter un lien externe précieux, servir un usage interne, répondre à une obligation légale, ou avoir été créée trois semaines plus tôt. Le trafic est la première colonne du tableau de décision, ce n'est jamais la seule, et une refonte qui ne s'appuierait que sur lui commettrait la moitié des erreurs qu'on cherche justement à éviter. Sur les dossiers où la volumétrie est importante, nous complétons cette lecture par un audit technique et sémantique mené sur le périmètre parisien, qui replace chaque page dans le paysage concurrentiel de sa requête plutôt que dans le seul tableau de bord de l'entreprise.

La troisième colonne du tableau d'inventaire est la plus difficile à remplir, parce qu'elle exige une mesure que beaucoup de sites n'ont jamais mise en place. Savoir qu'une page reçoit du trafic est une chose ; savoir qu'elle produit des demandes de devis, des appels, des prises de rendez-vous ou des inscriptions en est une autre, et c'est la seule qui compte vraiment pour l'entreprise. Quand cette mesure existe, nous la reprenons telle quelle. Quand elle n'existe pas — cas fréquent, y compris chez des sociétés de taille respectable — nous la reconstituons approximativement à partir des pages d'où partent les formulaires, des clics sur les numéros de téléphone quand ils ont été suivis, et de ce que l'entreprise sait de ses propres origines de contact. L'approximation vaut mieux que le vide.

Ce que cette colonne révèle contredit souvent la précédente. Les pages qui attirent le plus de monde ne sont presque jamais celles qui déclenchent le plus d'affaires. Un article de blog qui répond à une question générale draine des visiteurs en phase de curiosité, qui repartent sans rien demander ; une page de service très spécialisée, avec deux cents visites par mois, produit la moitié des demandes qualifiées. Cette dissymétrie est structurelle et elle a une conséquence directe sur la refonte : les critères de suppression ne peuvent pas être les mêmes selon les deux axes. Une page à faible trafic et forte conversion est un actif stratégique. Une page à fort trafic et conversion nulle n'est pas inutile pour autant — elle nourrit l'autorité du domaine et alimente les pages voisines par le maillage interne — mais elle ne mérite pas qu'on lui sacrifie la précédente.

Les pages discrètes du parcours de décision

Il existe une catégorie de pages dont la contribution n'apparaît dans aucun tableau de conversion et qui pèse pourtant lourdement sur la décision d'achat. La page « à propos », consultée par une proportion étonnante de prospects juste avant d'appeler. La page de tarifs ou de méthode, qui répond à la question que personne n'ose poser. La page des mentions légales, que les acheteurs professionnels ouvrent pour vérifier l'existence juridique de leur futur prestataire. Les études de cas, qui ne se positionnent sur rien mais que l'on envoie par courriel en cours de négociation. Sur les cycles de vente longs qui caractérisent une bonne part du tissu francilien, ces pages sont consultées entre le troisième et le sixième contact, quand la décision se prépare. Les supprimer parce qu'elles ne génèrent pas de trafic direct est une erreur de lecture qui se paie en affaires perdues, sans jamais apparaître dans une courbe.

Nous demandons donc toujours, à ce stade, un entretien avec la personne qui reçoit les appels et les demandes. Une assistante de direction, un commercial, un responsable d'agence savent en général très bien ce que les prospects mentionnent quand ils appellent : « j'ai vu votre page sur tel sujet », « votre exemple de projet à Levallois ressemble à ce que je cherche », « je n'ai pas trouvé vos tarifs ». Ces phrases valent tous les outils de mesure, et elles orientent l'inventaire mieux qu'un tableau croisé. Elles font souvent apparaître qu'une page jugée secondaire par la direction est en réalité la porte d'entrée principale d'un segment de clientèle entier.

Il existe un scénario que nous avons rencontré tant de fois qu'il mérite un traitement à part, parce qu'il détruit à lui seul plus de trafic que toutes les erreurs techniques réunies. Une entreprise décide de refaire son site et profite de l'occasion pour « faire le ménage ». Le blog est jugé daté, les articles sont anciens, les photos ne correspondent plus à la charte, le ton n'est plus celui de la marque. On décide de repartir sur une base propre avec dix articles neufs. Trois mois plus tard, le trafic a chuté de moitié et personne ne comprend pourquoi, puisque le nouveau site est objectivement meilleur.

L'explication est mécanique. Sur la plupart des sites d'entreprise, les pages commerciales se positionnent sur un petit nombre de requêtes très disputées, où l'on est rarement premier. Les contenus anciens, eux, occupent une multitude de requêtes précises, peu concurrentielles, que personne n'a ciblées volontairement et qui, additionnées, représentent une part majoritaire des visites. Un article publié en 2016 sur une évolution réglementaire, une note technique sur un problème de chantier, un compte rendu d'un salon professionnel : chacun apporte deux visites par jour, et il y en a cent quarante. Cette longue traîne ne se voit pas dans un rapport de positions sur vingt mots-clés stratégiques ; elle se voit uniquement quand on ouvre la liste complète des requêtes qui amènent des impressions, et c'est pour cette raison qu'on la supprime si souvent sans s'en rendre compte.

Vieux ne veut pas dire mort

L'ancienneté d'un contenu n'est en elle-même ni un défaut ni une qualité. Ce qui compte est de savoir si l'information qu'il porte est encore juste et si des gens la cherchent encore. Un article sur une norme abrogée doit disparaître ou être réécrit ; un article sur une méthode de calcul inchangée depuis quinze ans peut rester tel quel pendant quinze ans de plus. Entre les deux, l'immense majorité des contenus relève d'une troisième catégorie : ils sont encore valables mais mal présentés, mal titrés, sans mise à jour de date, avec des illustrations médiocres. Ceux-là se réactualisent en une heure chacun, à la même adresse, en conservant tout ce qu'ils ont accumulé. Un chantier de mise à jour de soixante articles anciens produit régulièrement plus de trafic supplémentaire que la publication de vingt articles neufs, pour un coût inférieur.

Nous appliquons donc une règle simple avant toute suppression de contenu ancien : on ouvre la liste des requêtes qui amènent des impressions vers cette page sur les douze derniers mois, et on regarde. Si la page apparaît sur des requêtes qui ont un sens pour l'activité, elle reste, éventuellement réécrite. Si elle apparaît sur des requêtes hors sujet ou sur rien du tout, la question se pose. Ce contrôle prend deux minutes par page. Sur un blog de deux cents articles, il représente une petite semaine de travail — à comparer avec les deux à trois ans nécessaires pour reconstruire un volume de longue traîne équivalent. Nous avons pratiqué cet arbitrage sur des sites d'éditeurs et de cabinets parisiens dont la direction était persuadée que leur blog ne servait à rien : dans presque tous les cas, il pesait entre la moitié et les deux tiers des visites entrantes.

Le plan de redirections est le document le plus important de toute la refonte et celui que l'on retrouve le moins souvent dans les projets qui ont mal tourné. Il ne s'improvise pas la veille de la mise en ligne, il ne se génère pas automatiquement, et il ne se limite pas aux pages principales. C'est un tableau à quatre colonnes : l'adresse ancienne exacte, l'adresse nouvelle exacte, le type de correspondance, et la justification en quelques mots. Il se construit à partir du tableau d'inventaire, dont il est le prolongement direct : chaque ligne marquée « fusionnée » ou « supprimée » produit une redirection, chaque ligne « conservée » avec un chemin modifié en produit une aussi.

Le type de redirection à employer est la 301, redirection permanente, qui indique aux moteurs que le déplacement est définitif et transfère l'essentiel des signaux accumulés. La 302, temporaire, se réserve aux situations réellement provisoires ; l'employer par défaut, ce que font certains plugins et certains hébergeurs par facilité, retarde le transfert et prolonge inutilement la période d'incertitude. Il faut aussi vérifier que la redirection est bien émise par le serveur et non simulée en JavaScript ou par une balise de rafraîchissement dans l'en-tête HTML : ces deux méthodes fonctionnent visuellement pour un humain et sont, du point de vue du transfert de signaux, à peu près sans effet.

Le point de destination, choisi page par page

La règle de fond tient en une phrase : chaque ancienne adresse doit être redirigée vers la page qui répond le plus précisément à la même intention. Une page « dépannage de chaudière à Paris 15 » ne se redirige pas vers la page « nos services », elle se redirige vers la page dépannage la plus proche géographiquement et thématiquement. Un article de blog sur un sujet précis se redirige vers l'article ou la page qui traite ce sujet, pas vers la liste des articles. Une fiche produit retirée se redirige vers la catégorie qui contient les produits équivalents, pas vers l'accueil de la boutique. Quand aucune destination pertinente n'existe, il faut se demander sérieusement si ce n'est pas le nouveau site qui a un trou, plutôt que l'ancienne page qui est de trop.

Les règles générales, écrites avec des expressions de correspondance, sont utiles pour les transformations systématiques : basculer tout un répertoire, ajouter ou retirer un préfixe, forcer https, unifier le www. Elles doivent rester peu nombreuses, être lues dans un ordre maîtrisé, et être suivies d'une règle de repli explicite. Les correspondances unitaires, ligne à ligne, traitent tout le reste. Sur un site vitrine, un plan complet compte couramment entre cent cinquante et six cents lignes ; sur un site ancien avec un historique de blog, on dépasse fréquemment le millier. Ce volume effraie, à tort : le tableau se remplit en grande partie par recoupement automatique des titres et des chemins, et seule une minorité de lignes demande un arbitrage humain.

Dernier point, souvent négligé : le plan se teste avant la bascule, pas après. Sur l'environnement de préproduction, on rejoue l'intégralité de la liste des anciennes adresses et l'on vérifie, pour chacune, le code renvoyé et la destination finale. Un tableur de contrôle avec une colonne « code attendu » et une colonne « code obtenu » suffit. Cette vérification prend quelques heures et évite la totalité des accidents que nous décrivons plus loin. Elle fait partie de ce que nous incluons systématiquement dans nos projets de création et refonte de site Internet, et nous considérons qu'un devis de refonte qui ne mentionne pas cette ligne est incomplet.

Une refonte s'accompagne fréquemment d'un changement d'infrastructure, et c'est là que se produisent les incidents les plus visibles pour l'entreprise, parce qu'ils touchent des choses que tout le monde utilise. Le premier point à vérifier, très en amont, est la propriété du nom de domaine. Il doit être enregistré au nom de la société, avec une adresse de contact administrative qui appartient à un salarié en poste, et les identifiants du bureau d'enregistrement doivent être détenus par l'entreprise. Nous rencontrons encore des situations où le domaine est au nom de l'ancien prestataire, parfois d'un ancien stagiaire, parfois d'une société dissoute. Tant que la relation est cordiale, le transfert prend une heure ; le jour d'un désaccord, il peut devenir un cauchemar juridique. La même vérification vaut pour les comptes de mesure, l'accès à la Search Console et l'espace d'hébergement.

Le changement d'hébergement demande une préparation méthodique. On abaisse la durée de vie des enregistrements DNS quelques jours avant l'opération, afin que le basculement se propage en minutes plutôt qu'en heures. On installe le nouveau site sur le nouveau serveur et on le teste par son adresse technique ou par modification locale du fichier de résolution, jamais en pointant le domaine « pour voir ». On vérifie les versions de PHP, les extensions serveur nécessaires, les limites de mémoire, les tâches planifiées, les certificats. Et l'on prévoit une fenêtre pendant laquelle les deux hébergements coexistent, parce que la propagation n'est jamais instantanée pour tout le monde : pendant quelques heures, une partie des visiteurs voit l'ancien site et une autre le nouveau.

La messagerie, victime silencieuse des migrations

Le point le plus douloureux, et celui que les entreprises n'anticipent presque jamais, concerne le courrier électronique. Beaucoup de PME hébergent leur messagerie chez le même prestataire que leur site, avec des adresses en @nomdelasociete.fr gérées par la même zone DNS. Changer d'hébergeur et recopier « les réglages du site » sans reprendre les enregistrements de messagerie provoque une interruption immédiate : les courriels entrants partent vers un serveur qui n'existe plus, ils rebondissent ou disparaissent, les collaborateurs ne peuvent plus relever leur boîte, et l'entreprise perd des demandes commerciales pendant une à trois journées sans même savoir combien. Nous avons vu un cabinet francilien découvrir trois semaines plus tard qu'il n'avait rien reçu pendant quarante-huit heures, et ne jamais savoir ce qu'il avait manqué.

La prévention est simple mais demande d'y penser. On relève l'intégralité de la zone DNS existante avant toute modification, enregistrement par enregistrement, en particulier ceux qui concernent la messagerie, l'authentification des expéditeurs et les services tiers connectés au domaine. On reproduit exactement cette zone chez le nouveau prestataire, à l'exception des seuls enregistrements qui doivent changer, c'est-à-dire ceux qui pointent vers le serveur web. Si la messagerie doit également déménager, on la traite comme un projet distinct, avant ou après la bascule du site, jamais le même jour. On vérifie aussi les formulaires du site, qui envoient des courriels et dont la configuration d'expédition change avec l'hébergement : un formulaire qui ne renvoie plus d'erreur mais dont les messages finissent en indésirables est une panne particulièrement pernicieuse, car elle passe la recette et se découvre plusieurs semaines plus tard.

Le choix du moment n'est pas un détail d'organisation, c'est une décision de gestion du risque. La règle que nous appliquons sans exception est de ne jamais basculer un vendredi après-midi, ni la veille d'un pont, ni avant une période de congés. Les incidents d'une mise en ligne se révèlent dans les vingt-quatre à soixante-douze heures, et ils demandent quelqu'un de disponible pour les traiter. Une bascule effectuée un mardi matin laisse trois jours ouvrés pleins devant elle, avec l'équipe présente, l'hébergeur joignable et le client capable de tester. Une bascule du vendredi soir laisse un site potentiellement cassé pendant soixante heures, découvert par les visiteurs avant de l'être par vous.

Le second critère est la saisonnalité de l'activité. On ne refait pas le site d'un professionnel du chauffage en octobre, celui d'un traiteur événementiel en novembre, celui d'un cabinet comptable en pleine période fiscale, ni celui d'un commerçant à l'entrée des fêtes. La bascule doit se situer dans un creux d'activité, pour deux raisons : la période de flottement qui suit coûte moins cher quand la demande est faible, et l'équipe de l'entreprise est plus disponible pour tester, corriger et valider. Sur les dossiers franciliens à forte saisonnalité, nous arbitrons souvent pour une mise en ligne en juillet ou en janvier, quitte à décaler de plusieurs semaines une livraison techniquement prête.

Le déroulé de la journée

La bascule elle-même s'exécute dans un ordre écrit à l'avance, avec un responsable identifié pour chaque étape et un point de non-retour clairement situé. On commence par une sauvegarde complète de l'ancien site — fichiers et base — stockée ailleurs que sur l'hébergement concerné, et l'on vérifie que cette sauvegarde est restaurable, ce qui n'est pas la même chose que de vérifier qu'elle existe. On met le nouveau site en production, on retire immédiatement le blocage d'indexation, et l'on vérifie ce retrait avant toute autre chose. On active les redirections et l'on rejoue un échantillon significatif du plan, en commençant par les vingt adresses qui portaient le plus de trafic et par toutes celles qui reçoivent des liens externes. On soumet le nouveau plan de site dans la Search Console. On teste les formulaires en conditions réelles. On vérifie que les outils de mesure enregistrent bien les visites.

Il faut également prévoir, et écrire noir sur blanc, la procédure de retour arrière : dans quel cas on la déclenche, qui la décide, combien de temps elle prend. Un retour arrière n'est pas un échec, c'est une soupape. Nous l'avons déclenché deux fois en une dizaine d'années, dans les deux cas pour un problème qui aurait demandé une journée de correction et qui aurait laissé le site inutilisable pendant ce temps. Enfin, on prévient les gens : le personnel qui répond au téléphone doit savoir que le site vient de changer, les commerciaux doivent connaître les nouvelles adresses des documents qu'ils envoient, et les partenaires qui affichent un lien vers vous peuvent être prévenus le jour même. Ces trois messages coûtent une demi-heure et évitent des semaines de petits frottements. Sur les marchés très disputés, la reprise de visibilité après bascule se pilote ensuite comme une campagne à part entière, et c'est le prolongement naturel du travail que décrit notre page d'agence de référencement sur Paris.

Les scénarios d'échec sont étonnamment peu nombreux et se répètent d'un dossier à l'autre. Les décrire n'a rien d'anecdotique : c'est la meilleure manière de comprendre ce que la méthode décrite plus haut cherche à prévenir, point par point. Le premier cas, et de loin le plus fréquent, est celui de la redirection absente ou globale. Une société de services franciliens fait refaire son site par un prestataire qui livre un travail graphiquement soigné. Les adresses changent toutes, parce que le nouveau CMS structure ses chemins différemment. Aucun plan de redirections n'a été demandé au devis, donc aucun n'a été prévu. Six semaines après, le trafic de recherche est divisé par trois et il ne remonte pas, parce que les cent quatre-vingts pages qui le portaient sont sorties de l'index sans successeur.

Le deuxième cas est celui de l'indexation bloquée. Le site est basculé un jeudi, tout fonctionne, tout le monde est satisfait. Personne ne remarque que l'instruction de blocage installée sur la préproduction est restée en place. Pendant quinze jours, rien ne se passe de visible : les pages déjà indexées restent affichées dans les résultats. Puis Google repasse, constate l'interdiction, et retire progressivement l'ensemble du site. La chute est brutale, tardive, et donc particulièrement déroutante puisqu'elle survient au moment où l'on avait cessé de surveiller. La correction prend une minute, la récupération complète prend en revanche plusieurs semaines.

Les contenus supprimés et les migrations à moitié faites

Le troisième cas est la suppression de contenu jugée anodine. Un éditeur de logiciel parisien décide de ne pas reprendre son blog dans la refonte : cent soixante articles, jugés trop techniques et mal écrits, dont il n'existait aucune analyse de performance. Ces articles apportaient les deux tiers des visites et la majorité des inscriptions à la démonstration produit. Le nouveau site, plus élégant, a mis dix-huit mois à retrouver son niveau, et il n'y est parvenu qu'en republiant une partie des contenus supprimés, retrouvés dans les archives du web faute de sauvegarde exploitable.

Le quatrième cas est le changement de nom de domaine mal accompagné. Une entreprise change de marque et bascule sur un nouveau domaine, ce qui est parfaitement légitime, mais traite l'opération comme un simple déménagement de fichiers : pas de déclaration de changement d'adresse dans la Search Console, redirections partielles, ancien domaine non renouvelé au bout d'un an. Or un changement de domaine demande de conserver l'ancien pendant plusieurs années, redirections actives, le temps que les liens externes soient mis à jour et que l'antériorité se transfère. Le cinquième cas, enfin, est plus subtil : la refonte livre un site dont le contenu principal n'est produit qu'après exécution de scripts dans le navigateur. Les pages s'affichent parfaitement pour un humain, mais ce que le moteur voit en premier est une coquille presque vide. Le trafic baisse lentement, sans cause apparente, et le diagnostic passe souvent à côté parce que tout le monde regarde le site avec ses yeux plutôt qu'avec les outils qui montrent la page servie avant traitement. Sur les projets marchands, ces situations se combinent volontiers avec des problèmes de catalogue que nous détaillons sur notre page dédiée au e-commerce à Paris.