VPS Autopilot

Aide utilisateur

Tout faire, dans l’ordre, sans surprise

Tu colles l’IP de ton VPS. L’agent lit ce serveur, puis n’installe que ce que tu confirmes. Profil platform : comptes + RBAC (connexion). Profil défaut : un opérateur, console locale. Ce qui est déjà posé sur cette machine n’est pas reproposé. Un autre VPS reprend les mêmes traitements depuis le début.

1. À quoi sert l’agent

Tu as un VPS. Au lieu d’installer Docker, un reverse-proxy ou une base « à la main », tu passes par cet outil.
- READ — lire (OS, CPU, RAM, logiciels). Automatique.
- CHANGE — modifier (clé SSH, sécurité, Docker, Traefik, MariaDB, compte deploy, une app). Plan + tu confirmes.
- DESTRUCTIVE — détruire. Refusé pour l’instant.
L’IA ne reçoit jamais un accès root libre. Les scripts sont versionnés, pas inventés à la volée.
2. Ouvrir le cockpit et remplir les paramètres

Menu Cockpit. Renseigne au minimum :
- Hôte / IP — l’adresse de ton VPS
- Utilisateur — le compte dédié à l’agent, nom simple de ton choix (défaut autopilot). Il est créé par la méthode D de l’étape 3, quelle que soit la distribution. Les comptes livrés par l’hébergeur (ubuntu, debian, root…) ne servent qu’à la méthode A.
- Port — 22 sauf si tu l’as changé
- Système — Auto convient
Tant que tu n’as pas cliqué Analyser le VPS avec succès, le tableau reste vide. Pas de données d’exemple.
3. Clé SSH (obligatoire pour analyser)

L’agent se présente avec une paire de clés : privée sur ce PC, publique sur le VPS (fichier ~/.ssh/authorized_keys).

Piège fréquent : la page « clés SSH » de ton compte chez l’hébergeur n’installe rien sur un VPS déjà créé. Elle ne sert qu’à la création ou à une réinstallation. Ne réinstalle pas le serveur pour ça.

Générer la clé une fois, sur ce PC (PowerShell) :
```
ssh-keygen -t ed25519 -f $HOME\.ssh\vps-autopilot -C "vps-autopilot" -N ""
```
S’il demande d’écraser : n. Fichiers : vps-autopilot (secret) et vps-autopilot.pub (à coller sur le serveur).

Clé déjà présente sur ce PC.

Quelle clé mettre sur le VPS ? Uniquement la publique : le fichier vps-autopilot.pub, affiché juste en dessous. C’est une seule ligne qui commence par ssh-ed25519 AAAA…. Ne colle jamais vps-autopilot (sans .pub) : c’est la clé secrète, elle reste sur ce PC.

Clé publique de cet agent (une seule ligne) — c’est celle-ci à copier :
```
Chargement…
```
Pour l’afficher toi-même dans PowerShell : Get-Content $HOME\.ssh\vps-autopilot.pub. Elle va sur le VPS dans ~/.ssh/authorized_keys de l’utilisateur avec lequel l’agent se connecte (le même que dans le champ Utilisateur, ex. autopilot).

Connecté en root ? Sur le serveur, ~ désigne alors /root, pas le compte de l’agent. Pour l’utilisateur vps, le fichier est /home/vps/.ssh/authorized_keys. La méthode D ci-dessous écrit le bon chemin pour toi.

Quatre façons de la poser sur le VPS :
A — Cockpit (le plus simple)
1. IP + utilisateur (ubuntu ou root).
2. Mot de passe du mail de livraison de ton hébergeur.
3. Installer la clé (CHANGE) → confirme.
Le mot de passe n’est pas enregistré. Une ligne dans authorized_keys.
B — Console web de l’hébergeur

