rentoo

Déploiement

Pour Pierre-Louis, sous Windows, dans PowerShell, depuis le dossier RENTOO. Source : scripts/deployer.ps1, eas.json, app.json, et les anciens guides (archivés dans docs/archives/), en ne gardant que ce qui est encore vrai.

Mettre en ligne une nouvelle version

Une fois la mise en ligne automatique configurée (section suivante), GitHub s’en charge après chaque fusion sur master. Depuis le PC, une seule commande :

npm run deployer

Le script regarde ce qui a changé depuis la dernière mise en ligne et ne refait que le nécessaire. Il s’arrête au premier problème et dit quoi faire.

Avant de commencer, il vérifie que vous êtes sur la branche master. Si des fichiers sont modifiés mais pas enregistrés (commit), il vous le dit et demande s’il faut continuer.

Les étapes, dans l’ordre

Étape	Ce qui se passe
1. Vérifications	`npm ci` si besoin, puis `npm run typecheck`, `npm run lint`, `npm test`. Un échec arrête tout.
2. GitHub	Envoie vos commits. S’arrête si GitHub a des commits que vous n’avez pas (`git pull --rebase`, puis relancez).
3. Base Supabase	Exécute les nouveaux scripts SQL (voir plus bas).
4. Fonctions	Redéploie les fonctions modifiées parmi `location`, `copilot`, `send-receipt`, `billing`, `veille`. Toutes si `_shared` a changé.
5. Web	`npx expo export --platform web --clear`, puis `npx eas-cli@latest deploy --prod`.
6. Téléphones	Mise à jour à distance, ou nouvelle compilation si c’est nécessaire.

À la fin, le script pose le repère deploiement (une étiquette git) sur la version mise en ligne. La prochaine fois, il repart de là. Si une étape a échoué ou a été passée, le repère ne bouge pas : réglez le problème et relancez simplement la commande.

Contrôle conseillé après chaque mise en ligne : se connecter, pointer un loyer, ouvrir une fiche locataire, ouvrir un lien « Mon logement ».

Les options

Les options s’écrivent après -- :

Commande	Effet
`npm run deployer -- -Simulation`	Montre ce qui serait fait, sans rien envoyer.
`npm run deployer -- -Canal production`	Envoie la mise à jour aux téléphones installés depuis les magasins (par défaut : `preview`).
`npm run deployer -- -Seulement fonctions,web`	Seulement certaines étapes : `verifications`, `github`, `sql`, `fonctions`, `web`, `mobile`. Le repère ne bouge pas.
`npm run deployer -- -Tout`	Redéploie toutes les fonctions et le web, même sans changement.
`npm run deployer -- -Apk`	Force une nouvelle compilation Android.
`npm run deployer -- -Migrations`	Une seule fois : fait suivre les scripts SQL par la CLI Supabase (voir plus bas).
`npm run deployer -- -Projet <identifiant>`	Envoie les scripts SQL et les fonctions vers un autre projet Supabase (recette).
`npm run deployer -- -SansTests`	Saute les vérifications. À éviter.

Première fois sur un ordinateur

GitHub : faites un git push à la main une fois, pour enregistrer vos identifiants.
Supabase : npx supabase login (le navigateur s’ouvre).
Expo : npx eas-cli@latest login.
Lancez npm run deployer. Sans repère deploiement, le script demande le numéro du dernier script SQL déjà exécuté, et si l’APK installé a été compilé après le 30/09/2026.

Le script ne lit et n’écrit aucune clé : il utilise ces connexions.

La mise en ligne automatique (GitHub)

Le fichier .github/workflows/mise-en-ligne.yml fait sur GitHub ce que fait npm run deployer sur le PC. Votre PC n’est plus nécessaire pour mettre en ligne.

Comment ça marche

Un changement arrive sur master (fusion d’une demande de Claude, ou envoi depuis le PC).
La vérification « Vérifications » tourne : types, lint, tests. Si elle échoue, rien n’est mis en ligne.
Recette, automatiquement : scripts SQL manquants (supabase db push) et les cinq fonctions, sur le projet de recette. Un projet neuf est complété au premier passage.
Production, quand vous la lancez : onglet Actions › Mise en ligne › Run workflow, choisissez le canal des téléphones, puis Run workflow. Ce clic est votre approbation. Elle passe les scripts SQL, les fonctions, la version web et la mise à jour des téléphones (canal preview par défaut).
Le repère deploiement avance : la prochaine fois, seul ce qui a changé depuis repart.

