Aller au contenu

Onboarding

À lire en premier. Ce qu'est Feelbat, comment le lancer, et où aller ensuite.

Qu'est-ce que Feelbat ?

Feelbat est une application IoT B2B de surveillance structurelle / de bâtiments. Les clients déploient des capteurs physiques sur des structures — pour surveiller fissures, inclinaison, vibration, nappe phréatique, humidité et luminosité —, les organisent en Projets, puis suivent mesures, seuils et alertes depuis leur téléphone.

Les données des capteurs atteignent l'application de deux façons :

  • Bluetooth LE — sur site, le téléphone est directement connecté au capteur.
  • Sigfox / LTE via une Gateway — à distance, le capteur remonte ses données de façon autonome, sans téléphone présent.

Un portefeuille de crédits / tokens (Stripe) monétise les fonctionnalités premium et la connectivité.

Objets de domaine principaux

Concept Description
Sensor Un appareil physique. Les types autorisés proviennent de REACT_APP_ALLOWED_SENSORS (JC1, JC2, DELTR, DELTA, DELTXP). Chaque type mesure des grandeurs différentes — DELTR → inclinaison/température, DELTA/JC1 → mouvement de fissure, JC2 → cisaillement/décalage, DELTXP → nappe phréatique, DELTX_H → humidité. Les capteurs DeltaV font aussi de la vibration/PPV (voir la feature changeMode). Les écrans de détail diffèrent entre capteurs électroniques (SensorElecDetail) et mécaniques* (SensorMecaDetails).
Project Conteneur de plus haut niveau regroupant capteurs, plans (positions des capteurs sur une carte), seuils et alertes. Peut être partagé avec d'autres utilisateurs et archivé. Possède un niveau (BASIC vs EXPERT_1) qui conditionne les fonctionnalités avancées. Les préférences d'unité d'affichage se définissent par projet (voir unitPreference).
Gateway Un appareil FEELBOX qui relaie les données des capteurs sur le réseau afin qu'ils remontent sans téléphone. Scan → enregistrement → association des capteurs.
Mesure / seuil Valeurs temporelles avec niveaux d'alarme min/max (Thresholds), un intervalle de mesure (MeasurementInterval, WakeUpTimes), tracées sous forme de graphiques (Charts, QuickLookValues).
Portefeuille / crédits Les utilisateurs achètent des crédits et des consommables (comptes typés, ex. connectivité SIGFOX/Linkfeel, PROJECT_EXPERT_1) dépensés pour débloquer fonctionnalités et connectivité (Wallet, Cart, OurOffers, PurchaseToken, Payment Stripe).
Mode expert Un projet est BASIC par défaut ; débloquer EXPERT_1 (gratuit avec un consommable PROJECT_EXPERT_1, sinon payé depuis le portefeuille) active les analyses avancées (UnlockExpert, ExpertBadge).
Linkfeel L'abonnement / crédit de connectivité Sigfox d'un capteur (possède une token_validity ; consommé comme un crédit SIGFOX).

Prérequis

  • Node 20, Yarn, Ruby + Bundler (Fastlane/CocoaPods), Xcode (iOS), Android Studio + SDK.
  • Un fichier .env.* pour l'environnement ciblé (voir release-process.md).
  • Des identifiants Mapbox (~/.netrc et/ou MAPBOX_DOWNLOADS_TOKEN) — voir troubleshooting.md.

Installation initiale

yarn install                 # exécute aussi postinstall : pods, permissions, patch-package
cd ios && pod install        # si postinstall ne l'a pas déjà fait
yarn setup-sdk               # écrit android/local.properties (chemin macOS — à adapter si besoin)

Lancer l'application

Chaque commande nécessite un environnement (ENVFILE) :

yarn start:development       # démarre Metro (réinitialise le cache)
yarn ios:developement        # lance sur le simulateur iOS   (noter l'orthographe)
yarn android:development     # lance sur l'émulateur Android

Autres environnements : :staging, :local, :prod.

Lancer les vérifications

yarn lint          # eslint src/
yarn typecheck     # tsc --noEmit
yarn test          # suite unitaire jest
yarn depcruise     # règles d'architecture

Detox (E2E) : voir testing.md.

Fonctionnement de l'application (le modèle mental en 60 secondes)

  1. App.tsx monte Redux (persisté) → Apollo → Theme → Navigation. Voir architecture.md.
  2. L'authentification est réactive : le token persisté dans Redux décide si l'utilisateur voit l'application authentifiée ou le parcours Login/Register. Aucun reset de navigation manuel à la connexion. Voir navigation.md.
  3. Les données sont offline-first : un flag online bascule Apollo entre réseau et cache-only ; les mutations faites hors ligne sont mises en file (deux files — un trackerLink Apollo générique et un syncManager métier) et rejouées à la reconnexion par HandleSyncMutationOnline. Voir architecture.md.
  4. Toute nouvelle fonctionnalité va dans src/features/ sous forme de module autonome à API publique restreinte, et non dans un nouveau sous-arbre de screens/.

Où aller ensuite

Je veux… Lire
Comprendre la structure et le flux de données architecture.md
Ajouter/modifier un écran ou une route navigation.md
Écrire du code à la manière de l'équipe coding-rules.md
Écrire ou lancer des tests testing.md
Comprendre la CI / ouvrir une PR ci-cd.md
Publier un build release-process.md
Se débloquer troubleshooting.md
Comprendre le « pourquoi » des décisions ADR
Construire un nouveau module de feature changeMode & unitPreference comme références