L'Exploratoire : un site d'orientation professionnelle rapide, accessible et sans cookie

L'Exploratoire est le lieu d'orientation professionnelle de We Ker à Rennes : ateliers, rencontres avec des professionnel·les, conseil individuel, gratuits et ouverts à tous les publics. Platane a conçu et développé son nouveau site, mis en ligne en août 2026 sur www.exploratoire.com, avec une consigne simple : rapide, accessible, et sans rien qui oblige à afficher un bandeau de cookies.

Le contexte

L'Exploratoire (2 cours des Alliés, Rennes) est porté par We Ker, né en 2018 de la fusion de la Maison de l'Emploi et de la Mission Locale du bassin rennais. Collégien·nes, lycéen·nes, étudiant·es, demandeur·ses d'emploi et salarié·es y viennent explorer les métiers et construire un projet professionnel : conseil individuel, ateliers collectifs, découverte des métiers, espace numérique, itinérance sur le territoire.

L'ancien site, sur un CMS propriétaire, ne reflétait plus l'activité du lieu : une programmation de plusieurs dizaines d'ateliers par mois gérée sur Linscription.com, des intervenant·es à mettre en avant, des ressources à partager, et une équipe qui devait pouvoir publier sans passer par un prestataire.

Le besoin : un site vitrine vivant, piloté par l'équipe, qui respecte les obligations d'une structure de service public (accessibilité RGAA, RGPD) et qui tienne dans le temps. La direction artistique a été confiée à Brut de Pomme, nos partenaires de longue date ; Platane a pris la conception technique, le développement, l'hébergement et la mise en ligne.

Ce que nous avons construit

Un site public et un back-office découplés : d'un côté le site, rendu côté serveur et servi par un CDN européen ; de l'autre le CMS Payload (open source, TypeScript, PostgreSQL), avec une administration entièrement en français et une API GraphQL typée entre les deux.

Côté visiteur : un accueil avec bandeau d'actualité et prochains événements, une page de présentation du lieu, les services, les fiches des intervenant·es (« rencontres pro »), la programmation des ateliers, une page Explorer qui rassemble articles, documents, vidéos et audios par catégorie, le contact, la déclaration d'accessibilité et les mentions légales.

Payload CMS : un back-office qui porte les règles du projet

• Tout le contenu vit dans Payload : annonces du bandeau, coordonnées et horaires, événements, activités permanentes, intervenant·es, ressources, articles (avec brouillons et enregistrement automatique), médias.
• Le schéma est du code TypeScript versionné, les migrations PostgreSQL sont jouées au déploiement, et le site consomme l'API GraphQL via des types générés : un champ renommé dans le CMS devient une erreur de compilation côté site, pas une page cassée en production.
• Les contraintes éditoriales sont dans l'outil : texte alternatif demandé à chaque image (un champ vide vaut déclaration d'image décorative, au sens du critère RGAA 1.2), recadrage et point focal dans l'admin, déclinaisons WebP et AVIF générées à chaque largeur, visuel Open Graph 1200 × 630 produit automatiquement, aperçu flou inliné dans la page. Sur les fichiers téléchargeables, une liste de contrôle et une case « accessibilité vérifiée » avant publication.
• Open source et auto-hébergé, code livré au client : pas de licence, pas de verrou.

Une programmation synchronisée avec Linscription.com, sans API

Les inscriptions aux ateliers passent par Linscription.com, qui n'offre ni API ni flux. Plutôt que de ressaisir chaque séance, une tâche planifiée dans Payload lit chaque jour le catalogue public, crée un événement par séance (une activité hebdomadaire devient une fiche par date), supprime ce qui a disparu et purge le cache du CDN une seule fois en fin de passage. Si la lecture échoue, la tâche échoue bruyamment et la base garde les données de la veille. L'équipe ne saisit à la main que ce que le catalogue n'expose pas, comme les activités permanentes du type « tous les mardis ».

