diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1bd86e5..a675780 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,69 @@
 # CHANGELOG — Set-OPS
 
+## 2026-09-02 (6) — Deuxieme reconstruction de validation : une course que la premiere n'avait pas montree
+
+**56 preuves. Reconstruction : 14/14 hotes, 0 echec. `make valider` : 0 echec sur 13
+hotes.** Chezlepro a ete rasee une seconde fois et refaite depuis le gabarit minimal, pour
+eprouver tout ce qui avait change depuis la veille.
+
+### Ce que ce cycle a VALIDE
+
+Les corrections de la veille ont toutes tenu en conditions reelles :
+
+- **La garde de clonage** — `edge-mta-01`, `infra-mail-01` et `ops-01` ont clone « AVEC
+  AVERTISSEMENT ». Les trois auraient ete declarees perdues l'avant-veille ; le clonage
+  continue, et l'avertissement s'affiche au lieu d'etre avale.
+- **La degradation de `client_artefacts`** — `infra-pki-01` et `infra-dns-01`, premieres
+  machines debout, sont restees sur le cache du SITE et l'ont dit. Elles ont bascule sur
+  celui du locataire dans la passe principale.
+- **`enabled` a la frontiere, la delegation de zone, le durcissement du site** — aucun
+  incident.
+
+### LE DEFAUT QUE SEULE UNE SECONDE RECONSTRUCTION POUVAIT MONTRER
+
+`forge-01` bouclait :
+
+    migration[v14a_add-foreign-keys-collaboration] ... failure to delete inconsistent
+    records before foreign key sync: la relation « collaboration » n'existe pas
+
+La base contenait **5 tables** avec `version=305` deja inscrite. A moitie faite.
+
+**C'est une course.** Le role DEMARRE Forgejo, qui entame son initialisation de premier
+lancement — creation du schema et migrations, plusieurs dizaines de secondes. Puis
+`flush_handlers` le REDEMARRE, parce qu'`app.ini` vient de changer. Redemarre au milieu,
+il laisse la version cible inscrite et le schema absent.
+
+Il ne s'en releve jamais seul : `ORM engine initialization attempt #1/10, #2/10…`
+indefiniment. Le service reste `active` — il n'a pas plante, il reessaie — et n'ecoute
+jamais son port. Une machine verte qui ne sert rien.
+
+**Pourquoi la premiere reconstruction ne l'avait pas vu.** Aux deploiements suivants la
+base est deja migree, le premier demarrage est instantane, et le redemarrage ne tombe au
+milieu de rien. Le defaut n'existe que sur une base VIERGE, et meme la il depend du
+timing. Il a fallu deux reconstructions completes.
+
+La correction attend la fin du premier demarrage AVANT tout redemarrage. Le schema a ete
+remis a zero — il ne contenait rien — et Forgejo est monte du premier coup.
+
+### La chaine de sauvegarde, prouvee sur une flotte entierement neuve
+
+Neuf detenteurs d'etat ont depose sur le depot du SITE, puis chacun a verifie SON depot
+distant et l'a rapporte a l'Icinga de l'ecosysteme :
+
+    collab-01      OK : instantane il y a 0 h, 108 fichier(s)
+    data-sql-01    OK : instantane il y a 0 h, 1 fichier(s)
+    edge-mta-01    OK : instantane il y a 0 h, 145 fichier(s)
+    forge-01       OK : instantane il y a 0 h, 29 fichier(s)
+    idm-01         OK : instantane il y a 0 h, 1 fichier(s)
+    infra-mail-01  OK : instantane il y a 0 h, 7 fichier(s)
+    infra-pki-01   OK : instantane il y a 0 h, 12 fichier(s)
+    web-dorsal-01  N'EMPORTE RIEN — a confirmer
+    web-frontal-01 N'EMPORTE RIEN — a confirmer
+
+Le cycle complet — deposer chez l'hebergeur, verifier avec la cle qu'on est seul a
+detenir, rapporter a sa propre supervision — tourne sur des machines nees il y a une
+heure.
+
 ## 2026-09-02 (5) — La verification suit la cle : chaque noeud constate SON depot
 
 **56 preuves. `make valider` : 0 echec sur 13 hotes**, test de restitution compris.
diff --git a/roles/serveur_forgejo/tasks/main.yml b/roles/serveur_forgejo/tasks/main.yml
index 3d4c9c1..ccb582c 100644
--- a/roles/serveur_forgejo/tasks/main.yml
+++ b/roles/serveur_forgejo/tasks/main.yml
@@ -286,10 +286,37 @@
     state: started
     daemon_reload: true
 
+# LAISSER LE PREMIER DEMARRAGE FINIR AVANT DE L'INTERROMPRE (2026-09-02).
+#
+# Au TOUT PREMIER demarrage, Forgejo cree son schema et deroule ses migrations — plusieurs
+# dizaines de secondes. Le `flush_handlers` ci-dessous le REDEMARRE parce qu'`app.ini`
+# vient de changer. Redemarre au milieu, il laisse une base a moitie faite : la version
+# cible est deja inscrite dans `version`, le schema ne l'est pas.
+#
+# Il ne s'en releve jamais seul. La migration suivante cherche une table qui n'a jamais
+# ete creee et echoue en boucle :
+#
+#   migration[v14a_add-foreign-keys-collaboration] ... failure to delete inconsistent
+#   records before foreign key sync: la relation « collaboration » n'existe pas
+#
+# ORM engine initialization attempt #1/10, #2/10... indefiniment. Le service reste
+# `active` — il n'a pas plante, il reessaie — et n'ecoute jamais son port.
+#
+# CE QUI RENDAIT CE DEFAUT INVISIBLE : aux deploiements SUIVANTS la base est deja migree,
+# le premier demarrage est instantane, et le redemarrage ne tombe au milieu de rien. Il
+# ne se manifeste que sur une base VIERGE — donc a la reconstruction, et pas a chaque
+# fois : c'est une course. Il a fallu deux reconstructions completes pour le voir.
+- name: Attendre la fin du PREMIER demarrage avant tout redemarrage
+  ansible.builtin.wait_for:
+    host: 127.0.0.1
+    port: "{{ serveur_forgejo_http_port }}"
+    timeout: 300
+  when: not ansible_check_mode
+
 - name: Appliquer les redemarrages Forgejo (config a jour) avant admin/OAuth2
   ansible.builtin.meta: flush_handlers
 
-- name: Attendre que Forgejo reponde (migrations terminees)
+- name: Attendre que Forgejo reponde (apres redemarrage)
   ansible.builtin.wait_for:
     host: 127.0.0.1
     port: "{{ serveur_forgejo_http_port }}"