Application mobile communautaire 📱

Contexte

Application mobile communautaire pour les freelances d'une solution de portage salarial, sur le modèle de Circle.com. L'idée : réunir au même endroit ce qui était dispersé (fil d'actualité, agenda d'événements, annuaire des membres, discussions privées), avec les opportunités de mission affichées directement dans l'app plutôt que dans un outil séparé. Projet mené pendant mon stage IA & Automatisation chez Café Crème.

Le même code tourne sur iOS, Android et dans le navigateur. L'app est branchée sur l'API interne de production, qu'il a fallu étendre en parallèle : côté serveur, la messagerie, les espaces et le réseau de contacts n'existaient pas.

Fonctionnalités clés

• Connexion sans mot de passe (code à usage unique envoyé par email), jeton conservé dans le stockage sécurisé du téléphone.
• Feed social : publication texte et/ou image, modification et suppression de ses propres contenus, likes, commentaires et réponses imbriquées, tri récent ou pertinent.
• Événements : agenda groupé par jour, création et modification par l'organisateur, inscription et désinscription, sélecteur de date natif.
• Annuaire des membres et réseau de contacts : demander, accepter ou retirer une relation, écran dédié avec badge des demandes en attente.
• Messagerie privée entre deux membres : liste des conversations, fil de discussion, badge de messages non lus sur l'onglet.
• Espaces thématiques : créer un espace, le rejoindre, filtrer le feed dessus et y publier. Le feed sans filtre reste la communauté générale.
• Notifications push : l'appareil s'enregistre à la connexion, le serveur déclenche les envois (événements, relations, messages, rappels).

Approche technique

Le front est écrit en React Native avec Expo et TypeScript, la navigation en expo-router (routing par fichiers, dans l'esprit de Next.js). L'état serveur passe par TanStack Query, les appels par une instance axios avec intercepteur qui injecte le jeton : seul un 401 déconnecte, un 403 signifie « action non autorisée » et ne casse pas la session. Le jeton vit dans expo-secure-store sur mobile, avec repli sur le stockage local en web. Le code est organisé en couches (types, api, hooks, composants, écrans) et le style repose sur une petite couche de tokens maison (espacements, rayons, typographies, ombres compatibles web et natif) plutôt que sur une librairie d'UI.

Côté serveur, l'API interne suit une architecture hexagonale (contrôleur, commande, cas d'usage, port de dépôt, adaptateur PostgreSQL). Je l'ai étendue en respectant ce découpage pour ajouter la messagerie (conversation et message), les espaces thématiques, le réseau de contacts et l'upload d'images. Sur ce dernier point, la chaîne complète part de l'app : expo-image-picker choisit une photo, un envoi multipart la dépose sur un stockage cloud et renvoie son URL publique, que la publication réutilise ensuite.

Un arbitrage assumé : l'API existante n'a pas de temps réel. Plutôt que d'introduire des WebSockets pour un premier jet, la messagerie se rafraîchit par polling via refetchInterval (quinze secondes sur la liste des conversations, cinq secondes sur une conversation ouverte). C'est documenté comme une étape, pas comme une cible.

Le multi-plateforme a demandé quelques adaptations : une confirmation générique à la place des alertes à boutons (absentes en web), un bouton retour explicite sur les écrans de détail, des ombres déclinées en boxShadow ou en elevation selon la plateforme. Pour le push, l'app récupère le jeton natif de l'appareil et l'enregistre côté serveur ; comme le vrai push demande un build de développement EAS, l'enregistrement échoue silencieusement dans le client Expo Go sans jamais bloquer le reste. Les profils de build EAS (développement, aperçu, production) sont en place.

Résultats

Une application fonctionnelle sur les trois plateformes, branchée sur l'API de production et couvrant les quatre piliers prévus au cadrage : missions, feed social, événements, entraide (messagerie et espaces). Le travail a autant porté sur le mobile que sur l'extension du backend, la moitié des fonctionnalités communautaires n'ayant aucun équivalent côté serveur au départ.

Un seul écran reste en démonstration, le suivi des candidatures, faute d'endpoint côté serveur : il est signalé comme tel dans l'interface plutôt que masqué.

Le code source n'est pas public (projet d'entreprise).