Set-OPS-Public/wiki/Reprendre-l-écosystème.md

Reprendre l'écosystème — tu viens d'hériter de tout ça

Pour qui : l'exploitant qui reprend un écosystème Set-OPS déjà déployé — livraison, passation, ou retour après six mois. Ce n'est pas une unité d'apprentissage : c'est un ordre d'opérations. Il ne contient presque rien en propre, il t'envoie au bon endroit dans le bon ordre.

La règle avant toutes les autres : ce wiki est publié depuis le dépôt (wiki/). Une page modifiée dans l'interface de la forge est détruite à la publication suivante. On lit ici, on écrit dans le dépôt.

---

① Dans quel état hérites-tu ?

Avant de toucher à quoi que ce soit. Tu ne sais pas encore si tu reprends un système sain ou une panne déjà commencée, et personne ne te le dira. Ces commandes ne modifient rien et sortent en erreur s'il y a un écart entre ce qui tourne et ce que le plan décrit.

make instance-courante   # vers quel écosystème pointe l'instance active ?
make prouver             # le dépôt est-il cohérent avec lui-même ? (aucun appel réseau)

make identite-plan       # realm, fédération LDAP, mappeurs, politique de mot de passe, comptes
make certificats-plan    # ce que le disque porte contre ce que la mémoire sert
make expositions-plan    # chaque service publié répond-il — depuis l'edge et depuis ton poste
make postgresql-plan     # le chiffrement est-il imposé, et à quels réseaux
make courriel-plan       # Postfix → LDAP → LMTP → Dovecot → IMAP, file d'attente comprise
make frontiere-mesurer   # ce qui n'est pas déclaré à la frontière est-il refusé ?

Quelques minutes pour ce qui demandait une journée d'enquête à la main. C'est aussi le premier réflexe après la reprise : après tout changement, après une panne, avant d'appeler quelqu'un.

make prouver ne suffit pas, et c'est important de le savoir tout de suite. Il lit le dépôt, jamais les machines. Le 2026-08-08, l'autorité de certification de la flotte est restée expirée huit heures sous un harnais entièrement vert. Voir Vérifier le déployé.

Détail de ce que chaque devis vérifie — et de ce qu'il ne vérifie pas : docs/devis-services.md.

---

② Entrer

Un prérequis et trois pièges, tous à la première connexion. Le runbook complet est dans docs/autorisation.md §6 ; voici l'ordre et la raison de chaque geste.

1. La clé de voûte. Le mot de passe de la voûte est lu depuis ANSIBLE_VAULT_PASSWORD_FILE (~/.config/setops-vault-pass par défaut). Sans ce fichier, rien n'est possible — ni les devis ci-dessus, ni un déploiement. C'est la première chose à sauvegarder hors de la machine, avec les vault.yml de chaque instance, qui ne sont pas versionnés.

2. Le mot de passe d'amorçage, à changer avant tout le reste (§6.1). L'annuaire refuse toute opération tant qu'il n'est pas changé, sauf le changement lui-même. Ce n'est pas optionnel.

3. La racine mène à la mauvaise console (§6.2). https://auth.<domaine>/ redirige vers la console du realm master, où ton compte n'existe pas. Keycloak répond « invalid username or password » — exact, et parfaitement trompeur : le mot de passe est bon, c'est la porte qui ne l'est pas.

4. Fais confiance à l'AC interne (§6.3), sinon ton navigateur criera sur chaque service. make ca-racine récupère la racine et son empreinte, make ca-empreinte la relit sur l'AC elle-même — c'est le témoin auquel comparer avant d'installer quoi que ce soit.

Et si tu te fermes dehors : §6.5.

---

③ De quoi c'est fait

Rien de tout ça n'est écrit à la main — tout se dérive du plan, et c'est le sujet de Le plan & l'adressage dérivé. Demande-le plutôt que de le lire quelque part :

make inventaire                    # vérifie l'inventaire et affiche le graphe des groupes
make hote-afficher HOTE=<nom>      # tout ce que le plan dérive pour un hôte
make inventaire-ui                 # la même chose, en console web

Pour comprendre	Va lire
ce que fait chaque service et pourquoi celui-là	Accueil du wiki, unités d'apprentissage
qui parle à qui, sur quel port	docs/flux-conception.md
comment un service en atteint un autre	Liaisons (bindings)
la carte du dépôt, pour modifier	docs/carte-set-ops.md

---

④ Quand ça casse

Les procédures : docs/runbooks-exploitation.md.

Deux réflexes qui évitent la moitié des fausses pistes :

• Un certificat renouvelé sur disque n'est pas un certificat servi. Tant que nginx, Postfix ou slapd n'ont pas été rechargés, ils servent l'ancien depuis la mémoire. make certificats-plan compare les deux, justement.
• Répare avec make deployer, constate avec les devis. Ce sont deux gestes différents, et les confondre fait perdre l'information au moment où elle sert.

---

⑤ Ce qui va te mentir

Un écosystème ne tombe pas en panne franchement : il te donne d'abord un signal faux. Un connect() TCP qui réussit vers le vide, une commande qui affiche « changed ✔ » sans avoir rien écrit, un tableau de bord vert au-dessus d'une autorité expirée.

Chacun coûte une demi-journée à qui le rencontre sans être prévenu. Le catalogue — chaque symptôme trompeur avec le contrôle qui tranche — fait l'objet de la page suivante, « Ce qui va te mentir », en cours d'écriture.

En attendant, la règle générale : quand une mesure accuse un composant, vérifie d'abord que ton instrument mesure ce que tu crois. Une sonde porte toujours un contrôle — une cible dont tu connais déjà la réponse. Si le contrôle ment, ne conclus rien.

---

Ce que tu dois changer en priorité

Avant d'oublier, et c'est dans docs/autorisation.md §6.8 : le mot de passe d'amorçage (section ② ci-dessus), les secrets restants de la voûte, et tout accès hérité de la livraison qui n'est pas à toi.