L’onboarding, pas à pas

L’app mène un serveur de son adresse à une machine qui travaille. Certaines étapes n’apparaissent que quand elles s’appliquent : l’agent quand il manque ou qu’il est en retard, la sauvegarde et les données quand votre organisation a des sauvegardes. Le rail en haut compte les étapes que ce serveur va vraiment traverser. Vous pouvez revenir en arrière tant que rien n’est installé ; ensuite, le chemin du retour passe par la suite, et un onboarding interrompu reprend là où il s’était arrêté.

L’app doit d’abord être installée et liée à votre compte, pour une organisation dont la licence est valide : gratuite pour ses premiers serveurs, avec une licence au-delà. Sans elle, chaque étape attend là où elle est et dit pourquoi.

1. Serveur

Choisissez un serveur que l’app connaît déjà, ou ajoutez-en un : son adresse, un port s’il n’est pas 22, et un compte root ou sudo pour la première connexion. Puis la clé : l’app génère une clé ed25519 pour ce serveur, garde la moitié privée sur votre disque, et écrit la moitié publique dans l’authorized_keys du serveur — avec le mot de passe du compte si vous le donnez, ou par une commande que vous collez vous-même. Elle se connecte ensuite avec cette seule clé avant d’aller plus loin. Voir votre clé et connecter l’app.

2. Inspection

La sonde lit la distribution, l’architecture, la mémoire, le disque libre et ce qui est déjà installé, et rend un verdict : prêt à être installé, déjà géré par Pupitre, déjà occupé par d’autres logiciels — auxquels Pupitre ne touche pas — ou incompatible, avec les raisons et ce qui permettrait de continuer. Elle n’écrit rien.

3. Agent

Seulement quand l’agent manque ou qu’il est en retard. L’app déclare le serveur à votre organisation, copie l’agent signé par la session SSH ouverte, compare ce que le serveur a reçu à la somme de contrôle de la version, et le démarre. Une machine qui porte déjà son identité n’est pas déclarée deux fois : une connexion coupée entre l’échange et sa réponse se reprend, elle n’est pas relancée.

4. Sauvegarde

Seulement quand votre organisation a des sauvegardes. Repartez de l’une d’elles, ou d’un serveur vierge. Repartir d’une sauvegarde demande le bucket connecté dans l’app et la phrase de passe des sauvegardes, vérifiée sur votre ordinateur avant que le serveur ne soit sollicité ; le serveur prend alors la configuration de cette sauvegarde, et les deux étapes suivantes s’ouvrent sur ce qu’elle contenait. Les données elles-mêmes reviennent à la fin. Voir les sauvegardes.

5. Services

Le catalogue, groupé par catégorie. core.system et core.hardening sont toujours inclus. Chaque module annonce ce qu’il installe et ce qu’il vous demandera, et des préréglages couvrent les formes courantes.

6. Configuration

Versions, ports, comptes, secrets. Chaque champ dit ce qu’il attend et refuse ce qui n’a pas la forme voulue, à sa hauteur, au moment où vous le remplissez. Une bulle à côté du libellé dit où trouver une valeur : les permissions exactes d’un token, la page qui le délivre, ce qu’il en coûte de se tromper. L’action est en bas.

Un module qui passe par un de vos comptes — Cloudflare, GitHub, 1Password, Neon, Vercel, Supabase, Stripe — demande ce compte ici, au-dessus de ses propres questions. Vous donnez chaque token une fois, pour tous vos serveurs, et l’app vérifie le compte qu’il ouvre au moment où vous le collez. Le token reste dans le trousseau de votre ordinateur ; ce qu’un serveur en a besoin voyage sur la ligne de secrets de l’installation, par l’entrée standard de la session SSH, et n’est jamais réaffiché.

Avant de lancer, l’app demande au serveur de peser la configuration : un port que quelque chose écoute déjà, un dossier qui est un fichier, un fuseau que la machine ignore. Ce qu’il refuse revient sur le champ concerné.

7. Installation

Étape par étape, en direct : le module, l’étape, le compteur, la durée. Une configuration qui ne tiendrait pas est refusée avant la première étape, machine intacte et champs nommés. Une étape qui échoue n’arrête pas les autres modules : elle est notée, et l’app propose de rejouer ce module. Chaque étape est idempotente, donc relancer l’installation ne fait aucun dégât. Voir le dépannage.

8. Sécurité

La sécurisation crée le compte de travail dev, y copie vos clés, vérifie que votre clé l’ouvre, puis coupe les mots de passe, pose AllowUsers, démarre ufw et fail2ban, et ferme root en dernier. Si la vérification échoue, root n’est pas fermé et l’app continue avec le premier compte. L’option « Garder l’accès root » laisse root joignable par clé SSH — jamais par mot de passe — et applique tout le reste. L’app se reconnecte ensuite en dev.

9. Données

Seulement quand le serveur est reparti d’une sauvegarde. Choisissez les parties à ramener — bases, projets, compte dev, dossiers en plus — et l’app les restaure, puis démarre les projets. Ou laissez les données dans le bucket.

10. Prêt

L’app dit avec quel compte elle se connecte et si root est fermé. L’onboarding est fini et ne revient pas.

Après l’onboarding

L’app est désormais la fenêtre sur cette machine : tableau de bord, projets, terminaux, agents, services. Votre premier projet est une URL git ou un dossier sur la machine : l’agent le clone, installe ses dépendances, le démarre dans tmux, et rapporte le port, l’URL et les logs. Voir les projets. Ajouter un module plus tard, c’est le même écran de catalogue, sans le reste du parcours.