Fiche du VPS chez l’hébergeur (pas la page « clés SSH ») → console web (KVM / VNC) → connecte-toi avec l’utilisateur de l’agent (sinon méthode D), puis :
```
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
nano ~/.ssh/authorized_keys
```
Dans nano, colle la ligne ssh-ed25519 … copiée plus haut (clic droit dans la console web), sur une seule ligne, sans espace avant. Enregistrer : Ctrl+O, Entrée, Ctrl+X.
C — PowerShell
```
ssh ubuntu@IP "mkdir -p ~/.ssh; chmod 700 ~/.ssh; touch ~/.ssh/authorized_keys; chmod 600 ~/.ssh/authorized_keys"
type $HOME\.ssh\vps-autopilot.pub | ssh ubuntu@IP "cat >> ~/.ssh/authorized_keys"
```
D — L’admin du serveur crée le compte de l’agent (aucun accès partagé)

Recommandé, et seul moyen pour un serveur que tu n’administres pas (ex. le serveur de ton organisation) : envoie ce bloc à l’administrateur. Il le colle dans sa propre session root (ou après sudo -i). Le bloc crée le compte de l’agent s’il n’existe pas (Ubuntu, Debian, RHEL, Rocky, Alma, Fedora…), puis y pose la clé. Personne ne te donne de mot de passe, et le compte n’a aucun droit sudo par défaut : assez pour l’analyse. La dernière ligne, commentée, donne sudo sans mot de passe ; à activer seulement si l’agent doit installer ou déployer.
Compte qui sera créé : autopilot (nom par défaut : autopilot). Il est modifiable, de deux façons :
1. Avant de copier : saisis le nom voulu dans le champ Utilisateur SSH du Cockpit (panneau de gauche). Le bloc ci-dessous se met à jour tout seul.
2. Après avoir copié : change la première ligne du bloc, U=autopilot, par exemple U=agentweb.
Nom simple : minuscules, chiffres, - ou _, commence par une lettre. Saisis ensuite le même nom dans le champ Utilisateur SSH pour analyser.
```
Chargement…
```
Le bloc est rempli avec la clé publique de cet agent et l’Utilisateur saisi dans le cockpit. Il n’ajoute pas la clé deux fois. La dernière ligne affichée doit être la clé ssh-ed25519 … de cet agent. Pour retirer l’accès plus tard : supprimer cette ligne du fichier.
Vérifier (PowerShell) : cette commande doit ouvrir une session sans demander de mot de passe.
```
ssh -i $HOME\.ssh\vps-autopilot ubuntu@IP
```
Utilisateur, IP et port sont repris du cockpit. Si elle demande un mot de passe : la clé n’est pas dans le bon authorized_keys (mauvais utilisateur, ou ligne coupée). Tape exit, puis Analyser le VPS dans la console.
3b. Donner temporairement les droits root au compte de l’agent

Le compte de l’agent n’a aucun droit sudo par défaut : assez pour analyser. Certaines opérations demandent de lire ou d’écrire ce que seul root peut toucher. Exemples : sauvegarder toutes les applications d’un serveur avant de les remettre en conteneurs (bases de données, fichiers protégés, configurations), ou préparer le serveur. Dans ce cas, l’administrateur donne temporairement sudo au compte, puis le retire.

Snapshot du serveur entier : l’agent ne le fait pas. Une copie complète de la machine (disque, système, tout compris) se prend depuis la console de ton hébergeur ou de l’hyperviseur de ton organisation (bouton « Snapshot » ou « Sauvegarde »). Fais-la avant toute opération avec root : c’est le seul vrai retour arrière. Les droits root temporaires servent à l’agent, pour sauvegarder les applications une par une.

1. L’admin donne les droits, dans sa session root (ou après sudo -i). Le compte est celui du champ Utilisateur SSH du cockpit (autopilot). Les droits se retirent tout seuls au bout de 4 heures (sur les systèmes avec systemd, c’est-à-dire presque tous).
```
Chargement…
```
2. Vérifier depuis ton PC (PowerShell) : la réponse doit être SUDO_OK.
```
Chargement…
```
3. Retirer les droits dès que l’opération est finie, sans attendre les 4 heures (session root de l’admin). La vérification de l’étape 2 doit alors échouer.
```
Chargement…
```
- Personne ne communique le mot de passe root : l’admin garde la main et peut retirer les droits à tout moment.
- Chaque commande passée avec sudo est tracée sur le serveur (/var/log/auth.log ou /var/log/secure).
- Un serveur que tu as déclaré en lecture seule dans l’agent le reste, même avec sudo : la protection est dans l’agent, pas sur le serveur.
- Pour un serveur que l’agent administre durablement (installations, déploiements), la ligne sudo permanente de la méthode D reste possible ; préfère la version temporaire tant que ce n’est pas décidé.
4. Analyser

