# Reprise en main de l'infrastructure — plan opératoire **Objectif** : redevenir seul détenteur des accès à la production, puis retirer ceux de l'équipe de développement externe. **Règle absolue qui gouverne tout ce document :** > **On ne coupe jamais un accès avant d'avoir (1) une sauvegarde qu'on maîtrise et (2) son propre > accès vérifié et fonctionnel.** Couper d'abord, c'est risquer de se retrouver enfermé dehors sur une machine qui héberge les données de 260 apprenants, sans moyen d'y revenir. --- ## Constats établis le 06/08/2026 | Élément | État | |---|---| | Serveur | VPS OVH, `57.129.1.122` (`ns3233390.ip-57-129-1.eu`), entité OVH GmbH | | Ports ouverts | 22 (SSH), 80, 443. **3306 fermé** — la base n'est pas exposée à Internet | | Domaine | `efektiv-academie.com`, registrar **OVH**, créé le 31/07/2025, DNS OVH | | Interface web de base | **Aucune** (phpMyAdmin, Adminer : absents) | | GitHub | `AAZTEKDEV` = compte **personnel**, pas une organisation. Droits admin disponibles depuis le Mac d'Enguerran | | Accès serveur | Identifiants transmis le 06/08 par l'équipe externe : utilisateur `ubuntu`, authentification par mot de passe. **Mot de passe à renouveler** (transmis en clair) | | **Environnement de recette** | **Il existe** — sur le domaine `efektiv-academie-dev.com` : `staging.efektiv-academie-dev.com` (front) et `api-staging.efektiv-academie-dev.com` (API). ⚠️ **Hébergé sur le même serveur que la production** (`57.129.1.122`) : pas d'isolation | | Arborescence | `/var/www/api.efektiv-academie.com` (API prod), `/var/www/efektiv-academie.com` (front prod), `/var/www/api-staging.efektiv-academie-dev.com`, `/var/www/staging.efektiv-academie-dev.com` | --- ## La question pivot : à quel nom est le compte OVH ? Tout dépend de cette réponse. Connecte-toi sur `ovh.com` et regarde la section « Mon compte ». **Cas A — le compte est à ton nom (ou à celui de ta société).** Tu peux tout reprendre **seul, aujourd'hui**, sans l'accord de personne. Passe directement à la phase 1. **Cas B — le compte est au nom de l'équipe externe.** Le serveur et le domaine leur appartiennent juridiquement. Il faut une **procédure de changement de propriétaire** OVH, qui exige leur accord. C'est une démarche formelle et gratuite, mais elle prend quelques jours. À lancer immédiatement, en parallèle de la phase 0. **Cas C — tu n'as pas les identifiants du compte OVH.** Si le compte est au nom de ta société, la récupération se fait auprès du support OVH avec un justificatif d'identité de l'entreprise. Sinon, on retombe sur le cas B. --- ## Phase 0 — Sauvegarder (avant toute chose, ne rien couper) 1. **Créer un snapshot du VPS** depuis l'espace OVH. C'est immédiat, sans coupure, et c'est le filet de sécurité de toute la suite. **Ne rien entreprendre avant que ce point soit fait.** 2. **Vérifier les sauvegardes automatiques** : existent-elles ? À quelle fréquence ? Quelle rétention ? Si aucune sauvegarde n'existe, c'est un risque à traiter en soi, indépendamment de ce chantier. 3. **Demander formellement la réversibilité** à l'équipe externe (courrier ou email, cf. modèle plus bas). Même si tu comptes récupérer l'accès autrement, la demande écrite constitue une trace utile. ## Phase 1 — Reprendre l'accès à la machine Trois voies, de la moins risquée à la plus lourde. **Voie 1 — Ils coopèrent.** Ils ajoutent ta clé publique sur le serveur. C'est cinq minutes, sans coupure. À privilégier tant que la relation le permet. ```bash cat ~/.ssh/id_ed25519.pub # à leur transmettre : ce contenu n'est pas secret ``` **Voie 2 — Snapshot restauré sur un serveur temporaire.** Tu restaures le snapshot de la phase 0 sur un **second VPS**, sur lequel tu es seul maître. Tu y récupères le `.env`, la structure de la base, la configuration du serveur — **sans jamais toucher à la production**. Coût : quelques euros pour quelques jours. C'est la voie que je recommande si la relation est tendue : risque nul, aucune coupure, et elle donne tout ce dont on a besoin pour l'audit et pour préparer la suite. **Voie 3 — Mode rescue OVH.** OVH redémarre le serveur sur un système de secours et t'envoie des identifiants temporaires par email. Tu entres sans connaître aucun mot de passe, tu montes le disque, tu lis et tu modifies ce que tu veux (y compris pour te créer un accès permanent). **Mais cela impose un redémarrage, donc une coupure de service.** À planifier hors heures d'usage, et seulement si les voies 1 et 2 échouent. ## Phase 2 — Renouveler tous les secrets Une fois l'accès repris, **tout ce que l'équipe externe a pu voir doit être considéré comme compromis**. Le fichier `.env` du serveur contient l'intégralité des clés : c'est le point de départ de l'inventaire. | Secret | Où | Remarque | |---|---|---| | Mot de passe base de données | `.env` + MySQL | Changer côté MySQL puis côté `.env` | | `APP_KEY` Laravel | `.env` | ⚠️ **Vérifier avant de la changer** : elle chiffre les cookies et toute colonne chiffrée. Un changement non préparé peut rendre des données illisibles | | Accès SSH | `~/.ssh/authorized_keys` du serveur | Retirer leurs clés, garder la tienne | | Mot de passe root / sudo | Serveur | À changer | | Mailjet | `.env` | Régénérer la clé API | | Stripe | `.env` | Régénérer — sensible, argent en jeu | | Sentry | `src/sentry.js` (front) et `.env` | DSN en clair dans le front | | ZegoCloud | Front, en dur | **Déjà à révoquer** (cf. PR #11 : secret exposé dans le bundle) | | Pusher | `.env` | Régénérer | | Vimeo | Selon configuration | Vérifier | | Compte OVH | ovh.com | Mot de passe + activer la double authentification | | Registrar / DNS | OVH | Vérifier le verrou de transfert du domaine | | GitHub | `AAZTEKDEV` | Voir ci-dessous | **Sur GitHub**, deux actions distinctes : renouveler le mot de passe et les jetons du compte `AAZTEKDEV`, et surtout **migrer les dépôts vers une véritable organisation** au nom de la société. Un compte personnel qui détient le code d'une entreprise est un risque structurel : il ne survit pas au départ de la personne, et ne permet pas de gérer des droits par équipe. ## Phase 3 — Couper les accès de l'équipe externe **Seulement une fois les phases 1 et 2 terminées et vérifiées.** Point de contrôle avant de couper : tu as ouvert une session SSH avec ta propre clé, tu as un snapshot récent, et tu as renouvelé les secrets. Ensuite : retirer leurs clés SSH, leurs comptes utilisateurs sur la machine, leurs accès OVH (sous-comptes éventuels), et leurs collaborateurs GitHub. ## Phase 4 — Ce qu'il faut avoir récupéré avant de les libérer Au-delà des accès, demande-leur par écrit : - la **procédure de déploiement** (comment le code passe du dépôt à la production) ; - l'existence et l'emplacement d'un **environnement de recette** ; - la configuration du serveur web (Apache ou nginx), les tâches planifiées (`cron`), les services en arrière-plan (notamment le *worker* de file d'attente, indispensable aux emails) ; - la politique de **sauvegarde** et la procédure de restauration ; - les certificats SSL et leur renouvellement ; - tout script ou automatisation vivant hors du dépôt. Sans ces éléments, tu auras les clés mais pas le mode d'emploi. --- ## Modèle de demande de réversibilité > Objet : demande de réversibilité et de transfert des accès — plateforme Efektiv Académie > > Bonjour, > > Dans le cadre de la reprise en interne de la maintenance de la plateforme, nous vous demandons > de nous transmettre les éléments suivants sous [15] jours : > > 1. Un accès administrateur au serveur hébergeant l'application (ajout de notre clé publique SSH, > que nous vous transmettons ci-joint), ainsi que les identifiants du compte d'hébergement si > celui-ci est à votre nom. > 2. La documentation d'exploitation : procédure de déploiement, environnements existants, > tâches planifiées, services en arrière-plan, politique de sauvegarde et procédure de > restauration. > 3. La liste des services tiers utilisés et des comptes associés. > > Nous procéderons ensuite au renouvellement des secrets, ce qui mettra fin à vos accès. Nous > restons disponibles pour organiser une passation dans de bonnes conditions. Selon ce que prévoit votre contrat (clause de réversibilité, préavis), il peut être utile de faire relire ce courrier avant envoi. --- ## Impact sur le calendrier de la V1 Ce chantier **ne bloque pas le développement**. Le lot L1 (socle de tracking) crée de nouvelles tables et ne dépend pas de l'audit du schéma existant : il peut avancer en parallèle. En revanche il **bloque la mise en production**, donc les lots L5 et la livraison de mi-septembre. C'est aujourd'hui le premier risque du planning — devant la charge de développement elle-même.