# Mises à jour de l'app (OTA) — guide simple

> But : modifier l'app et l'envoyer aux téléphones **sans rebuild ni store**,
> en quelques secondes. Réservé aux changements **JS/TS** (écrans, textes,
> logique). Un changement **natif** (permission, module natif) demande un vrai
> build — voir tout en bas.

## L'image à retenir

Pense à un **site web** : tu modifies le code, tu « publies », les visiteurs
voient la nouvelle version au prochain chargement. Ici c'est pareil :
- `npm run update:test` / `update:prod` = **tu publies**.
- L'app, **à chaque ouverture**, va voir s'il y a du neuf et se met à jour seule.

## Les 2 groupes de téléphones (channels)

On a configuré 2 « canaux » = 2 publics distincts :

| Canal | Pour qui | Build qui le reçoit |
|---|---|---|
| **preview** (test) | toi + testeurs | APK fait avec `npm run build:test` |
| **production** | les techniciens | APK fait avec `npm run build:prod` |

Un téléphone reçoit les updates **du canal de son APK**. Donc tu pousses sur
`preview` pour tester tranquille, et seulement quand tu es sûr, tu pousses sur
`production` pour tout le monde. **Tester ne dérange jamais les techniciens.**

## Ton quotidien (90 % du temps)

1. Tu modifies du code (un texte, un écran, la logique des notifs…).
2. Tu testes en local : `npm start` (app Expo Go / dev).
3. Quand c'est bon, tu publies aux **testeurs** :
   ```bash
   npm run update:test
   ```
   (il demande un petit message, ex. « corrige libellé bouton » — tape-le, Entrée.)
4. Tu vérifies sur ton téléphone de test (rouvre l'app → la MAJ se télécharge).
5. Content ? Tu publies aux **techniciens** :
   ```bash
   npm run update:prod
   ```

C'est tout. Quelques secondes, pas de queue, pas de store.

## Les 4 commandes (mémo)

| Commande | Ce que ça fait | Fréquence |
|---|---|---|
| `npm run update:test` | publie ta modif aux **testeurs** | souvent ⚡ |
| `npm run update:prod` | publie ta modif aux **techniciens** | quand validé |
| `npm run build:test` | refait un **APK de test** (rare) | si natif |
| `npm run build:prod` | refait l'**APK techniciens** (rare) | si natif |

## Quand un simple `update` NE suffit PAS (→ rebuild)

Une update OTA ne peut pas changer la coque native. Il faut **rebuild** (donc
`npm run build:*`, ou ta CI GitLab) si tu :
- ajoutes/retires une **permission** ou un **plugin/module natif** ;
- modifies la partie **native** d'`app.json` (icône, package, splash…) ;
- changes la **version** de l'app (`version` dans `app.json`).

Dans ces cas : 1 rebuild + réinstall, puis tu repars en OTA pour la suite.

> Détail technique : les updates ne s'appliquent qu'aux builds de **même
> `runtimeVersion`** (ici basée sur `version` = `1.0.0`). Si tu bumps la version,
> il faut un nouveau build pour que les updates de la nouvelle version arrivent.

## Récap mental

- **Code JS changé** → `npm run update:test` → (vérif) → `npm run update:prod`. Secondes.
- **Natif changé** → `npm run build:*` (ou CI GitLab) → réinstall → puis OTA.
- 3 serveurs distincts : EAS Update (le code de l'app) ≠ Expo Push (les notifs) ≠ ton backend (les données).