Étude de cas · Festival électro et culture bretonne

Phare Ouest'Ival — un site de festival qui tient dans un pouce

Phare Ouest'Ival est un festival électro et culture bretonne organisé par l'association Abadakore, à Plescop dans le Golfe du Morbihan. La deuxième édition s'est tenue les 28 et 29 août 2026.

Un site de festival n'est pas un site d'entreprise. Il est consulté debout, dehors, sur un téléphone, souvent au moment où l'on cherche une heure de passage ou l'adresse du site — parfois avec un réseau saturé par plusieurs milliers de personnes au même endroit. Et il n'a pas la même utilité selon qu'on est trois mois avant l'événement, pendant, ou trois mois après.

Un mois, du premier échange à la mise en ligne.

Voir le site en ligne(phareouestival.fr, nouvelle fenêtre)
Foule en contre-jour devant les lumières de la scène — Phare Ouest'Ival, festival électro à Plescop

Le point de départ : aucun site

Il n'y avait rien. La présence en ligne du festival tenait sur les réseaux sociaux, où l'information est bonne le jour où elle est publiée et introuvable la semaine suivante.

L'enjeu n'était donc pas de faire joli, mais de donner au festival une adresse stable : un endroit qui répond aux mêmes questions toute l'année, qui existe dans les résultats de recherche, et qui ne dépend pas d'un fil d'actualité.

Les quatre décisions qui structurent le site

Une seule page, six ancres

Merci, line-up, infos pratiques, sur place, contact : tout tient dans un défilement, sans navigation entre des pages qu'il faudrait recharger. Sur un téléphone, au milieu d'un champ, chaque chargement évité compte.

Le festival déclaré comme un événement, pas comme du texte

Les dates, le lieu, le statut et le mode de présence sont balisés en MusicEvent. Pour un moteur de recherche, ce n'est plus une page qui parle d'un festival : c'est un événement daté et situé, qu'il peut afficher comme tel.

Aucune dépendance tierce

Pas de tracker, pas de police distante, pas de lecteur vidéo embarqué : le site ne charge rien d'autre que lui-même. Ce qui veut dire, entre autres, qu'il n'y a aucun bandeau de consentement à afficher — la question ne se pose pas.

Un site qui change d'état entre deux éditions

Aujourd'hui, le site est en mode « édition terminée » : il remercie les festivalier·ère·s, les artistes, les bénévoles et les partenaires, plutôt que d'annoncer indéfiniment un événement passé. C'est l'écueil classique des sites d'événement, et il se traite au moment de la conception, pas après.

Ce que le site fait

  • Une page, six sections ancrées, et une page de mentions légales.
  • Des données structurées MusicEvent complètes : nom de l'édition, dates de début et de fin, lieu avec son adresse, statut de l'événement et mode de présence.
  • Vingt-huit visuels — artistes, partenaires, ambiance — tous pourvus d'une alternative textuelle, et vingt-six chargés seulement quand on arrive dessus.
  • Le logo en titre de page, marqué comme prioritaire au chargement : c'est le plus grand élément affiché, le navigateur le sait et va le chercher en premier.
  • Un sitemap et un robots.txt servis, et une adresse de contact directe.
  • Aucun domaine tiers appelé, sur la totalité de la page.

Ce que ça donne, mesuré

Les chiffres ci-dessous ont été relevés sur le site en ligne, dans les conditions d'un téléphone sur un réseau moyen — c'est-à-dire dans les conditions réelles d'usage d'un site de festival.

0,9 s

Affichage du plus grand élément (LCP)

Google considère un site rapide en dessous de 2,5 s.

0

Décalage visuel cumulé (CLS)

Rien ne bouge pendant le chargement, malgré vingt-huit images. Le seuil de pénalité est de 0,1.

10

Requêtes réseau

Toutes vers le site lui-même : aucune connexion tierce à établir.

600 Ko

Poids de la page

Pour une page qui affiche vingt-huit visuels : l'essentiel n'est chargé qu'au défilement.

Relevé le 17 septembre 2026 sur phareouestival.fr — émulation mobile, réseau limité à 1,6 Mbit/s avec 150 ms de latence, processeur ralenti quatre fois, médiane de trois passes.

Ces mesures décrivent le site au jour du relevé. Elles bougent quand le contenu bouge : c'est la raison pour laquelle la date est écrite à côté.

Ce que ça rend possible

Ce que le site permet, par construction. Ce ne sont pas des résultats commerciaux rapportés mais des conséquences de ses fonctionnalités : chaque point se vérifie en ouvrant la page.

Les dates peuvent sortir directement dans Google

Parce qu'elles sont déclarées en MusicEvent et non écrites dans un paragraphe, les dates et le lieu sont exploitables par les moteurs et les agrégateurs d'événements sans que personne ait à les ressaisir ailleurs.

Aucun bandeau de consentement à afficher

Sans tracker ni ressource tierce, il n'y a pas de cookie soumis à consentement, donc pas de bandeau — ni la charge juridique qui va avec. C'est un choix de conception, pas une case cochée après coup.

Le programme reste consultable quand le réseau ne suit pas

Dix requêtes, toutes vers le même domaine, et un premier affichage sous la seconde en réseau dégradé : le site ne dépend de la disponibilité de personne d’autre le jour où quelques milliers de téléphones partagent la même antenne.

L'adresse survit à l'édition

Le site bascule en mode remerciement entre deux éditions au lieu de rester figé sur un événement passé. L'adresse continue d'exister, d'être indexée, et d'accueillir la suivante.

Un projet du même genre ?

Dites-nous où vous en êtes. Nous répondons sous deux jours ouvrés, et le premier échange ne coûte rien.