Chaque séance sort en données structurées Event (date, horaire, lieu, lien d'inscription) : la page Programmation en porte aujourd'hui 58, exploitables par Google pour ses résultats enrichis.

Performance : supprimer les causes plutôt que rattraper un score

Mesures Lighthouse sur la page d'accueil en production, le 20 août 2026, en mobile simulé : performance 99, accessibilité 100, SEO 100 ; LCP 1,7 s, TBT 10 ms, CLS 0 ; 28 requêtes et 760 Ko au total, polices comprises, pour une seule origine et zéro script tiers. Sur ordinateur : performance 97, LCP 0,8 s, TBT 0 ms. Le score de performance varie d'une passe à l'autre, c'est inhérent à l'outil ; les constats stables sont ceux qui comptent : aucun décalage de mise en page, un fil principal quasi libre, aucune requête vers un tiers.

• Rendu serveur et cache CDN longue durée, purgé à la demande. Les pages sont mises en cache un an sur le CDN ; chaque publication dans Payload déclenche une purge, et la page suivante est reconstruite puis remise en cache. Le visiteur reçoit du HTML complet depuis un nœud proche de lui.
• Polices auto-hébergées avec un repli aux métriques recalées. DM Sans, Bricolage Grotesque et Selfie Printed sont servies par le site ; une police de repli locale est ajustée (size-adjust, ascent-override, descent-override) pour occuper exactement la même place, si bien que le texte ne bouge pas à l'arrivée de la vraie police. Sur la page Programmation, c'est ce qui ramène le CLS de 0,27 à moins de 0,05.
• Images responsives : déclinaisons AVIF et WebP par largeur, srcset, dimensions intrinsèques, priorité de chargement sur l'image principale, chargement différé ailleurs.
• Pas de poids inutile : pas de tag manager, pas de pixel, pas de police distante, pas de bibliothèque UI lourde ; 145 Ko de JavaScript pour toute la page d'accueil.
• La mesure fait partie du projet : un script Lighthouse multi-passes dans le dépôt relève médiane et dispersion sur les neuf gabarits du site, pour distinguer une vraie régression du bruit de mesure.

Zéro service tiers dans le navigateur, donc pas de bandeau de cookies

Vérifié sur la production : aucun cookie déposé, aucune requête vers un domaine tiers au chargement des pages. Concrètement :

• La mesure d'audience repose sur Umami, auto-hébergé sur notre cluster et servi depuis le domaine du site : pas de cookie, pas d'identifiant persistant, pas de croisement entre sites.
• Polices et scripts sont servis par le site lui-même : pas de Google Fonts, pas de CDN JavaScript public.
• Les vidéos intégrées dans les articles (YouTube, Vimeo, Dailymotion) sont des façades : le lecteur et ses traceurs ne se chargent qu'au clic, en mode sans cookie quand la plateforme le permet, avec une transcription textuelle dépliable dessous.
• Le formulaire de contact est traité côté serveur, sans service de formulaire externe ni captcha tiers.
• Hébergement sur notre cluster Kubernetes Scaleway à Paris, médias sur Object Storage Scaleway, CDN Bunny, base PostgreSQL : les données restent dans l'Union européenne.

Rien ne relève du consentement, donc rien à afficher : le site est lisible dès le premier pixel, sur mobile comme sur ordinateur.

Accessibilité : conforme RGAA 4.1, déclaré et outillé

Notre équipe compte une auditrice accessibilité certifiée (Access42, Opquast). Le site a été audité en interne sur les critères du RGAA 4.1 (axe-core : 0 violation sur les dix pages auditées) et déclaré totalement conforme ; la déclaration d'accessibilité est en ligne. Navigation clavier complète, focus visibles, hiérarchie de titres, liens « nouvelle fenêtre » annoncés, transcriptions sous les vidéos et audios, respect de la préférence de réduction des animations, et un bouton « Options d'accessibilité » sur toutes les pages : agrandir le texte, police adaptée à la dyslexie, contrastes renforcés, pause des animations.

Un détail qui ne se voit pas : les fonds texturés « papier » de la maquette ont été retraités pixel par pixel pour garantir un contraste d'au moins 4,5:1 au texte blanc sur chaque point de l'image, sans que la texture change visiblement. Lighthouse accessibilité : 100 sur chaque page mesurée.

SEO : une refonte sans perte

• Inventaire de l'ancien site depuis les archives du web : 2 028 URL archivées, 622 chemins de contenu, 169 encore en ligne au 1er août 2026, tous redirigés en 301 vers la section équivalente du nouveau site, jamais en masse vers l'accueil.
• Canonique, balises Open Graph, sitemap et robots générés ; données structurées Organization et LocalBusiness avec horaires, WebSite avec action de recherche, Event sur la programmation, fil d'Ariane sur les fiches.
• Du contenu que l'équipe fait vivre : fiches intervenant·es, ressources et articles alimentent la page Explorer, socle d'une stratégie éditoriale sur l'orientation et la reconversion professionnelle à Rennes.

La stack technique

• Site : TanStack Start (Vite, Nitro, React 19), TypeScript strict, Tailwind CSS 4, GraphQL avec types générés, Vitest
• CMS : Payload 3, PostgreSQL, stockage S3, éditeur Lexical, tâches planifiées, migrations versionnées
• Infrastructure : images Docker construites en CI, déploiement continu par Flux sur Kubernetes Scaleway (Paris), CDN Bunny, Umami auto-hébergé, supervision des erreurs du back-office avec Sentry
• Qualité : ESLint strict et typé (dont jsx-a11y), Prettier, vérification en CI de la dérive entre schéma CMS et types du site

Le résultat

Un site que l'équipe de L'Exploratoire administre seule, depuis la programmation jusqu'aux médias, sans toucher au code. Entièrement hébergé en France, sans bandeau de cookies, déclaré conforme RGAA 4.1, avec des scores Lighthouse à 100 en accessibilité et en SEO et une page d'accueil qui tient en moins de 800 Ko. Platane en assure l'hébergement et la maintenance.

Ce projet illustre ce que nous défendons pour un site vitrine public : un CMS open source que le client possède, des performances qui viennent de l'architecture plutôt que d'un rattrapage, et la souveraineté des données par défaut. Nos audits d'accessibilité RGAA et notre agence de Rennes sont au service de ce type de projets.