Une communauté d’entrepreneurs se compte facilement : tant de membres, tant de rencontres. Préserver une mémoire utile est plus difficile. Qui connaît qui ? Que fait cette personne aujourd’hui ? Qu’a-t-elle écrit à son inscription ? Qui a promis de reprendre la conversation après un événement ?
J’ai construit le CRM de Founders Dubai autour de ces distinctions. Une fiche membre n’est pas seulement un contact dans une liste. Elle relie les réponses initiales, les informations actuelles, les événements et les actions de l’équipe.
Ci-dessous, la fiche d’un membre fictif de Founders CRM : profil, entreprise et historique de participation. C’est un exemple de fiche de travail, pas un accès à la base de la communauté.
Fiche membre
Interface archivée · données de démonstration
Un questionnaire ne doit pas être réécrit après coup
Les réponses initiales sont conservées à part des informations actuelles modifiables. Une personne peut changer d’entreprise ou d’activité. L’organisateur doit actualiser la fiche, mais cela ne signifie pas que le membre avait initialement fourni cette nouvelle version.
Les changements ont un historique et un auteur. Les opérations prévues permettent d’annuler une modification tout en gardant la trace de ce qui s’est passé. C’est plus utile qu’un champ générique « dernière mise à jour » qui donne l’heure mais laisse chacun hausser innocemment les épaules.
Une tâche dans trois vues
La planification propose liste, kanban et diagramme de Gantt. Il est facile de créer trois belles applications qui divergent progressivement. Les vues travaillent donc sur des tâches et sous-tâches communes.
Les tâches de la même démo sont ouvertes sur le kanban. On peut voir leur répartition et les actions locales disponibles ; les vraies tâches de l’équipe ne changent pas.
Kanban de l’équipe
Interface archivée · données de démonstration
Une interface MCP privée donne accès aux opérations autorisées depuis ChatGPT. Le confort du langage courant s’arrête là où commence l’action concrète : bon projet, bon état et bons accès sont nécessaires. Une réponse « terminé » de l’assistant n’inscrit rien à elle seule dans le processus.
L’application principale utilise React et Vite, le serveur un Cloudflare Worker avec D1. Une Telegram Mini App donne au membre son profil et des fonctions limitées. Les informations des organisateurs ne doivent pas devenir communes parce que deux personnes ont ouvert le même lien.
Un même nom ne désigne pas forcément une même personne
L’écosystème comporte des services indépendants et d’anciennes données. Un nom ou identifiant Telegram identique ne suffit pas à fusionner automatiquement deux identités. Le découvrir après l’apparition de l’historique d’un autre sur une fiche serait particulièrement désagréable.
Transférer des fonctions entre systèmes et transférer des personnes sont donc deux tâches différentes. On peut réutiliser un composant éprouvé sans importer les permissions et informations d’autrui.
Le parcours de l’organisateur commence par une fiche membre puis continue avec les tâches communes. Questionnaire, informations actuelles et historique des modifications sont séparés pour que le présent ne réécrive pas le passé. L’article montre des fiches de démo, pas la base des membres.
Histoires liées : Site de la communauté Founders Dubai · Le studio et notre travail commun.
@nevsky_alexander
Sur Instagram, Dubaï au-delà de la carte postale : la famille, la ville, les trouvailles et la vie entre deux projets. Sur Threads, des réflexions à voix haute sur le design et l’IA. Sur YouTube, des vidéos qui ont besoin de plus de place qu’une story. Retrouvez-moi là où vous vous sentez bien, et gardons le contact