Stadium Traveller — plateforme communautaire, PWA et 14 000 pages référencées

Le point de départ

Une startup, une communauté internationale — les groundhoppers, ces voyageurs qui collectionnent les stades visités — et rien sur le marché pour la servir. Ni réseau social généraliste, ni CMS, ni application de voyage : il fallait un produit, avec sa base de 2 500 stades, sa carte, ses comptes et ses règles propres.

Le projet est parti d'une page blanche, à Strasbourg. Pas de thème acheté, pas de framework, pas de brique louée au mois : chaque écran a été dessiné et codé pour cet usage-là.

Ce que la plateforme fait, concrètement

• 2 500 stades documentés, cartographiés et consultables.
• Comptes utilisateurs — profil, visites enregistrées, listes de souhaits.
• Voyages — création d'itinéraires, stades à visiter, partage avec la communauté.
• Messagerie et fil social — discussions, échanges, réactions.
• Actualités, événements et partenariats, publiés depuis le back-office.
• Notifications push, jusque sur l'écran verrouillé du téléphone.

Le tout dans une seule application web, sans version à installer séparément sur chaque système.

La PWA, en clair

Une PWA — progressive web app, application web progressive — est un site qui s'installe comme une application : icône sur l'écran d'accueil, ouverture en plein écran, fonctionnement conservé quand le réseau faiblit, et notifications push. Sans passer par l'App Store ni le Play Store.

Pour une startup, l'intérêt est autant financier que technique : une seule base de code au lieu de trois (web, iOS, Android), aucune commission de magasin d'applications, aucune validation à attendre pour publier un correctif, et une mise à jour qui arrive chez tous les utilisateurs le même jour.

Les notifications push, sans application native

Une notification push part du serveur et s'affiche sur le téléphone même quand le site est fermé : un membre vous suit, un stade de votre liste accueille un événement, votre voyage approche. C'est le mécanisme qui fait revenir une communauté — celui qui manque à un site classique, où l'on ne revient que si l'on y pense.

Techniquement, un service worker écoute en arrière-plan. L'utilisateur donne son accord une fois et peut le retirer quand il veut : rien n'est envoyé sans consentement, et chaque envoi est traçable.

La carte, les clusters et le calcul GPS

Afficher 2 500 points sur une carte sans la rendre illisible demande du travail. Les stades sont regroupés en clusters qui se déplient au zoom, la position de l'utilisateur est prise en compte, et les distances sont calculées pour répondre à la seule question qui compte sur le terrain : qu'est-ce qu'il y a autour de moi, et à quelle distance ?

La même mécanique sert un réseau de points de vente, un parc de bornes ou une flotte d'équipements : le sujet change, le problème d'affichage est identique.

Les parkings, branchés sur l'open data de Strasbourg

Autour du stade strasbourgeois, la plateforme affiche les parkings : emplacement, caractéristiques, informations publiées par la collectivité. Rien n'est saisi à la main — les données viennent des données ouvertes de l'Eurométropole de Strasbourg, interrogées automatiquement et remises en forme sur la carte.

C'est tout l'intérêt de l'open data : une collectivité publie, un outil exploite, l'utilisateur y gagne un service que personne n'a eu à ressaisir ni à maintenir. La même mécanique s'applique à n'importe quel jeu de données publiques — transports, horaires, équipements, subventions.

Un back-office de plus de 80 options

Tout se pilote sans développeur : la base des stades, les contenus, les actualités, les événements, les partenariats, les comptes, la modération, les notifications, les traductions et le référencement. Plus de 80 options de gestion, ajoutées au fil des besoins réels — jamais par anticipation, jamais pour remplir une grille de fonctionnalités.

C'est ce qui permet à une équipe réduite de faire tourner un produit dont le catalogue se compte en milliers d'entrées.

Des dizaines d'idées, toutes intégrées

C'est ce qui sépare un produit d'un site. Sur plusieurs années, la plateforme a reçu des dizaines et des dizaines de demandes : une nouvelle façon de trier les stades, un champ qui manquait, une notification à déclencher autrement, un écran à repenser, une règle communautaire à durcir. Toutes ont été étudiées, validées et intégrées.

Aucune n'a buté sur « ce n'est pas prévu par le logiciel », parce qu'il n'y a aucune solution du marché en dessous : il n'y a que du code écrit ici, qu'on peut plier à l'idée du jour. C'est très exactement ce qu'on achète quand on fait faire du sur-mesure.

14 000 pages, quatre langues, première page mondiale

Une base de 2 500 stades produit un volume qu'aucune rédaction humaine ne tiendrait : plus de 14 000 pages, en quatre langues. Chacune doit être unique, utile et correctement balisée — sinon elle devient un duplicata qui tire tout le site vers le bas.

Résultat : plus de 30 % des stades ressortent en première page mondiale, à côté de Wikipédia, et devant le site officiel du club sur une partie d'entre eux. Sur des requêtes où le concurrent n'est pas une entreprise mais une institution.

La même méthode s'applique à tout catalogue : SEO et visibilité IA.

Lauréat Tango & Scan 2023

Le projet a remporté le Tango & Scan 2023. Ce qui se joue derrière ce type de plateforme n'est pas un site : c'est un produit qui doit tenir en même temps la charge, la communauté, la modération, la cartographie et le référencement — et continuer d'évoluer une fois lancé.

Le service correspondant : applications métier et plateformes sur mesure. Pour une startup, l'entrée se fait presque toujours par un premier périmètre réduit et chiffré : méthode et tarifs.