Splaze, un profil unique
pour trois plateformes
Réunir les jeux, les trophées et les succès d'un joueur venus de PlayStation, Steam et Xbox dans un seul profil, sur le web comme sur mobile. Quatre surfaces, une seule source de vérité.
Voir Splaze en ligne Parler d'un projet
- Rôle
- Développeur produit, au sein de l'équipe
- Surfaces
- Site public, back-office, application iOS, application Android
- Technologies
- Next.js, Swift, Kotlin, Supabase, PostgreSQL, Node
- État
- En production, plus de 1 800 joueurs inscrits
- En ligne
- splaze.fr
Une progression qui
n'existe nulle part
Un joueur possède rarement une seule machine. Sa bibliothèque se répartit entre une console, un PC et parfois une deuxième console, et chaque écosystème garde jalousement ses données.
PlayStation compte ses trophées, Steam ses succès, Xbox ses points. Les trois utilisent un vocabulaire différent, un rythme de mise à jour différent et une définition différente de ce qu'est « terminer » un jeu. Résultat : quinze ans de parties existent en trois morceaux, et nulle part en entier.
Splaze répond à ce manque. Un seul profil rassemble la bibliothèque complète, la progression réelle par jeu, la comparaison avec ses amis et le partage. Ce qui paraît simple vu du visiteur suppose, derrière, de faire parler ensemble trois sources qui n'ont pas été conçues pour cela.
Quatre surfaces,
un seul produit
Je travaille sur l'ensemble du produit, du rendu d'un écran mobile jusqu'aux traitements serveur qui tournent sans personne devant.
- Le site public en Next.js : profils, bibliothèques, pages de jeux, comparaisons, tout ce qui doit être indexable et rapide au premier affichage
- Le back-office, également en Next.js : administration du catalogue, des comptes et de ce qui part en production
- L'application iOS en Swift, native, avec les composants et les gestes attendus sur la plateforme
- L'application Android en Kotlin, native elle aussi, publiée sur le Google Play Store
- Les traitements serveur en Node : synchronisation continue des comptes de jeu, alimentation de la base PostgreSQL derrière Supabase
Le choix du natif sur mobile n'est pas un réflexe. Une application qui affiche des milliers de vignettes, garde une bibliothèque consultable hors connexion et se rafraîchit en tâche de fond travaille sur le terrain où les couches intermédiaires coûtent le plus cher. Deux bases de code séparées demandent plus de discipline, mais donnent un produit qui se comporte comme le système sur lequel il tourne.
La synchronisation,
pas l'interface
Sur ce genre de produit, la difficulté n'est presque jamais l'écran. Elle est dans ce qui se passe entre deux écrans.
Chaque plateforme expose ses données à sa façon : formats, identifiants, granularité, fraîcheur. Un même jeu peut porter trois noms, trois identifiants et trois listes de succès qui ne se recouvrent pas exactement. Rapprocher tout cela demande un travail de correspondance qui ne se voit pas et qui conditionne pourtant la confiance du joueur : si sa progression est fausse, le produit est mort.
La synchronisation tourne en continu, côté serveur, sans intervention. Elle doit rester rejouable sans dupliquer, reprendre après une coupure, et absorber le fait qu'une source soit temporairement indisponible sans mettre le profil entier en défaut. C'est cette partie invisible qui occupe la plus grande part du travail.
Une base de code
partagée
Je ne suis pas seul sur Splaze. Le produit avance au sein d'une équipe, sur une base de code commune, avec des choix arbitrés à plusieurs et un suivi partagé de ce qui part en production.
C'est une dimension que je tiens à afficher, parce qu'elle ne s'improvise pas. Écrire du code que quelqu'un d'autre reprendra, défendre une décision technique devant des personnes qui ne partagent pas votre intuition, accepter d'en abandonner une, tenir une convention même quand elle vous ralentit sur le moment : rien de tout cela n'apparaît quand on travaille seul.
Pour un client, cela change une chose concrète. Un projet livré par mes soins n'est pas un objet personnel illisible par le suivant. Il est écrit pour être repris.
En production,
sur trois magasins
Splaze compte plus de 1 800 joueurs inscrits. Les deux applications mobiles sont publiées : l'une sur l'App Store, l'autre sur le Google Play Store, avec tout ce que cela suppose de conformité, de fiches, de captures, de politiques de confidentialité et de cycles de validation.
Passer la revue d'Apple et celle de Google n'est pas une formalité. C'est une compétence en soi, faite de règles écrites nulle part au même endroit, et c'est souvent là que les projets mobiles s'enlisent. Je l'ai faite, deux fois, sur deux plateformes.
Ce qu'on me
demande ensuite
- Pouvez-vous faire la même chose pour mon produit ?
- Si votre projet suppose un site, un back-office et une ou deux applications mobiles qui partagent les mêmes données, oui : c'est exactement la forme de Splaze. Voir la page développeur d'application mobile pour le cadre et les tarifs.
- Natif ou React Native ?
- Cela dépend du produit. Une application riche en interactions, en affichage de listes longues ou en fonctionnement hors connexion gagne au natif. Une application de contenu, publiée vite sur les deux magasins avec un budget contenu, gagne au multiplateforme. Je pratique les deux et je vous dis lequel sert votre cas, pas lequel m'arrange.
- Combien de temps pour une application publiée ?
- Comptez huit à quatorze semaines entre le cadrage et la mise en ligne sur les magasins pour une première version sérieuse, revue Apple et Google incluses. Le simulateur donne une fourchette en trente secondes.
- Qui possède le code ?
- Sur mes missions client, vous. Le code source est livré sur votre dépôt Git à la fin du projet, sans dépendance à un compte que je contrôlerais.
Voir aussi
Un produit web
et mobile ?
Le simulateur donne une fourchette en trente secondes, sans inscription. Elle part avec votre message si vous décidez de m'écrire, et je réponds sous 24 heures ouvrées.