Le contexte
Une association vit sur des outils qui ne sont pas les siens : un groupe de discussion où les messages se perdent, une page de réseau social que tout le monde ne suit pas, un fichier de membres que seule une personne sait tenir à jour. Le besoin est toujours le même — un endroit unique, qui porte le nom de l’association — et le budget ne permet jamais de financer un développement dédié.
App Community Suite est la réponse que nous avons construite : une base applicative unique, déclinée en une application propre à chaque association.
L’enjeu
Le piège de ce type de produit est connu : à partir du deuxième client, la base se duplique. Chaque association demande un ajustement, on le fait « juste pour elle », et six mois plus tard il existe quatre applications différentes qu’il faut corriger quatre fois. Le produit est mort avant d’avoir été vendu.
Trois contraintes s’y ajoutent.
L’association doit être l’éditeur visible. Une association qui met une application dans les mains de ses membres ne veut pas voir le nom de son prestataire sur l’écran d’accueil. L’application porte son nom, son logo, ses couleurs, et sa propre fiche sur les magasins d’applications.
Un visiteur doit pouvoir regarder sans compte. Une application dont tout le contenu est derrière une invitation n’est pas promouvable : elle ne se partage pas, ne se référence pas, et se fait refuser en revue faute de contenu visible.
L’association choisit ce qui sort du cercle des membres. Ce n’est pas un réglage global mais un choix objet par objet — cet événement oui, cette galerie non — pris par des bénévoles qui n’ont reçu aucune formation.
Ce que nous avons fait
- Un back-end Django portant les membres, les événements, la galerie, la messagerie, les votes, les sondages, la trésorerie, la modération et les notifications, exposé en API REST commune à toutes les déclinaisons.
- Une séparation stricte entre le code métier et la déclinaison client. Le métier vit sur une seule branche ; chaque association n’a qu’un fichier de configuration et un dossier d’images. Un correctif écrit une fois se propage à toutes les déclinaisons par rebase, jamais par copier-coller.
- Une application Flutter unique pour iOS et Android, dont l’identité visuelle est lue dans la configuration plutôt qu’écrite dans les écrans.
- Une vitrine publique rendue côté serveur, pour que l’agenda, les actualités et la galerie soient consultables — et indexables — sans compte, avec un parcours d’adhésion qui ramène le visiteur vers une invitation validée par un responsable.
- Un outil d’administration web avec quatre niveaux de rôles et une file de modération, parce qu’un espace où les membres publient a besoin d’un endroit où l’on décide.
Le résultat
La première association est en production : son application est publiée sous son propre nom et ses membres l’utilisent au quotidien. Deux autres déclinaisons sont préparées sur la même base.
La leçon de ce produit tient en une phrase : la partie difficile n’est pas d’écrire la deuxième application, c’est la discipline qui interdit de l’écrire. Tout ce qui ressemble à un ajustement spécifique est d’abord examiné comme un besoin générique mal formulé — et la plupart du temps, c’en est un.
