Une interface simple, des règles qui tiennent

Un lieu public. Une durée choisie. Deux participants. L’application permet de proposer ou de rejoindre une activité près de soi, sans parcourir des photos ou des biographies. Derrière ce format volontairement réduit, nous construisons un produit qui doit gérer une place unique, des horaires, des connexions interrompues et des informations qui ne doivent pas être visibles de tous.

Le contexte

Prendre un café, marcher, visiter une exposition : le point de départ est une activité et une disponibilité communes. Une personne propose, une autre rejoint. Elles se découvrent sur place.

Le produit est conçu et développé par Scopes, depuis Montpellier. Le travail couvre la conception du parcours, l’application iOS et Android, les services métier, l’administration et le site de présentation. La contrainte est de garder l’expérience lisible tout en traitant les situations moins visibles : deux personnes réservent au même instant, une réponse réseau arrive après une déconnexion, un rendez-vous expire pendant qu’une requête attend.

Ces situations déterminent l’architecture autant que les écrans.

Modéliser le parcours avant de multiplier les écrans

Le cycle d’une proposition est décrit par des états et des transitions explicites : publication, réservation, arrivée, annulation, expiration. Les règles sont regroupées dans un module TypeScript indépendant du réseau et de la base de données. Il reçoit l’identité de l’acteur et l’heure fournie par le serveur, puis décide si l’action est possible.

Cette séparation permet de vérifier une règle à la milliseconde près sans lancer l’application. Elle évite aussi qu’un écran, une route HTTP et un traitement automatique interprètent différemment la même situation.

L’API repose sur Fastify et PostgreSQL. Le choix d’un monolithe modulaire garde les opérations métier dans une même transaction et limite le nombre de services à exploiter. Les contrats de validation sont partagés avec les clients ; les accès SQL restent côté serveur.

Garantir la place unique

Si deux personnes appuient sur « Rejoindre » simultanément, une seule doit obtenir la place. La décision est prise dans une transaction PostgreSQL qui verrouille la proposition concernée. La deuxième demande relit donc un état déjà réservé.

L’heure est vérifiée après l’obtention du verrou : attendre une transaction ne doit pas permettre de rejoindre une activité dont le début est passé entre-temps.

La création traite également les reprises réseau. Chaque demande porte une clé qui permet de reconnaître sa répétition. Si la première création a réussi mais que sa réponse s’est perdue, la nouvelle tentative retrouve la même proposition. Elle ne publie pas une deuxième activité. Ces comportements sont testés avec des transactions concurrentes dans une véritable base PostgreSQL.

Chercher autour de soi, à sa demande

L’application utilise React Native et Expo, avec une carte native comme point d’entrée. La personne choisit une zone, un rayon de recherche et des contraintes de temps et de durée. PostGIS effectue la recherche géographique côté serveur, avec des distances exprimées en mètres.

La localisation est demandée par une action explicite. Une zone peut aussi être choisie manuellement. Déplacer la carte ne déclenche pas systématiquement une nouvelle requête : l’utilisateur confirme la recherche dans la zone affichée. Le parcours n’a pas besoin de suivre ses déplacements en arrière-plan.

Faire respecter la confidentialité par l’API

La connexion repose sur un numéro de téléphone et un code de vérification. Le parcours n’exige pas de photo, de biographie ou d’identité civile à présenter aux autres participants. Cela ne rend pas le service anonyme : des données de compte et de participation restent nécessaires à son fonctionnement.

Sur place, chacun peut renseigner un signe du moment, par exemple « sac à dos jaune ». Les deux signes sont révélés après les deux déclarations d’arrivée. Cette règle est appliquée dans les réponses du serveur : masquer un champ à l’écran ne suffirait pas. La liste des activités ne contient pas ces informations.

Les sessions sont révocables et leurs jetons sont conservés sous forme d’empreintes en base. Côté mobile, les réponses asynchrones sont rattachées à la session qui les a demandées. Une ancienne requête ne doit pas réafficher des données après un changement de compte.

Prévoir l’exploitation dès la construction

Le support dispose d’une interface interne distincte de l’application mobile, avec son propre serveur, son authentification et un rôle SQL dédié. Les demandes peuvent être suivies, affectées, résolues puis rouvertes lorsqu’un utilisateur apporte un complément.

Les actions sensibles sont historisées. Les versions des dossiers permettent de détecter une modification devenue périmée, par exemple lorsque deux intervenants travaillent sur le même sujet. Les nouvelles tentatives après une coupure réseau sont également prises en compte.

Le développement avance par fonctionnalités complètes : règles métier, API, persistance, interface, puis vérification du parcours. Les tests unitaires couvrent les décisions ; les tests d’intégration vérifient les contraintes de base de données ; les essais d’interface mettent à l’épreuve les erreurs, les reprises et les déconnexions. Les scénarios utilisant des fournisseurs simulés restent distingués des essais sur de vrais services et appareils.

Ce qui reste

Le projet dispose d’un parcours de création et de participation implémenté, d’une recherche géographique, de règles de confidentialité testables et d’un outil de support. La suite du développement porte notamment sur les notifications, la qualification des intégrations externes et des parcours sur appareils physiques, ainsi que l’affinement de l’interface avant la distribution mobile.

Le site de présentation du produit est déjà public. Il est généré en HTML statique dans les 24 langues officielles de l’Union européenne. Son animation synchronise deux téléphones pour expliquer le parcours ; elle constitue une représentation du produit, pas une capture de l’application native. Le site fonctionne sans traceur publicitaire ni outil d’analytics côté visiteur.

L’application mobile reste en développement au moment de cette rédaction. Nous ne présentons donc pas encore de résultats d’usage ou de déploiement à grande échelle. Le travail documente une exigence plus immédiate : rendre un geste simple pour l’utilisateur sans laisser ses règles au hasard du réseau, de l’horloge ou de l’interface.

Fiche technique

Technologies mobilisées : TypeScript, React Native, Expo, Fastify, PostgreSQL, PostGIS, React et Vite pour l’administration, Vitest et Docker. Site statique HTML, CSS et JavaScript, génération Node.js et hébergement Railway.

Périmètre : conception produit, architecture, développement mobile et serveur, administration, tests et site multilingue.

Statut : produit Scopes, application mobile en développement en 2026. Le nom du produit est retiré de cette note ; il se partage sur demande.

Vous préparez une application mobile avec des règles métier qui ne doivent pas dépendre du réseau ? Scopes conçoit et développe des applications iOS et Android depuis Montpellier : voir notre page développement mobile à Montpellier ou décrire votre contexte.