# Travailler depuis n'importe où — mise en place de l'infrastructure cloud

Document de cadrage, écrit le 21/08/2026. **But** : pouvoir piloter le LMS et
lancer des fils de développement **ordinateur fermé**, depuis un mobile ou une
tablette, sans VPS ni machine dédiée.

## Ce qui est acquis, et ce qui ne l'est pas

**Acquis** — une session cloud tourne sur une machine virtuelle gérée par
Anthropic, **survit à la fermeture du portable**, et se pilote depuis l'app
mobile. Elle **clone le dépôt GitHub** au lancement.

**Non acquis** — elle ne voit **pas** le disque local. Donc, sans configuration :
pas de `.env`, pas de base de données, pas de PHP ni de Node installés, pas
d'accès SSH.

**L'alternative à connaître** : le *Remote Control* garde l'exécution **sur la
machine locale** (système de fichiers, serveurs MCP et outils intacts) et permet
de piloter depuis le mobile — mais la machine doit **rester éveillée**. C'est le
bon choix pour ce qui dépend du disque local ; le cloud est le bon choix pour ce
qui vit dans git. **Le LMS vit entièrement dans git.**

## Les trois questions à résoudre

### 1. Le stack technique
Un environnement cloud accepte un **script d'installation** exécuté au démarrage
de chaque session. Il doit poser ce dont un fil a besoin pour travailler :
PHP 8.2 et ses extensions, composer, Node 24 **exactement** (le 25 et le 26
cassent la suite front), et une base MySQL locale à la session.

⚠️ **Un fil s'exécute DANS l'environnement de la session.** Une session de
pilotage qui lance des fils de développement a donc besoin du stack complet, au
même titre qu'une session de développement. La distinction pilotage/développement
**ne tient pas** côté environnement : il n'y a qu'un environnement à configurer.

### 2. Les secrets
Les **variables d'environnement** de l'environnement cloud. Le `.env` n'est pas
transporté : il est **reconstruit au démarrage** par le script d'installation, à
partir de ces variables. Les identifiants git, eux, passent par un mandataire et
ne sont **jamais** dans le bac à sable.

⚠️ **Décision de gouvernance, pas détail technique** : les clés d'API vivraient
alors dans une configuration hébergée par un tiers. À arbitrer explicitement,
avec le même sérieux que les accords de traitement des données.

À inventorier avant de commencer : ce que contient réellement le `.env` de chaque
dépôt, et **lesquelles de ces valeurs sont indispensables à un fil** (jouer les
tests demande beaucoup moins que faire tourner l'application).

### 3. L'accès au serveur
**Le déploiement n'en a plus besoin** : le déploiement continu (21/08) utilise sa
**propre clé, dans les secrets GitHub**. Restent trois gestes qui passent encore
par une connexion directe :

| Geste | Peut-il s'en passer ? |
|---|---|
| **Jouer une migration** | Oui — un workflow déclenché à la main ferait le geste de façon **tracée et auditable**, ce qui vaut mieux qu'une connexion interactive. **À construire.** |
| **Vérifier l'état déployé** | Oui — déjà fait par l'API (version servie, sondes de routes). |
| **Lire les journaux du serveur** | Non, en l'état. Usage rare, à traiter au cas par cas. |

**Playwright n'a pas besoin d'accès serveur** — un navigateur et un accès réseau
à l'environnement de recette suffisent. Vérifier que le niveau d'accès réseau de
l'environnement cloud l'autorise.

## Ce qui reste local, et c'est assumé

La **production vidéo** du microlearning : modules et fichiers lourds
délibérément hors dépôt, secrets de rendu, chaîne de traitement coûteuse. Elle ne
migre pas — et c'est le bon choix.

## Ordre proposé

1. **Inventorier les secrets** réellement nécessaires, par dépôt et par usage.
2. **Écrire le script d'installation** et le valider sur une session cloud jetable :
   la suite de tests passe-t-elle ? un fil peut-il travailler ?
3. **Arbitrer la gouvernance** des secrets avant de les déposer.
4. **Construire le workflow de migration**, qui supprime le dernier besoin
   d'accès interactif au serveur.
5. **Éprouver en réel** : une session cloud, un fil, un train complet.

## Critère de réussite

> Depuis un mobile, ordinateur fermé : trier un signalement, lancer un fil de
> correctif, évaluer son annonce, passer le train, vérifier le déploiement.
> **Sans aucune connexion à la machine locale.**