Ce qui casse dans le site d'un club au bout de six mois.

Pourquoi six mois

Six mois, c'est une saison. Le site a été livré avant l'ouverture de septembre, avec la programmation d'automne, les photos de la soirée d'inauguration et un bouton « réserver une table » qui fonctionnait. En mars, tout est encore en ligne. Rien n'a été piraté, rien n'affiche d'erreur visible. Mais un client qui arrive depuis Google voit un site qui parle d'un autre moment, et il part. Ce qui suit est la liste, dans l'ordre de fréquence, de ce que nous trouvons quand un gérant de club ou de salle nous appelle pour « refaire le site ». La plupart du temps, il ne faut pas le refaire ; il faut réparer ce qui n'avait pas été prévu.

La programmation s'arrête en mars

C'est le premier symptôme et le plus visible. La page « Soirées » affiche encore les dates de décembre, ou pire, elle est vide parce que quelqu'un a supprimé les événements passés sans en ajouter de nouveaux. Le compte Instagram, lui, est à jour : c'est là que l'équipe publie, parce que c'est là que c'est facile.

La cause n'est pas la paresse, c'est l'outil. Ajouter une soirée demande d'ouvrir un ordinateur, de se souvenir d'un mot de passe, de redimensionner une image, de remplir douze champs. À 18 h, un vendredi, personne ne le fait. Le site que nous livrons a une interface de publication pensée pour un téléphone : une affiche, une date, un titre, un lien de réservation. Deux minutes. Et les soirées passées disparaissent seules de la page d'accueil sans être supprimées, pour que la page « archives » continue d'exister et d'être indexée.

Le lien de réservation mène nulle part

Le bouton « Réserver une table » pointait vers un formulaire, un numéro WhatsApp ou une plateforme de billetterie. Six mois plus tard, la plateforme a changé d'adresse, le numéro est celui d'un RP qui est parti, ou le formulaire envoie ses messages vers une boîte que plus personne n'ouvre. Le client clique, rien ne se passe ou personne ne répond, et il réserve ailleurs.

Deux règles à la livraison. La première : tout lien sortant est listé dans un document que le gérant possède, avec la date de vérification. La seconde : la réservation doit arriver dans un endroit que l'équipe regarde de toute façon, c'est-à-dire un outil de salle, pas une boîte email dédiée. C'est l'une des raisons pour lesquelles nous avons construit NightBook : la réservation du site tombe dans la liste que le chef de rang a déjà sous les yeux.

Les horaires se contredisent

Le site dit « ouvert du jeudi au samedi, 23 h à 6 h ». La fiche Google dit « vendredi et samedi ». Instagram dit autre chose dans la bio. Aucun des trois n'est complètement faux : les horaires ont changé en janvier et une seule des trois sources a été mise à jour.

Pour Google, c'est un signal d'incohérence qui coûte du classement local. Pour le client, c'est un déplacement pour rien devant une porte fermée. La solution technique est simple : les horaires n'existent qu'à un seul endroit, dans le site, et la fiche Google est mise à jour depuis la même donnée, par une API ou par une routine mensuelle. La solution humaine l'est moins : quelqu'un doit être responsable de cette donnée, et c'est écrit dans la formation de livraison.

• Horaires : une source, le site.
• Fiche Google, Instagram, annuaires : copiés depuis cette source, jamais saisis à part.
• Une personne nommée, un rappel mensuel.

Les images pèsent quatre mégaoctets

Le site était rapide à la livraison parce que nous avions compressé chaque image. Depuis, l'équipe a ajouté trente affiches exportées directement depuis le logiciel du graphiste, en 4 000 pixels de large et 4 Mo chacune. Sur un téléphone, devant la porte, en 4G saturée à 1 h du matin, la page d'accueil met huit secondes à s'afficher. Personne n'attend huit secondes.

Ce n'est pas au gérant de compresser des images. Le site doit le faire seul : chaque image déposée est convertie, redimensionnée pour les écrans qui la demandent et servie dans un format moderne. Dans Next.js, c'est le rôle du composant d'image, à condition qu'il soit utilisé partout, y compris pour les images ajoutées après la livraison :

<Image
  src={soiree.affiche}
  alt={`Affiche de la soirée ${soiree.titre}`}
  width={1200}
  height={1600}
  sizes="(max-width: 768px) 100vw, 50vw"
/>

Le texte alternatif est écrit depuis le titre de la soirée, pas laissé vide : c'est ce que Google lit, et ce que lit une personne qui n'affiche pas les images.

Le formulaire écrit à personne

Le formulaire de contact ou de privatisation envoyait vers l'adresse de la personne qui a suivi le projet. Elle est partie. Ou l'envoi passait par un service tiers dont l'essai gratuit a expiré. Ou les messages arrivent, mais dans les indésirables. Dans les trois cas, le site dit « message envoyé » et le message n'arrive nulle part. Pour une demande de privatisation, c'est cher.

Deux mesures. Le formulaire écrit vers une adresse de fonction (privatisation@…), pas vers une personne. Et chaque envoi est aussi enregistré dans une base que le gérant peut consulter, pour que rien ne dépende d'une boîte email. Une fois par mois, un message de test est envoyé et vérifié. C'est dans le contrat de maintenance parce que personne ne le fait spontanément.

Le domaine, le certificat, la dépendance

Les trois pannes silencieuses. Le nom de domaine a été pris par un prestataire précédent et l'email de renouvellement part vers lui. Le certificat expire parce que l'hébergeur ne le renouvelle pas seul. Une bibliothèque du site n'est plus maintenue et une mise à jour de navigateur casse la galerie photo. Aucune des trois ne prévient.

Un site sans maintenance ne tombe pas en panne. Il cesse de fonctionner un morceau à la fois, et personne ne s'en rend compte avant le client.

Le nom de domaine est au nom du club, sur un compte dont le gérant a le mot de passe, avec le renouvellement automatique activé. Le certificat est géré par l'hébergeur (Vercel le fait). Les dépendances sont mises à jour dans le cadre d'un contrat de maintenance mensuel, et le site est un site statique : moins de pièces mobiles, moins de choses qui cassent.

Ce qu'il faut prévoir à la livraison

Rien de tout cela n'est un problème de design. Ce sont des problèmes d'exploitation, et ils se règlent le jour de la livraison, pas six mois après :

1. Une interface de publication utilisable depuis un téléphone, en deux minutes.
2. La réservation qui tombe dans l'outil de salle, pas dans une boîte email.
3. Les horaires à un seul endroit, une personne responsable, un rappel mensuel.
4. Les images compressées par le site, pas par l'équipe ; un texte alternatif généré depuis le contenu.
5. Un formulaire vers une adresse de fonction, avec enregistrement des envois et un test mensuel.
6. Domaine au nom du club, certificat géré par l'hébergeur, maintenance mensuelle contractuelle.

C'est ce que nous livrons avec chaque site de club, et c'est ce que nous vérifions pour nos propres produits chaque semaine. Si votre site a six mois et que vous reconnaissez trois points de cette liste, il n'a probablement pas besoin d'être refait. Il a besoin d'être exploité.