Comme le script local, la mise en ligne ne déploie que ce qui a changé. Elle ne lance pas de compilation Android : si app.json, eas.json ou package.json change, elle le signale et n’envoie pas de mise à jour à distance.

Pourquoi un lancement manuel : sur un dépôt privé avec l’offre gratuite de GitHub, l’option « Required reviewers » des environnements n’existe pas. Le bouton Run workflow la remplace.

À faire une fois

Dans le dépôt GitHub piedzo/rentoo, Settings :

Environments › New environment : créez recette, puis production.
Secrets and variables › Actions › New repository secret :

Secret	Où le trouver
`SUPABASE_ACCESS_TOKEN`	supabase.com › Account › Access Tokens › Generate new token
`PRODUCTION_PROJECT_ID`	Identifiant du projet de production (Project Settings › General › Reference ID)
`PRODUCTION_DB_PASSWORD`	Mot de passe de la base de production (Project Settings › Database)
`RECETTE_PROJECT_ID`	Identifiant du projet de recette
`RECETTE_DB_PASSWORD`	Mot de passe de la base de recette
`EXPO_TOKEN`	expo.dev › Account settings › Access tokens › Create token

Secrets and variables › Actions › Variables › New repository variable : MISE_EN_LIGNE_PRODUCTION = oui. Mettez non pour bloquer toute mise en ligne de la production, même lancée à la main.
Sur le PC, une seule fois, si ce n’est pas déjà fait : npm run deployer -- -Migrations sur la production. Sans cela, la production s’arrête avec un message plutôt que de rejouer tous les scripts SQL.

Sans ces secrets, chaque étape s’arrête proprement avec un message dans l’onglet Actions : rien n’est envoyé. Les secrets ne sont lisibles ni par Claude ni dans le dépôt.

Version du serveur GitHub. Les deux workflows tournent sur ubuntu-24.04, fixé à la main, et non sur ubuntu-latest, qui passe à Ubuntu 26 à partir du 19/10/2026. Pourquoi : un changement de serveur peut casser une étape sans qu’on ait touché au code. On passera à une version plus récente volontairement, dans une demande de fusion vérifiée, avant la fin de prise en charge d’Ubuntu 24.04 annoncée par GitHub.

Les scripts SQL

L’ancien mode : copier-coller guidé

C’est le mode par défaut tant que -Migrations n’a pas été lancé. Pour chaque nouveau script, le déployeur le copie et ouvre SQL Editor. Vous collez (Ctrl+V), cliquez sur Run, puis répondez o (fait), p (passer) ou q (arrêter).

Le nouveau mode : la CLI Supabase

La base retient elle-même les scripts passés. Plus de copier-coller, plus de doute.

Une seule fois : npm run deployer -- -Migrations.
- Le script relie le dossier au projet (npx supabase link) ; la CLI demande le mot de passe de la base (Supabase › Project Settings › Database).
- Il demande le numéro du dernier script déjà exécuté à la main, et marque les scripts jusqu’à ce numéro comme faits (npx supabase migration repair). Aucune table n’est modifiée.
Ensuite, chaque npm run deployer montre les scripts en attente (npx supabase db push --dry-run), puis les exécute après votre accord (npx supabase db push).

Ce réglage est retenu dans le dossier (git config rentoo.migrations), pas dans le projet Supabase. À vérifier : si -Migrations a déjà été fait sur la production.

La recette : un second Gladoo pour tester

La recette est une copie complète de Gladoo, branchée sur des données de test. On y vérifie chaque changement avant la production.

	Recette (tests)	Production (live)
Base et fonctions	Projet Supabase `rentoo-recette` (`undlheciqdamijgwnvbp`)	Projet `rentoo-production`
Web	https://rentoo–recette.expo.app	https://rentoo.expo.app
Téléphone	Appli « Gladoo Recette » (`fr.rentoo.app.recette`, icône orange), installable à côté de Gladoo	Appli Gladoo
Mises à jour à distance	Canal `recette`	Canaux `preview` et `production`
Repère de dernière mise en ligne	Étiquette git `recette`	Étiquette git `deploiement`

