Le défi
Ce que nous avons réalisé
Un seul back-office pour tout un réseau d’applications
Avec deux applications, on peut garder le contenu dans des fichiers à l’intérieur de chacune. Avec vingt-quatre, la moindre correction de texte devient une nouvelle version sur Google Play et une semaine d’attente.
Nous avons bâti une plateforme où le contenu vit à part des applications : un rédacteur le modifie dans l’administration, et les téléphones récupèrent le nouveau jeu tout seuls — sans mise à jour de l’application.
Chaque tuile est une application : combien d’éléments elle contient et quelle version de contenu est publiée.
L’application ne fait que lire
La décision d’architecture centrale est simple : le téléphone n’écrit rien dans la plateforme, sauf des événements anonymes. Il récupère le manifeste, récupère le jeu d’éléments dans sa langue, et c’est tout. Pas de comptes, pas de synchronisation, pas de conflits.
De ce fait, une nouvelle application se monte presque sans code : on crée une fiche dans l’administration, une clé est générée, on remplit rubriques et éléments, on appuie sur Publier — et la version de contenu augmente d’une unité. La clé et l’adresse sont inscrites dans l’application, qui fonctionne ensuite seule.
Vingt-quatre applications dans un seul tableau
Chacune a sa clé d’accès, son jeu de langues, sa version de contenu et son état. On voit ce qui est publié, ce qui est en cours et ce qui n’est encore qu’une idée. Ce n’est pas une vitrine : c’est la liste de travail depuis laquelle tout le réseau est piloté.
Des éléments de formes différentes
Une recette, un guide, une question de quiz, une carte de jeu, un code d’erreur, une devinette, un fait — chaque format a son propre formulaire d’édition, pas un unique champ « texte ». Cent éléments s’ajoutent par import : on colle un tableau, on choisit le type et la langue, et le système rend compte ligne par ligne — ce qui est passé, ce qui ne l’est pas et pourquoi.
Ne pas payer ce qui n’a pas changé
Le jeu d’éléments d’une application pèse des centaines de kilooctets. Le télécharger à chaque lancement n’a pas de sens : la réponse porte donc une étiquette de version, et si le téléphone a déjà le jeu à jour, le serveur répond « rien n’a changé » et n’envoie rien.
C’est là que se cachait le piège qui annulait l’économie : un proxy qui compresse les réponses réécrit l’étiquette dans sa forme « faible », et la comparaison stricte cesse de correspondre. Le téléphone retéléchargeait tout, à chaque fois. Il a fallu apprendre à la comparaison à accepter les trois formes de l’étiquette — stricte, faible et séparée par des virgules.
Des médias qui n’alourdissent pas l’application
Chaque image est convertie en WebP au téléversement et conservée en deux tailles : complète jusqu’à 1200 pixels et vignette jusqu’à 400. Le serveur les diffuse avec un cache long, et l’application reçoit des adresses prêtes — aucune conversion sur le téléphone.
Des statistiques sans données personnelles
Les applications envoient des événements anonymes — une ouverture, une navigation, une action. Aucun identifiant de personne, aucun contact. Cinquante événements au maximum par requête, et les lignes mal formées sont simplement écartées plutôt que de faire échouer l’appel entier.
À côté, la plateforme rassemble les chiffres du magasin d’applications et de la régie publicitaire — pour lire installations et revenus là où se trouve le contenu, et non dans trois consoles différentes.
Déroulé du projet
Sous le capot
Plateforme
Laravel avec une administration Filament. Elle vit sur un hébergement ordinaire : sans root, sans conteneurs, file et cache en base, images converties dès le téléversement.
API
Quatre points de lecture, une clé dans l’en-tête, des limites par clé et par adresse, une étiquette de version avec la réponse « rien n’a changé ». Les erreurs sont du JSON simple avec un code.
Coffre
Un espace distinct pour les builds et le matériel de boutique : icônes, captures, descriptions. Plus les renvois croisés entre les applications du réseau.
Le résultat
Un réseau de vingt-quatre applications où une correction de texte atteint l’utilisateur en minutes et non en une semaine. Une nouvelle application se monte dans l’administration en quelques minutes : créer, remplir, publier, coller la clé.
Et tout cela tourne sur un hébergement ordinaire — sans serveur dédié, sans files en mémoire et sans conteneurs, qu’on n’aurait de toute façon nulle part où lancer.
Un projet similaire ?
Discutons de vos objectifs et voyons comment nous pouvons vous aider.
Demander un devis gratuit →