Bouton Analyser le VPS. L’empreinte SSH est enregistrée, puis lecture seule. Si « Authentification refusée » : la clé n’est pas sur ce compte — étape 3.

Ensuite seulement : OS, CPU, RAM, disque, logiciels de ce VPS.

Mes serveurs (haut du panneau de gauche) : chaque serveur analysé avec succès y est gardé (nom, adresse, utilisateur, port ; jamais de mot de passe). Un clic rouvre sa session : les champs sont remplis et la dernière analyse s’affiche aussitôt, avec sa date, sans se reconnecter. Relance Analyser le VPS pour la rafraîchir. Au démarrage, le cockpit rouvre le dernier serveur utilisé. Oublier le retire de la liste (l’analyse enregistrée sur ce PC n’est pas effacée).

Réglages (sous chaque serveur), à fixer avant les installations :
- HTTP seul : le serveur n’est pas joignable en HTTPS depuis l’extérieur (réseau interne, passerelle qui n’ouvre pas le 443). Traefik est installé sans certificat ni redirection, les sites répondent en http://.
- Port web public : quand la passerelle traduit un port (ex. 8080 vers 80), les liens et la vérification après déploiement utilisent ce port. Vide = port standard.
- Serveur partagé : d’autres personnes s’y connectent en SSH avec un mot de passe. La sécurité pose pare-feu, fail2ban et mises à jour automatiques, mais ne coupe pas ces connexions.
Sur un serveur désigné par son adresse IP (pas de nom de domaine), les plateformes sont routées par chemin seul (/app, /app/api) : la même URL marche par l’adresse publique et par l’adresse interne.
4b. Le parcours guidé (par défaut)

Après l’analyse, le cockpit n’affiche qu’une étape à la fois : Analyser → Préparer le serveur → Plateforme → Accès Git → Données → En ligne. La carte « Prochaine étape » dit quoi faire et propose un seul bouton.
- Préparer le serveur — un seul plan à confirmer, puis Sécurité, Docker, Traefik, MariaDB et compte deploy s’enchaînent (ce qui est déjà posé est sauté).
- Accès Git — une clé par dépôt ; colle-la sur GitHub, puis Vérifier (lecture seule, aucun clone). Un tuto en 5 étapes s’ouvre la première fois (Générer, Copier, ouvrir la page Deploy keys, remplir le formulaire avec Allow write access décoché, Vérifier) ; rejouable avec « Suivre le tuto » ou le bouton Tuto de chaque dépôt.
- Données — restaurer un dump et des fichiers, ou passer l’étape.
- En ligne — l’agent teste chaque adresse HTTPS (certificat valide exigé).
Les étapes faites restent cliquables pour y revenir. Mode expert réaffiche tous les panneaux (choix fin des installations, apps simples). Options de connexion (rail de gauche) réaffiche mot de passe, clé et empreinte une fois connecté. Nom d’hôte avec {{HOST}} : remplacé au déploiement — après le mapping DNS, change le nom d’hôte, Enregistrer, Déployer.
5. Choisir quoi installer (après l’analyse)