Un bandeau orange « RECETTE · données de test » reste affiché en haut de l’écran en recette, jamais en production.

Comment l’application sait où elle est

Le code est le même. L’environnement est reconnu à l’ouverture (src/lib/environment.ts) :

téléphone : le canal gravé à la compilation (recette pour l’appli Gladoo Recette) ;
web : l’adresse (…--recette.expo.app) ;
développement : EXPO_PUBLIC_APP_VARIANT=recette npx expo start force la recette.

En recette, la base et l’adresse web des liens envoyés (signalement, devis, espace locataire) sont celles de la recette. Le fichier .env reste celui de la production.

app.config.ts complète app.json : avec APP_VARIANT=recette (profil recette d’eas.json), il change le nom, l’identifiant, le schéma de liens (rentoo-recette://) et les icônes (assets/images/recette/).

Mettre une version en recette : automatique, sur GitHub

Rien à lancer sur le PC. GitHub (Actions › Mise en ligne) s’en charge :

après chaque envoi sur master dont les vérifications sont vertes (un envoi de documentation seule ne lance rien) : seulement ce qui a changé depuis le repère recette — scripts SQL, fonctions une par une, web de recette, appli Gladoo Recette (mise à jour à distance ; nouvelle compilation de l’APK si app.json, app.config.ts, eas.json ou package.json ont changé, avec le lien de l’APK dans le résumé du lancement) ;
pour essayer une branche avant de la fusionner : Actions › Mise en ligne › Run workflow, choisir la branche, cible recette.

Un contrôle de santé suit : le web de recette doit répondre.

Passer en production : un clic, seulement ce qui a été validé

Actions › Mise en ligne › Run workflow, branche master, cible production, canal des téléphones (preview pour les APK installés). La production refuse toute version qui n’est pas exactement celle en recette (même contenu que le repère recette) : on ne met en ligne que ce qui a été testé.

Ensuite, un contrôle de santé vérifie le web tout de suite, puis 5 minutes après le journal app_errors (l’attente est payée en minutes GitHub ; la minuterie gratuite des environnements n’existe pas pour un dépôt privé en formule Pro) : la moindre erreur de mise à jour (téléphones revenus à l’ancienne version) fait échouer le contrôle, et GitHub vous prévient par e-mail.

npm run deployer -- -Recette reste possible sur un PC, en secours.

Première fois (une seule fois)

Clé de signature de l’appli de recette : sur expo.dev › projet rentoo › Credentials › Android › fr.rentoo.app.recette, créer une clé (une compilation sans écran ne peut pas la créer). Puis la première compilation part de GitHub (Run workflow, cible recette, case « Forcer une nouvelle compilation de l’APK »). Ouvrez le lien de l’APK sur le téléphone Android et installez-le : il s’ajoute à côté de Gladoo.
Secret EXPO_TOKEN : il doit être lisible par l’environnement GitHub recette (secret du dépôt, ou de l’environnement recette), pas seulement production.
Supabase › rentoo-recette › Authentication › URL Configuration : ajoutez https://rentoo--recette.expo.app (adresse du site et adresses de redirection) et rentoo-recette://**.
E-mails : reprenez dans le projet de recette les modèles d’e-mail de la production (voir « Installation initiale »).
Secrets des fonctions du projet de recette (liste plus bas). Pour Stripe, uniquement les clés de test (sk_test_…, prix de test, webhook de test vers https://undlheciqdamijgwnvbp.supabase.co/functions/v1/billing).
iPhone : l’appli de recette passe par TestFlight, qui demande un compte Apple Developer (npx eas-cli@latest build --platform ios --profile recette). Pas encore fait.

Base et fonctions seules

npm run deployer -- -Projet <identifiant> envoie seulement les scripts SQL et les fonctions vers un autre projet Supabase (le web et les téléphones restent sur la production).

Attention : la préparation -Migrations vaut pour le dossier. Avant le déploiement suivant en production, relancez npm run deployer -- -Migrations sur le projet de production.

Les canaux preview et production

Définis dans eas.json :

Canal	Profil de compilation	Pour qui
`preview`	APK Android interne	Testeurs (APK partagé par lien)
`recette`	APK Android interne « Gladoo Recette » (`APP_VARIANT=recette`)	Vous, pour valider avant la production
`production`	Version des magasins, numéro de compilation incrémenté automatiquement	Téléphones installés depuis Google Play ou l’App Store

npm run deployer envoie au canal preview ; npm run deployer -- -Canal production au canal production. Le téléphone vérifie les mises à jour au lancement et au retour dans l’application (au plus toutes les 30 minutes). Une version téléchargée s’installe d’elle-même à l’ouverture suivante, sans rien demander : plus de bandeau « Redémarrer ». Réglages › À propos affiche « Nouvelle version prête » avec « Installer maintenant ». Un lancement de secours, une erreur de mise à jour ou une version qui reste prête sans jamais s’appliquer (trois ouvertures de suite) est noté dans le journal app_errors (genre update). Retour arrière possible : npx eas-cli@latest update:rollback.

Quand recompiler l’APK

Une mise à jour à distance suffit pour les écrans, les textes, les calculs et les couleurs. Une nouvelle compilation est nécessaire quand :

app.json ou eas.json change (icône, permission, version) ;
une dépendance est ajoutée, retirée ou change de version dans package.json (nouveau module natif) ;
l’APK installé date d’avant le 30/09/2026 (il ne reçoit pas les mises à jour à distance) ;
vous changez "version" dans app.json : la règle appVersion réserve les mises à jour aux applications compilées avec la même version.

Le déployeur détecte ces cas et propose npx eas-cli@latest build --platform android --profile <canal>. Il propose aussi d’envoyer la mise à jour à distance aux téléphones déjà installés.

iPhone : le déployeur ne le fait pas. Commandes : npx eas-cli@latest build --platform ios --profile production, puis npx eas-cli@latest submit --platform ios. Il faut un compte Apple Developer. L’ancien guide archives/DEPLOIEMENT_TEST.md conseille d’ajouter "infoPlist": { "ITSAppUsesNonExemptEncryption": false } dans la section ios de app.json avant la première compilation ; ce n’est pas encore fait.

La publication web

Le déployeur publie le web quand src/, public/, assets/, app.json ou les dépendances changent :

npx expo export --platform web --clear
npx eas-cli@latest deploy --prod

La version web sert aussi les pages sans compte (annonce, candidat, signature, devis, « Mon logement »). Le site vitrine public/decouvrir.html part avec elle. Si l’adresse publique change, mettez à jour EXPO_PUBLIC_WEB_URL dans .env, puis republiez.

Les secrets des fonctions

Ils se déclarent avec npx supabase secrets set NOM=valeur, ou dans Supabase › Edge Functions › Secrets. Jamais dans le code ni dans .env. Liste lue dans les fonctions (Deno.env.get) :

Fonction	Secrets
Toutes	`SUPABASE_URL`, `SUPABASE_ANON_KEY` (fournis par Supabase, à vérifier)
E-mails (`send-receipt`, `location`, `veille`, via `_shared/mail.ts`)	`SMTP_HOST`, `SMTP_PORT`, `SMTP_USER`, `SMTP_PASS`, ou `RESEND_API_KEY` ; `MAIL_FROM` ; plus tard `MAIL_DOMAIN`
`copilot`	`ANTHROPIC_API_KEY` ; facultatif `COPILOT_MODEL` ; tests seulement `ANTHROPIC_BASE_URL`
`billing`	`STRIPE_SECRET_KEY`, `STRIPE_WEBHOOK_SECRET`, `BILLING_SECRET`, `STRIPE_PRICE_ESSENTIEL_MENSUEL`, `STRIPE_PRICE_ESSENTIEL_ANNUEL`, `STRIPE_PRICE_PRO_MENSUEL`, `STRIPE_PRICE_PRO_ANNUEL`, `STRIPE_PRICE_PATRIMOINE_MENSUEL`, `STRIPE_PRICE_PATRIMOINE_ANNUEL` ; tests seulement `STRIPE_API_BASE`
`location`	`ACCESS_SECRET` (affiché par le script 016), `RECAP_SECRET`, `SITE_URL` ; facultatifs `EXPO_ACCESS_TOKEN`, `APP_STORE_URL`, `PLAY_STORE_URL` ; tests seulement `EXPO_PUSH_URL`
`veille`	`VEILLE_SECRET`, `ADMIN_EMAIL` ; tests seulement `VEILLE_INSEE_BASE`, `VEILLE_ZONES_URL`

Secrets du coffre de la base (SQL Editor, vault.create_secret) : project_url, veille_secret (même valeur que VEILLE_SECRET), rentoo_recap_secret (même valeur que RECAP_SECRET).

BILLING_SECRET doit être identique à celui de la base (affiché par le script 018). ACCESS_SECRET aussi (affiché par le script 016).

Installation initiale (nouveau projet)

À faire une fois, pour un projet Supabase neuf (production ou recette).

1. Base de données

Méthode actuelle : npm run deployer -- -Projet <identifiant> -Migrations (répondre 000), puis npm run deployer -- -Projet <identifiant>. Tous les scripts passent dans l’ordre.
Le script 016 affiche ACCESS_SECRET=… et le script 018 BILLING_SECRET=… : copiez ces valeurs pour les secrets.
Avant le script 027 : créez dans le coffre project_url et veille_secret, et le secret de fonction VEILLE_SECRET (voir exploitation.md).
Extensions pg_cron et pg_net : le script 027 les active lui-même. Elles servent à la veille, aux rappels d’assurance (044), aux récapitulatifs et à l’envoi rapide des notifications. En cas de refus, les activer dans Database › Extensions.

2. Authentification

Authentication › Sign In / Providers › Email : « Confirm email » activé, longueur minimale du mot de passe à 8.
Authentication › Emails › SMTP Settings : brancher un service d’envoi. L’expéditeur fourni par Supabase est très limité.
Authentication › Emails › Templates, onglet Source :

Modèle	Fichier à coller
Confirm signup	`supabase/templates/confirmation.html`
Reset password	`supabase/templates/recovery.html`
Magic Link	`supabase/templates/magic_link.html` (signature des baux)

3. E-mails des fonctions

Brevo est le service conseillé (emails.md) : adresse d’expédition vérifiée, clé SMTP, puis les secrets SMTP_* et MAIL_FROM. Essai : Réglages › Profil et bailleur › Vos e-mails › « M’envoyer un e-mail de test ».

4. Fonctions et autres services

Déployez les fonctions (le déployeur le fait).
Roo : clé Anthropic dans ANTHROPIC_API_KEY.
Paiement : produits et prix Stripe, webhook vers …/functions/v1/billing avec les événements checkout.session.completed, customer.subscription.created, customer.subscription.updated, customer.subscription.deleted, portail client activé, puis les secrets STRIPE_* (détail dans archives/AMELIORATIONS-jusqu-au-12-10-2026.md, section « Brancher le paiement Stripe »).
Notifications Android : projet Firebase et clé FCM V1 envoyée à EAS (npx eas-cli@latest credentials).

5. Application

.env : EXPO_PUBLIC_SUPABASE_URL, EXPO_PUBLIC_SUPABASE_KEY (clé publishable, jamais la clé secrète), EXPO_PUBLIC_WEB_URL. Modèle : .env.example.
npm ci, puis npm run deployer.

6. Accès sur invitation (facultatif)

Pendant la version de test, l’inscription peut exiger un code : table beta_invites, réglage invite_required dans app_settings (exemples SQL dans archives/DEPLOIEMENT_TEST.md).

Messages fréquents

Message	Quoi faire
« Fichiers modifiés mais pas encore enregistrés »	Enregistrez-les (commit), ou répondez `n` et relancez plus tard.
« GitHub a N commit(s) que vous n’avez pas »	`git pull --rebase`, puis relancez.
« npm run lint a échoué » (ou typecheck, test)	Corriger le problème affiché avant de mettre en ligne.
Échec d’une fonction	Souvent la session Supabase expirée : `npx supabase login`, puis relancez.
Échec de la compilation Android	Ouvrir le lien des journaux affiché. Si « Install dependencies » échoue : `git checkout package-lock.json`, puis `npm ci`.