La carte Installations (le bouton Installer) est juste sous le tableau. La liste « Que doit installer l’agent ? » est en dessous, dans un menu fermé : clique le titre pour déplier. Elle décrit ce que tu veux sur ce VPS, ce n’est pas le bouton.
- Coche la section (Sécurité, Docker, Traefik, MariaDB, Compte deploy…). Ce menu décrit ce que tu veux. Le bouton Installer n’est pas dans les cases : il est dans la carte Installations, au-dessus.
- Une nouvelle section par défaut (ex. Compte deploy) est ajoutée toute seule à une pile déjà enregistrée. Décocher reste possible et n’est pas recassé au rechargement.
- Les détails (UFW, Compose, groupe docker…) sont dans un menu fermé. « 2 à installer » = encore cochés et pas détectés sur ce VPS → bouton Installer du composant dans Installations (pas dans ce menu).
- Le pourquoi et ce que ça fera sont dans un second menu, fermé par défaut.
- Déjà présent sur ce serveur : case grisée, mention « déjà installé », non recochable.
- Décocher est permis. Si ça casse la politique (sécurité, Docker, Traefik, backups), tu es prévenu.
- Redis est optionnel. Nginx sur l’hôte n’est pas proposé (risque webshell) : pas de case.
- Rien n’est installé tant que tu n’as pas confirmé un CHANGE.
6. Bouton Installer
- Il n’apparaît que dans la carte Installations, si le composant (ou un détail encore coché) manque sur ce VPS. Les actions READY sont en premier. Exemple : moteur Docker déjà là mais Compose / groupe docker encore cochés et non détectés → bouton Installer Docker (idempotent, ne réinstalle pas le moteur).
- S’il est déjà conforme ici : pas de bouton, mention « déjà installé ». Une IP neuve reverra le bouton.
- Exécutable aujourd’hui : Sécurité, Docker, Traefik, MariaDB, Compte deploy.
- Sécurité n’est complète que si UFW est actif, fail2ban tourne, le mot de passe SSH est coupé et root SSH est fermé. fail2ban seul ne suffit pas.
- Traefik et MariaDB : seulement après une sécurité complète sur ce VPS, et Docker présent. Traefik ouvre 80/443 sans exposer d’app. MariaDB n’écoute pas sur Internet.
- Compte deploy : même prérequis. Utilisateur deploy, groupe docker, pas de sudo, clé de l’agent copiée. Aucune app n’est lancée.
- Redis et backups : exécutables (Redis = conteneur ; backups = dump chiffré + copie locale). Une app simple : bande Applications. Un produit à plusieurs services : bande Plateformes (Enregistrer puis Déployer).
- Pendant analyse, clé ou install : un écran décrit le traitement. Ne ferme pas la page. Traefik / MariaDB : jusqu’à ~5 min (téléchargement d’image).
- À la fin, une fenêtre indique succès ou échec (et pourquoi). Clique Fermer. En cas d’échec, l’état déjà connu du VPS n’est pas effacé.
Ordre conseillé : clé SSH → analyser → sécurité → Docker → Traefik → MariaDB → compte deploy → app (Git).
7. Déployer une app
- Avant Déployer : un popup liste ce qui sera fait. Liens publics en https://. Traefik installe toujours HTTPS (Let’s Encrypt) + redirection HTTP→HTTPS.
- Domaine de base optionnel (ex. apps.mondomaine.com) : les apps deviennent https://mon-app.apps.mondomaine.com. DNS * → IP du VPS. Sans domaine : fallback lab identifiant.<IP>.sslip.io (aussi en HTTPS).
- Identifiant = slug court (mon-app), pas le domaine. Nom d’hôte = DNS complet. Git = https://… public, ou git@github.com:org/repo.git + clé lecture seule (Deploy key, pas d’écriture).
- Sur chaque ligne de la liste : Modifier (remplit le formulaire), Supprimer (retire la ligne locale, sans arrêter le conteneur VPS), Déployer / Mettre à jour.
- Premier essai conseillé : une petite application avec un Dockerfile à la racine (port interne, ex. 8080). Git HTTPS public, ou SSH + Deploy key. Nom d’hôte : DNS vers le VPS, ou app.<IP>.sslip.io.
- L’instance publique est cargo : page de preuve + /api/v1/health. Aucun CHANGE depuis Internet. Le cockpit reste sur 127.0.0.1:8088. Plus tard (V9) : cockpit en ligne derrière login, une session et des paramètres par opérateur.
- Le DNS du nom d’hôte vers l’IP du VPS est à toi (sauf astuce sslip). Si MariaDB est déjà sur ce VPS : à chaque Déployer, une base + user SQL dédiés à l’app (db.env sur le serveur, hors git).
7b. Déclarer une plateforme (plusieurs services)
- Pour un produit du type site + API (éventuellement admin, Redis, fichiers), utilise la bande Plateformes, pas trois apps 1:1 collées à la main.
- Identifiant = slug du produit. Chaque service = un Git (HTTPS public ou git@… + une clé lecture seule par dépôt), un port interne, des besoins (MariaDB, Redis, volume fichiers). Sous-dossier optionnel si le Dockerfile n’est pas à la racine du dépôt (monorepo).
- DNS : sous-domaines (api. / www.) ou chemins sur un seul hôte (/ + /api + /admin). En chemins, Traefik retire le préfixe : l’app écoute à la racine du conteneur.
- Variable de build typique : NEXT_PUBLIC_API_URL vers l’URL publique de l’API (sous-domaine ou https://hote/api).
- Enregistrer reste local. Déployer ouvre un popup de plan, puis un CHANGE : clone de chaque Git, build, Traefik HTTPS, aucun port publié. Redis / MariaDB doivent déjà être installés si tu les as cochés sur un service.
- Code source sur le serveur (case à cocher) : garder (défaut) laisse les clones sous platforms/…/src comme copie de secours ; ne pas garder les efface après le build (images seules). Les deux options sont valides — à choisir par plateforme.
- Chaque service a besoin d’un Dockerfile (racine du dépôt ou sous-dossier) ou d’un modèle choisi dans la liste « Dockerfile » : Next.js, Node, Spring Boot (Java 11 / 17 / 21). L’agent écrit alors Dockerfile.autopilot sur le serveur, sans toucher au dépôt. (Avant V7-06 : pas de modèle pour les plateformes.)
- Garder le préfixe : à cocher quand l’app sait déjà qu’elle vit sous /chemin (Next basePath, Spring context-path). Sinon Traefik retire le préfixe.
- Variables de build (une par ligne, CLE=valeur) : figées dans l’image, ex. NEXT_PUBLIC_API_URL. Variables d’exécution : lues au démarrage du conteneur, ex. SPRING_PROFILES_ACTIVE. {{HOST}} est remplacé par le nom d’hôte du service. Les secrets (mots de passe, tokens) s’affichent ******** : laisse-les ainsi pour garder la valeur enregistrée. Mieux : pose-les avec Secrets d’exécution (ligne suivante), ils ne sont alors jamais enregistrés sur ce poste.
- Secrets d’exécution (sous la console SQL) : choisis la plateforme, le service, le nom (ex. MAIL_PASSWORD) et la valeur (saisie masquée), puis Poser le secret (à confirmer). La valeur est écrite directement dans svc-<service>.local.env sur le VPS (600, compte deploy), prime sur une variable de même nom de la fiche, et le service est redémarré si la case est cochée. Elle n’est jamais enregistrée sur ce poste, jamais réaffichée, jamais dans le journal. Voir les noms posés liste les noms, jamais les valeurs. Retirer supprime la ligne. Refusé : apostrophe droite ' ou retour à la ligne dans la valeur. La plateforme doit avoir été déployée une fois.
- Redis privé : un Redis sans mot de passe réservé à la plateforme (réseau interne), pour une app qui ne sait pas envoyer de mot de passe Redis.
- Modèle site + back-office + API pré-remplit 3 services d’exemple (site Next /, back-office Next /admin, API Spring Boot /api avec base, cache et fichiers). Remplace l’identifiant et les dépôts Git par les tiens, ajuste les chemins, puis Enregistrer.
- Dépôts privés : GitHub refuse la même Deploy key sur deux dépôts. Sous la liste, une ligne par dépôt git@… : Générer, Copier, ouvrir le lien « Deploy keys », coller la clé avec Allow write access décoché.
- Console SQL (sous les clés Git, et à la dernière étape du parcours) : SQL dans la base de la plateforme, avec l’utilisateur de la plateforme. Lecture (SELECT, SHOW, DESCRIBE, EXPLAIN) immédiate, 1000 lignes max. Écriture (INSERT, UPDATE, DELETE, ALTER, CREATE…) : plan à confirmer, puis sauvegarde de toute la base sur le VPS (backups/…-before-sql-….sql.gz, 20 gardées) avant exécution. Arrêt à la première erreur. Refusé : DROP, TRUNCATE, droits, autres bases, fichiers du serveur, commandes client. Fichier .sql de 5 Mo max ; au-delà, « Restaurer les données ».
- Restaurer les données : dump SQL (.sql / .sql.gz) et/ou archive des fichiers (.tar.gz / .zip, contenu à la racine). À faire avant le premier Déployer pour une app qui ne crée pas sa base seule. La base et les fichiers déjà présents sont sauvegardés sur le VPS (/opt/vps-autopilot/platforms/<id>/backups) avant d’être remplacés. Préfère une base de démonstration aux données réelles. Si l’import échoue, la base revient automatiquement à cette sauvegarde et les services sont relancés. Erreur de clé étrangère (ERROR 1452) : décoche « Vérifier les clés étrangères pendant l’import » et relance.
- Garde en ligne : chaque Déployer installe sur le serveur un minuteur (vps-autopilot-keepalive) qui relance toutes les 2 minutes, et au démarrage, les services de plateforme arrêtés. Pour arrêter volontairement une plateforme plus de 2 minutes, crée /opt/vps-autopilot/platforms/<id>/.maintenance (pris en compte 2 h).
- Supprimer retire la fiche locale seulement (ne stoppe pas les conteneurs).
7c. Rapport d’audit pour un client

Bande Rapport (mode expert), après une analyse. Facultatif : le nom du client à afficher. Rapport d’audit client télécharge une page HTML ; ouvre-la puis Imprimer › PDF pour l’envoyer.
- Le rapport se fait sur la dernière analyse : aucune connexion, rien n’est modifié. Analyse d’abord pour un rapport à jour.
- Note de A à E sur 100 : chaque constat retire des points selon sa gravité (critique, élevé, moyen, faible). Un seul constat critique plafonne la note à D.
- Pour chaque constat : ce qui a été observé, le risque, ce qu’il faut faire. Les points forts sont listés à part.
7d. Sauvegardes et exercice de restauration

Installe d’abord Backups chiffrés (Installations). Le VPS sauvegarde alors chaque nuit vers 02:30 MariaDB (toutes les bases) et les fichiers déposés par les utilisateurs (volumes /app/data des plateformes et des apps) : deux fichiers chiffrés de même horodatage, 14 sauvegardes gardées dans /opt/vps-autopilot/backups. Un serveur équipé avant cette mise à jour apparaît « à installer » : réinstalle Backups chiffrés pour ajouter les fichiers. Bande Sauvegardes (mode expert) :
- Sauvegarder maintenant (à confirmer) : sauvegarde immédiate, copie sur ce poste, lecture complète.
- Copier la dernière : amène sur ce poste la sauvegarde de la nuit et son archive de fichiers (dans state/backups/<serveur>/) et les vérifie. Si la liaison coupe, la copie reprend où elle s’était arrêtée ; relancer « Copier la dernière » reprend aussi. Refusé sur un serveur en lecture seule.
- Vérifier : déchiffre et lit toute la copie. « Complète » = la fin du dump est présente ; le nombre de tables par base est affiché. Ligne « Fichiers des volumes » : nombre de fichiers par volume. « Inutilisable » = ne compte pas dessus.
- Exercice de restauration (à confirmer) : chaque base de la sauvegarde est importée dans une base jetable du VPS, ses tables sont comptées puis la base jetable est supprimée ; l’archive des fichiers est extraite dans un dossier jetable de /var/tmp et ses fichiers comptés par volume. Tes bases et volumes ne sont pas touchés. Fais-le au moins une fois par mois : une sauvegarde qui ne se restaure pas n’existe pas.
- Exercice automatique : depuis cette version, le VPS refait lui-même l’exercice chaque 1er du mois vers 04:00 (et une fois à l’installation) sur sa dernière sauvegarde : chaque base est importée dans une base jetable, chaque volume extrait dans /var/tmp, les tables et fichiers sont comptés contre le contenu de la sauvegarde, puis tout est supprimé. Le résultat s’affiche au-dessus de la liste après une analyse, et dans le rapport d’audit (échec = risque élevé ; plus de 40 jours sans exercice = constat faible). Un serveur équipé avant apparaît « à installer » : réinstalle Backups chiffrés.
- Copies sur ce poste : les 10 plus récentes par serveur sont gardées, plus la dernière dont l’exercice a réussi ; les plus anciennes (dump, archive des fichiers, fiches) sont supprimées après chaque nouvelle copie.
- Restaurer la plateforme (à confirmer) : n’apparaît que si la base ou le volume de fichiers de la plateforme est dans la sauvegarde. L’existant est d’abord copié sur le VPS ; le volume est remis à l’identique (les fichiers ajoutés depuis sont retirés, propriétaires et droits remis) ; si l’import ou l’extraction échoue, l’existant revient automatiquement.
- La clé de chiffrement est state/backup.key sur ce poste (et sur le VPS, lisible par root seul). Sans elle, aucune sauvegarde ne s’ouvre : garde-en une copie en lieu sûr.
- Apps (une app = un conteneur) : leurs fichiers sont sauvegardés, vérifiés et testés, mais la restauration depuis la console ne couvre que les plateformes.
7e. Journal des interventions

Bande Journal (mode expert) : chaque action lancée depuis la console sur ce serveur (analyse, installation, déploiement, sauvegarde, exercice, restauration, SQL, rapport d’audit) avec la date, le compte Windows qui l’a lancée, l’utilisateur SSH, le résultat et, en cas d’échec ou de refus, le message.
- Exporter (HTML) : page imprimable à joindre au compte rendu d’intervention (nom du client repris de la bande Rapport). Exporter (CSV) : pour un tableur.
- Le journal est sur ce poste, un fichier par serveur dans state/journal/ ; les réglages faits sans serveur sont dans _poste.jsonl. On n’y efface rien depuis la console.
- Jamais recopiés : le texte des requêtes SQL, les mots de passe, les variables d’environnement. Seuls l’identifiant de plateforme, le composant, le fichier de sauvegarde et la confirmation sont gardés.
7f. Fin de mission : retirer les accès de l’agent

À faire dans les 2 jours ouvrés après la fin du mandat. Procédure complète, avec la vérification du client à chaque étape : .docs/commercial/retrait-acces.md.
1. Dernières preuves : Analyser, Rapport d’audit client, Sauvegarder maintenant + Exercice de restauration, Journal › Exporter (HTML et CSV). Tout remettre au client.
2. Clé de chiffrement : remettre le contenu de state/backup.key par un canal convenu (jamais avec les sauvegardes).
3. Mots de passe connus pendant la mission (SMTP, hébergeur…) : le client les change.
4. Clés Git : supprimer les Deploy keys vps-autopilot-git-readonly… de chaque dépôt.
5. sudo : supprimer /etc/sudoers.d/90-vps-autopilot-temp et le fichier du compte de l’agent.
6. Clé SSH : retirer la ligne de la clé de l’agent de authorized_keys (chaque compte où elle est posée), supprimer le compte dédié s’il ne sert plus. Le client vérifie que la connexion est refusée.
7. Ce poste : Oublier le serveur, retirer ses plateformes et apps, supprimer state/backups/<serveur>/ à la date prévue, garder le journal le temps convenu.
8. Attestation de retrait signée, remise au client.
Les sauvegardes, l’exercice mensuel, la garde en ligne et les sites restent sur le serveur et continuent de tourner sans l’agent : ils appartiennent au client.

Alertes e-mail : si le compte SMTP était le tien, Retirer les alertes (bande Sauvegardes) avant de partir, ou laisse le client poser son propre compte.
7g. Alertes e-mail du serveur

Bande Sauvegardes, panneau Alertes e-mail. Le VPS envoie lui-même ses messages, même si ce poste est éteint.
- Quand : la sauvegarde de nuit échoue, l’exercice de restauration mensuel échoue (avec le détail tables / fichiers), et, si la case est cochée, un résumé après chaque exercice réussi (une preuve par mois pour le client).
- Compte SMTP : celui d’une boîte d’envoi (hébergeur mail, Brevo, Gmail avec mot de passe d’application…). 465 = SSL, 587 = STARTTLS. « Aucun » n’est accepté que pour un relais sur le serveur lui-même (127.0.0.1).
- Enregistrer et envoyer un essai (à confirmer) pose les réglages et envoie tout de suite un message d’essai ; le résultat (parti ou réponse du serveur SMTP) s’affiche. Envoyer un essai rejoue l’envoi seul.
- Mot de passe : écrit sur le VPS seulement (/opt/vps-autopilot/notify.env, 600, root), jamais sur ce poste, jamais réaffiché, jamais dans le journal. Laisser le champ vide garde celui déjà posé.
- L’analyse affiche l’état (actives, dernier envoi) et le rapport d’audit le juge : pas d’alerte = constat faible, dernier envoi en échec = constat moyen.
- Limite : un serveur éteint ou injoignable ne peut rien envoyer. Pas de supervision 24/7.
7h. Plateforme multi-comptes (profil platform)

ADR-046 / V9. Lancer avec --spring.profiles.active=platform (et PLATFORM_BOOTSTRAP_EMAIL pour le premier super-admin).
- Login : page /login.html — e-mail + mot de passe. Défaut usine : VpsAutopilot!ChangeMe (changé à la 1^re connexion sur /change-password.html). Lien magique encore dispo en lab.
- Admin UI : page /admin.html — comptes, permissions des rôles, assignations.
- Rôles : SUPER_ADMIN (toi), OPERATOR, VIEWER — permissions éditables.
- Assignation : rattacher un serveur à un compte ; sans ça, l’opérateur reçoit 403.
- Clés SSH : restent sur l’instance qui exécute (jamais dans le navigateur).
- La console locale sans profil platform (1.x) reste sans login sur 127.0.0.1.
8. Couleurs du tableau
- Vert doux — présent / sain
- Gris — absent (pas encore installé)
- Ambre — inconnu
- Rouge doux — à surveiller (SSH trop ouvert, pare-feu inactif, disque plein)
Le tableau est découpé en bandes : État du serveur, Logiciels, Applications et plateformes, Pile et installations, Rapport, Sauvegardes. Filet à gauche, teintes calmes.
9. Ce que l’agent ne fera pas
- Ouvrir le cockpit Installer/Déployer sur Internet sans login (cargo = preuve seulement ; profil platform = login + RBAC, ADR-046).
- Cibler un serveur interdit ou déjà bloqué par l’agent.
- Installer Apache, PHP ou Nginx directement sur l’hôte.
- Lancer un shell root inventé par une IA.
- Afficher un faux serveur (4 vCPU « démo ») à la place du tien.

VPS Autopilot

Trois offres, une méthode

Audit

Mise en ligne

Maintenance

Trois niveaux de risque

READ

CHANGE

DESTRUCTIVE

Prêt à piloter un serveur ?

Tout faire, dans l’ordre, sans surprise

1. À quoi sert l’agent

2. Ouvrir le cockpit et remplir les paramètres

3. Clé SSH (obligatoire pour analyser)

A — Cockpit (le plus simple)

B — Console web de l’hébergeur

C — PowerShell

D — L’admin du serveur crée le compte de l’agent (aucun accès partagé)

3b. Donner temporairement les droits root au compte de l’agent

4. Analyser

4b. Le parcours guidé (par défaut)

5. Choisir quoi installer (après l’analyse)

6. Bouton Installer

7. Déployer une app

7b. Déclarer une plateforme (plusieurs services)

7c. Rapport d’audit pour un client

7d. Sauvegardes et exercice de restauration

7e. Journal des interventions

7f. Fin de mission : retirer les accès de l’agent

7g. Alertes e-mail du serveur

7h. Plateforme multi-comptes (profil platform)

8. Couleurs du tableau

9. Ce que l’agent ne fera pas

—

—

READ

—

—

—

—

Déployer une app

Déclarer une plateforme

Installations

Que doit installer l’agent ?

Une sauvegarde ne compte que si elle se restaure

Qui a fait quoi, quand, avec quel résultat

7h. Plateforme multi-comptes (profil `platform`)