fix(ci): use local pagefind binary instead of npx wrapper

Reviewed-on: #299

.gitea/ISSUE_TEMPLATE/correction-paragraphe.md

@@ -3,7 +3,7 @@ name: "Correction paragraphe"
 about: "Proposer une correction ciblée (un paragraphe) avec justification."
 ---
 
-## Chemin (ex: /archicratie/prologue/)
+## Chemin (ex: /archicrat-ia/prologue/)
 <!-- obligatoire -->
 /...
 

.gitea/ISSUE_TEMPLATE/verification-factuelle.md

@@ -3,7 +3,7 @@ name: "Vérification factuelle / sources"
 about: "Signaler une assertion à sourcer ou à corriger (preuves, références)."
 ---
 
-## Chemin (ex: /archicratie/prologue/)
+## Chemin (ex: /archicrat-ia/prologue/)
 <!-- obligatoire -->
 /...
 

.gitea/workflows/anno-apply-pr.yml

@@ -0,0 +1,450 @@
+name: Anno Apply (PR)
+
+on:
+  issues:
+    types: [labeled]
+  workflow_dispatch:
+    inputs:
+      issue:
+        description: "Issue number to apply"
+        required: true
+
+env:
+  NODE_OPTIONS: --dns-result-order=ipv4first
+
+defaults:
+  run:
+    shell: bash
+
+concurrency:
+  group: anno-apply-${{ github.event.issue.number || github.event.issue.index || inputs.issue || 'manual' }}
+  cancel-in-progress: true
+
+jobs:
+  apply-approved:
+    runs-on: mac-ci
+    container:
+      image: mcr.microsoft.com/devcontainers/javascript-node:22-bookworm
+
+    steps:
+      - name: Tools sanity
+        run: |
+          set -euo pipefail
+          git --version
+          node --version
+          npm --version
+
+      - name: Derive context (event.json / workflow_dispatch)
+        env:
+          INPUT_ISSUE: ${{ inputs.issue }}
+          FORGE_API: ${{ vars.FORGE_API || vars.FORGE_BASE || vars.FORGE_BASE_URL }}
+        run: |
+          set -euo pipefail
+          export EVENT_JSON="/var/run/act/workflow/event.json"
+          test -f "$EVENT_JSON" || { echo "Missing $EVENT_JSON"; exit 1; }
+
+          node --input-type=module - <<'NODE' > /tmp/anno.env
+          import fs from "node:fs";
+
+          const ev = JSON.parse(fs.readFileSync(process.env.EVENT_JSON, "utf8"));
+          const repoObj = ev?.repository || {};
+
+          const cloneUrl =
+            repoObj?.clone_url ||
+            (repoObj?.html_url ? (repoObj.html_url.replace(/\/$/,"") + ".git") : "");
+
+          if (!cloneUrl) throw new Error("No repository clone_url/html_url in event.json");
+
+          let owner =
+            repoObj?.owner?.login ||
+            repoObj?.owner?.username ||
+            (repoObj?.full_name ? repoObj.full_name.split("/")[0] : "");
+
+          let repo =
+            repoObj?.name ||
+            (repoObj?.full_name ? repoObj.full_name.split("/")[1] : "");
+
+          if (!owner || !repo) {
+            const m = cloneUrl.match(/[:/](?<o>[^/]+)\/(?<r>[^/]+?)(?:\.git)?$/);
+            if (m?.groups) {
+              owner = owner || m.groups.o;
+              repo = repo || m.groups.r;
+            }
+          }
+          if (!owner || !repo) throw new Error("Cannot infer owner/repo");
+
+          const defaultBranch = repoObj?.default_branch || "main";
+
+          const issueNumber =
+            ev?.issue?.number ||
+            ev?.issue?.index ||
+            (process.env.INPUT_ISSUE ? Number(process.env.INPUT_ISSUE) : 0);
+
+          if (!issueNumber || !Number.isFinite(Number(issueNumber))) {
+            throw new Error("No issue number in event.json or workflow_dispatch input");
+          }
+
+          let labelName = "workflow_dispatch";
+          const lab = ev?.label;
+          if (typeof lab === "string") labelName = lab;
+          else if (lab && typeof lab === "object" && typeof lab.name === "string") labelName = lab.name;
+          else if (ev?.label?.name) labelName = ev.label.name;
+
+          const u = new URL(cloneUrl);
+          const origin = u.origin;
+
+          const apiBase = (process.env.FORGE_API && String(process.env.FORGE_API).trim())
+            ? String(process.env.FORGE_API).trim().replace(/\/+$/,"")
+            : origin;
+
+          function sh(s) { return JSON.stringify(String(s)); }
+
+          process.stdout.write([
+            `CLONE_URL=${sh(cloneUrl)}`,
+            `OWNER=${sh(owner)}`,
+            `REPO=${sh(repo)}`,
+            `DEFAULT_BRANCH=${sh(defaultBranch)}`,
+            `ISSUE_NUMBER=${sh(issueNumber)}`,
+            `LABEL_NAME=${sh(labelName)}`,
+            `API_BASE=${sh(apiBase)}`
+          ].join("\n") + "\n");
+          NODE
+
+          echo "context:"
+          sed -n '1,120p' /tmp/anno.env
+
+      - name: Early gate (label event fast-skip, but tolerant)
+        run: |
+          set -euo pipefail
+          source /tmp/anno.env
+
+          echo "event label = $LABEL_NAME"
+
+          if [[ "$LABEL_NAME" != "state/approved" && "$LABEL_NAME" != "workflow_dispatch" && "$LABEL_NAME" != "" && "$LABEL_NAME" != "[object Object]" ]]; then
+            echo "label=$LABEL_NAME => skip early"
+            echo "SKIP=1" >> /tmp/anno.env
+            echo "SKIP_REASON=\"label_not_approved_event\"" >> /tmp/anno.env
+            exit 0
+          fi
+
+          echo "continue to API gating (issue=$ISSUE_NUMBER)"
+
+      - name: Fetch issue + hard gate on labels + Type
+        env:
+          FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
+        run: |
+          set -euo pipefail
+          source /tmp/anno.env
+          [[ "${SKIP:-0}" != "1" ]] || { echo "skipped"; exit 0; }
+
+          test -n "${FORGE_TOKEN:-}" || { echo "Missing secret FORGE_TOKEN"; exit 1; }
+
+          curl -fsS \
+            -H "Authorization: token $FORGE_TOKEN" \
+            -H "Accept: application/json" \
+            "$API_BASE/api/v1/repos/$OWNER/$REPO/issues/$ISSUE_NUMBER" \
+            -o /tmp/issue.json
+
+          node --input-type=module - <<'NODE' >> /tmp/anno.env
+          import fs from "node:fs";
+
+          const issue = JSON.parse(fs.readFileSync("/tmp/issue.json", "utf8"));
+          const body = String(issue.body || "").replace(/\r\n/g, "\n");
+
+          const labels = Array.isArray(issue.labels)
+            ? issue.labels.map(l => String(l.name || "")).filter(Boolean)
+            : [];
+          const hasApproved = labels.includes("state/approved");
+
+          function pickLine(key) {
+            const re = new RegExp(`^\\s*${key}\\s*:\\s*([^\\n\\r]+)`, "mi");
+            const m = body.match(re);
+            return m ? m[1].trim() : "";
+          }
+
+          const typeRaw = pickLine("Type");
+          const type = String(typeRaw || "").trim().toLowerCase();
+
+          const allowedAnno = new Set(["type/media", "type/reference", "type/comment"]);
+          const proposerTypes = new Set(["type/correction", "type/fact-check"]);
+
+          const out = [];
+          out.push(`ISSUE_TYPE=${JSON.stringify(type)}`);
+
+          if (!hasApproved) {
+            out.push(`SKIP=1`);
+            out.push(`SKIP_REASON=${JSON.stringify("not_approved_label_present")}`);
+            process.stdout.write(out.join("\n") + "\n");
+            process.exit(0);
+          }
+
+          if (!type) {
+            out.push(`SKIP=1`);
+            out.push(`SKIP_REASON=${JSON.stringify("missing_type")}`);
+          } else if (allowedAnno.has(type)) {
+            // proceed
+          } else if (proposerTypes.has(type)) {
+            out.push(`SKIP=1`);
+            out.push(`SKIP_REASON=${JSON.stringify("proposer_type:" + type)}`);
+          } else {
+            out.push(`SKIP=1`);
+            out.push(`SKIP_REASON=${JSON.stringify("unsupported_type:" + type)}`);
+          }
+
+          process.stdout.write(out.join("\n") + "\n");
+          NODE
+
+          echo "gating result:"
+          grep -E '^(ISSUE_TYPE|SKIP|SKIP_REASON)=' /tmp/anno.env || true
+
+      - name: Comment issue if skipped (unsupported / missing Type only)
+        if: ${{ always() }}
+        env:
+          FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
+        run: |
+          set -euo pipefail
+          source /tmp/anno.env || true
+
+          [[ "${SKIP:-0}" == "1" ]] || exit 0
+
+          if [[ "${SKIP_REASON:-}" == "not_approved_label_present" || "${SKIP_REASON:-}" == "label_not_approved_event" ]]; then
+            echo "skip reason=${SKIP_REASON} -> no comment"
+            exit 0
+          fi
+
+          if [[ "${SKIP_REASON:-}" == proposer_type:* ]]; then
+            echo "proposer ticket detected -> anno stays silent"
+            exit 0
+          fi
+
+          test -n "${FORGE_TOKEN:-}" || exit 0
+
+          REASON="${SKIP_REASON:-}"
+          TYPE="${ISSUE_TYPE:-}"
+
+          if [[ "$REASON" == unsupported_type:* ]]; then
+            MSG="Ticket #${ISSUE_NUMBER} ignored: unsupported Type (${TYPE}). Supported types: type/media, type/reference, type/comment."
+          else
+            MSG="Ticket #${ISSUE_NUMBER} ignored: missing or unreadable 'Type:'. Expected: type/media|type/reference|type/comment"
+          fi
+
+          PAYLOAD="$(node --input-type=module -e 'console.log(JSON.stringify({body: process.argv[1] || ""}))' "$MSG")"
+
+          curl -fsS -X POST \
+            -H "Authorization: token $FORGE_TOKEN" \
+            -H "Content-Type: application/json" \
+            "$API_BASE/api/v1/repos/$OWNER/$REPO/issues/$ISSUE_NUMBER/comments" \
+            --data-binary "$PAYLOAD"
+
+      - name: Checkout default branch
+        run: |
+          set -euo pipefail
+          source /tmp/anno.env
+          [[ "${SKIP:-0}" != "1" ]] || { echo "skipped"; exit 0; }
+
+          rm -rf .git
+          git init -q
+          git remote add origin "$CLONE_URL"
+          git fetch --depth 1 origin "$DEFAULT_BRANCH"
+          git -c advice.detachedHead=false checkout -q FETCH_HEAD
+          git log -1 --oneline
+
+      - name: Install deps
+        run: |
+          set -euo pipefail
+          source /tmp/anno.env
+          [[ "${SKIP:-0}" != "1" ]] || { echo "skipped"; exit 0; }
+          npm ci --no-audit --no-fund
+
+      - name: Check apply script exists
+        run: |
+          set -euo pipefail
+          source /tmp/anno.env
+          [[ "${SKIP:-0}" != "1" ]] || { echo "skipped"; exit 0; }
+          test -f scripts/apply-annotation-ticket.mjs || {
+            echo "missing scripts/apply-annotation-ticket.mjs on $DEFAULT_BRANCH"
+            ls -la scripts | sed -n '1,200p' || true
+            exit 1
+          }
+
+      - name: Build dist (needed for --verify)
+        run: |
+          set -euo pipefail
+          source /tmp/anno.env
+          [[ "${SKIP:-0}" != "1" ]] || { echo "skipped"; exit 0; }
+
+          npm run build
+
+          test -f dist/para-index.json || {
+            echo "missing dist/para-index.json after build"
+            ls -la dist | sed -n '1,200p' || true
+            exit 1
+          }
+          echo "dist/para-index.json present"
+
+      - name: Apply ticket on bot branch (strict+verify, commit)
+        continue-on-error: true
+        env:
+          FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
+          BOT_GIT_NAME: ${{ secrets.BOT_GIT_NAME }}
+          BOT_GIT_EMAIL: ${{ secrets.BOT_GIT_EMAIL }}
+        run: |
+          set -euo pipefail
+          source /tmp/anno.env
+          [[ "${SKIP:-0}" != "1" ]] || { echo "skipped"; exit 0; }
+          test -d .git || { echo "not a git repo (checkout failed)"; echo "APPLY_RC=90" >> /tmp/anno.env; exit 0; }
+
+          test -n "${FORGE_TOKEN:-}" || { echo "Missing secret FORGE_TOKEN"; exit 1; }
+
+          git config user.name  "${BOT_GIT_NAME:-archicratie-bot}"
+          git config user.email "${BOT_GIT_EMAIL:-bot@archicratie.local}"
+
+          START_SHA="$(git rev-parse HEAD)"
+          TS="$(date -u +%Y%m%d-%H%M%S)"
+          BR="bot/anno-${ISSUE_NUMBER}-${TS}"
+          echo "BRANCH=$BR" >> /tmp/anno.env
+          git checkout -b "$BR"
+
+          export FORGE_API="$API_BASE"
+          export GITEA_OWNER="$OWNER"
+          export GITEA_REPO="$REPO"
+
+          LOG="/tmp/apply.log"
+          set +e
+          node scripts/apply-annotation-ticket.mjs "$ISSUE_NUMBER" --strict --verify --commit >"$LOG" 2>&1
+          RC=$?
+          set -e
+
+          echo "APPLY_RC=$RC" >> /tmp/anno.env
+
+          echo "== apply log (tail) =="
+          tail -n 180 "$LOG" || true
+
+          END_SHA="$(git rev-parse HEAD)"
+
+          if [[ "$RC" -ne 0 ]]; then
+            echo "NOOP=0" >> /tmp/anno.env
+            exit 0
+          fi
+
+          if [[ "$START_SHA" == "$END_SHA" ]]; then
+            echo "NOOP=1" >> /tmp/anno.env
+          else
+            echo "NOOP=0" >> /tmp/anno.env
+            echo "END_SHA=$END_SHA" >> /tmp/anno.env
+          fi
+
+      - name: Comment issue on failure (strict/verify/etc)
+        if: ${{ always() }}
+        env:
+          FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
+        run: |
+          set -euo pipefail
+          source /tmp/anno.env || true
+          [[ "${SKIP:-0}" != "1" ]] || { echo "skipped"; exit 0; }
+
+          RC="${APPLY_RC:-0}"
+          if [[ "$RC" == "0" ]]; then
+            echo "no failure detected"
+            exit 0
+          fi
+
+          test -n "${FORGE_TOKEN:-}" || exit 0
+
+          if [[ -f /tmp/apply.log ]]; then
+            BODY="$(tail -n 160 /tmp/apply.log | sed 's/\r$//')"
+          else
+            BODY="(no apply log found)"
+          fi
+
+          MSG="apply-annotation-ticket failed (rc=${RC}).\n\n\`\`\`\n${BODY}\n\`\`\`\n"
+          PAYLOAD="$(node --input-type=module -e 'console.log(JSON.stringify({body: process.argv[1] || ""}))' "$MSG")"
+
+          curl -fsS -X POST \
+            -H "Authorization: token $FORGE_TOKEN" \
+            -H "Content-Type: application/json" \
+            "$API_BASE/api/v1/repos/$OWNER/$REPO/issues/$ISSUE_NUMBER/comments" \
+            --data-binary "$PAYLOAD"
+
+      - name: Push bot branch
+        if: ${{ always() }}
+        env:
+          FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
+        run: |
+          set -euo pipefail
+          source /tmp/anno.env || true
+          [[ "${SKIP:-0}" != "1" ]] || exit 0
+
+          [[ "${APPLY_RC:-0}" == "0" ]] || { echo "apply failed -> skip push"; exit 0; }
+          [[ "${NOOP:-0}" == "0" ]] || { echo "no-op -> skip push"; exit 0; }
+          test -d .git || { echo "no git repo -> skip push"; exit 0; }
+
+          AUTH_URL="$(node --input-type=module -e '
+            const [clone, tok] = process.argv.slice(1);
+            const u = new URL(clone);
+            u.username = "oauth2";
+            u.password = tok;
+            console.log(u.toString());
+          ' "$CLONE_URL" "$FORGE_TOKEN")"
+
+          git remote set-url origin "$AUTH_URL"
+          git push -u origin "$BRANCH"
+
+      - name: Create PR + comment issue
+        if: ${{ always() }}
+        env:
+          FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
+        run: |
+          set -euo pipefail
+          source /tmp/anno.env || true
+          [[ "${SKIP:-0}" != "1" ]] || exit 0
+
+          [[ "${APPLY_RC:-0}" == "0" ]] || { echo "apply failed -> skip PR"; exit 0; }
+          [[ "${NOOP:-0}" == "0" ]] || { echo "no-op -> skip PR"; exit 0; }
+
+          PR_TITLE="anno: apply ticket #${ISSUE_NUMBER}"
+          PR_BODY="PR auto depuis ticket #${ISSUE_NUMBER} (state/approved).\n\n- Branche: ${BRANCH}\n- Commit: ${END_SHA}\n\nMerge si CI OK."
+
+          PR_PAYLOAD="$(node --input-type=module -e '
+            const [title, body, base, head] = process.argv.slice(1);
+            console.log(JSON.stringify({ title, body, base, head, allow_maintainer_edit: true }));
+          ' "$PR_TITLE" "$PR_BODY" "$DEFAULT_BRANCH" "${OWNER}:${BRANCH}")"
+
+          PR_JSON="$(curl -fsS -X POST \
+            -H "Authorization: token $FORGE_TOKEN" \
+            -H "Content-Type: application/json" \
+            "$API_BASE/api/v1/repos/$OWNER/$REPO/pulls" \
+            --data-binary "$PR_PAYLOAD")"
+
+          PR_URL="$(node --input-type=module -e '
+            const pr = JSON.parse(process.argv[1] || "{}");
+            console.log(pr.html_url || pr.url || "");
+          ' "$PR_JSON")"
+
+          test -n "$PR_URL" || { echo "PR URL missing. Raw: $PR_JSON"; exit 1; }
+
+          MSG="PR created for ticket #${ISSUE_NUMBER}: ${PR_URL}"
+          C_PAYLOAD="$(node --input-type=module -e 'console.log(JSON.stringify({body: process.argv[1] || ""}))' "$MSG")"
+
+          curl -fsS -X POST \
+            -H "Authorization: token $FORGE_TOKEN" \
+            -H "Content-Type: application/json" \
+            "$API_BASE/api/v1/repos/$OWNER/$REPO/issues/$ISSUE_NUMBER/comments" \
+            --data-binary "$C_PAYLOAD"
+
+          echo "PR: $PR_URL"
+
+      - name: Finalize (fail job if apply failed)
+        if: ${{ always() }}
+        run: |
+          set -euo pipefail
+          source /tmp/anno.env || true
+
+          [[ "${SKIP:-0}" != "1" ]] || { echo "skipped"; exit 0; }
+
+          RC="${APPLY_RC:-0}"
+          if [[ "$RC" != "0" ]]; then
+            echo "apply failed (rc=$RC)"
+            exit "$RC"
+          fi
+          echo "apply ok"

.gitea/workflows/anno-reject.yml

@@ -0,0 +1,181 @@
+name: Anno Reject (close issue)
+
+on:
+  issues:
+    types: [labeled]
+  workflow_dispatch:
+    inputs:
+      issue:
+        description: "Issue number to reject/close"
+        required: true
+
+env:
+  NODE_OPTIONS: --dns-result-order=ipv4first
+
+defaults:
+  run:
+    shell: bash
+
+concurrency:
+  group: anno-reject-${{ github.event.issue.number || github.event.issue.index || inputs.issue || 'manual' }}
+  cancel-in-progress: true
+
+jobs:
+  reject:
+    runs-on: mac-ci
+    container:
+      image: mcr.microsoft.com/devcontainers/javascript-node:22-bookworm
+
+    steps:
+      - name: Tools sanity
+        run: |
+          set -euo pipefail
+          node --version
+
+      - name: Derive context (event.json / workflow_dispatch)
+        env:
+          INPUT_ISSUE: ${{ inputs.issue }}
+          FORGE_API: ${{ vars.FORGE_API || vars.FORGE_BASE || vars.FORGE_BASE_URL }}
+        run: |
+          set -euo pipefail
+          export EVENT_JSON="/var/run/act/workflow/event.json"
+          test -f "$EVENT_JSON" || { echo "❌ Missing $EVENT_JSON"; exit 1; }
+
+          node --input-type=module - <<'NODE' > /tmp/reject.env
+          import fs from "node:fs";
+
+          const ev = JSON.parse(fs.readFileSync(process.env.EVENT_JSON, "utf8"));
+          const repoObj = ev?.repository || {};
+
+          const cloneUrl =
+            repoObj?.clone_url ||
+            (repoObj?.html_url ? (repoObj.html_url.replace(/\/$/,"") + ".git") : "");
+
+          let owner =
+            repoObj?.owner?.login ||
+            repoObj?.owner?.username ||
+            (repoObj?.full_name ? repoObj.full_name.split("/")[0] : "");
+
+          let repo =
+            repoObj?.name ||
+            (repoObj?.full_name ? repoObj.full_name.split("/")[1] : "");
+
+          if ((!owner || !repo) && cloneUrl) {
+            const m = cloneUrl.match(/[:/](?<o>[^/]+)\/(?<r>[^/]+?)(?:\.git)?$/);
+            if (m?.groups) { owner = owner || m.groups.o; repo = repo || m.groups.r; }
+          }
+          if (!owner || !repo) throw new Error("Cannot infer owner/repo");
+
+          const issueNumber =
+            ev?.issue?.number ||
+            ev?.issue?.index ||
+            (process.env.INPUT_ISSUE ? Number(process.env.INPUT_ISSUE) : 0);
+
+          if (!issueNumber || !Number.isFinite(Number(issueNumber))) {
+            throw new Error("No issue number in event.json or workflow_dispatch input");
+          }
+
+          // label name: best-effort (non-bloquant)
+          let labelName = "workflow_dispatch";
+          const lab = ev?.label;
+          if (typeof lab === "string") labelName = lab;
+          else if (lab && typeof lab === "object" && typeof lab.name === "string") labelName = lab.name;
+
+          let apiBase = "";
+          if (process.env.FORGE_API && String(process.env.FORGE_API).trim()) {
+            apiBase = String(process.env.FORGE_API).trim().replace(/\/+$/,"");
+          } else if (cloneUrl) {
+            apiBase = new URL(cloneUrl).origin;
+          } else {
+            apiBase = "";
+          }
+
+          function sh(s){ return JSON.stringify(String(s)); }
+
+          process.stdout.write([
+            `OWNER=${sh(owner)}`,
+            `REPO=${sh(repo)}`,
+            `ISSUE_NUMBER=${sh(issueNumber)}`,
+            `LABEL_NAME=${sh(labelName)}`,
+            `API_BASE=${sh(apiBase)}`
+          ].join("\n") + "\n");
+          NODE
+
+          echo "✅ context:"
+          sed -n '1,120p' /tmp/reject.env
+
+      - name: Early gate (fast-skip, tolerant)
+        run: |
+          set -euo pipefail
+          source /tmp/reject.env
+          echo "ℹ️ event label = $LABEL_NAME"
+
+          if [[ "$LABEL_NAME" != "state/rejected" && "$LABEL_NAME" != "workflow_dispatch" && "$LABEL_NAME" != "" && "$LABEL_NAME" != "[object Object]" ]]; then
+            echo "ℹ️ label=$LABEL_NAME => skip early"
+            echo "SKIP=1" >> /tmp/reject.env
+            echo "SKIP_REASON=\"label_not_rejected_event\"" >> /tmp/reject.env
+            exit 0
+          fi
+
+      - name: Comment + close (only if label state/rejected is PRESENT now, and no conflict)
+        env:
+          FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
+        run: |
+          set -euo pipefail
+          source /tmp/reject.env
+          [[ "${SKIP:-0}" != "1" ]] || { echo "ℹ️ skipped"; exit 0; }
+
+          test -n "${FORGE_TOKEN:-}" || { echo "❌ Missing secret FORGE_TOKEN"; exit 1; }
+          test -n "${API_BASE:-}" || { echo "❌ Missing API_BASE"; exit 1; }
+
+          curl -fsS \
+            -H "Authorization: token $FORGE_TOKEN" \
+            -H "Accept: application/json" \
+            "$API_BASE/api/v1/repos/$OWNER/$REPO/issues/$ISSUE_NUMBER" \
+            -o /tmp/reject.issue.json
+
+          node --input-type=module - <<'NODE' > /tmp/reject.flags
+          import fs from "node:fs";
+          const issue = JSON.parse(fs.readFileSync("/tmp/reject.issue.json","utf8"));
+          const labels = Array.isArray(issue.labels) ? issue.labels.map(l => String(l.name || "")).filter(Boolean) : [];
+          const hasApproved = labels.includes("state/approved");
+          const hasRejected = labels.includes("state/rejected");
+          process.stdout.write(`HAS_APPROVED=${hasApproved ? "1":"0"}\nHAS_REJECTED=${hasRejected ? "1":"0"}\n`);
+          NODE
+
+          source /tmp/reject.flags
+
+          # Do nothing unless state/rejected is truly present now (anti payload weird)
+          if [[ "${HAS_REJECTED:-0}" != "1" ]]; then
+            echo "ℹ️ state/rejected not present -> skip"
+            exit 0
+          fi
+
+          if [[ "${HAS_APPROVED:-0}" == "1" && "${HAS_REJECTED:-0}" == "1" ]]; then
+            MSG="⚠️ Conflit d'état sur le ticket #${ISSUE_NUMBER} : labels **state/approved** et **state/rejected** présents.\n\n➡️ Action manuelle requise : retirer l'un des deux labels avant relance."
+            PAYLOAD="$(node --input-type=module -e 'console.log(JSON.stringify({body: process.argv[1]||""}))' "$MSG")"
+            curl -fsS -X POST \
+              -H "Authorization: token $FORGE_TOKEN" \
+              -H "Content-Type: application/json" \
+              "$API_BASE/api/v1/repos/$OWNER/$REPO/issues/$ISSUE_NUMBER/comments" \
+              --data-binary "$PAYLOAD"
+            echo "ℹ️ conflict => stop"
+            exit 0
+          fi
+
+          MSG="❌ Ticket #${ISSUE_NUMBER} refusé (label state/rejected)."
+          PAYLOAD="$(node --input-type=module -e 'console.log(JSON.stringify({body: process.argv[1]||""}))' "$MSG")"
+
+          curl -fsS -X POST \
+            -H "Authorization: token $FORGE_TOKEN" \
+            -H "Content-Type: application/json" \
+            "$API_BASE/api/v1/repos/$OWNER/$REPO/issues/$ISSUE_NUMBER/comments" \
+            --data-binary "$PAYLOAD"
+
+          curl -fsS -X PATCH \
+            -H "Authorization: token $FORGE_TOKEN" \
+            -H "Content-Type: application/json" \
+            "$API_BASE/api/v1/repos/$OWNER/$REPO/issues/$ISSUE_NUMBER" \
+            --data-binary '{"state":"closed"}'
+
+          echo "✅ rejected+closed"

.gitea/workflows/auto-label-issues.yml

@@ -4,22 +4,37 @@ on:
   issues:
     types: [opened, edited]
 
+concurrency:
+  group: auto-label-${{ github.event.issue.number || github.event.issue.index || 'manual' }}
+  cancel-in-progress: true
+
 jobs:
   label:
-    runs-on: ubuntu-latest
+    runs-on: mac-ci
+    container:
+      image: mcr.microsoft.com/devcontainers/javascript-node:22-bookworm
+
     steps:
       - name: Apply labels from Type/State/Category
         env:
-          FORGE_BASE: ${{ vars.FORGE_API || vars.FORGE_BASE }}
+          # IMPORTANT: préfère FORGE_BASE (LAN) si défini, sinon FORGE_API
+          FORGE_BASE: ${{ vars.FORGE_BASE || vars.FORGE_API || vars.FORGE_API_BASE }}
           FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
           REPO_FULL: ${{ gitea.repository }}
           EVENT_PATH: ${{ github.event_path }}
+          NODE_OPTIONS: --dns-result-order=ipv4first
         run: |
           python3 - <<'PY'
-          import json, os, re, urllib.request, urllib.error
+          import json, os, re, time, urllib.request, urllib.error, socket
+
+          forge = (os.environ.get("FORGE_BASE") or "").rstrip("/")
+          if not forge:
+              raise SystemExit("Missing FORGE_BASE/FORGE_API repo variable (e.g. http://192.168.1.20:3000)")
+
+          token = os.environ.get("FORGE_TOKEN") or ""
+          if not token:
+              raise SystemExit("Missing secret FORGE_TOKEN")
 
-          forge = os.environ["FORGE_BASE"].rstrip("/")
-          token = os.environ["FORGE_TOKEN"]
           owner, repo = os.environ["REPO_FULL"].split("/", 1)
           event_path = os.environ["EVENT_PATH"]
 
@@ -46,12 +61,9 @@ jobs:
           print("PARSED:", {"Type": t, "State": s, "Category": c})
 
           # 1) explicite depuis le body
-          if t:
-              desired.add(t)
-          if s:
-              desired.add(s)
-          if c:
-              desired.add(c)
+          if t: desired.add(t)
+          if s: desired.add(s)
+          if c: desired.add(c)
 
           # 2) fallback depuis le titre si Type absent
           if not t:
@@ -76,42 +88,56 @@ jobs:
               "Authorization": f"token {token}",
               "Accept": "application/json",
               "Content-Type": "application/json",
-              "User-Agent": "archicratie-auto-label/1.0",
+              "User-Agent": "archicratie-auto-label/1.1",
           }
 
-          def jreq(method, url, payload=None):
+          def jreq(method, url, payload=None, timeout=60, retries=4, backoff=2.0):
               data = None if payload is None else json.dumps(payload).encode("utf-8")
-              req = urllib.request.Request(url, data=data, headers=headers, method=method)
-              try:
-                  with urllib.request.urlopen(req, timeout=20) as r:
-                      b = r.read()
-                      return json.loads(b.decode("utf-8")) if b else None
-              except urllib.error.HTTPError as e:
-                  b = e.read().decode("utf-8", errors="replace")
-                  raise RuntimeError(f"HTTP {e.code} {method} {url}\n{b}") from e
+              last_err = None
+              for i in range(retries):
+                  req = urllib.request.Request(url, data=data, headers=headers, method=method)
+                  try:
+                      with urllib.request.urlopen(req, timeout=timeout) as r:
+                          b = r.read()
+                          return json.loads(b.decode("utf-8")) if b else None
+                  except urllib.error.HTTPError as e:
+                      b = e.read().decode("utf-8", errors="replace")
+                      raise RuntimeError(f"HTTP {e.code} {method} {url}\n{b}") from e
+                  except (TimeoutError, socket.timeout, urllib.error.URLError) as e:
+                      last_err = e
+                      # retry only on network/timeout
+                      time.sleep(backoff * (i + 1))
+              raise RuntimeError(f"Network/timeout after retries: {method} {url}\n{last_err}")
 
           # labels repo
-          labels = jreq("GET", f"{api}/repos/{owner}/{repo}/labels?limit=1000") or []
+          labels = jreq("GET", f"{api}/repos/{owner}/{repo}/labels?limit=1000", timeout=60) or []
           name_to_id = {x.get("name"): x.get("id") for x in labels}
 
           missing = [x for x in desired if x not in name_to_id]
           if missing:
               raise SystemExit("Missing labels in repo: " + ", ".join(sorted(missing)))
 
-          wanted_ids = [name_to_id[x] for x in desired]
+          wanted_ids = sorted({int(name_to_id[x]) for x in desired})
 
           # labels actuels de l'issue
-          current = jreq("GET", f"{api}/repos/{owner}/{repo}/issues/{number}/labels") or []
-          current_ids = {x.get("id") for x in current if x.get("id") is not None}
+          current = jreq("GET", f"{api}/repos/{owner}/{repo}/issues/{number}/labels", timeout=60) or []
+          current_ids = {int(x.get("id")) for x in current if x.get("id") is not None}
 
           final_ids = sorted(current_ids.union(wanted_ids))
 
-          # set labels = union (n'enlève rien)
+          # Replace labels = union (n'enlève rien)
           url = f"{api}/repos/{owner}/{repo}/issues/{number}/labels"
-          try:
-              jreq("PUT", url, {"labels": final_ids})
-          except Exception:
-              jreq("PUT", url, final_ids)
+
+          # IMPORTANT: on n'envoie JAMAIS une liste brute ici (ça a causé le 422)
+          jreq("PUT", url, {"labels": final_ids}, timeout=90, retries=4)
+
+          # vérif post-apply (anti "timeout mais appliqué")
+          post = jreq("GET", f"{api}/repos/{owner}/{repo}/issues/{number}/labels", timeout=60) or []
+          post_ids = {int(x.get("id")) for x in post if x.get("id") is not None}
+
+          missing_ids = [i for i in wanted_ids if i not in post_ids]
+          if missing_ids:
+              raise RuntimeError(f"Labels not applied after PUT (missing ids): {missing_ids}")
 
           print(f"OK labels #{number}: {sorted(desired)}")
           PY

.gitea/workflows/ci.yaml

@@ -3,7 +3,7 @@ name: CI
 on:
   push:
   pull_request:
-    branches: [master]
+    branches: [main]
   workflow_dispatch:
 
 env:
@@ -15,7 +15,7 @@ defaults:
 
 jobs:
   build-and-anchors:
-    runs-on: ubuntu-latest
+    runs-on: mac-ci
     container:
       image: mcr.microsoft.com/devcontainers/javascript-node:22-bookworm
 
@@ -79,22 +79,7 @@ jobs:
           set -euo pipefail
           npm ci
 
-      - name: Inline scripts syntax check
+      - name: Full test suite (CI=1)
         run: |
           set -euo pipefail
-          node scripts/check-inline-js.mjs
-
-      - name: Build (includes postbuild injection + pagefind)
-        run: |
-          set -euo pipefail
-          npm run build
-
-      - name: Anchors contract
-        run: |
-          set -euo pipefail
-          npm run test:anchors
-
-      - name: Verify anchor aliases injected in dist
-        run: |
-          set -euo pipefail
-          node scripts/verify-anchor-aliases-in-dist.mjs
+          npm run ci

.gitea/workflows/ci.yml

@@ -1,103 +0,0 @@
-name: CI
-
-on:
-  push: {}
-  pull_request:
-    branches: ["master"]
-  workflow_dispatch: {}
-
-env:
-  NODE_OPTIONS: --dns-result-order=ipv4first
-
-defaults:
-  run:
-    shell: bash
-
-jobs:
-  build-and-anchors:
-    runs-on: ubuntu-latest
-    container:
-      image: mcr.microsoft.com/devcontainers/javascript-node:22-bookworm
-
-    steps:
-      - name: Tools sanity
-        run: |
-          set -euo pipefail
-          git --version
-          node --version
-          npm --version
-          npm ping --registry=https://registry.npmjs.org
-
-      - name: Checkout (from event.json, no external actions)
-        run: |
-          set -euo pipefail
-          EVENT_JSON="/var/run/act/workflow/event.json"
-          test -f "$EVENT_JSON" || (echo "❌ Missing $EVENT_JSON" && exit 1)
-
-          eval "$(node - <<'NODE'
-          import fs from "node:fs";
-          const ev = JSON.parse(fs.readFileSync("/var/run/act/workflow/event.json","utf8"));
-          const repo =
-            ev?.repository?.clone_url ||
-            (ev?.repository?.html_url ? (ev.repository.html_url.replace(/\/$/,'') + ".git") : "");
-          const sha =
-            ev?.after ||
-            ev?.pull_request?.head?.sha ||
-            ev?.head_commit?.id ||
-            ev?.sha ||
-            "";
-          if (!repo) { console.error("No repository.clone_url/html_url in event.json"); process.exit(1); }
-          if (!sha)  { console.error("No sha/after/pull_request.head.sha in event.json"); process.exit(1); }
-          console.log(`REPO_URL=${JSON.stringify(repo)}`);
-          console.log(`SHA=${JSON.stringify(sha)}`);
-NODE
-          )"
-
-          echo "Repo URL: $REPO_URL"
-          echo "SHA:      $SHA"
-
-          rm -rf .git
-          git init
-          git remote add origin "$REPO_URL"
-          git fetch --depth 1 origin "$SHA"
-          git checkout -q FETCH_HEAD
-          git log -1 --oneline
-
-      - name: Anchor aliases schema
-        run: |
-          set -euo pipefail
-          node scripts/check-anchor-aliases.mjs
-
-      - name: NPM harden
-        run: |
-          set -euo pipefail
-          npm config set fetch-retries 5
-          npm config set fetch-retry-mintimeout 20000
-          npm config set fetch-retry-maxtimeout 120000
-          npm config set registry https://registry.npmjs.org
-          npm config get registry
-
-      - name: Install deps
-        run: |
-          set -euo pipefail
-          npm ci
-
-      - name: Inline scripts syntax check
-        run: |
-          set -euo pipefail
-          node scripts/check-inline-js.mjs
-
-      - name: Build (includes postbuild injection + pagefind)
-        run: |
-          set -euo pipefail
-          npm run build
-
-      - name: Anchors contract
-        run: |
-          set -euo pipefail
-          npm run test:anchors
-
-      - name: Verify anchor aliases injected in dist
-        run: |
-          set -euo pipefail
-          node scripts/verify-anchor-aliases-in-dist.mjs

.gitea/workflows/deploy-staging-live.yml

@@ -0,0 +1,613 @@
+name: Deploy staging+live (annotations)
+
+on:
+  push:
+    branches: [main]
+  workflow_dispatch:
+    inputs:
+      force:
+        description: "Force FULL deploy (rebuild+restart) even if gate would hotpatch-only (1=yes, 0=no)"
+        required: false
+        default: "0"
+
+env:
+  NODE_OPTIONS: --dns-result-order=ipv4first
+  DOCKER_API_VERSION: "1.43"
+  COMPOSE_VERSION: "2.29.7"
+  ASTRO_TELEMETRY_DISABLED: "1"
+
+defaults:
+  run:
+    shell: bash
+
+concurrency:
+  group: deploy-staging-live-main
+  cancel-in-progress: false
+
+jobs:
+  deploy:
+    runs-on: nas-deploy
+    container:
+      image: localhost:5000/archicratie/nas-deploy-node22@sha256:fefa8bb307005cebec07796661ab25528dc319c33a8f1e480e1d66f90cd5cff6
+
+    steps:
+      - name: Tools sanity
+        run: |
+          set -euo pipefail
+          git --version
+          node --version
+          npm --version
+
+      - name: Checkout (push or workflow_dispatch, no external actions)
+        env:
+          EVENT_JSON: /var/run/act/workflow/event.json
+        run: |
+          set -euo pipefail
+          test -f "$EVENT_JSON" || { echo "❌ Missing $EVENT_JSON"; exit 1; }
+
+          node --input-type=module <<'NODE'
+          import fs from "node:fs";
+
+          const ev = JSON.parse(fs.readFileSync(process.env.EVENT_JSON, "utf8"));
+          const repoObj = ev?.repository || {};
+
+          const cloneUrl =
+            repoObj?.clone_url ||
+            (repoObj?.html_url ? (repoObj.html_url.replace(/\/$/,"") + ".git") : "");
+          if (!cloneUrl) throw new Error("No repository clone_url/html_url in event.json");
+
+          const defaultBranch = repoObj?.default_branch || "main";
+
+          // Push-range (most reliable for change detection)
+          const before = String(ev?.before || "").trim();
+          const after =
+            (process.env.GITHUB_SHA && String(process.env.GITHUB_SHA).trim()) ||
+            String(ev?.after || ev?.sha || ev?.head_commit?.id || ev?.pull_request?.head?.sha || "").trim();
+
+          const shq = (s) => "'" + String(s).replace(/'/g, "'\\''") + "'";
+
+          fs.writeFileSync("/tmp/deploy.env", [
+            `REPO_URL=${shq(cloneUrl)}`,
+            `DEFAULT_BRANCH=${shq(defaultBranch)}`,
+            `BEFORE=${shq(before)}`,
+            `AFTER=${shq(after)}`
+          ].join("\n") + "\n");
+          NODE
+
+          source /tmp/deploy.env
+          echo "Repo URL:       $REPO_URL"
+          echo "Default branch: $DEFAULT_BRANCH"
+          echo "BEFORE:         ${BEFORE:-<empty>}"
+          echo "AFTER:          ${AFTER:-<empty>}"
+
+          rm -rf .git
+          git init -q
+          git remote add origin "$REPO_URL"
+
+          # Checkout AFTER (or default branch if missing)
+          if [[ -n "${AFTER:-}" ]]; then
+            git fetch --depth 50 origin "$AFTER"
+            git -c advice.detachedHead=false checkout -q FETCH_HEAD
+          else
+            git fetch --depth 50 origin "$DEFAULT_BRANCH"
+            git -c advice.detachedHead=false checkout -q "origin/$DEFAULT_BRANCH"
+            AFTER="$(git rev-parse HEAD)"
+            echo "AFTER='$AFTER'" >> /tmp/deploy.env
+            echo "Resolved AFTER: $AFTER"
+          fi
+
+          git log -1 --oneline
+
+      - name: Gate — decide SKIP vs HOTPATCH vs FULL rebuild
+        env:
+          INPUT_FORCE: ${{ inputs.force }}
+          EVENT_JSON: /var/run/act/workflow/event.json
+        run: |
+          set -euo pipefail
+          source /tmp/deploy.env
+
+          FORCE="${INPUT_FORCE:-0}"
+
+          # Lire before/after du push depuis event.json (merge-proof)
+          node --input-type=module <<'NODE'
+          import fs from "node:fs";
+          const ev = JSON.parse(fs.readFileSync(process.env.EVENT_JSON, "utf8"));
+          const before = ev?.before || "";
+          const after  = ev?.after  || ev?.sha || "";
+          const shq = (s) => "'" + String(s).replace(/'/g, "'\\''") + "'";
+          fs.writeFileSync("/tmp/gate.env", [
+            `EV_BEFORE=${shq(before)}`,
+            `EV_AFTER=${shq(after)}`
+          ].join("\n") + "\n");
+          NODE
+
+          source /tmp/gate.env
+
+          BEFORE="${EV_BEFORE:-}"
+          AFTER="${EV_AFTER:-}"
+          if [[ -z "${AFTER:-}" ]]; then
+            AFTER="${SHA:-}"
+          fi
+
+          echo "Gate ctx: BEFORE=${BEFORE:-<empty>} AFTER=${AFTER:-<empty>} FORCE=${FORCE}"
+
+          # Produire une liste CHANGED fiable :
+          # - si BEFORE/AFTER valides -> git diff before..after
+          # - sinon fallback -> diff parent1..after ou show after
+          CHANGED=""
+          Z40="0000000000000000000000000000000000000000"
+
+          if [[ -n "${BEFORE:-}" && "${BEFORE}" != "${Z40}" ]] \
+             && git cat-file -e "${BEFORE}^{commit}" 2>/dev/null \
+             && git cat-file -e "${AFTER}^{commit}"  2>/dev/null; then
+            CHANGED="$(git diff --name-only "${BEFORE}" "${AFTER}" || true)"
+          else
+            P1="$(git rev-parse "${AFTER}^" 2>/dev/null || true)"
+            if [[ -n "${P1:-}" ]] && git cat-file -e "${P1}^{commit}" 2>/dev/null; then
+              CHANGED="$(git diff --name-only "${P1}" "${AFTER}" || true)"
+            else
+              CHANGED="$(git show --name-only --pretty="" "${AFTER}" | sed '/^$/d' || true)"
+            fi
+          fi
+
+          printf "%s\n" "${CHANGED}" > /tmp/changed.txt
+
+          echo "== changed files (first 200) =="
+          sed -n '1,200p' /tmp/changed.txt || true
+
+          # Flags
+          HAS_FULL=0
+          HAS_HOTPATCH=0
+
+          # HOTPATCH si annotations/media touchés
+          if grep -qE '^(src/annotations/|public/media/)' /tmp/changed.txt; then
+            HAS_HOTPATCH=1
+          fi
+
+          # FULL si build-impacting (robuste)
+          # 1) Tout src/ SAUF src/annotations/
+          if grep -qE '^src/' /tmp/changed.txt && grep -qEv '^src/annotations/' /tmp/changed.txt; then
+            HAS_FULL=1
+          fi
+
+          # 2) scripts/
+          if grep -qE '^scripts/' /tmp/changed.txt; then
+            HAS_FULL=1
+          fi
+
+          # 3) Tout public/ SAUF public/media/
+          if grep -qE '^public/' /tmp/changed.txt && grep -qEv '^public/media/' /tmp/changed.txt; then
+            HAS_FULL=1
+          fi
+
+          # 4) fichiers racine qui changent le build / l’image
+          if grep -qE '^(package\.json|package-lock\.json|astro\.config\.mjs|tsconfig\.json|\.npmrc|\.nvmrc|Dockerfile|docker-compose\.yml|nginx\.conf)$' /tmp/changed.txt; then
+            HAS_FULL=1
+          fi
+
+          echo "Gate flags: HAS_FULL=${HAS_FULL} HAS_HOTPATCH=${HAS_HOTPATCH}"
+
+          # Décision
+          if [[ "${FORCE}" == "1" ]]; then
+            GO=1
+            MODE="full"
+            echo "✅ force=1 -> MODE=full (rebuild+restart)"
+          elif [[ "${HAS_FULL}" == "1" ]]; then
+            GO=1
+            MODE="full"
+            echo "✅ build-impacting change -> MODE=full (rebuild+restart)"
+          elif [[ "${HAS_HOTPATCH}" == "1" ]]; then
+            GO=1
+            MODE="hotpatch"
+            echo "✅ annotations/media change -> MODE=hotpatch"
+          else
+            GO=0
+            MODE="skip"
+            echo "ℹ️ no relevant change -> skip deploy"
+          fi
+
+          echo "GO=${GO}" >> /tmp/deploy.env
+          echo "MODE='${MODE}'" >> /tmp/deploy.env
+
+      - name: Toolchain sanity + resolve COMPOSE_PROJECT_NAME
+        run: |
+          set -euo pipefail
+          source /tmp/deploy.env
+          [[ "${GO:-0}" == "1" ]] || { echo "ℹ️ skipped"; exit 0; }
+
+          # tools are prebaked in the image
+          git --version
+          docker version
+          docker compose version
+          python3 -c 'import yaml; print("PyYAML OK")'
+
+          # Reuse existing compose project name if containers already exist
+          PROJ="$(docker inspect archicratie-web-blue --format '{{ index .Config.Labels "com.docker.compose.project" }}' 2>/dev/null || true)"
+          if [[ -z "${PROJ:-}" ]]; then
+            PROJ="$(docker inspect archicratie-web-green --format '{{ index .Config.Labels "com.docker.compose.project" }}' 2>/dev/null || true)"
+          fi
+          if [[ -z "${PROJ:-}" ]]; then PROJ="archicratie-web"; fi
+          echo "COMPOSE_PROJECT_NAME='$PROJ'" >> /tmp/deploy.env
+          echo "✅ Using COMPOSE_PROJECT_NAME=$PROJ"
+
+          # Assert target containers exist (hotpatch needs them)
+          for c in archicratie-web-blue archicratie-web-green; do
+            docker inspect "$c" >/dev/null 2>&1 || { echo "❌ missing container $c"; exit 5; }
+          done
+
+      - name: Assert required vars (PUBLIC_GITEA_*) — only needed for MODE=full
+        env:
+          PUBLIC_GITEA_BASE: ${{ vars.PUBLIC_GITEA_BASE }}
+          PUBLIC_GITEA_OWNER: ${{ vars.PUBLIC_GITEA_OWNER }}
+          PUBLIC_GITEA_REPO: ${{ vars.PUBLIC_GITEA_REPO }}
+        run: |
+          set -euo pipefail
+          source /tmp/deploy.env
+          [[ "${GO:-0}" == "1" ]] || { echo "ℹ️ skipped"; exit 0; }
+          [[ "${MODE:-hotpatch}" == "full" ]] || { echo "ℹ️ hotpatch mode -> vars not required"; exit 0; }
+
+          test -n "${PUBLIC_GITEA_BASE:-}"  || { echo "❌ missing repo var PUBLIC_GITEA_BASE"; exit 2; }
+          test -n "${PUBLIC_GITEA_OWNER:-}" || { echo "❌ missing repo var PUBLIC_GITEA_OWNER"; exit 2; }
+          test -n "${PUBLIC_GITEA_REPO:-}"  || { echo "❌ missing repo var PUBLIC_GITEA_REPO"; exit 2; }
+          echo "✅ vars OK"
+
+      - name: Assert deploy files exist — only needed for MODE=full
+        run: |
+          set -euo pipefail
+          source /tmp/deploy.env
+          [[ "${GO:-0}" == "1" ]] || { echo "ℹ️ skipped"; exit 0; }
+          [[ "${MODE:-hotpatch}" == "full" ]] || { echo "ℹ️ hotpatch mode -> files not required"; exit 0; }
+
+          test -f docker-compose.yml
+          test -f Dockerfile
+          test -f nginx.conf
+          echo "✅ deploy files OK"
+
+      - name: FULL — Build + deploy staging (blue) then warmup+smoke
+        env:
+          PUBLIC_GITEA_BASE: ${{ vars.PUBLIC_GITEA_BASE }}
+          PUBLIC_GITEA_OWNER: ${{ vars.PUBLIC_GITEA_OWNER }}
+          PUBLIC_GITEA_REPO: ${{ vars.PUBLIC_GITEA_REPO }}
+        run: |
+          set -euo pipefail
+          source /tmp/deploy.env
+          [[ "${GO:-0}" == "1" ]] || { echo "ℹ️ skipped"; exit 0; }
+          [[ "${MODE:-hotpatch}" == "full" ]] || { echo "ℹ️ MODE=$MODE -> skip full rebuild"; exit 0; }
+
+          PROJ="${COMPOSE_PROJECT_NAME:-archicratie-web}"
+
+          wait_url() {
+            local url="$1"
+            local label="$2"
+            local tries="${3:-60}"
+            for i in $(seq 1 "$tries"); do
+              if curl -fsS --max-time 4 "$url" >/dev/null; then
+                echo "✅ $label OK ($url)"
+                return 0
+              fi
+              echo "… warmup $label ($i/$tries)"
+              sleep 1
+            done
+            echo "❌ timeout $label ($url)"
+            return 1
+          }
+
+          TS="$(date -u +%Y%m%d-%H%M%S)"
+          echo "TS='$TS'" >> /tmp/deploy.env
+          docker image tag archicratie-web:blue  "archicratie-web:blue.BAK.${TS}"  || true
+          docker image tag archicratie-web:green "archicratie-web:green.BAK.${TS}" || true
+
+          BUILD_TIME_RAW="$(TZ=Europe/Paris date '+%Y-%m-%dT%H:%M:%S%z')"
+          BUILD_TIME="${BUILD_TIME_RAW:0:${#BUILD_TIME_RAW}-2}:${BUILD_TIME_RAW:${#BUILD_TIME_RAW}-2}"
+
+          PUBLIC_OPS_ENV=staging \
+          PUBLIC_OPS_UPSTREAM=web_blue \
+          PUBLIC_BUILD_SHA="${AFTER}" \
+          PUBLIC_BUILD_TIME="${BUILD_TIME}" \
+          node scripts/write-ops-health.mjs
+
+          test -f public/__ops/health.json
+          echo "=== public/__ops/health.json (blue/staging) ==="
+          cat public/__ops/health.json
+
+          docker compose -p "$PROJ" -f docker-compose.yml build web_blue
+          docker rm -f archicratie-web-blue || true
+          docker compose -p "$PROJ" -f docker-compose.yml up -d --force-recreate --remove-orphans web_blue
+
+          # warmup endpoints
+          wait_url "http://127.0.0.1:8081/para-index.json"        "blue para-index"
+          wait_url "http://127.0.0.1:8081/annotations-index.json" "blue annotations-index"
+          wait_url "http://127.0.0.1:8081/pagefind/pagefind.js"   "blue pagefind.js"
+
+          wait_url "http://127.0.0.1:8081/__ops/health.json" "blue ops health"
+
+          curl -fsS --max-time 6 "http://127.0.0.1:8081/__ops/health.json" \
+            | python3 -c 'import sys, json; j=json.load(sys.stdin); print("env=", j.get("env")); print("upstream=", j.get("upstream")); print("buildSha=", j.get("buildSha")); print("builtAt=", j.get("builtAt"))'
+
+          CANON="$(curl -fsS --max-time 6 "http://127.0.0.1:8081/archicrat-ia/chapitre-1/" | grep -oE 'rel="canonical" href="[^"]+"' | head -n1 || true)"
+          echo "canonical(blue)=$CANON"
+          echo "$CANON" | grep -q 'https://staging\.archicratie\.trans-hands\.synology\.me/' || {
+            echo "❌ staging canonical mismatch"
+            docker logs --tail 120 archicratie-web-blue || true
+            exit 3
+          }
+
+          echo "✅ staging OK"
+
+      - name: FULL — Build + deploy live (green) then warmup+smoke + rollback if needed
+        env:
+          PUBLIC_GITEA_BASE: ${{ vars.PUBLIC_GITEA_BASE }}
+          PUBLIC_GITEA_OWNER: ${{ vars.PUBLIC_GITEA_OWNER }}
+          PUBLIC_GITEA_REPO: ${{ vars.PUBLIC_GITEA_REPO }}
+        run: |
+          set -euo pipefail
+          source /tmp/deploy.env
+          [[ "${GO:-0}" == "1" ]] || { echo "ℹ️ skipped"; exit 0; }
+          [[ "${MODE:-hotpatch}" == "full" ]] || { echo "ℹ️ MODE=$MODE -> skip full rebuild"; exit 0; }
+
+          PROJ="${COMPOSE_PROJECT_NAME:-archicratie-web}"
+          TS="${TS:-$(date -u +%Y%m%d-%H%M%S)}"
+
+          wait_url() {
+            local url="$1"
+            local label="$2"
+            local tries="${3:-60}"
+            for i in $(seq 1 "$tries"); do
+              if curl -fsS --max-time 4 "$url" >/dev/null; then
+                echo "✅ $label OK ($url)"
+                return 0
+              fi
+              echo "… warmup $label ($i/$tries)"
+              sleep 1
+            done
+            echo "❌ timeout $label ($url)"
+            return 1
+          }
+
+          rollback() {
+            echo "⚠️ rollback green -> previous image tag (best effort)"
+            docker image tag "archicratie-web:green.BAK.${TS}" archicratie-web:green || true
+            docker rm -f archicratie-web-green || true
+            docker compose -p "$PROJ" -f docker-compose.yml up -d --force-recreate --remove-orphans web_green || true
+          }
+
+          BUILD_TIME_RAW="$(TZ=Europe/Paris date '+%Y-%m-%dT%H:%M:%S%z')"
+          BUILD_TIME="${BUILD_TIME_RAW:0:${#BUILD_TIME_RAW}-2}:${BUILD_TIME_RAW:${#BUILD_TIME_RAW}-2}"
+
+          PUBLIC_OPS_ENV=prod \
+          PUBLIC_OPS_UPSTREAM=web_green \
+          PUBLIC_BUILD_SHA="${AFTER}" \
+          PUBLIC_BUILD_TIME="${BUILD_TIME}" \
+          node scripts/write-ops-health.mjs
+
+          test -f public/__ops/health.json
+          echo "=== public/__ops/health.json (green/prod) ==="
+          cat public/__ops/health.json
+
+          # build/restart green
+          if ! docker compose -p "$PROJ" -f docker-compose.yml build web_green; then
+            echo "❌ build green failed"; rollback; exit 4
+          fi
+
+          docker rm -f archicratie-web-green || true
+          docker compose -p "$PROJ" -f docker-compose.yml up -d --force-recreate --remove-orphans web_green
+
+          # warmup endpoints
+          if ! wait_url "http://127.0.0.1:8082/para-index.json"        "green para-index"; then rollback; exit 4; fi
+          if ! wait_url "http://127.0.0.1:8082/annotations-index.json" "green annotations-index"; then rollback; exit 4; fi
+          if ! wait_url "http://127.0.0.1:8082/pagefind/pagefind.js"   "green pagefind.js"; then rollback; exit 4; fi
+
+          if ! wait_url "http://127.0.0.1:8082/__ops/health.json" "green ops health"; then rollback; exit 4; fi
+
+          curl -fsS --max-time 6 "http://127.0.0.1:8082/__ops/health.json" \
+            | python3 -c 'import sys, json; j=json.load(sys.stdin); print("env=", j.get("env")); print("upstream=", j.get("upstream")); print("buildSha=", j.get("buildSha")); print("builtAt=", j.get("builtAt"))'
+
+          CANON="$(curl -fsS --max-time 6 "http://127.0.0.1:8082/archicrat-ia/chapitre-1/" | grep -oE 'rel="canonical" href="[^"]+"' | head -n1 || true)"
+          echo "canonical(green)=$CANON"
+          echo "$CANON" | grep -q 'https://archicratie\.trans-hands\.synology\.me/' || {
+            echo "❌ live canonical mismatch"
+            docker logs --tail 120 archicratie-web-green || true
+            rollback
+            exit 4
+          }
+
+          echo "✅ live OK"
+
+      - name: HOTPATCH — deep merge shards -> annotations-index + copy changed media into blue+green
+        run: |
+          set -euo pipefail
+          source /tmp/deploy.env
+          [[ "${GO:-0}" == "1" ]] || { echo "ℹ️ skipped"; exit 0; }
+
+          python3 - <<'PY'
+          import os, re, json, glob
+          import yaml
+          import datetime as dt
+
+          ROOT = os.getcwd()
+          ANNO_ROOT = os.path.join(ROOT, "src", "annotations")
+
+          def is_obj(x): return isinstance(x, dict)
+          def is_arr(x): return isinstance(x, list)
+
+          def iso_dt(x):
+            if isinstance(x, dt.datetime):
+              if x.tzinfo is None:
+                return x.isoformat()
+              return x.astimezone(dt.timezone.utc).isoformat().replace("+00:00","Z")
+            if isinstance(x, dt.date):
+              return x.isoformat()
+            return None
+
+          def normalize(x):
+            s = iso_dt(x)
+            if s is not None: return s
+            if isinstance(x, dict):
+              return {str(k): normalize(v) for k, v in x.items()}
+            if isinstance(x, list):
+              return [normalize(v) for v in x]
+            return x
+
+          def key_media(it): return str((it or {}).get("src",""))
+          def key_ref(it):
+            it = it or {}
+            return "||".join([str(it.get("url","")), str(it.get("label","")), str(it.get("kind","")), str(it.get("citation",""))])
+          def key_comment(it): return str((it or {}).get("text","")).strip()
+
+          def dedup_extend(dst_list, src_list, key_fn):
+            seen = set(); out = []
+            for x in (dst_list or []):
+              x = normalize(x); k = key_fn(x)
+              if k and k not in seen: seen.add(k); out.append(x)
+            for x in (src_list or []):
+              x = normalize(x); k = key_fn(x)
+              if k and k not in seen: seen.add(k); out.append(x)
+            return out
+
+          def deep_merge(dst, src):
+            src = normalize(src)
+            for k, v in (src or {}).items():
+              if k in ("media","refs","comments_editorial") and is_arr(v):
+                if k == "media": dst[k] = dedup_extend(dst.get(k, []), v, key_media)
+                elif k == "refs": dst[k] = dedup_extend(dst.get(k, []), v, key_ref)
+                else: dst[k] = dedup_extend(dst.get(k, []), v, key_comment)
+                continue
+
+              if is_obj(v):
+                if not is_obj(dst.get(k)): dst[k] = {}
+                deep_merge(dst[k], v)
+                continue
+
+              if is_arr(v):
+                cur = dst.get(k, [])
+                if not is_arr(cur): cur = []
+                seen = set(); out = []
+                for x in cur:
+                  x = normalize(x)
+                  s = json.dumps(x, sort_keys=True, ensure_ascii=False)
+                  if s not in seen: seen.add(s); out.append(x)
+                for x in v:
+                  x = normalize(x)
+                  s = json.dumps(x, sort_keys=True, ensure_ascii=False)
+                  if s not in seen: seen.add(s); out.append(x)
+                dst[k] = out
+                continue
+
+              v = normalize(v)
+              if k not in dst or dst.get(k) in (None, ""):
+                dst[k] = v
+
+          def para_num(pid):
+            m = re.match(r"^p-(\d+)-", str(pid))
+            return int(m.group(1)) if m else 10**9
+
+          def sort_lists(entry):
+            for k in ("media","refs","comments_editorial"):
+              arr = entry.get(k)
+              if not is_arr(arr): continue
+              def ts(x):
+                x = normalize(x)
+                try:
+                  s = str((x or {}).get("ts",""))
+                  return dt.datetime.fromisoformat(s.replace("Z","+00:00")).timestamp() if s else 0
+                except Exception:
+                  return 0
+              arr = [normalize(x) for x in arr]
+              arr.sort(key=lambda x: (ts(x), json.dumps(x, sort_keys=True, ensure_ascii=False)))
+              entry[k] = arr
+
+          if not os.path.isdir(ANNO_ROOT):
+            raise SystemExit(f"Missing annotations root: {ANNO_ROOT}")
+
+          pages = {}
+          errors = []
+
+          files = sorted(glob.glob(os.path.join(ANNO_ROOT, "**", "*.yml"), recursive=True))
+          for fp in files:
+            try:
+              with open(fp, "r", encoding="utf-8") as f:
+                doc = yaml.safe_load(f) or {}
+              doc = normalize(doc)
+              if not isinstance(doc, dict) or doc.get("schema") != 1:
+                continue
+
+              page = str(doc.get("page","")).strip().strip("/")
+              paras = doc.get("paras") or {}
+              if not page or not isinstance(paras, dict):
+                continue
+
+              pg = pages.setdefault(page, {"paras": {}})
+              for pid, entry in paras.items():
+                pid = str(pid)
+                if pid not in pg["paras"] or not isinstance(pg["paras"].get(pid), dict):
+                  pg["paras"][pid] = {}
+                if isinstance(entry, dict):
+                  deep_merge(pg["paras"][pid], entry)
+                sort_lists(pg["paras"][pid])
+
+            except Exception as e:
+              errors.append({"file": os.path.relpath(fp, ROOT), "error": str(e)})
+
+          for page, obj in pages.items():
+            keys = list((obj.get("paras") or {}).keys())
+            keys.sort(key=lambda k: (para_num(k), k))
+            obj["paras"] = {k: obj["paras"][k] for k in keys}
+
+          out = {
+            "schema": 1,
+            "generatedAt": dt.datetime.utcnow().replace(tzinfo=dt.timezone.utc).isoformat().replace("+00:00","Z"),
+            "pages": pages,
+            "stats": {
+              "pages": len(pages),
+              "paras": sum(len(v.get("paras") or {}) for v in pages.values()),
+              "errors": len(errors),
+            },
+            "errors": errors,
+          }
+
+          with open("/tmp/annotations-index.json", "w", encoding="utf-8") as f:
+            json.dump(out, f, ensure_ascii=False)
+
+          print("OK: wrote /tmp/annotations-index.json pages=", out["stats"]["pages"], "paras=", out["stats"]["paras"], "errors=", out["stats"]["errors"])
+          PY
+
+          # patch JSON into running containers
+          for c in archicratie-web-blue archicratie-web-green; do
+            echo "== patch annotations-index.json into $c =="
+            docker cp /tmp/annotations-index.json "${c}:/usr/share/nginx/html/annotations-index.json"
+          done
+
+          # copy changed media files into containers (so new media appears without rebuild)
+          if [[ -s /tmp/changed.txt ]]; then
+            while IFS= read -r f; do
+              [[ -n "$f" ]] || continue
+              if [[ "$f" == public/media/* ]]; then
+                dest="/usr/share/nginx/html/${f#public/}"   # => /usr/share/nginx/html/media/...
+                for c in archicratie-web-blue archicratie-web-green; do
+                  echo "== copy media into $c: $f -> $dest =="
+                  docker exec "$c" sh -lc "mkdir -p \"$(dirname "$dest")\""
+                  docker cp "$f" "$c:$dest"
+                done
+              fi
+            done < /tmp/changed.txt
+          fi
+
+          # smoke after patch
+          for p in 8081 8082; do
+            echo "== smoke annotations-index on $p =="
+            curl -fsS --max-time 6 "http://127.0.0.1:${p}/annotations-index.json" \
+              | python3 -c 'import sys,json; j=json.load(sys.stdin); print("generatedAt:", j.get("generatedAt")); print("pages:", len(j.get("pages") or {})); print("paras:", j.get("stats",{}).get("paras"))'
+          done
+
+          echo "✅ hotpatch done"
+
+      - name: Debug on failure (containers status/logs)
+        if: ${{ failure() }}
+        run: |
+          set -euo pipefail
+          echo "== docker ps =="
+          docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Image}}' | sed -n '1,80p' || true
+          for c in archicratie-web-blue archicratie-web-green; do
+            echo "== logs $c (tail 200) =="
+            docker logs --tail 200 "$c" || true
+          done

.gitea/workflows/proposer-apply-pr.yml

@@ -0,0 +1,788 @@
+name: Proposer Apply (Queue)
+
+on:
+  issues:
+    types: [labeled]
+  push:
+    branches: [main]
+  workflow_dispatch:
+    inputs:
+      issue:
+        description: "Issue number to prioritize (optional)"
+        required: false
+        default: ""
+
+env:
+  NODE_OPTIONS: --dns-result-order=ipv4first
+
+defaults:
+  run:
+    shell: bash
+
+concurrency:
+  group: proposer-queue-main
+  cancel-in-progress: false
+
+jobs:
+  apply-proposer:
+    runs-on: mac-ci
+    container:
+      image: mcr.microsoft.com/devcontainers/javascript-node:22-bookworm
+
+    steps:
+      - name: Tools sanity
+        run: |
+          set -euo pipefail
+          git --version
+          node --version
+          npm --version
+
+      - name: Derive context (event.json / workflow_dispatch / push)
+        env:
+          INPUT_ISSUE: ${{ inputs.issue }}
+          EVENT_NAME_IN: ${{ github.event_name }}
+          FORGE_API: ${{ vars.FORGE_API || vars.FORGE_BASE }}
+        run: |
+          set -euo pipefail
+          export EVENT_JSON="/var/run/act/workflow/event.json"
+          test -f "$EVENT_JSON" || { echo "Missing $EVENT_JSON"; exit 1; }
+
+          node --input-type=module - <<'NODE' > /tmp/proposer.env
+          import fs from "node:fs";
+
+          const ev = JSON.parse(fs.readFileSync(process.env.EVENT_JSON, "utf8"));
+          const repoObj = ev?.repository || {};
+
+          const cloneUrl =
+            repoObj?.clone_url ||
+            (repoObj?.html_url ? (repoObj.html_url.replace(/\/$/, "") + ".git") : "");
+
+          if (!cloneUrl) throw new Error("No repository clone_url/html_url in event.json");
+
+          let owner =
+            repoObj?.owner?.login ||
+            repoObj?.owner?.username ||
+            (repoObj?.full_name ? repoObj.full_name.split("/")[0] : "");
+
+          let repo =
+            repoObj?.name ||
+            (repoObj?.full_name ? repoObj.full_name.split("/")[1] : "");
+
+          if (!owner || !repo) {
+            const m = cloneUrl.match(/[:/](?<o>[^/]+)\/(?<r>[^/]+?)(?:\.git)?$/);
+            if (m?.groups) {
+              owner = owner || m.groups.o;
+              repo = repo || m.groups.r;
+            }
+          }
+
+          if (!owner || !repo) throw new Error("Cannot infer owner/repo");
+
+          const defaultBranch = repoObj?.default_branch || "main";
+
+          const issueNumber =
+            ev?.issue?.number ||
+            ev?.issue?.index ||
+            (process.env.INPUT_ISSUE ? Number(process.env.INPUT_ISSUE) : 0) ||
+            0;
+
+          const labelName =
+            ev?.label?.name ||
+            (typeof ev?.label === "string" ? ev.label : "") ||
+            "";
+
+          const eventName =
+            String(process.env.EVENT_NAME_IN || "").trim() ||
+            (ev?.issue ? "issues" : (ev?.before || ev?.after ? "push" : "workflow_dispatch"));
+
+          const u = new URL(cloneUrl);
+          const origin = u.origin;
+
+          const apiBase =
+            (process.env.FORGE_API && String(process.env.FORGE_API).trim())
+              ? String(process.env.FORGE_API).trim().replace(/\/+$/, "")
+              : origin;
+
+          function sh(s) {
+            return JSON.stringify(String(s));
+          }
+
+          process.stdout.write([
+            `CLONE_URL=${sh(cloneUrl)}`,
+            `OWNER=${sh(owner)}`,
+            `REPO=${sh(repo)}`,
+            `DEFAULT_BRANCH=${sh(defaultBranch)}`,
+            `ISSUE_NUMBER=${sh(issueNumber)}`,
+            `LABEL_NAME=${sh(labelName)}`,
+            `EVENT_NAME=${sh(eventName)}`,
+            `API_BASE=${sh(apiBase)}`
+          ].join("\n") + "\n");
+          NODE
+
+          echo "Context:"
+          sed -n '1,200p' /tmp/proposer.env
+
+      - name: Early gate (tolerant on empty issue label payload)
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env
+
+          echo "event=$EVENT_NAME label=${LABEL_NAME:-<empty>}"
+
+          if [[ "$EVENT_NAME" == "issues" ]]; then
+            if [[ -n "${LABEL_NAME:-}" && "$LABEL_NAME" != "state/approved" ]]; then
+              echo "issues/labeled with explicit non-approved label=$LABEL_NAME -> skip"
+              echo 'SKIP=1' >> /tmp/proposer.env
+              echo 'SKIP_REASON="label_not_state_approved_event"' >> /tmp/proposer.env
+              exit 0
+            fi
+          fi
+
+          echo "Proceed to API-based selection/gating"
+
+      - name: Checkout default branch
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env
+          [[ "${SKIP:-0}" != "1" ]] || { echo "Skipped"; exit 0; }
+
+          rm -rf .git
+          git init -q
+          git remote add origin "$CLONE_URL"
+          git fetch --depth 1 origin "$DEFAULT_BRANCH"
+          git -c advice.detachedHead=false checkout -q FETCH_HEAD
+          git log -1 --oneline
+
+      - name: Detect app dir (repo-root vs ./site)
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env
+          [[ "${SKIP:-0}" != "1" ]] || { echo "Skipped"; exit 0; }
+
+          APP_DIR="."
+          if [[ -d "site" && -f "site/package.json" ]]; then
+            APP_DIR="site"
+          fi
+
+          echo "APP_DIR=$APP_DIR" >> /tmp/proposer.env
+          echo "APP_DIR=$APP_DIR"
+
+          test -f "$APP_DIR/package.json" || {
+            echo "package.json missing in APP_DIR=$APP_DIR"
+            exit 1
+          }
+
+          test -d "$APP_DIR/scripts" || {
+            echo "scripts/ missing in APP_DIR=$APP_DIR"
+            exit 1
+          }
+
+      - name: Select next proposer batch (by path)
+        env:
+          FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env
+          [[ "${SKIP:-0}" != "1" ]] || { echo "Skipped"; exit 0; }
+
+          test -n "${FORGE_TOKEN:-}" || {
+            echo "Missing secret FORGE_TOKEN"
+            exit 1
+          }
+
+          export GITEA_OWNER="$OWNER"
+          export GITEA_REPO="$REPO"
+          export FORGE_API="$API_BASE"
+
+          cd "$APP_DIR"
+
+          test -f scripts/pick-proposer-issue.mjs || {
+            echo "missing scripts/pick-proposer-issue.mjs in APP_DIR=$APP_DIR"
+            ls -la scripts | sed -n '1,200p' || true
+            exit 1
+          }
+
+          node scripts/pick-proposer-issue.mjs "${ISSUE_NUMBER:-0}" > /tmp/proposer.pick.env
+          cat /tmp/proposer.pick.env >> /tmp/proposer.env
+          source /tmp/proposer.pick.env
+
+          if [[ "${TARGET_FOUND:-0}" != "1" ]]; then
+            echo 'SKIP=1' >> /tmp/proposer.env
+            echo "SKIP_REASON=${TARGET_REASON:-no_target}" >> /tmp/proposer.env
+            echo "No target batch"
+            exit 0
+          fi
+
+          echo "Target batch:"
+          grep -E '^(TARGET_PRIMARY_ISSUE|TARGET_ISSUES|TARGET_COUNT|TARGET_CHEMIN)=' /tmp/proposer.env
+
+      - name: Derive deterministic batch identity
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env
+          [[ "${SKIP:-0}" != "1" ]] || { echo "Skipped"; exit 0; }
+
+          export TARGET_ISSUES TARGET_CHEMIN
+
+          node --input-type=module - <<'NODE'
+          import fs from "node:fs";
+          import crypto from "node:crypto";
+
+          const issues = String(process.env.TARGET_ISSUES || "")
+            .trim()
+            .split(/\s+/)
+            .filter(Boolean)
+            .sort((a, b) => Number(a) - Number(b));
+
+          const chemin = String(process.env.TARGET_CHEMIN || "").trim();
+          const keySource = `${chemin}::${issues.join(",")}`;
+          const hash = crypto.createHash("sha1").update(keySource).digest("hex").slice(0, 12);
+          const primary = issues[0] || "0";
+          const batchBranch = `bot/proposer-${primary}-${hash}`;
+
+          fs.appendFileSync(
+            "/tmp/proposer.env",
+            [
+              `BATCH_KEY=${JSON.stringify(keySource)}`,
+              `BATCH_HASH=${JSON.stringify(hash)}`,
+              `BATCH_BRANCH=${JSON.stringify(batchBranch)}`
+            ].join("\n") + "\n"
+          );
+          NODE
+
+          echo "Batch identity:"
+          grep -E '^(BATCH_KEY|BATCH_HASH|BATCH_BRANCH)=' /tmp/proposer.env
+
+      - name: Inspect open proposer PRs
+        env:
+          FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env
+          [[ "${SKIP:-0}" != "1" ]] || { echo "Skipped"; exit 0; }
+
+          curl -fsS \
+            -H "Authorization: token $FORGE_TOKEN" \
+            -H "Accept: application/json" \
+            "$API_BASE/api/v1/repos/$OWNER/$REPO/pulls?state=open&limit=100" \
+            -o /tmp/open_pulls.json
+
+          export TARGET_ISSUES="${TARGET_ISSUES:-}"
+          export BATCH_BRANCH="${BATCH_BRANCH:-}"
+          export BATCH_KEY="${BATCH_KEY:-}"
+
+          node --input-type=module - <<'NODE' >> /tmp/proposer.env
+          import fs from "node:fs";
+
+          const pulls = JSON.parse(fs.readFileSync("/tmp/open_pulls.json", "utf8"));
+          const issues = String(process.env.TARGET_ISSUES || "")
+            .trim()
+            .split(/\s+/)
+            .filter(Boolean);
+
+          const batchBranch = String(process.env.BATCH_BRANCH || "");
+          const batchKey = String(process.env.BATCH_KEY || "");
+
+          const proposerOpen = Array.isArray(pulls)
+            ? pulls.filter((pr) => String(pr?.head?.ref || "").startsWith("bot/proposer-"))
+            : [];
+
+          const sameBatch = proposerOpen.find((pr) => {
+            const ref = String(pr?.head?.ref || "");
+            const title = String(pr?.title || "");
+            const body = String(pr?.body || "");
+
+            if (batchBranch && ref === batchBranch) return true;
+            if (batchKey && body.includes(`Batch-Key: ${batchKey}`)) return true;
+
+            return issues.some((n) =>
+              ref.startsWith(`bot/proposer-${n}-`) ||
+              title.includes(`#${n}`) ||
+              body.includes(`#${n}`) ||
+              body.includes(`ticket #${n}`)
+            );
+          });
+
+          const out = [];
+
+          if (sameBatch) {
+            out.push("SKIP=1");
+            out.push(`SKIP_REASON=${JSON.stringify("issue_already_has_open_pr")}`);
+            out.push(`OPEN_PR_URL=${JSON.stringify(String(sameBatch.html_url || sameBatch.url || ""))}`);
+            out.push(`OPEN_PR_BRANCH=${JSON.stringify(String(sameBatch?.head?.ref || ""))}`);
+          } else if (proposerOpen.length > 0) {
+            const first = proposerOpen[0];
+            out.push("SKIP=1");
+            out.push(`SKIP_REASON=${JSON.stringify("queue_busy_open_proposer_pr")}`);
+            out.push(`OPEN_PR_URL=${JSON.stringify(String(first.html_url || first.url || ""))}`);
+            out.push(`OPEN_PR_BRANCH=${JSON.stringify(String(first?.head?.ref || ""))}`);
+          }
+
+          process.stdout.write(out.join("\n") + (out.length ? "\n" : ""));
+          NODE
+
+      - name: Guard on remote batch branch before heavy work
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env
+          [[ "${SKIP:-0}" != "1" ]] || { echo "Skipped"; exit 0; }
+
+          if git ls-remote --exit-code --heads origin "$BATCH_BRANCH" >/dev/null 2>&1; then
+            echo 'SKIP=1' >> /tmp/proposer.env
+            echo 'SKIP_REASON="batch_branch_exists_without_pr"' >> /tmp/proposer.env
+            echo "OPEN_PR_BRANCH=${BATCH_BRANCH}" >> /tmp/proposer.env
+            echo "Remote batch branch already exists -> skip duplicate materialization"
+            exit 0
+          fi
+
+          echo "Remote batch branch is free"
+
+      - name: Comment issue if queued / skipped
+        if: ${{ always() }}
+        env:
+          FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env || true
+
+          [[ "${SKIP:-0}" == "1" ]] || exit 0
+          [[ "${EVENT_NAME:-}" != "push" ]] || exit 0
+
+          if [[ "${SKIP_REASON:-}" == "label_not_state_approved_event" || "${SKIP_REASON:-}" == "label_not_state_approved" ]]; then
+            echo "Skip reason=${SKIP_REASON} -> no comment"
+            exit 0
+          fi
+
+          test -n "${FORGE_TOKEN:-}" || exit 0
+
+          ISSUE_TO_COMMENT="${ISSUE_NUMBER:-0}"
+          if [[ "$ISSUE_TO_COMMENT" == "0" || -z "$ISSUE_TO_COMMENT" ]]; then
+            ISSUE_TO_COMMENT="${TARGET_PRIMARY_ISSUE:-0}"
+          fi
+          [[ "$ISSUE_TO_COMMENT" != "0" ]] || exit 0
+
+          case "${SKIP_REASON:-}" in
+            queue_busy_open_proposer_pr)
+              MSG="Ticket queued in proposer queue. An open proposer PR already exists: ${OPEN_PR_URL:-"(URL unavailable)"}. The workflow will resume after merge on main."
+              ;;
+            issue_already_has_open_pr)
+              MSG="This batch already has an open proposer PR: ${OPEN_PR_URL:-"(URL unavailable)"}"
+              ;;
+            batch_branch_exists_without_pr)
+              MSG="This batch already has a remote batch branch (${OPEN_PR_BRANCH:-"(unknown branch)"}). Manual inspection is required before any new proposer PR is created."
+              ;;
+            batch_branch_already_materialized)
+              MSG="This batch was already materialized by another run on branch ${OPEN_PR_BRANCH:-"(unknown branch)"}. No duplicate PR was created."
+              ;;
+            explicit_issue_missing_chemin)
+              MSG="Proposer Apply: cannot process this ticket automatically because field Chemin is missing or unreadable."
+              ;;
+            explicit_issue_missing_type)
+              MSG="Proposer Apply: cannot process this ticket automatically because field Type is missing or unreadable."
+              ;;
+            explicit_issue_not_approved)
+              MSG="Proposer Apply: this ticket is not currently labeled state/approved."
+              ;;
+            explicit_issue_rejected)
+              MSG="Proposer Apply: this ticket has state/rejected and is not eligible for the proposer queue."
+              ;;
+            no_open_approved_proposer_issue)
+              MSG="No approved proposer ticket is currently waiting."
+              ;;
+            *)
+              MSG="Proposer Apply: skip - ${SKIP_REASON:-unspecified reason}."
+              ;;
+          esac
+
+          export MSG
+          node --input-type=module - <<'NODE' > /tmp/proposer.skip.comment.json
+          const msg = process.env.MSG || "";
+          process.stdout.write(JSON.stringify({ body: msg }));
+          NODE
+
+          curl -fsS -X POST \
+            -H "Authorization: token $FORGE_TOKEN" \
+            -H "Content-Type: application/json" \
+            "$API_BASE/api/v1/repos/$OWNER/$REPO/issues/$ISSUE_TO_COMMENT/comments" \
+            --data-binary @/tmp/proposer.skip.comment.json || true
+
+      - name: NPM harden
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env
+          [[ "${SKIP:-0}" != "1" ]] || exit 0
+
+          cd "$APP_DIR"
+          npm config set fetch-retries 5
+          npm config set fetch-retry-mintimeout 20000
+          npm config set fetch-retry-maxtimeout 120000
+          npm config set registry https://registry.npmjs.org
+
+      - name: Install deps
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env
+          [[ "${SKIP:-0}" != "1" ]] || exit 0
+
+          cd "$APP_DIR"
+          npm ci --no-audit --no-fund
+
+      - name: Build dist baseline
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env
+          [[ "${SKIP:-0}" != "1" ]] || exit 0
+
+          cd "$APP_DIR"
+          npm run build
+
+      - name: Apply proposer batch on bot branch
+        continue-on-error: true
+        env:
+          FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
+          BOT_GIT_NAME: ${{ secrets.BOT_GIT_NAME }}
+          BOT_GIT_EMAIL: ${{ secrets.BOT_GIT_EMAIL }}
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env
+          [[ "${SKIP:-0}" != "1" ]] || { echo "Skipped"; exit 0; }
+
+          git config user.name "${BOT_GIT_NAME:-archicratie-bot}"
+          git config user.email "${BOT_GIT_EMAIL:-bot@archicratie.local}"
+
+          START_SHA="$(git rev-parse HEAD)"
+          BR="$BATCH_BRANCH"
+          echo "BRANCH=$BR" >> /tmp/proposer.env
+          git checkout -b "$BR"
+
+          export GITEA_OWNER="$OWNER"
+          export GITEA_REPO="$REPO"
+          export FORGE_API="$API_BASE"
+
+          LOG="/tmp/proposer-apply.log"
+          : > "$LOG"
+
+          RC=0
+          FAILED_ISSUE=""
+
+          for ISSUE in $TARGET_ISSUES; do
+            echo "" >> "$LOG"
+            echo "== ticket #$ISSUE ==" >> "$LOG"
+
+            set +e
+            (cd "$APP_DIR" && node scripts/apply-ticket.mjs "$ISSUE" --alias --commit) >> "$LOG" 2>&1
+            STEP_RC=$?
+            set -e
+
+            if [[ "$STEP_RC" -ne 0 ]]; then
+              RC="$STEP_RC"
+              FAILED_ISSUE="$ISSUE"
+              break
+            fi
+          done
+
+          echo "APPLY_RC=$RC" >> /tmp/proposer.env
+          echo "FAILED_ISSUE=${FAILED_ISSUE}" >> /tmp/proposer.env
+
+          echo "Apply log (tail):"
+          tail -n 220 "$LOG" || true
+
+          END_SHA="$(git rev-parse HEAD)"
+
+          if [[ "$RC" -ne 0 ]]; then
+            echo "NOOP=0" >> /tmp/proposer.env
+            exit 0
+          fi
+
+          if [[ "$START_SHA" == "$END_SHA" ]]; then
+            echo "NOOP=1" >> /tmp/proposer.env
+          else
+            echo "NOOP=0" >> /tmp/proposer.env
+            echo "END_SHA=$END_SHA" >> /tmp/proposer.env
+          fi
+
+      - name: Rebase bot branch on latest main
+        continue-on-error: true
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env || true
+          [[ "${SKIP:-0}" != "1" ]] || exit 0
+          [[ "${APPLY_RC:-0}" == "0" ]] || exit 0
+          [[ "${NOOP:-0}" == "0" ]] || exit 0
+
+          LOG="/tmp/proposer-apply.log"
+
+          git fetch origin "$DEFAULT_BRANCH"
+
+          set +e
+          git rebase "origin/$DEFAULT_BRANCH" >> "$LOG" 2>&1
+          RC=$?
+          set -e
+
+          if [[ "$RC" -ne 0 ]]; then
+            git rebase --abort || true
+          fi
+
+          echo "REBASE_RC=$RC" >> /tmp/proposer.env
+
+          echo "Rebase log (tail):"
+          tail -n 220 "$LOG" || true
+
+      - name: Comment issues on failure
+        if: ${{ always() }}
+        env:
+          FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env || true
+          [[ "${SKIP:-0}" != "1" ]] || exit 0
+
+          APPLY_RC="${APPLY_RC:-0}"
+          REBASE_RC="${REBASE_RC:-0}"
+
+          if [[ "$APPLY_RC" == "0" && "$REBASE_RC" == "0" ]]; then
+            echo "No failure detected"
+            exit 0
+          fi
+
+          test -n "${FORGE_TOKEN:-}" || exit 0
+
+          if [[ -f /tmp/proposer-apply.log ]]; then
+            BODY="$(tail -n 160 /tmp/proposer-apply.log | sed 's/\r$//')"
+          else
+            BODY="(no proposer log found)"
+          fi
+
+          export BODY APPLY_RC REBASE_RC FAILED_ISSUE
+
+          if [[ "$APPLY_RC" != "0" ]]; then
+            export FAILURE_KIND="apply"
+          else
+            export FAILURE_KIND="rebase"
+          fi
+
+          node --input-type=module - <<'NODE' > /tmp/proposer.failure.comment.json
+          const body = process.env.BODY || "";
+          const applyRc = process.env.APPLY_RC || "0";
+          const rebaseRc = process.env.REBASE_RC || "0";
+          const failedIssue = process.env.FAILED_ISSUE || "unknown";
+          const kind = process.env.FAILURE_KIND || "apply";
+
+          const msg =
+            kind === "apply"
+              ? `Batch proposer failed on ticket #${failedIssue} (rc=${applyRc}).\n\n\`\`\`\n${body}\n\`\`\`\n`
+              : `Rebase proposer failed on main (rc=${rebaseRc}).\n\n\`\`\`\n${body}\n\`\`\`\n`;
+
+          process.stdout.write(JSON.stringify({ body: msg }));
+          NODE
+
+          for ISSUE in ${TARGET_ISSUES:-}; do
+            curl -fsS -X POST \
+              -H "Authorization: token $FORGE_TOKEN" \
+              -H "Content-Type: application/json" \
+              "$API_BASE/api/v1/repos/$OWNER/$REPO/issues/$ISSUE/comments" \
+              --data-binary @/tmp/proposer.failure.comment.json || true
+          done
+
+      - name: Late guard against duplicate batch materialization
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env || true
+          [[ "${SKIP:-0}" != "1" ]] || exit 0
+          [[ "${APPLY_RC:-0}" == "0" ]] || exit 0
+          [[ "${REBASE_RC:-0}" == "0" ]] || exit 0
+          [[ "${NOOP:-0}" == "0" ]] || exit 0
+
+          REMOTE_SHA="$(git ls-remote --heads origin "$BATCH_BRANCH" | awk 'NR==1 {print $1}')"
+
+          if [[ -n "${REMOTE_SHA:-}" && "${REMOTE_SHA}" != "${END_SHA:-}" ]]; then
+            echo 'SKIP=1' >> /tmp/proposer.env
+            echo 'SKIP_REASON="batch_branch_already_materialized"' >> /tmp/proposer.env
+            echo "OPEN_PR_BRANCH=${BATCH_BRANCH}" >> /tmp/proposer.env
+            echo "Remote batch branch already exists at $REMOTE_SHA -> skip duplicate push/PR"
+            exit 0
+          fi
+
+          echo "Late guard OK"
+
+      - name: Push bot branch
+        if: ${{ always() }}
+        env:
+          FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env || true
+          [[ "${SKIP:-0}" != "1" ]] || exit 0
+          [[ "${APPLY_RC:-0}" == "0" ]] || { echo "Apply failed -> skip push"; exit 0; }
+          [[ "${REBASE_RC:-0}" == "0" ]] || { echo "Rebase failed -> skip push"; exit 0; }
+          [[ "${NOOP:-0}" == "0" ]] || { echo "No-op -> skip push"; exit 0; }
+          [[ -n "${BRANCH:-}" ]] || { echo "BRANCH unset -> skip push"; exit 0; }
+
+          AUTH_URL="$(node --input-type=module -e '
+            const [clone, tok] = process.argv.slice(1);
+            const u = new URL(clone);
+            u.username = "oauth2";
+            u.password = tok;
+            console.log(u.toString());
+          ' "$CLONE_URL" "$FORGE_TOKEN")"
+
+          git remote set-url origin "$AUTH_URL"
+          git push -u origin "$BRANCH"
+
+      - name: Create PR + comment issues + close issues
+        if: ${{ always() }}
+        env:
+          FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env || true
+          [[ "${SKIP:-0}" != "1" ]] || exit 0
+          [[ "${APPLY_RC:-0}" == "0" ]] || exit 0
+          [[ "${REBASE_RC:-0}" == "0" ]] || exit 0
+          [[ "${NOOP:-0}" == "0" ]] || exit 0
+          [[ -n "${BRANCH:-}" ]] || { echo "BRANCH unset -> skip PR"; exit 0; }
+
+          test -n "${FORGE_TOKEN:-}" || { echo "Missing FORGE_TOKEN"; exit 1; }
+
+          OPEN_PRS_JSON="$(curl -fsS \
+            -H "Authorization: token $FORGE_TOKEN" \
+            -H "Accept: application/json" \
+            "$API_BASE/api/v1/repos/$OWNER/$REPO/pulls?state=open&limit=100")"
+
+          export OPEN_PRS_JSON BATCH_BRANCH BATCH_KEY
+
+          EXISTING_PR_URL="$(node --input-type=module -e '
+            const pulls = JSON.parse(process.env.OPEN_PRS_JSON || "[]");
+            const branch = String(process.env.BATCH_BRANCH || "");
+            const key = String(process.env.BATCH_KEY || "");
+            const current = Array.isArray(pulls)
+              ? pulls.find((pr) => {
+                  const ref = String(pr?.head?.ref || "");
+                  const body = String(pr?.body || "");
+                  return (branch && ref === branch) || (key && body.includes(`Batch-Key: ${key}`));
+                })
+              : null;
+            process.stdout.write(current ? String(current.html_url || current.url || "") : "");
+          ')"
+
+          if [[ -n "${EXISTING_PR_URL:-}" ]]; then
+            echo "PR already exists for this batch: $EXISTING_PR_URL"
+            exit 0
+          fi
+
+          if [[ "${TARGET_COUNT:-0}" == "1" ]]; then
+            PR_TITLE="proposer: apply ticket #${TARGET_PRIMARY_ISSUE}"
+          else
+            PR_TITLE="proposer: apply ${TARGET_COUNT} tickets on ${TARGET_CHEMIN}"
+          fi
+
+          export PR_TITLE TARGET_CHEMIN TARGET_ISSUES BRANCH END_SHA DEFAULT_BRANCH OWNER BATCH_KEY
+
+          node --input-type=module -e '
+            import fs from "node:fs";
+
+            const issues = String(process.env.TARGET_ISSUES || "")
+              .trim()
+              .split(/\s+/)
+              .filter(Boolean);
+
+            const body = [
+              `PR auto depuis ticket${issues.length > 1 ? "s" : ""} ${issues.map((n) => `#${n}`).join(", ")} (state/approved).`,
+              "",
+              `- Chemin: ${process.env.TARGET_CHEMIN || "(inconnu)"}`,
+              "- Tickets:",
+              ...issues.map((n) => `  - #${n}`),
+              `- Branche: ${process.env.BRANCH || ""}`,
+              `- Commit: ${process.env.END_SHA || "unknown"}`,
+              `- Batch-Key: ${process.env.BATCH_KEY || ""}`,
+              "",
+              "Merge si CI OK."
+            ].join("\n");
+
+            fs.writeFileSync(
+              "/tmp/proposer.pr.json",
+              JSON.stringify({
+                title: process.env.PR_TITLE || "proposer: apply tickets",
+                body,
+                base: process.env.DEFAULT_BRANCH || "main",
+                head: `${process.env.OWNER}:${process.env.BRANCH}`,
+                allow_maintainer_edit: true
+              })
+            );
+          '
+
+          PR_JSON="$(curl -fsS -X POST \
+            -H "Authorization: token $FORGE_TOKEN" \
+            -H "Content-Type: application/json" \
+            "$API_BASE/api/v1/repos/$OWNER/$REPO/pulls" \
+            --data-binary @/tmp/proposer.pr.json)"
+
+          PR_URL="$(node --input-type=module -e 'const pr = JSON.parse(process.argv[1] || "{}"); console.log(pr.html_url || pr.url || "");' "$PR_JSON")"
+
+          test -n "$PR_URL" || {
+            echo "PR URL missing. Raw: $PR_JSON"
+            exit 1
+          }
+
+          for ISSUE in $TARGET_ISSUES; do
+            export ISSUE PR_URL
+
+            node --input-type=module -e '
+              import fs from "node:fs";
+
+              const issue = process.env.ISSUE || "";
+              const url = process.env.PR_URL || "";
+              const msg =
+                `PR proposer creee pour le ticket #${issue} : ${url}\n\n` +
+                `Le ticket est cloture automatiquement ; la discussion peut se poursuivre dans la PR.`;
+
+              fs.writeFileSync(
+                "/tmp/proposer.issue.close.comment.json",
+                JSON.stringify({ body: msg })
+              );
+            '
+
+            curl -fsS -X POST \
+              -H "Authorization: token $FORGE_TOKEN" \
+              -H "Content-Type: application/json" \
+              "$API_BASE/api/v1/repos/$OWNER/$REPO/issues/$ISSUE/comments" \
+              --data-binary @/tmp/proposer.issue.close.comment.json
+
+            curl -fsS -X PATCH \
+              -H "Authorization: token $FORGE_TOKEN" \
+              -H "Content-Type: application/json" \
+              "$API_BASE/api/v1/repos/$OWNER/$REPO/issues/$ISSUE" \
+              --data-binary '{"state":"closed"}'
+
+            ISSUE_STATE="$(curl -fsS \
+              -H "Authorization: token $FORGE_TOKEN" \
+              -H "Accept: application/json" \
+              "$API_BASE/api/v1/repos/$OWNER/$REPO/issues/$ISSUE" | \
+              node --input-type=module -e 'let s=""; process.stdin.on("data", d => s += d); process.stdin.on("end", () => { const j = JSON.parse(s || "{}"); process.stdout.write(String(j.state || "")); });')"
+
+            [[ "$ISSUE_STATE" == "closed" ]] || {
+              echo "Issue #$ISSUE is still not closed after PATCH"
+              exit 1
+            }
+          done
+
+          echo "PR: $PR_URL"
+
+      - name: Finalize
+        if: ${{ always() }}
+        run: |
+          set -euo pipefail
+          source /tmp/proposer.env || true
+          [[ "${SKIP:-0}" != "1" ]] || exit 0
+
+          if [[ "${APPLY_RC:-0}" != "0" ]]; then
+            echo "Apply failed (rc=${APPLY_RC})"
+            exit "${APPLY_RC}"
+          fi
+
+          if [[ "${REBASE_RC:-0}" != "0" ]]; then
+            echo "Rebase failed (rc=${REBASE_RC})"
+            exit "${REBASE_RC}"
+          fi
+
+          echo "Proposer queue OK"

.gitea/workflows/smoke.yml

@@ -3,7 +3,7 @@ on: [push, workflow_dispatch]
 
 jobs:
   smoke:
-    runs-on: ubuntu-latest
+    runs-on: mac-ci
     steps:
       - run: node -v && npm -v
       - run: echo "runner OK"

.gitignore

@@ -3,6 +3,10 @@
 .env.*
 !.env.example
 
+# dev-only
+public/_auth/whoami
+public/_auth/whoami/*
+
 # --- local backups ---
 *.bak
 *.bak.*
@@ -24,3 +28,7 @@ public/favicon_io.zip
 
 # macOS
 .DS_Store
+
+# local temp workspace
+.tmp/
+public/__ops/health.json

Dockerfile

@@ -12,7 +12,7 @@ ENV npm_config_update_notifier=false \
 # (Optionnel mais propre) git + certificats
 RUN apt-get -o Acquire::Retries=5 -o Acquire::ForceIPv4=true update \
  && apt-get install -y --no-install-recommends ca-certificates git \
- && rm -rf /var/lib/apt/lists/*	
+ && rm -rf /var/lib/apt/lists/*
 
 # Déps d’abord (cache Docker)
 COPY package.json package-lock.json ./
@@ -25,9 +25,21 @@ COPY . .
 ARG PUBLIC_GITEA_BASE
 ARG PUBLIC_GITEA_OWNER
 ARG PUBLIC_GITEA_REPO
+
+# ✅ Canonical + sitemap base (astro.config.mjs lit process.env.PUBLIC_SITE)
+ARG PUBLIC_SITE
+
+# ✅ Garde-fou : si 1 → build fail si PUBLIC_SITE absent
+ARG REQUIRE_PUBLIC_SITE=0
+
 ENV PUBLIC_GITEA_BASE=$PUBLIC_GITEA_BASE \
     PUBLIC_GITEA_OWNER=$PUBLIC_GITEA_OWNER \
-    PUBLIC_GITEA_REPO=$PUBLIC_GITEA_REPO
+    PUBLIC_GITEA_REPO=$PUBLIC_GITEA_REPO \
+    PUBLIC_SITE=$PUBLIC_SITE \
+    REQUIRE_PUBLIC_SITE=$REQUIRE_PUBLIC_SITE
+
+# ✅ antifragile : refuse de builder sans PUBLIC_SITE quand on l’exige
+RUN node -e "if (process.env.REQUIRE_PUBLIC_SITE==='1' && !process.env.PUBLIC_SITE) { console.error('FATAL: PUBLIC_SITE is required (canonical/sitemap).'); process.exit(1) }"
 
 # Build Astro (postbuild tourne via npm scripts)
 RUN npm run build
@@ -38,4 +50,4 @@ COPY nginx.conf /etc/nginx/conf.d/default.conf
 COPY --from=build /app/dist/ /usr/share/nginx/html/
 RUN find /usr/share/nginx/html -type d -exec chmod 755 {} \; \
  && find /usr/share/nginx/html -type f -exec chmod 644 {} \;
-EXPOSE 80
+EXPOSE 80

astro.config.mjs

@@ -86,6 +86,10 @@ function rehypeDedupeIds() {
 }
 
 export default defineConfig({
+  legacy: {
+    collectionsBackwardsCompat: true,
+  },
+  
   output: "static",
   trailingSlash: "always",
   site: process.env.PUBLIC_SITE ?? "http://localhost:4321",

config/anchor-churn-allowlist.json

@@ -0,0 +1,5 @@
+{
+  "accepted_resets": {
+    "archicrat-ia/chapitre-1/index.html": "Reset intentionnel des ancres après révision doctrinale substantielle du chapitre 1. Site neuf, sans annotations ni compatibilité descendante à préserver."
+  }
+}

docker-compose.yml

@@ -5,6 +5,8 @@ services:
       dockerfile: Dockerfile
       network: host
       args:
+        REQUIRE_PUBLIC_SITE: "1"
+        PUBLIC_SITE: "https://staging.archicratie.trans-hands.synology.me"
         PUBLIC_GITEA_BASE: ${PUBLIC_GITEA_BASE}
         PUBLIC_GITEA_OWNER: ${PUBLIC_GITEA_OWNER}
         PUBLIC_GITEA_REPO: ${PUBLIC_GITEA_REPO}
@@ -20,6 +22,8 @@ services:
       dockerfile: Dockerfile
       network: host
       args:
+        REQUIRE_PUBLIC_SITE: "1"
+        PUBLIC_SITE: "https://archicratie.trans-hands.synology.me"
         PUBLIC_GITEA_BASE: ${PUBLIC_GITEA_BASE}
         PUBLIC_GITEA_OWNER: ${PUBLIC_GITEA_OWNER}
         PUBLIC_GITEA_REPO: ${PUBLIC_GITEA_REPO}
@@ -27,4 +31,4 @@ services:
     container_name: archicratie-web-green
     ports:
       - "127.0.0.1:8082:80"
-    restart: unless-stopped
+    restart: unless-stopped

docs/EDITORIAL-ANNOTATIONS-SPEC.md

@@ -0,0 +1,327 @@
+# SPEC — Annotations éditoriales (YAML v1) + merge + anti-doublon
+> Objectif : permettre aux tickets (Gitea) de déposer “Références / Médias / Commentaires” dans `src/annotations/**`,
+> de façon univoque, stable, et sans régression.
+
+## 0) Contexte et intention
+Le site est statique. L’édition collaborative se fait via :
+- un mode “proposition” (UI / modal)
+- un ticket Gitea (issue) standardisé
+- un script d’application côté éditeur (`apply-ticket.mjs` ou équivalent)
+- génération d’un YAML d’annotations versionné dans Git
+
+La donnée d’annotation doit être :
+- **audit-able** (Git)
+- **merge-able** (sans tout casser)
+- **stable** (IDs paragraphes / liens / médias)
+- **scalable** (éviter YAML monstrueux à long terme)
+
+## 1) Arborescence canonique
+### 1.1 Un workKey par “ouvrage / section du site”
+On veut une univocité entre :
+- SiteNav (Méthode, Essai-thèse, Traité, Cas IA, Glossaire, Atlas)
+et
+- l’arborescence annotations
+
+Proposition canonique (workKey = route racine) :
+- `methode`
+- `archicrat-ia` (Essai-thèse ArchiCraT-IA)
+- `traite`
+- `ia`
+- `glossaire`
+- `atlas`
+
+### 1.2 Règle de stockage “v1”
+**Par page**, un YAML unique :
+
+src/annotations/<workKey>/<slugSansWorkKey>.yml
+
+Exemples :
+- Page : `/archicrat-ia/prologue/`
+  - slug content = `archicrat-ia/prologue`
+  - fichier : `src/annotations/archicrat-ia/prologue.yml`
+
+- Page : `/traite/00-demarrage/`
+  - fichier : `src/annotations/traite/00-demarrage.yml`
+
+> Note : “slugSansWorkKey” = la partie après `<workKey>/`.
+> S’il y a des sous-dossiers (chapitres), le chemin reflète la structure : `chapitre-1/section-a.yml` si on choisit du sharding.
+
+## 2) Question “gros YAML” : page unique vs sharding par paragraphe
+### 2.1 Option A (v1 recommandée) : 1 YAML par page
+Avantages :
+- simple
+- peu de fichiers
+- diff lisible si volume modéré
+- cohérent avec un modèle “annotations par page”
+
+Inconvénients :
+- YAML peut grossir si milliers d’annotations
+
+### 2.2 Option B (v2 future) : sharding par paragraphe
+
+src/annotations/<workKey>/<slugSansWorkKey>/<paraId>.yml
+
+Avantages :
+- fichiers petits
+- merges moins conflictuels
+Inconvénients :
+- plus de fichiers
+- tooling plus complexe (indexation + merge multi-fichiers)
+
+### 2.3 Recommandation de mission (sans casser l’existant)
+- On démarre en **Option A**.
+- On se garde une migration future (v2) quand le volume réel le justifie.
+- On impose dès v1 : **clé unique + merge déterministe + anti-doublon**, ce qui rend la migration future possible.
+
+## 3) Format YAML v1 (schéma complet)
+### 3.1 Top-level
+en yaml :
+
+schema: 1
+
+# Optionnel mais recommandé (doit matcher la page)
+page: "<workKey>/<slugSansWorkKey>"
+
+meta:
+  title: "Titre de la page (optionnel)"
+  updatedAt: "2026-02-21T12:34:56Z"   # ISO8601
+  updatedBy: "username"              # compte editor
+  source:
+    kind: "ticket"
+    id: 123
+    url: "https://gitea.../issues/123"
+
+paras:
+  "<paraId>":
+    references: []
+    media: []
+    comments: []
+
+### 3.2 paras : clé = paraId (ex: p-0-d7974f88)
+
+Chaque paragraphe peut porter 3 types d’éléments :
+
+references
+
+media
+
+comments
+
+Règle : si une section est vide, elle peut être [] ou absente.
+Mais pour simplifier les merges, on recommande de garder la forme canonique avec [].
+
+## 4) Formats des items + clés uniques
+### 4.1 References
+#### 4.1.1 Format
+
+references:
+  - id: "ref:doi:10.1234/abcd.efgh"   # clé stable (voir 4.1.2)
+    kind: "doi"                       # doi | url | isbn | arxiv | hal | other
+    label: "Titre court"
+    target: "https://doi.org/10.1234/abcd.efgh"
+    note: "Pourquoi c’est pertinent (optionnel)"
+    addedAt: "2026-02-21T12:34:56Z"
+    addedBy: "username"
+
+#### 4.1.2 Règle de clé unique (anti-doublon)
+
+id doit être stable et déterministe :
+
+doi → ref:doi:<doi>
+
+isbn → ref:isbn:<isbn>
+
+url → ref:url:<normalizedUrl>
+
+Normalisation URL (v1) : au minimum
+
+trim
+
+lowercase scheme/host
+
+retirer trailing slash si non significatif
+
+conserver query si importante
+
+#### 4.1.3 Merge / précédence
+
+Quand on merge deux listes references :
+
+union par id (clé unique)
+
+si même id existe des deux côtés :
+
+conserver kind/target de l’item le plus “riche” (target non vide gagne)
+
+concat/merge note :
+
+si notes différentes : garder les deux en les séparant (ex: noteA + "\n---\n" + noteB)
+
+addedAt : conserver le plus ancien
+
+addedBy : conserver le premier (ou liste si on veut, mais v1 simple : first)
+
+### 4.2 Media
+#### 4.2.1 Format
+
+media:
+  - id: "media:image:sha256:abcd..."   # clé stable (voir 4.2.2)
+    type: "image"                      # image | video | audio | file
+    src: "/public/media/<workKey>/<slugSansWorkKey>/<paraId>/<filename>"
+    caption: "Légende (optionnel)"
+    credit: "Auteur/source (optionnel)"
+    license: "CC-BY (optionnel)"
+    addedAt: "2026-02-21T12:34:56Z"
+    addedBy: "username"
+
+#### 4.2.2 Règle de clé unique
+
+id déterministe :
+
+idéal : hash du fichier (sha256)
+
+sinon : hash de type + src
+
+v1 (si on ne calcule pas de hash fichier) :
+
+media:<type>:<src>
+
+#### 4.2.3 Merge / précédence
+
+union par id
+
+si collision :
+
+garder src identique (sinon c’est un bug)
+
+fusionner caption/credit/license selon “non vide gagne”
+
+addedAt : plus ancien
+
+### 4.3 Comments
+#### 4.3.1 Format
+
+comments:
+  - id: "cmt:20260221T123456Z:username:0001"
+    kind: "comment"        # comment | question | objection | todo | validation
+    text: "Texte du commentaire"
+    status: "open"         # open | resolved
+    addedAt: "2026-02-21T12:34:56Z"
+    addedBy: "username"
+    source:
+      kind: "ticket"
+      id: 123
+
+#### 4.3.2 Clé unique
+
+Les commentaires sont “append-only” → id peut être générée (timestamp + user + compteur)
+
+Anti-doublon : si on ré-applique un ticket, on refuse de dupliquer un id existant.
+
+#### 4.3.3 Merge / précédence
+
+union par id
+
+collisions rares, mais si elles arrivent :
+
+si textes différents → garder les deux (on renomme l’id du second)
+
+## 5) Règles globales de merge (résumé)
+
+Quand on applique un ticket sur un YAML existant :
+
+vérifier schema == 1
+
+vérifier page si présent :
+
+doit matcher <workKey>/<slugSansWorkKey>
+
+paras :
+
+créer paras[paraId] si absent
+
+pour chaque liste (references/media/comments) :
+
+merge par id (anti-doublon)
+
+appliquer règles de précédence (non vide gagne / concat note / append-only comments)
+
+## 6) Table de correspondance “UI ticket → YAML”
+
+Cette table permet à un successeur IA d’implémenter apply-ticket.mjs sans ambiguïté.
+
+### 6.1 Champs UI minimaux
+
+workKey (sélection implicite via page)
+
+pagePath (ex: /archicrat-ia/prologue/)
+
+pageSlug (ex: archicrat-ia/prologue)
+
+paraId (ex: p-0-d7974f88)
+
+kind :
+
+reference
+
+media
+
+comment
+
+### 6.2 Mapping exact
+
+| UI kind   | UI champs                                                   | YAML cible                   |
+| --------- | ----------------------------------------------------------- | ---------------------------- |
+| reference | kind(doi/url/isbn), target, label, note                     | `paras[paraId].references[]` |
+| media     | type(image/video/audio/file), src, caption, credit, license | `paras[paraId].media[]`      |
+| comment   | kind(comment/question/objection/todo/validation), text      | `paras[paraId].comments[]`   |
+
+### 6.3 Règles de génération d’ID (implémentation)
+
+reference.id :
+
+doi : ref:doi:${doi}
+
+isbn : ref:isbn:${isbn}
+
+url : ref:url:${normalize(url)}
+
+media.id :
+
+media:${type}:${src}
+
+comment.id :
+
+cmt:${timestamp}:${user}:${counter}
+
+## 7) Validation YAML (sanity)
+
+Avant commit (et en CI) :
+
+YAML parse OK
+
+schema OK
+
+page si présent cohérent
+
+paras est un mapping
+
+paraId match pattern : ^p-\d+-[a-f0-9]{8}$ (existant)
+
+src media pointe dans /public/media/... (ou /media/... si on choisit un alias, mais v1 canon : /public/media/...)
+
+## 8) Notes de compatibilité
+
+Les routes “Essai-thèse” ont été migrées vers /archicrat-ia/*.
+
+Les anciennes routes /archicratie/archicrat-ia/* peuvent exister en legacy, mais la donnée canonique d’annotation doit suivre le workKey final (archicrat-ia).
+
+## 9) Ce que l’étape 9 devra implémenter
+
+pipeline : ticket → YAML (apply-ticket)
+
+index : build-annotations-index + check-annotations
+
+tooling : détection médias orphelins / liens cassés
+
+éventuellement : migration vers sharding par paragraphe (v2) si volume réel le justifie

docs/OPS-DEPLOYMENT.md

@@ -25,6 +25,19 @@ Objectif : déployer une nouvelle version du site sur le NAS (DS220+) sans jamai
 
 ➡️ Déploiement = `docs/DEPLOY_PROD_SYNOLOGY_DS220.md` (procédure détaillée, à jour).
 
+## Mise à jour (2026-03-03) — Gate CI de déploiement (SKIP / HOTPATCH / FULL) + preuves A/B
+
+La procédure de déploiement “vivante” est désormais pilotée par **Gitea Actions** via le workflow :
+- `.gitea/workflows/deploy-staging-live.yml`
+
+Ce workflow décide automatiquement :
+- **FULL** (rebuild + restart blue + green) dès qu’un changement impacte le build (ex: `src/content/`, `src/pages/`, `scripts/`, `src/anchors/`, etc.)
+- **HOTPATCH** (patch JSON + copie media) quand le changement ne concerne que `src/annotations/` et/ou `public/media/`
+- **SKIP** sinon
+
+Les preuves et la procédure de test reproductible A/B sont documentées dans :
+➡️ `docs/runbooks/DEPLOY-BLUE-GREEN.md` → section “CI Deploy gate (merge-proof) + Tests A/B + preuve alias injection”.
+
 ## Schéma (résumé, sans commandes)
 
 - Ne jamais toucher au slot live.

docs/OPS_COCKPIT.md

@@ -202,4 +202,33 @@ docker compose logs --tail=200 web_blue
 docker compose logs --tail=200 web_green
 
 # Si tu veux suivre en live :
-docker compose logs -f web_green
+docker compose logs -f web_green
+
+
+## Historique synthétique (2026-03-03) — Stabilisation CI/CD “zéro surprise”
+
+### Problème initial observé
+- Déploiement parfois lancé en “hotpatch” alors qu’un rebuild était nécessaire.
+- Sur merge commits, la détection de fichiers modifiés pouvait être ambiguë.
+- Résultat : besoin de `force=1` manuel pour éviter des incohérences.
+
+### Correctif appliqué
+- Gate CI rendu **merge-proof** :
+  - lecture de `BEFORE` et `AFTER` depuis `event.json`
+  - calcul des fichiers modifiés via `git diff --name-only BEFORE AFTER`
+
+- Politique de décision stabilisée :
+  - FULL auto dès qu’un changement impacte build/runtime (content/pages/scripts/anchors/etc.)
+  - HOTPATCH auto uniquement pour annotations/media
+
+### Preuves
+- Test A (touch src/content) :
+  - Gate flags: HAS_FULL=1 HAS_HOTPATCH=0 → MODE=full
+- Test B (touch src/annotations) :
+  - Gate flags: HAS_FULL=0 HAS_HOTPATCH=1 → MODE=hotpatch
+
+### Audit post-déploiement (preuves côté NAS)
+- 8081 + 8082 répondent HTTP 200
+- `/para-index.json` + `/annotations-index.json` OK
+- Aliases injectés visibles dans HTML via `.para-alias` quand alias présent
+

docs/START-HERE.md

@@ -0,0 +1,683 @@
+# START-HERE — Archicratie / Édition Web (v3)
+> Onboarding + exploitation “nickel chrome” (DEV → Gitea → CI → Release → Blue/Green → Edge/SSO → localhost auto-sync)
+
+## 0) TL;DR (la règle d’or)
+
+- **Gitea = source canonique**.
+- **`main` est protégée** : toute modification passe par **branche → PR → CI → merge**.
+- **Le NAS n’est pas la source** : si un hotfix est fait sur NAS, il doit être **backporté immédiatement** via PR.
+- **Le site est statique Astro** : la prod sert du HTML via nginx ; l’accès est contrôlé au niveau reverse-proxy (Traefik + Authelia).
+- **Le localhost automatique n’est pas le repo de dev** : il tourne depuis un **worktree dédié**, synchronisé sur `origin/main`.
+
+---
+
+## 1) Architecture mentale (ultra simple)
+
+- **DEV canonique (Mac Studio)** : édition, dev, tests, commits, pushes
+- **Gitea** : dépôt canonique, PR, CI, workflows éditoriaux
+- **NAS (DS220+)** : déploiement blue/green
+  - `web_blue` → staging upstream → `127.0.0.1:8081`
+  - `web_green` → live upstream → `127.0.0.1:8082`
+- **Edge (Traefik)** : routage des hosts
+  - `staging.archicratie...` → 8081
+  - `archicratie...` → 8082
+  - **Authelia** devant, via middleware `chain-auth@file`
+- **Localhost auto-sync**
+  - un **repo canonique de développement**
+  - un **worktree localhost miroir de `origin/main`**
+  - un **agent de sync**
+  - un **agent Astro**
+
+---
+
+## 2) Répertoires & conventions (repo)
+
+### 2.1 Contenu canon (édition)
+
+- `src/content/**` : contenu MD / MDX canon
+- `src/pages/**` : routes Astro
+- `src/components/**` : composants UI
+- `src/layouts/**` : layouts
+- `src/styles/**` : CSS global
+
+### 2.2 Annotations (pré-Édition “tickets”)
+
+- `src/annotations/<workKey>/<slug>.yml`
+- Exemple :
+  `src/annotations/archicrat-ia/prologue.yml`
+
+Objectif :
+stocker “Références / Médias / Commentaires” par page et par paragraphe (`p-...`).
+
+### 2.3 Scripts (tooling / build)
+
+- `scripts/inject-anchor-aliases.mjs` : injection aliases dans `dist`
+- `scripts/dedupe-ids-dist.mjs` : retrait IDs dupliqués
+- `scripts/build-para-index.mjs` : index paragraphes
+- `scripts/build-annotations-index.mjs` : index annotations
+- `scripts/check-anchors.mjs` : contrat stabilité d’ancres
+- `scripts/check-annotations*.mjs` : sanity YAML + médias
+
+> Important : ces scripts ne sont pas accessoires.  
+> Ils font partie du contrat de stabilité éditoriale.
+
+---
+
+## 3) Les trois espaces à ne jamais confondre
+
+### 3.1 Repo canonique de développement
+
+```text
+/Volumes/FunIA/dev/archicratie-edition/site
+```
+
+Usage :
+
+- développement normal
+- branches de travail
+- nouvelles fonctionnalités
+- corrections manuelles
+- commits
+- pushes
+- PR
+
+### 3.2 Worktree localhost miroir de `main`
+
+```text
+/Users/s-funia/ops-local/archicratie/localhost-worktree
+```
+
+Branche attendue :
+
+```text
+localhost-sync
+```
+
+Usage :
+
+- exécuter le localhost automatique
+- refléter `origin/main`
+- ne jamais servir d’espace de développement
+
+### 3.3 Ops local hors repo
+
+```text
+/Users/s-funia/ops-local/archicratie
+```
+
+Usage :
+
+- scripts d’exploitation
+- état
+- logs
+- automatisation `launchd`
+
+---
+
+## 4) Pourquoi cette séparation existe
+
+Il ne faut pas utiliser le repo canonique de développement comme serveur localhost permanent.
+
+Sinon on mélange :
+
+- travail en cours
+- commits non poussés
+- essais temporaires
+- état réellement publié sur `main`
+
+Le résultat devient ambigu.
+
+La séparation retenue est donc :
+
+- **repo canonique** = espace de développement
+- **worktree localhost** = miroir exécutable de `origin/main`
+- **ops local** = scripts et automatisation
+
+C’est cette séparation qui rend le système lisible, robuste et opérable.
+
+---
+
+## 5) Workflow Git “pro” (main protégée)
+
+### 5.1 Cycle standard (toute modif)
+
+```bash
+git checkout main
+git pull --ff-only
+
+BR="chore/xxx-$(date +%Y%m%d)"
+git checkout -b "$BR"
+
+# dev…
+npm i
+npm run build
+npm run test:anchors
+
+git add -A
+git commit -m "xxx: description claire"
+git push -u origin "$BR"
+```
+
+### 5.2 PR vers `main`
+
+- ouvrir une PR dans Gitea
+- attendre une CI verte
+- merger
+- laisser les workflows faire le reste
+
+### 5.3 Cas spécial : hotfix prod (NAS)
+
+On peut faire un hotfix d’urgence côté NAS si nécessaire.
+
+Mais l’état final doit toujours revenir dans Gitea :
+
+- branche
+- PR
+- CI
+- merge
+
+---
+
+## 6) Déploiement (NAS) — principe
+
+### 6.1 Release pack
+
+On génère un pack reproductible, puis on déploie.
+
+### 6.2 Blue/Green
+
+- `web_blue` = staging (`8081`)
+- `web_green` = live (`8082`)
+
+Le reverse-proxy choisit l’upstream selon le host demandé.
+
+---
+
+## 7) Happy path complet
+
+### 7.1 DEV (Mac)
+
+```bash
+git checkout main && git pull --ff-only
+git checkout -b chore/my-change-$(date +%Y%m%d)
+
+npm i
+rm -rf .astro node_modules/.vite dist
+npm run build
+npm run test:anchors
+npm run dev
+```
+
+### 7.2 Push + PR
+
+```bash
+git add -A
+git commit -m "chore: my change"
+git push -u origin chore/my-change-YYYYMMDD
+```
+
+Puis ouvrir la PR dans Gitea.
+
+### 7.3 Déploiement NAS
+
+Voir :
+
+```text
+docs/runbooks/DEPLOY-BLUE-GREEN.md
+```
+
+---
+
+## 8) Localhost auto-sync — ce qu’il faut retenir
+
+Le localhost automatique sert à voir **la vérité de `main`**, pas à développer du neuf.
+
+### 8.1 Scripts principaux
+
+#### Script de sync
+
+```text
+~/ops-local/archicratie/auto-sync-localhost.sh
+```
+
+Rôle :
+
+- fetch `origin/main`
+- réaligner le worktree localhost
+- lancer `npm ci` si besoin
+- redéclencher l’agent Astro si nécessaire
+
+#### Script Astro
+
+```text
+~/ops-local/archicratie/run-astro-localhost.sh
+```
+
+Rôle :
+
+- lancer `astro dev`
+- depuis le bon worktree
+- avec le bon runtime Node
+- sur `127.0.0.1:4321`
+
+> Oui : ce script est nécessaire.  
+> Il isole proprement le lancement du serveur Astro dans un contexte `launchd` stable.
+
+### 8.2 LaunchAgents
+
+#### Agent sync
+
+```text
+~/Library/LaunchAgents/me.archicratie.localhost-sync.plist
+```
+
+#### Agent Astro
+
+```text
+~/Library/LaunchAgents/me.archicratie.localhost-astro.plist
+```
+
+### 8.3 Document de référence
+
+Pour tout le détail d’exploitation du localhost automatique, lire :
+
+```text
+docs/OPS-LOCALHOST-AUTO-SYNC.md
+```
+
+---
+
+## 9) Règle d’or : il y a deux usages locaux distincts
+
+### 9.1 Voir ce qui est réellement sur `main`
+
+Utiliser :
+
+```text
+http://127.0.0.1:4321
+```
+
+Ce localhost doit être considéré comme :
+
+**un miroir local exécutable de `origin/main`**
+
+### 9.2 Développer / tester une nouvelle fonctionnalité
+
+Utiliser le repo canonique :
+
+```bash
+cd /Volumes/FunIA/dev/archicratie-edition/site
+npm run dev
+```
+
+Donc :
+
+- **localhost auto-sync** = vérité de `main`
+- **localhost de dev manuel** = expérimentation en cours
+
+Il ne faut pas les confondre.
+
+---
+
+## 10) Ce qu’il ne faut pas faire
+
+### 10.1 Ne pas développer dans le worktree localhost
+
+Le worktree localhost est piloté automatiquement.
+
+Il peut être :
+
+- réaligné
+- nettoyé
+- redémarré
+
+Donc :
+
+- pas de commits dedans
+- pas de dev feature dedans
+- pas d’expérimentation de fond dedans
+
+### 10.2 Ne pas utiliser le repo canonique comme miroir auto-sync
+
+Sinon on mélange :
+
+- espace de dev
+- état publié
+- serveur local permanent
+
+### 10.3 Ne pas remettre les scripts ops sur un volume externe
+
+Les scripts d’ops doivent rester sous `HOME`.
+
+Le fait de les mettre sous `/Volumes/...` a déjà provoqué des erreurs du type :
+
+```text
+Operation not permitted
+```
+
+### 10.4 Ne pas supprimer `run-astro-localhost.sh`
+
+Ce script fait partie de l’architecture actuelle.
+Le supprimer reviendrait à réintroduire le flou entre sync Git et exécution d’Astro.
+
+---
+
+## 11) Commandes de contrôle essentielles
+
+### 11.1 État global
+
+```bash
+~/ops-local/archicratie/doctor-localhost.sh
+```
+
+### 11.2 État Git
+
+```bash
+git -C ~/ops-local/archicratie/localhost-worktree rev-parse HEAD
+git -C /Volumes/FunIA/dev/archicratie-edition/site ls-remote origin refs/heads/main
+git -C ~/ops-local/archicratie/localhost-worktree branch --show-current
+```
+
+### 11.3 État LaunchAgents
+
+```bash
+launchctl print "gui/$(id -u)/me.archicratie.localhost-sync" | sed -n '1,160p'
+launchctl print "gui/$(id -u)/me.archicratie.localhost-astro" | sed -n '1,160p'
+```
+
+### 11.4 État logs
+
+```bash
+tail -n 120 ~/ops-local/archicratie/logs/auto-sync-localhost.log
+tail -n 120 ~/ops-local/archicratie/logs/astro-localhost.log
+tail -n 80 ~/Library/Logs/archicratie-localhost-sync.err.log
+tail -n 80 ~/Library/Logs/archicratie-localhost-astro.err.log
+```
+
+### 11.5 État serveur
+
+```bash
+lsof -nP -iTCP:4321 -sTCP:LISTEN
+PID="$(lsof -tiTCP:4321 -sTCP:LISTEN | head -n 1)"
+ps -p "$PID" -o pid=,command=
+lsof -a -p "$PID" -d cwd
+```
+
+### 11.6 Vérification contenu
+
+```bash
+curl -s http://127.0.0.1:4321/archicrat-ia/prologue/ | grep -n "taxe Zucman"
+```
+
+---
+
+## 12) Problèmes classiques + diagnostic
+
+### 12.1 “Le staging ne ressemble pas au local”
+
+Comparer les upstream directs :
+
+```bash
+curl -sS http://127.0.0.1:8081/ | head -n 2
+curl -sS http://127.0.0.1:8082/ | head -n 2
+```
+
+Vérifier le routeur edge :
+
+```bash
+curl -sSI -H 'Host: staging.archicratie.trans-hands.synology.me' http://127.0.0.1:18080/ \
+ | grep -iE 'HTTP/|location:|x-archi-router'
+```
+
+Voir :
+
+```text
+docs/runbooks/EDGE-TRAEFIK.md
+```
+
+### 12.2 Canonical incorrect
+
+Cause probable : `PUBLIC_SITE` mal injecté au build.
+
+Test :
+
+```bash
+curl -sS http://127.0.0.1:8082/ | grep -oE 'rel="canonical" href="[^"]+"' | head -1
+```
+
+Voir :
+
+```text
+docs/runbooks/ENV-PUBLIC_SITE.md
+```
+
+### 12.3 Contrat anchors en échec après migration d’URL
+
+Procédure safe :
+
+```bash
+cp -a tests/anchors-baseline.json /tmp/anchors-baseline.json.bak.$(date +%F-%H%M%S)
+
+node - <<'NODE'
+import fs from 'fs';
+const p='tests/anchors-baseline.json';
+const j=JSON.parse(fs.readFileSync(p,'utf8'));
+const out={};
+for (const [k,v] of Object.entries(j)) {
+  const nk = k.replace(/^archicratie\/archicrat-ia\//, 'archicrat-ia/');
+  out[nk]=v;
+}
+fs.writeFileSync(p, JSON.stringify(out,null,2)+'\n');
+console.log('updated keys:', Object.keys(j).length, '->', Object.keys(out).length);
+NODE
+
+npm run test:anchors
+```
+
+### 12.4 “Le localhost auto-sync ne montre pas les dernières modifs”
+
+Commande réflexe :
+
+```bash
+~/ops-local/archicratie/doctor-localhost.sh
+```
+
+Puis :
+
+```bash
+git -C ~/ops-local/archicratie/localhost-worktree rev-parse HEAD
+git -C /Volumes/FunIA/dev/archicratie-edition/site ls-remote origin refs/heads/main
+```
+
+Si les SHA diffèrent :
+- le sync n’a pas tourné
+- ou l’agent sync a un problème
+
+### 12.5 “Le SHA est bon mais le contenu web est faux”
+
+Vérifier quel Astro écoute réellement :
+
+```bash
+lsof -nP -iTCP:4321 -sTCP:LISTEN
+PID="$(lsof -tiTCP:4321 -sTCP:LISTEN | head -n 1)"
+ps -p "$PID" -o pid=,command=
+lsof -a -p "$PID" -d cwd
+```
+
+Attendu :
+- commande contenant `astro dev`
+- cwd = `~/ops-local/archicratie/localhost-worktree`
+
+### 12.6 Erreur `EBADENGINE`
+
+Cause probable :
+- Node 23 utilisé au lieu de Node 22
+
+Résolution :
+- forcer `node@22` dans les scripts et les LaunchAgents
+
+### 12.7 Erreur `Operation not permitted`
+
+Cause probable :
+- scripts d’ops placés sous `/Volumes/...`
+
+Résolution :
+- garder les scripts sous :
+
+```text
+~/ops-local/archicratie
+```
+
+### 12.8 Erreur `EPERM` sur `astro.mjs`
+
+Cause probable :
+- ancien worktree sur volume externe
+- ancien chemin résiduel
+- Astro lancé depuis un mauvais emplacement
+
+Résolution :
+- worktree localhost sous :
+
+```text
+~/ops-local/archicratie/localhost-worktree
+```
+
+- scripts cohérents avec ce chemin
+- réinstallation propre via :
+
+```bash
+~/ops-local/archicratie/install-localhost-sync.sh
+```
+
+---
+
+## 13) Redémarrage machine
+
+Après reboot, le comportement attendu est :
+
+1. le LaunchAgent sync se recharge
+2. le LaunchAgent Astro se recharge
+3. le worktree localhost est réaligné
+4. Astro redémarre sur `127.0.0.1:4321`
+
+### Vérification rapide après reboot
+
+```bash
+~/ops-local/archicratie/doctor-localhost.sh
+```
+
+Si nécessaire :
+
+```bash
+~/ops-local/archicratie/install-localhost-sync.sh
+```
+
+---
+
+## 14) Procédure de secours manuelle
+
+### Forcer un sync
+
+```bash
+~/ops-local/archicratie/auto-sync-localhost.sh
+```
+
+### Réinstaller proprement le dispositif local
+
+```bash
+~/ops-local/archicratie/install-localhost-sync.sh
+```
+
+### Diagnostic complet
+
+```bash
+~/ops-local/archicratie/doctor-localhost.sh
+```
+
+---
+
+## 15) Décision d’exploitation finale
+
+La politique retenue est la suivante :
+
+- **repo canonique** = espace de développement
+- **worktree localhost** = miroir automatique de `main`
+- **ops sous HOME** = scripts, logs, automation
+- **LaunchAgent sync** = réalignement Git
+- **LaunchAgent Astro** = exécution stable du serveur local
+- **Astro local** = lancé uniquement depuis le worktree localhost
+
+Cette séparation rend le dispositif plus :
+
+- lisible
+- robuste
+- opérable
+- antifragile
+
+---
+
+## 16) Résumé opératoire
+
+### Pour voir la vérité de `main`
+
+Ouvrir :
+
+```text
+http://127.0.0.1:4321
+```
+
+Le serveur doit provenir de :
+
+```text
+/Users/s-funia/ops-local/archicratie/localhost-worktree
+```
+
+### Pour développer
+
+Travailler dans :
+
+```text
+/Volumes/FunIA/dev/archicratie-edition/site
+```
+
+avec les commandes habituelles.
+
+### Pour réparer vite
+
+```bash
+~/ops-local/archicratie/doctor-localhost.sh
+~/ops-local/archicratie/auto-sync-localhost.sh
+```
+
+---
+
+## 17) Mémoire courte
+
+Si un jour plus rien n’est clair, repartir de ces commandes :
+
+```bash
+~/ops-local/archicratie/doctor-localhost.sh
+git -C ~/ops-local/archicratie/localhost-worktree rev-parse HEAD
+git -C /Volumes/FunIA/dev/archicratie-edition/site ls-remote origin refs/heads/main
+lsof -nP -iTCP:4321 -sTCP:LISTEN
+```
+
+Puis lire :
+
+```bash
+tail -n 120 ~/ops-local/archicratie/logs/auto-sync-localhost.log
+tail -n 120 ~/ops-local/archicratie/logs/astro-localhost.log
+```
+
+---
+
+## 18) Statut actuel visé
+
+Quand tout fonctionne correctement :
+
+- le worktree localhost pointe sur le même SHA que `origin/main`
+- `astro dev` écoute sur `127.0.0.1:4321`
+- son cwd est `~/ops-local/archicratie/localhost-worktree`
+- le contenu servi correspond au contenu mergé sur `main`
+
+C’est l’état de référence à préserver.

docs/runbooks/DEPLOY-BLUE-GREEN.md

@@ -0,0 +1,546 @@
+# RUNBOOK — Déploiement Blue/Green (NAS DS220+)
+> Objectif : déployer une release **sans casser**, avec rollback immédiat.
+
+## 0) Portée
+Ce runbook décrit le déploiement de l’édition web Archicratie sur NAS (Synology), en mode blue/green :
+- `web_blue` : upstream staging → `127.0.0.1:8081`
+- `web_green` : upstream live → `127.0.0.1:8082`
+- Edge Traefik publie :
+  - `staging.archicratie.trans-hands.synology.me` → 8081
+  - `archicratie.trans-hands.synology.me` → 8082
+
+## 1) Pré-requis
+- Accès shell NAS (user `archicratia`) + `sudo`
+- Docker Compose Synology nécessite souvent :
+  - `sudo env DOCKER_API_VERSION=1.43 docker compose ...`
+- Les fichiers edge Traefik sont dans :
+  - `/volume2/docker/edge/config/dynamic/`
+
+## 2) Répertoires canon (NAS)
+On considère ces chemins (adapter si besoin, mais rester cohérent) :
+- Base : `/volume2/docker/archicratie-web`
+- Releases : `/volume2/docker/archicratie-web/releases/YYYYMMDD-HHMMSS/app`
+- Symlink actif : `/volume2/docker/archicratie-web/current` → pointe vers le `.../app` actif
+
+## 3) Garde-fous (AVANT toute action)
+### 3.1 Snapshot de l’état actuel
+en bash :
+
+cd /volume2/docker/archicratie-web
+ls -la current || true
+readlink current || true
+
+### 3.2 Vérifier l’état live/staging upstream direct
+
+curl -sSI http://127.0.0.1:8081/ | head -n 12
+curl -sSI http://127.0.0.1:8082/ | head -n 12
+
+### 3.3 Vérifier l’état edge (host routing)
+
+curl -sSI -H 'Host: staging.archicratie.trans-hands.synology.me' http://127.0.0.1:18080/ \
+ | grep -iE 'HTTP/|location:|x-archi-router' | head -n 30
+
+curl -sSI -H 'Host: archicratie.trans-hands.synology.me' http://127.0.0.1:18080/ \
+ | grep -iE 'HTTP/|location:|x-archi-router' | head -n 30
+
+ Si tu n’es pas authentifié, tu verras un 302 vers auth... : c’est normal.
+
+## 4) Procédure de déploiement (release pack → nouvelle release)
+### 4.1 Déposer le pack
+
+Hypothèse : tu as un .tgz “release pack” (issu de release-pack.sh) dans incoming/ :
+
+cd /volume2/docker/archicratie-web
+ls -la incoming | tail -n 20
+
+### 4.2 Créer un répertoire release
+
+TS="$(date +%Y%m%d-%H%M%S)"
+REL="/volume2/docker/archicratie-web/releases/$TS"
+APP="$REL/app"
+sudo mkdir -p "$APP"
+
+### 4.3 Extraire le pack
+
+PKG="/volume2/docker/archicratie-web/incoming/archicratie-web.tar.gz"  # adapter au nom réel
+sudo tar -xzf "$PKG" -C "$APP"
+
+### 4.4 Sanity check (fichiers attendus)
+
+sudo test -f "$APP/Dockerfile" && echo "OK Dockerfile"
+sudo test -f "$APP/docker-compose.yml" && echo "OK compose"
+sudo test -f "$APP/astro.config.mjs" && echo "OK astro config"
+sudo test -f "$APP/src/layouts/EditionLayout.astro" && echo "OK layout"
+sudo test -f "$APP/src/pages/archicrat-ia/index.astro" && echo "OK archicrat-ia index"
+sudo test -f "$APP/docs/diagrams/archicratie-web-edition-global-verbatim-v2.svg" && echo "OK diagrams"
+
+### 4.5 Permissions (crucial sur Synology)
+
+But : archicratia:users doit pouvoir traverser le parent + lire le contenu.
+
+sudo chown -R archicratia:users "$REL"
+sudo chmod -R u+rwX,g+rX,o-rwx "$REL"
+sudo chmod 750 "$REL" "$APP"
+
+Vérifier :
+
+ls -ld "$REL" "$APP"
+ls -la "$APP" | head
+
+## 5) Activation : basculer current vers la nouvelle release
+### 5.1 Backup du current existant
+
+cd /volume2/docker/archicratie-web
+TS2="$(date +%F-%H%M%S)"
+
+# on backup "current" (symlink ou dossier)
+if [ -e current ] || [ -L current ]; then
+  sudo mv -f current "current.BAK.$TS2"
+  echo "✅ backup: current.BAK.$TS2"
+fi
+
+### 5.2 Recréer current (symlink propre)
+
+sudo ln -s "$APP" current
+
+ls -la current
+readlink current
+sudo test -f current/docker-compose.yml && echo "✅ OK: current/docker-compose.yml"
+
+Si cd current échoue, c’est que current n’est pas un symlink correct OU que le parent n’est pas traversable (permissions).
+
+## 6) Build & run : (re)construire web_blue/web_green
+### 6.1 Vérifier la config compose
+
+cd /volume2/docker/archicratie-web/current
+sudo env DOCKER_API_VERSION=1.43 docker compose -f docker-compose.yml config \
+  | grep -nE 'services:|web_blue:|web_green:|context:|dockerfile:|PUBLIC_SITE|REQUIRE_PUBLIC_SITE' \
+  | sed -n '1,220p'
+
+### 6.2 Build propre (recommandé si changement de code/config)
+
+sudo env DOCKER_API_VERSION=1.43 docker compose build --no-cache web_blue web_green
+
+### 6.3 Up (force recreate)
+
+sudo env DOCKER_API_VERSION=1.43 docker compose up -d --force-recreate web_blue web_green
+
+### 6.4 Vérifier upstream direct (8081/8082)
+
+curl -sSI http://127.0.0.1:8081/ | head -n 12
+curl -sSI http://127.0.0.1:8082/ | head -n 12
+
+## 7) Tests de non-régression (MINIMAL CHECKLIST)
+
+À exécuter systématiquement après up.
+
+### 7.1 Upstreams directs
+
+curl -sSI http://127.0.0.1:8081/ | head -n 12
+curl -sSI http://127.0.0.1:8082/ | head -n 12
+
+### 7.2 Canonical (anti “localhost en prod”)
+
+curl -sS http://127.0.0.1:8081/ | grep -oE 'rel="canonical" href="[^"]+"' | head -n 1
+curl -sS http://127.0.0.1:8082/ | grep -oE 'rel="canonical" href="[^"]+"' | head -n 1
+
+Attendu :
+
+blue (8081) → https://staging.archicratie.../
+
+green (8082) → https://archicratie.../
+
+### 7.3 Edge routing (Host header + diag)
+
+curl -sSI -H 'Host: staging.archicratie.trans-hands.synology.me' http://127.0.0.1:18080/ \
+ | grep -iE 'HTTP/|location:|x-archi-router' | head -n 30
+
+curl -sSI -H 'Host: staging.archicratie.trans-hands.synology.me' http://127.0.0.1:18080/_auth/whoami \
+ | grep -iE 'HTTP/|location:|x-archi-router' | head -n 30
+
+### 7.4 Smoke UI (manuel)
+
+Home : lien “Essai-thèse — ArchiCraT-IA” → /archicrat-ia/
+
+TOC global : liens /archicrat-ia/* (pas de préfixe /archicratie/archicrat-ia/*)
+
+Reading-follow/TOC local : scroll ok
+
+## 8) Rollback (si un seul test est mauvais)
+
+Objectif : revenir immédiatement à l’état précédent.
+
+### 8.1 Repointer current sur l’ancien backup
+
+cd /volume2/docker/archicratie-web
+ls -la current.BAK.* | tail -n 5
+
+# choisir le plus récent
+OLD="current.BAK.YYYY-MM-DD-HHMMSS"
+sudo rm -f current
+sudo ln -s "$(readlink -f "$OLD")" current 2>/dev/null || sudo ln -s "$(readlink "$OLD")" current
+
+ls -la current
+readlink current
+
+### 8.2 Rebuild + recreate
+
+cd /volume2/docker/archicratie-web/current
+sudo env DOCKER_API_VERSION=1.43 docker compose build --no-cache web_blue web_green
+sudo env DOCKER_API_VERSION=1.43 docker compose up -d --force-recreate web_blue web_green
+
+### 8.3 Re-tester la checklist (section 7)
+
+Si rollback OK : investiguer en environnement isolé (staging upstream uniquement, ou release dans un autre current).
+
+## 9) Notes opérationnelles
+
+Ne jamais modifier dist/ “à la main” sur NAS.
+
+Si un hotfix prod est indispensable : documenter et backporter via PR Gitea.
+
+Le canonical dépend du build : PUBLIC_SITE doit être injecté (voir runbook ENV-PUBLIC_SITE).
+
+## 10) CI Deploy (Gitea Actions) — Gate SKIP / HOTPATCH / FULL (merge-proof) + preuves
+
+Cette section documente le comportement **canonique** du workflow :
+- `.gitea/workflows/deploy-staging-live.yml`
+
+Objectif : **zéro surprise**.
+On ne veut plus “penser à force=1”.
+Le gate doit décider automatiquement, y compris sur des **merge commits**.
+
+### 10.1 — Principe (ce que fait réellement le gate)
+
+Le job `deploy` calcule les fichiers modifiés entre :
+- `BEFORE` = commit précédent (avant le push sur main)
+- `AFTER`  = commit actuel (après le push / merge sur main)
+
+Puis il classe le déploiement dans un mode :
+
+- **MODE=full**
+  - rebuild image + restart `archicratie-web-blue` (8081) + `archicratie-web-green` (8082)
+  - warmup endpoints (para-index, annotations-index, pagefind.js)
+  - vérification canonical staging + live
+
+- **MODE=hotpatch**
+  - rebuild d’un `annotations-index.json` consolidé depuis `src/annotations/**`
+  - patch direct dans les conteneurs en cours d’exécution (blue+green)
+  - copie des médias modifiés `public/media/**` vers `/usr/share/nginx/html/media/**`
+  - smoke sur `/annotations-index.json` des deux ports
+
+- **MODE=skip**
+  - pas de déploiement (on évite le bruit)
+
+⚠️ Important : le mode “hotpatch” **ne rebuild pas** Astro.
+Donc toute modification de contenu, routes, scripts, anchors, etc. doit déclencher **full**.
+
+### 10.2 — Matrice de décision (règles officielles)
+
+Le gate définit deux flags :
+- `HAS_FULL=1` si changement “build-impacting”
+- `HAS_HOTPATCH=1` si changement “annotations/media only”
+
+Règle de priorité :
+1) Si `HAS_FULL=1` → **MODE=full**
+2) Sinon si `HAS_HOTPATCH=1` → **MODE=hotpatch**
+3) Sinon → **MODE=skip**
+
+#### 10.2.1 — Changements qui déclenchent FULL (build-impacting)
+
+Exemples typiques (non exhaustif, mais on couvre le cœur) :
+- `src/content/**` (contenu MD/MDX)
+- `src/pages/**` (routes Astro)
+- `src/anchors/**` (aliases d’ancres)
+- `scripts/**` (tooling postbuild : injection, index, tests)
+- `src/layouts/**`, `src/components/**`, `src/styles/**` (rendu et scripts inline)
+- `astro.config.mjs`, `package.json`, `package-lock.json`
+- `Dockerfile`, `docker-compose.yml`, `nginx.conf`
+- `.gitea/workflows/**` (changement infra CI/CD)
+
+=> On veut **full** pour garantir cohérence et éviter “site partiellement mis à jour”.
+
+#### 10.2.2 — Changements qui déclenchent HOTPATCH (sans rebuild)
+
+Uniquement :
+- `src/annotations/**` (shards YAML)
+- `public/media/**` (assets média)
+
+=> On veut hotpatch pour vitesse et éviter rebuild NAS.
+
+### 10.3 — “Merge-proof” : pourquoi on ne lit PAS seulement `git show $SHA`
+
+Sur un merge commit, `git show --name-only $SHA` peut être trompeur selon le contexte.
+La méthode robuste est :
+- utiliser `event.json` (Gitea Actions) pour récupérer `before` et `after`
+- calculer `git diff --name-only BEFORE AFTER`
+
+C’est ce qui rend le gate **merge-proof**.
+
+### 10.4 — Tests de preuve A/B (reproductibles)
+
+Ces tests valident le gate sans ambiguïté.
+But : vérifier que le mode choisi est EXACTEMENT celui attendu.
+
+#### Test A — toucher `src/content/...` (FULL auto)
+
+1) Créer une branche test
+2) Modifier 1 fichier dans `src/content/` (ex : ajouter une ligne de commentaire non destructive)
+3) PR → merge dans `main`
+4) Vérifier dans `deploy-staging-live.yml` :
+
+Attendus :
+- `Gate flags: HAS_FULL=1 HAS_HOTPATCH=0`
+- `✅ build-impacting change -> MODE=full (rebuild+restart)`
+- Les étapes FULL (blue puis green) s’exécutent réellement
+
+#### Test B — toucher `src/annotations/...` uniquement (HOTPATCH auto)
+
+1) Créer une branche test
+2) Modifier 1 fichier sous `src/annotations/**` (ex: un champ comment, ts, etc.)
+3) PR → merge dans `main`
+4) Vérifier dans `deploy-staging-live.yml` :
+
+Attendus :
+- `Gate flags: HAS_FULL=0 HAS_HOTPATCH=1`
+- `✅ annotations/media change -> MODE=hotpatch`
+- Les étapes FULL sont “skip” (durée 0s)
+- L’étape HOTPATCH s’exécute réellement
+
+### 10.5 — Preuve opérationnelle côté NAS (2 URLs + 2 commandes)
+
+But : prouver que staging+live servent bien les endpoints essentiels (et que le déploiement n’a pas “fait semblant”).
+
+#### 10.5.1 — Deux URLs à vérifier (staging et live)
+
+- Staging (blue) : `http://127.0.0.1:8081/`
+- Live (green)  : `http://127.0.0.1:8082/`
+
+#### 10.5.2 — Deux commandes minimales (zéro débat)
+
+```bash
+curl -fsSI http://127.0.0.1:8081/ | head -n 1
+curl -fsSI http://127.0.0.1:8082/ | head -n 1
+
+---
+
+## 10) CI Deploy (Gitea Actions) — Gate SKIP / HOTPATCH / FULL (merge-proof) + preuves
+
+Cette section documente le comportement **canonique** du workflow :
+- `.gitea/workflows/deploy-staging-live.yml`
+
+Objectif : **zéro surprise**.
+On ne veut plus “penser à force=1”.
+Le gate doit décider automatiquement, y compris sur des **merge commits**.
+
+### 10.1 — Principe (ce que fait réellement le gate)
+
+Le job `deploy` calcule les fichiers modifiés entre :
+- `BEFORE` = commit précédent (avant le push sur main)
+- `AFTER`  = commit actuel (après le push / merge sur main)
+
+Puis il classe le déploiement dans un mode :
+
+- **MODE=full**
+  - rebuild image + restart `archicratie-web-blue` (8081) + `archicratie-web-green` (8082)
+  - warmup endpoints (para-index, annotations-index, pagefind.js)
+  - vérification canonical staging + live
+
+- **MODE=hotpatch**
+  - rebuild d’un `annotations-index.json` consolidé depuis `src/annotations/**`
+  - patch direct dans les conteneurs en cours d’exécution (blue+green)
+  - copie des médias modifiés `public/media/**` vers `/usr/share/nginx/html/media/**`
+  - smoke sur `/annotations-index.json` des deux ports
+
+- **MODE=skip**
+  - pas de déploiement (on évite le bruit)
+
+⚠️ Important : le mode “hotpatch” **ne rebuild pas** Astro.
+Donc toute modification de contenu, routes, scripts, anchors, etc. doit déclencher **full**.
+
+### 10.2 — Matrice de décision (règles officielles)
+
+Le gate définit deux flags :
+- `HAS_FULL=1` si changement “build-impacting”
+- `HAS_HOTPATCH=1` si changement “annotations/media only”
+
+Règle de priorité :
+1) Si `HAS_FULL=1` → **MODE=full**
+2) Sinon si `HAS_HOTPATCH=1` → **MODE=hotpatch**
+3) Sinon → **MODE=skip**
+
+#### 10.2.1 — Changements qui déclenchent FULL (build-impacting)
+
+Exemples typiques (non exhaustif, mais on couvre le cœur) :
+- `src/content/**` (contenu MD/MDX)
+- `src/pages/**` (routes Astro)
+- `src/anchors/**` (aliases d’ancres)
+- `scripts/**` (tooling postbuild : injection, index, tests)
+- `src/layouts/**`, `src/components/**`, `src/styles/**` (rendu et scripts inline)
+- `astro.config.mjs`, `package.json`, `package-lock.json`
+- `Dockerfile`, `docker-compose.yml`, `nginx.conf`
+- `.gitea/workflows/**` (changement infra CI/CD)
+
+=> On veut **full** pour garantir cohérence et éviter “site partiellement mis à jour”.
+
+#### 10.2.2 — Changements qui déclenchent HOTPATCH (sans rebuild)
+
+Uniquement :
+- `src/annotations/**` (shards YAML)
+- `public/media/**` (assets média)
+
+=> On veut hotpatch pour vitesse et éviter rebuild NAS.
+
+### 10.3 — “Merge-proof” : pourquoi on ne lit PAS seulement `git show $SHA`
+
+Sur un merge commit, `git show --name-only $SHA` peut être trompeur selon le contexte.
+La méthode robuste est :
+- utiliser `event.json` (Gitea Actions) pour récupérer `before` et `after`
+- calculer `git diff --name-only BEFORE AFTER`
+
+C’est ce qui rend le gate **merge-proof**.
+
+### 10.4 — Tests de preuve A/B (reproductibles)
+
+Ces tests valident le gate sans ambiguïté.
+But : vérifier que le mode choisi est EXACTEMENT celui attendu.
+
+#### Test A — toucher `src/content/...` (FULL auto)
+
+1) Créer une branche test
+2) Modifier 1 fichier dans `src/content/` (ex : ajouter une ligne de commentaire non destructive)
+3) PR → merge dans `main`
+4) Vérifier dans `deploy-staging-live.yml` :
+
+Attendus :
+- `Gate flags: HAS_FULL=1 HAS_HOTPATCH=0`
+- `✅ build-impacting change -> MODE=full (rebuild+restart)`
+- Les étapes FULL (blue puis green) s’exécutent réellement
+
+#### Test B — toucher `src/annotations/...` uniquement (HOTPATCH auto)
+
+1) Créer une branche test
+2) Modifier 1 fichier sous `src/annotations/**` (ex: un champ comment, ts, etc.)
+3) PR → merge dans `main`
+4) Vérifier dans `deploy-staging-live.yml` :
+
+Attendus :
+- `Gate flags: HAS_FULL=0 HAS_HOTPATCH=1`
+- `✅ annotations/media change -> MODE=hotpatch`
+- Les étapes FULL sont “skip” (durée 0s)
+- L’étape HOTPATCH s’exécute réellement
+
+### 10.5 — Preuve opérationnelle côté NAS (2 URLs + 2 commandes)
+
+But : prouver que staging+live servent bien les endpoints essentiels (et que le déploiement n’a pas “fait semblant”).
+
+#### 10.5.1 — Deux URLs à vérifier (staging et live)
+
+- Staging (blue) : `http://127.0.0.1:8081/`
+- Live (green)  : `http://127.0.0.1:8082/`
+
+#### 10.5.2 — Deux commandes minimales (zéro débat)
+
+en bash :
+curl -fsSI http://127.0.0.1:8081/ | head -n 1
+curl -fsSI http://127.0.0.1:8082/ | head -n 1
+
+Attendu : HTTP/1.1 200 OK des deux côtés.
+
+10.6 — Preuve “alias injection” (ancre ancienne → nouvelle) sur une page
+
+Contexte : lorsqu’un paragraphe change (ex: ticket “Proposer” appliqué),
+l’ID de paragraphe peut changer, mais on doit préserver les liens anciens via :
+
+src/anchors/anchor-aliases.json
+
+injection build-time dans dist (span .para-alias)
+
+10.6.1 — Check rapide (staging + live)
+
+Remplacer OLD/NEW par tes ids réels :
+
+Attendu : HTTP/1.1 200 OK des deux côtés.
+
+10.6 — Preuve “alias injection” (ancre ancienne → nouvelle) sur une page
+
+Contexte : lorsqu’un paragraphe change (ex: ticket “Proposer” appliqué),
+l’ID de paragraphe peut changer, mais on doit préserver les liens anciens via :
+
+src/anchors/anchor-aliases.json
+
+injection build-time dans dist (span .para-alias)
+
+10.6.1 — Check rapide (staging + live)
+
+Remplacer OLD/NEW par tes ids réels :
+
+OLD="p-1-60c7ea48"
+NEW="p-1-a21087b0"
+
+for P in 8081 8082; do
+  echo "=== $P ==="
+  HTML="$(curl -fsS "http://127.0.0.1:${P}/archicrat-ia/chapitre-3/" | tr -d '\r')"
+  echo "OLD count: $(printf '%s' "$HTML" | grep -o "$OLD" | wc -l | tr -d ' ')"
+  echo "NEW count: $(printf '%s' "$HTML" | grep -o "$NEW" | wc -l | tr -d ' ')"
+  printf '%s\n' "$HTML" | grep -nE "$OLD|$NEW|class=\"para-alias\"" | head -n 40 || true
+done
+
+Attendu :
+
+présence d’un alias : <span id="$OLD" class="para-alias"...>
+
+présence du nouveau paragraphe : <p id="$NEW">...
+
+10.6.2 — Check “lien ancien ne casse pas” (HTTP 200)
+
+for P in 8081 8082; do
+  curl -fsSI "http://127.0.0.1:${P}/archicrat-ia/chapitre-3/#${OLD}" | head -n 1
+done
+
+Attendu : HTTP/1.1 200 OK et navigation fonctionnelle côté navigateur.
+
+10.7 — Troubleshooting gate (symptômes typiques)
+Symptom 1 : job bloqué “Set up job” très longtemps
+
+Causes fréquentes :
+
+runner indisponible / capacity saturée
+
+runner ne récupère pas les tâches (fetch_timeout trop court + réseau instable)
+
+erreur dans “Gate — decide …” qui casse bash (et donne l’impression d’un hang)
+
+Commandes NAS (diagnostic rapide) :
+
+docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Image}}' | grep -E 'gitea-act-runner|registry|archicratie-web'
+docker logs --since 30m --tail 400 gitea-act-runner | tail -n 200
+Symptom 2 : conditional binary operator expected
+
+Cause :
+
+test bash du type [[ "$X" == "1" && "$Y" == "2" ]] mal formé
+
+variable vide non quotée
+
+usage d’un opérateur non supporté dans la shell effective
+
+Fix :
+
+set -euo pipefail
+
+toujours quoter : [[ "${VAR:-}" == "..." ]]
+
+logguer BEFORE/AFTER/FORCE et s’assurer qu’ils ne sont pas vides
+
+Symptom 3 : le gate liste “trop de fichiers” alors qu’on a changé 1 seul fichier
+
+Cause :
+
+comparaison faite sur le mauvais range (ex: git show sur merge, ou mauvais parent)
+Fix :
+
+toujours utiliser git diff --name-only "$BEFORE" "$AFTER" (merge-proof)
+
+confirmer dans le log : Gate ctx: BEFORE=... AFTER=...
+

docs/runbooks/EDGE-TRAEFIK.md

@@ -0,0 +1,147 @@
+# RUNBOOK — Edge Traefik (routing + SSO Authelia)
+> Objectif : comprendre et diagnostiquer rapidement qui route quoi, et pourquoi staging/live peuvent diverger.
+
+## 0) Portée
+Edge Traefik route plusieurs hosts vers des backends locaux (127.0.0.1:*), avec Auth via Authelia.
+
+Répertoire :
+- `/volume2/docker/edge/config/dynamic/`
+
+Port d’entrée edge :
+- `http://127.0.0.1:18080/` (entryPoint `web`)
+- Les hosts publics pointent vers cet edge.
+
+## 1) Fichiers dynamiques (canon)
+### 00-smoke.yml
+- route `/__smoke` vers le service `smoke_svc` → `127.0.0.1:18081`
+
+### 10-core.yml
+- définit les middlewares :
+  - `sanitize-remote`
+  - `authelia` (forwardAuth vers 9091)
+  - `chain-auth` (chain sanitize-remote + authelia)
+
+### 20-archicratie-backend.yml
+- définit service `archicratie_web` → `127.0.0.1:8082` (live upstream)
+
+### 21-archicratie-staging.yml
+- route staging host vers `127.0.0.1:8081` (staging upstream)
+- applique middlewares `diag-staging@file` et `chain-auth@file`
+- IMPORTANT : `diag-staging@file` doit exister
+
+### 22-archicratie-authinfo-staging.yml
+- route `/ _auth /` sur staging vers `whoami@file`
+- applique `diag-staging-authinfo@file` + `chain-auth@file`
+- IMPORTANT : `diag-staging-authinfo@file` doit exister
+
+### 90-overlay-staging-fix.yml (overlay de diagnostic + fallback)
+Rôle :
+- **fournir** les middlewares manquants (`diag-staging`, `diag-staging-authinfo`)
+- optionnel : fallback route si 21/22 sont cassés
+- injecter un header `X-Archi-Router` pour identifier le routeur utilisé
+
+### 92-overlay-live-fix.yml
+- route live host `archicratie.trans-hands.synology.me` → `archicratie_web@file` (8082)
+- route `/ _auth/whoami` → `whoami@file` (18081)
+
+## 2) Diagnostiquer rapidement : quel routeur répond ?
+### 2.1 Test “host header” (sans UI)
+# en bash :
+
+curl -sSI -H 'Host: staging.archicratie.trans-hands.synology.me' http://127.0.0.1:18080/ \
+ | grep -iE 'HTTP/|location:|x-archi-router' | head -n 30
+
+curl -sSI -H 'Host: staging.archicratie.trans-hands.synology.me' http://127.0.0.1:18080/_auth/whoami \
+ | grep -iE 'HTTP/|location:|x-archi-router' | head -n 30
+
+# Interprétation :
+
+X-Archi-Router: staging@21 → routeur 21-archicratie-staging.yml OK
+
+X-Archi-Router: staging-authinfo@22 → routeur authinfo OK
+
+Si tu vois staging-fallback@90 → tu es tombé sur le fallback 90 (donc 21/22 potentiellement invalides)
+
+### 2.2 Vérifier l’upstream direct derrière edge
+
+curl -sSI http://127.0.0.1:8081/ | head -n 12
+curl -sSI http://127.0.0.1:8082/ | head -n 12
+
+Si 8081 et 8082 servent des versions différentes : c’est “normal” en blue/green, mais il faut savoir laquelle est censée être staging/live.
+
+## 3) Diagnostiquer les erreurs Traefik (fichier invalide / middleware manquant)
+### 3.1 Grep “level=error”
+
+sudo docker logs edge-traefik --since 5m | grep -Ei 'level=error|middleware|router|service|yaml' | tail -n 80
+
+# Cas typique :
+
+middleware "diag-staging@file" does not exist
+→ 21-archicratie-staging.yml référence un middleware absent. Solution : le définir (souvent dans 90-overlay-staging-fix.yml).
+
+## 4) Procédure safe de modification (jamais en aveugle)
+### 4.1 Backup
+
+cd /volume2/docker/edge/config/dynamic
+TS="$(date +%F-%H%M%S)"
+sudo cp -a 90-overlay-staging-fix.yml "90-overlay-staging-fix.yml.bak.$TS"
+
+### 4.2 Édition (ex : ajouter middlewares diag)
+
+Faire une modif minimale
+
+Ne pas casser les règles existantes (Host + PathPrefix)
+
+Respecter les priorités (voir section 5)
+
+### 4.3 Reload Traefik
+
+sudo docker restart edge-traefik
+
+### 4.4 Tests immédiats
+
+curl -sSI -H 'Host: staging.archicratie.trans-hands.synology.me' http://127.0.0.1:18080/ \
+ | grep -iE 'HTTP/|location:|x-archi-router'
+
+curl -sSI -H 'Host: staging.archicratie.trans-hands.synology.me' http://127.0.0.1:18080/_auth/whoami \
+ | grep -iE 'HTTP/|location:|x-archi-router'
+
+## 5) Priorités Traefik (le point subtil)
+
+Traefik choisit le routeur selon :
+
+la correspondance de règle
+
+la priority (plus grand gagne)
+
+en cas d’égalité, l’ordre interne (à éviter)
+
+### 5.1 Canon pour staging
+
+21-archicratie-staging.yml : priority 10
+
+22-archicratie-authinfo-staging.yml : priority 10000
+
+90-overlay-staging-fix.yml :
+
+fallback host : priority faible (ex: 5) pour ne PAS écraser 21
+
+fallback whoami : priority < 10000 (ex: 9000) pour ne PAS écraser 22
+
+=> On garde 90 comme filet de sécurité / diag, pas comme “source”.
+
+## 6) Rollback (si un changement edge casse staging/live)
+
+cd /volume2/docker/edge/config/dynamic
+# choisir le bon backup
+sudo mv -f 90-overlay-staging-fix.yml "90-overlay-staging-fix.yml.BAD.$(date +%F-%H%M%S)"
+sudo cp -a 90-overlay-staging-fix.yml.bak.YYYY-MM-DD-HHMMSS 90-overlay-staging-fix.yml
+sudo docker restart edge-traefik
+
+Puis re-tests section 2.
+
+## 7) Remarques
+
+Les 302 Authelia sont normaux si non authentifié.
+
+Un 404 “Not Found” depuis edge alors que 8081 répond : souvent routeur manquant / invalidé / middleware absent.

docs/runbooks/ENV-PUBLIC_SITE.md

@@ -0,0 +1,114 @@
+# RUNBOOK — PUBLIC_SITE (canonical + sitemap) “anti localhost en prod”
+> Objectif : ne plus jamais voir `rel="canonical" href="http://localhost:4321/"` en staging/live.
+
+## 0) Pourquoi c’est critique
+Astro génère :
+- `<link rel="canonical" href="...">`
+- `sitemap-index.xml`
+
+Ces valeurs dépendent de `site` dans `astro.config.mjs`.
+
+Si `site` vaut `http://localhost:4321` au moment du build Docker, **la prod sortira des canonical faux** :
+- SEO / partage / cohérence de navigation impactés
+- confusion staging/live
+
+## 1) Règle canonique
+- `astro.config.mjs` :
+# en js :
+
+site: process.env.PUBLIC_SITE ?? "http://localhost:4321"
+
+# Donc :
+
+En DEV local : pas besoin de PUBLIC_SITE (fallback ok)
+
+En build “déploiement” : on DOIT fournir PUBLIC_SITE
+
+## 2) Exigence “antifragile”
+### 2.1 Dockerfile (build stage)
+
+On injecte PUBLIC_SITE au build et on peut le rendre obligatoire :
+
+ARG PUBLIC_SITE
+
+ARG REQUIRE_PUBLIC_SITE=0
+
+ENV PUBLIC_SITE=$PUBLIC_SITE
+
+# garde-fou :
+
+RUN if [ "$REQUIRE_PUBLIC_SITE" = "1" ] && [ -z "$PUBLIC_SITE" ]; then \
+      echo "ERROR: PUBLIC_SITE is required (REQUIRE_PUBLIC_SITE=1)"; exit 1; \
+    fi
+
+=> Si quelqu’un oublie l’URL en prod, le build casse au lieu de produire une release mauvaise.
+
+## 3) docker-compose : blue/staging vs green/live
+
+Objectif : injecter deux valeurs différentes, sans bricolage.
+
+### 3.1 .env (NAS)
+
+Exemple canonique :
+
+PUBLIC_SITE_BLUE=https://staging.archicratie.trans-hands.synology.me
+PUBLIC_SITE_GREEN=https://archicratie.trans-hands.synology.me
+
+### 3.2 docker-compose.yml
+
+web_blue :
+
+REQUIRE_PUBLIC_SITE: "1"
+
+PUBLIC_SITE: ${PUBLIC_SITE_BLUE}
+
+web_green :
+
+REQUIRE_PUBLIC_SITE: "1"
+
+PUBLIC_SITE: ${PUBLIC_SITE_GREEN}
+
+## 4) Tests (obligatoires après build)
+### 4.1 Vérifier l’injection dans compose
+
+sudo env DOCKER_API_VERSION=1.43 docker compose config \
+ | grep -nE 'PUBLIC_SITE|REQUIRE_PUBLIC_SITE|web_blue:|web_green:' | sed -n '1,200p'
+
+### 4.2 Vérifier canonical (upstream direct)
+
+curl -sS http://127.0.0.1:8081/ | grep -oE 'rel="canonical" href="[^"]+"' | head -n 1
+curl -sS http://127.0.0.1:8082/ | grep -oE 'rel="canonical" href="[^"]+"' | head -n 1
+
+# Attendu :
+
+blue : https://staging.../
+
+green : https://archicratie.../
+
+## 5) Procédure de correction (si canonical est faux)
+### 5.1 Vérifier astro.config.mjs dans la release courante
+
+cd /volume2/docker/archicratie-web/current
+grep -nE 'site:\s*process\.env\.PUBLIC_SITE' astro.config.mjs
+
+### 5.2 Vérifier que Dockerfile exporte PUBLIC_SITE
+
+grep -nE 'ARG PUBLIC_SITE|ENV PUBLIC_SITE|REQUIRE_PUBLIC_SITE' Dockerfile
+
+### 5.3 Vérifier .env et compose
+
+grep -nE 'PUBLIC_SITE_BLUE|PUBLIC_SITE_GREEN' .env
+grep -nE 'PUBLIC_SITE|REQUIRE_PUBLIC_SITE' docker-compose.yml
+
+### 5.4 Rebuild + recreate
+
+sudo env DOCKER_API_VERSION=1.43 docker compose build --no-cache web_blue web_green
+sudo env DOCKER_API_VERSION=1.43 docker compose up -d --force-recreate web_blue web_green
+
+Puis tests section 4.
+
+## 6) Notes
+
+Cette mécanique doit être backportée dans Gitea (source canonique), sinon ça re-cassera au prochain pack.
+
+En DEV local, conserver le fallback http://localhost:4321 est utile et normal.

package.json

@@ -4,35 +4,33 @@
   "version": "0.0.1",
   "private": true,
   "scripts": {
-    "dev": "astro dev",
+    "dev": "node scripts/write-dev-whoami.mjs && astro dev",
     "preview": "astro preview",
     "astro": "astro",
-
     "clean": "rm -rf dist",
     "build": "astro build",
     "build:clean": "npm run clean && npm run build",
-
-    "postbuild": "node scripts/inject-anchor-aliases.mjs && node scripts/dedupe-ids-dist.mjs && npx pagefind --site dist",
-
+    "build:search": "pagefind --site dist",
+    "postbuild": "node scripts/inject-anchor-aliases.mjs && node scripts/dedupe-ids-dist.mjs && node scripts/build-para-index.mjs && node scripts/build-annotations-index.mjs && node scripts/purge-dist-dev-whoami.mjs && npm run build:search",
     "import": "node scripts/import-docx.mjs",
     "apply:ticket": "node scripts/apply-ticket.mjs",
-
     "audit:dist": "node scripts/audit-dist.mjs",
-
+    "build:para-index": "node scripts/build-para-index.mjs",
+    "build:annotations-index": "node scripts/build-annotations-index.mjs",
     "test:aliases": "node scripts/check-anchor-aliases.mjs",
     "test:anchors": "node scripts/check-anchors.mjs",
     "test:anchors:update": "node scripts/check-anchors.mjs --update",
-
-    "test": "npm run test:aliases && npm run build:clean && npm run audit:dist && node scripts/verify-anchor-aliases-in-dist.mjs && npm run test:anchors && node scripts/check-inline-js.mjs",
-
+    "test:annotations": "node scripts/check-annotations.mjs",
+    "test:annotations:media": "node scripts/check-annotations-media.mjs",
+    "test": "npm run test:aliases && npm run build:clean && npm run audit:dist && node scripts/verify-anchor-aliases-in-dist.mjs && npm run test:anchors && npm run test:annotations && npm run test:annotations:media && node scripts/check-inline-js.mjs",
     "ci": "CI=1 npm test"
   },
   "dependencies": {
-    "@astrojs/mdx": "^4.3.13",
-    "astro": "^5.16.11"
+    "@astrojs/mdx": "^5.0.0",
+    "astro": "^6.0.2"
   },
   "devDependencies": {
-    "@astrojs/sitemap": "^3.7.0",
+    "@astrojs/sitemap": "^3.7.1",
     "mammoth": "^1.11.0",
     "pagefind": "^1.4.0",
     "rehype-autolink-headings": "^7.1.0",

public/site.webmanifest

@@ -1 +1 @@
-{"name":"","short_name":"","icons":[{"src":"/android-chrome-192x192.png","sizes":"192x192","type":"image/png"},{"src":"/android-chrome-512x512.png","sizes":"512x512","type":"image/png"}],"theme_color":"#ffffff","background_color":"#ffffff","display":"standalone"}
+{"name":"","short_name":"","icons":[{"src":"/android-chrome-192x192.png","sizes":"192x192","type":"image/png"},{"src":"/android-chrome-512x512.png","sizes":"512x512","type":"image/png"}],"theme_color":"#ffffff","background_color":"#ffffff","display":"standalone","orientation":"any"}

scripts/apply-annotation-ticket.mjs

@@ -0,0 +1,899 @@
+#!/usr/bin/env node
+// scripts/apply-annotation-ticket.mjs
+//
+// Applique un ticket Gitea "type/media | type/reference | type/comment" vers:
+//
+//   ✅ src/annotations/<oeuvre>/<chapitre>/<paraId>.yml   (sharding par paragraphe)
+//   ✅ public/media/<oeuvre>/<chapitre>/<paraId>/<file>
+//
+// Compat rétro : lit (si présent) l'ancien monolithe:
+//   src/annotations/<oeuvre>/<chapitre>.yml
+// et deep-merge NON destructif dans le shard lors d'une nouvelle application,
+// pour permettre une migration progressive sans perte.
+//
+// Robuste, idempotent, non destructif.
+// DRY RUN si --dry-run
+// Options: --dry-run --no-download --verify --strict --commit --close
+//
+// Env requis:
+//   FORGE_API   = base API Gitea (LAN) ex: http://192.168.1.20:3000
+//   FORGE_TOKEN = PAT Gitea (repo + issues)
+//
+// Env optionnel:
+//   GITEA_OWNER / GITEA_REPO (sinon auto-détecté via git remote)
+//   ANNO_DIR    (défaut: src/annotations)
+//   PUBLIC_DIR  (défaut: public)
+//   MEDIA_ROOT  (défaut URL: /media)
+//
+// Ticket attendu (body):
+//   Chemin: /archicrat-ia/chapitre-4/
+//   Ancre: #p-0-xxxxxxxx
+//   Type: type/media | type/reference | type/comment
+//
+// Exit codes:
+//   0 ok
+//   1 erreur fatale
+//   2 refus (strict/verify/usage)
+
+import fs from "node:fs/promises";
+import path from "node:path";
+import process from "node:process";
+import { spawnSync } from "node:child_process";
+import YAML from "yaml";
+
+/* ---------------------------------- usage --------------------------------- */
+
+function usage(exitCode = 0) {
+  console.log(`
+apply-annotation-ticket — applique un ticket SidePanel (media/ref/comment) vers src/annotations/ (shard par paragraphe)
+
+Usage:
+  node scripts/apply-annotation-ticket.mjs <issue_number> [--dry-run] [--no-download] [--verify] [--strict] [--commit] [--close]
+
+Flags:
+  --dry-run      : n'écrit rien (affiche un aperçu)
+  --no-download  : n'essaie pas de télécharger les pièces jointes (media)
+  --verify       : vérifie que (page, ancre) existent (dist/para-index.json si dispo, sinon baseline)
+  --strict       : refuse si URL ref invalide (http/https) OU caption media vide OU verify impossible
+  --commit       : git add + git commit (commit dans la branche courante)
+  --close        : ferme le ticket (nécessite --commit)
+
+Env requis:
+  FORGE_API   = base API Gitea (LAN) ex: http://192.168.1.20:3000
+  FORGE_TOKEN = PAT Gitea (repo + issues)
+
+Env optionnel:
+  GITEA_OWNER / GITEA_REPO  (sinon auto-détecté via git remote)
+  ANNO_DIR    (défaut: src/annotations)
+  PUBLIC_DIR  (défaut: public)
+  MEDIA_ROOT  (défaut URL: /media)
+
+Exit codes:
+  0 ok
+  1 erreur fatale
+  2 refus (strict/verify/close sans commit / incohérence)
+`);
+  process.exit(exitCode);
+}
+
+/* ---------------------------------- args ---------------------------------- */
+
+const argv = process.argv.slice(2);
+if (argv.length === 0 || argv.includes("--help") || argv.includes("-h")) usage(0);
+
+const issueNum = Number(argv[0]);
+if (!Number.isFinite(issueNum) || issueNum <= 0) {
+  console.error("❌ Numéro de ticket invalide.");
+  usage(2);
+}
+
+const DRY_RUN = argv.includes("--dry-run");
+const NO_DOWNLOAD = argv.includes("--no-download");
+const DO_VERIFY = argv.includes("--verify");
+const STRICT = argv.includes("--strict");
+const DO_COMMIT = argv.includes("--commit");
+const DO_CLOSE = argv.includes("--close");
+
+if (DO_CLOSE && !DO_COMMIT) {
+  console.error("❌ --close nécessite --commit.");
+  process.exit(2);
+}
+
+if (typeof fetch !== "function") {
+  console.error("❌ fetch() indisponible. Utilise Node 18+.");
+  process.exit(1);
+}
+
+/* --------------------------------- config --------------------------------- */
+
+const CWD = process.cwd();
+const ANNO_DIR = path.join(CWD, process.env.ANNO_DIR || "src", "annotations");
+const PUBLIC_DIR = path.join(CWD, process.env.PUBLIC_DIR || "public");
+const MEDIA_URL_ROOT = String(process.env.MEDIA_ROOT || "/media").replace(/\/+$/, "");
+
+/* --------------------------------- helpers -------------------------------- */
+
+function getEnv(name, fallback = "") {
+  return (process.env[name] ?? fallback).trim();
+}
+
+function run(cmd, args, opts = {}) {
+  const r = spawnSync(cmd, args, { stdio: "inherit", ...opts });
+  if (r.error) throw r.error;
+  if (r.status !== 0) throw new Error(`Command failed: ${cmd} ${args.join(" ")}`);
+}
+
+function runQuiet(cmd, args, opts = {}) {
+  const r = spawnSync(cmd, args, { encoding: "utf8", stdio: "pipe", ...opts });
+  if (r.error) throw r.error;
+  if (r.status !== 0) {
+    const out = (r.stdout || "") + (r.stderr || "");
+    throw new Error(`Command failed: ${cmd} ${args.join(" ")}\n${out}`);
+  }
+  return r.stdout || "";
+}
+
+async function exists(p) {
+  try {
+    await fs.access(p);
+    return true;
+  } catch {
+    return false;
+  }
+}
+
+function inferOwnerRepoFromGit() {
+  const r = spawnSync("git", ["remote", "get-url", "origin"], { encoding: "utf-8" });
+  if (r.status !== 0) return null;
+  const u = (r.stdout || "").trim();
+  const m = u.match(/[:/](?<owner>[^/]+)\/(?<repo>[^/]+?)(?:\.git)?$/);
+  if (!m?.groups) return null;
+  return { owner: m.groups.owner, repo: m.groups.repo };
+}
+
+function gitHasStagedChanges() {
+  const r = spawnSync("git", ["diff", "--cached", "--quiet"]);
+  return r.status === 1;
+}
+
+function escapeRegExp(s) {
+  return String(s).replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
+}
+
+function pickLine(body, key) {
+  const re = new RegExp(`^\\s*${escapeRegExp(key)}\\s*:\\s*([^\\n\\r]+)`, "mi");
+  const m = String(body || "").match(re);
+  return m ? m[1].trim() : "";
+}
+
+function pickSection(body, markers) {
+  const text = String(body || "").replace(/\r\n/g, "\n");
+  const idx = markers
+    .map((m) => ({ m, i: text.toLowerCase().indexOf(m.toLowerCase()) }))
+    .filter((x) => x.i >= 0)
+    .sort((a, b) => a.i - b.i)[0];
+  if (!idx) return "";
+
+  const start = idx.i + idx.m.length;
+  const tail = text.slice(start);
+
+  const stops = ["\n## ", "\n---", "\nJustification", "\nProposition", "\nSources"];
+  let end = tail.length;
+  for (const s of stops) {
+    const j = tail.toLowerCase().indexOf(s.toLowerCase());
+    if (j >= 0 && j < end) end = j;
+  }
+  return tail.slice(0, end).trim();
+}
+
+function normalizeChemin(chemin) {
+  let c = String(chemin || "").trim();
+  if (!c) return "";
+  if (!c.startsWith("/")) c = "/" + c;
+  if (!c.endsWith("/")) c = c + "/";
+  c = c.replace(/\/{2,}/g, "/");
+  return c;
+}
+
+function normalizePageKeyFromChemin(chemin) {
+  // ex: /archicrat-ia/chapitre-4/ => archicrat-ia/chapitre-4
+  return normalizeChemin(chemin).replace(/^\/+|\/+$/g, "");
+}
+
+function normalizeAnchorId(s) {
+  let a = String(s || "").trim();
+  if (a.startsWith("#")) a = a.slice(1);
+  return a;
+}
+
+function assert(cond, msg, code = 1) {
+  if (!cond) {
+    const e = new Error(msg);
+    e.__exitCode = code;
+    throw e;
+  }
+}
+
+function isPlainObject(x) {
+  return !!x && typeof x === "object" && !Array.isArray(x);
+}
+
+function paraIndexFromId(id) {
+  const m = String(id).match(/^p-(\d+)-/i);
+  return m ? Number(m[1]) : Number.NaN;
+}
+
+function isHttpUrl(u) {
+  try {
+    const x = new URL(String(u));
+    return x.protocol === "http:" || x.protocol === "https:";
+  } catch {
+    return false;
+  }
+}
+
+function stableSortByTs(arr) {
+  if (!Array.isArray(arr)) return;
+  arr.sort((a, b) => {
+    const ta = Date.parse(a?.ts || "") || 0;
+    const tb = Date.parse(b?.ts || "") || 0;
+    if (ta !== tb) return ta - tb;
+    return JSON.stringify(a).localeCompare(JSON.stringify(b));
+  });
+}
+
+function normPage(s) {
+    let x = String(s || "").trim();
+    if (!x) return "";
+    // retire origin si on a une URL complète
+    x = x.replace(/^https?:\/\/[^/]+/i, "");
+    // enlève query/hash
+    x = x.split("#")[0].split("?")[0];
+    // enlève index.html
+    x = x.replace(/index\.html$/i, "");
+    // enlève slashs de bord
+    x = x.replace(/^\/+/, "").replace(/\/+$/, "");
+    return x;
+  }
+
+/* ------------------------------ para-index (verify + order) ------------------------------ */
+
+async function loadParaOrderFromDist(pageKey) {
+    const distIdx = path.join(CWD, "dist", "para-index.json");
+    if (!(await exists(distIdx))) return null;
+  
+    let j;
+    try {
+      j = JSON.parse(await fs.readFile(distIdx, "utf8"));
+    } catch {
+      return null;
+    }
+  
+    const want = normPage(pageKey);
+  
+    // Support A) { items:[{id,page,...}, ...] } (ou variantes)
+    const items = Array.isArray(j?.items)
+      ? j.items
+      : Array.isArray(j?.index?.items)
+        ? j.index.items
+        : null;
+  
+    if (items) {
+      const ids = [];
+      for (const it of items) {
+        // page peut être dans plein de clés différentes
+        const pageCand = normPage(
+          it?.page ??
+          it?.pageKey ??
+          it?.path ??
+          it?.route ??
+          it?.href ??
+          it?.url ??
+          ""
+        );
+  
+        // id peut être dans plein de clés différentes
+        let id = String(it?.id ?? it?.paraId ?? it?.anchorId ?? it?.anchor ?? "");
+        if (id.startsWith("#")) id = id.slice(1);
+  
+        if (pageCand === want && id) ids.push(id);
+      }
+      if (ids.length) return ids;
+    }
+  
+    // Support B) { byId: { "p-...": { page:"...", ... }, ... } }
+    if (j?.byId && typeof j.byId === "object") {
+      const ids = Object.keys(j.byId)
+        .filter((id) => {
+          const meta = j.byId[id] || {};
+          const pageCand = normPage(meta.page ?? meta.pageKey ?? meta.path ?? meta.route ?? meta.url ?? "");
+          return pageCand === want;
+        });
+  
+      if (ids.length) {
+        ids.sort((a, b) => {
+          const ia = paraIndexFromId(a);
+          const ib = paraIndexFromId(b);
+          if (Number.isFinite(ia) && Number.isFinite(ib) && ia !== ib) return ia - ib;
+          return String(a).localeCompare(String(b));
+        });
+        return ids;
+      }
+    }
+  
+    // Support C) { pages: { "archicrat-ia/chapitre-4": { ids:[...] } } } (ou variantes)
+    if (j?.pages && typeof j.pages === "object") {
+      // essaie de trouver la bonne clé même si elle est /.../ ou .../index.html
+      const keys = Object.keys(j.pages);
+      const hit = keys.find((k) => normPage(k) === want);
+      if (hit) {
+        const pg = j.pages[hit];
+        if (Array.isArray(pg?.ids)) return pg.ids.map(String);
+        if (Array.isArray(pg?.paras)) return pg.paras.map(String);
+      }
+    }
+  
+    return null;
+  }
+
+  async function tryVerifyAnchor(pageKey, anchorId) {
+    // 1) dist/para-index.json : order complet si possible
+    const order = await loadParaOrderFromDist(pageKey);
+    if (order) return order.includes(anchorId);
+  
+    // 1bis) dist/para-index.json : fallback “best effort” => recherche brute (IDs quasi uniques)
+    const distIdx = path.join(CWD, "dist", "para-index.json");
+    if (await exists(distIdx)) {
+      try {
+        const raw = await fs.readFile(distIdx, "utf8");
+        if (raw.includes(`"${anchorId}"`) || raw.includes(`"#${anchorId}"`)) {
+          return true;
+        }
+      } catch {
+        // ignore
+      }
+    }
+  
+    // 2) tests/anchors-baseline.json (fallback)
+    const base = path.join(CWD, "tests", "anchors-baseline.json");
+    if (await exists(base)) {
+      try {
+        const j = JSON.parse(await fs.readFile(base, "utf8"));
+        const candidates = [];
+        if (j?.pages && typeof j.pages === "object") {
+          for (const [k, v] of Object.entries(j.pages)) {
+            if (!Array.isArray(v)) continue;
+            if (normPage(k).includes(normPage(pageKey))) candidates.push(...v);
+          }
+        }
+        if (Array.isArray(j?.entries)) {
+          for (const it of j.entries) {
+            const p = String(it?.page || "");
+            const ids = it?.ids;
+            if (Array.isArray(ids) && normPage(p).includes(normPage(pageKey))) candidates.push(...ids);
+          }
+        }
+        if (candidates.length) return candidates.some((x) => String(x) === anchorId);
+      } catch {
+        // ignore
+      }
+    }
+  
+    return null; // cannot verify
+  }
+
+/* ----------------------------- deep merge helpers (non destructive) ----------------------------- */
+
+function keyMedia(x) {
+  return String(x?.src || "");
+}
+function keyRef(x) {
+  return `${x?.url || ""}||${x?.label || ""}||${x?.kind || ""}||${x?.citation || ""}`;
+}
+function keyComment(x) {
+  return String(x?.text || "").trim();
+}
+
+function uniqUnion(dstArr, srcArr, keyFn) {
+  const out = Array.isArray(dstArr) ? [...dstArr] : [];
+  const seen = new Set(out.map((x) => keyFn(x)));
+  for (const it of (Array.isArray(srcArr) ? srcArr : [])) {
+    const k = keyFn(it);
+    if (!k) continue;
+    if (!seen.has(k)) {
+      seen.add(k);
+      out.push(it);
+    }
+  }
+  return out;
+}
+
+function deepMergeEntry(dst, src) {
+  if (!isPlainObject(dst) || !isPlainObject(src)) return;
+
+  for (const [k, v] of Object.entries(src)) {
+    if (k === "media" && Array.isArray(v)) {
+      dst.media = uniqUnion(dst.media, v, keyMedia);
+      continue;
+    }
+    if (k === "refs" && Array.isArray(v)) {
+      dst.refs = uniqUnion(dst.refs, v, keyRef);
+      continue;
+    }
+    if (k === "comments_editorial" && Array.isArray(v)) {
+      dst.comments_editorial = uniqUnion(dst.comments_editorial, v, keyComment);
+      continue;
+    }
+
+    if (isPlainObject(v)) {
+      if (!isPlainObject(dst[k])) dst[k] = {};
+      deepMergeEntry(dst[k], v);
+      continue;
+    }
+
+    if (Array.isArray(v)) {
+      const cur = Array.isArray(dst[k]) ? dst[k] : [];
+      const seen = new Set(cur.map((x) => JSON.stringify(x)));
+      const out = [...cur];
+      for (const it of v) {
+        const s = JSON.stringify(it);
+        if (!seen.has(s)) {
+          seen.add(s);
+          out.push(it);
+        }
+      }
+      dst[k] = out;
+      continue;
+    }
+
+    // scalar: set only if missing/empty
+    if (!(k in dst) || dst[k] == null || dst[k] === "") {
+      dst[k] = v;
+    }
+  }
+}
+
+/* ----------------------------- annotations I/O ----------------------------- */
+
+async function loadAnnoDocYaml(fileAbs, pageKey) {
+  if (!(await exists(fileAbs))) {
+    return { schema: 1, page: pageKey, paras: {} };
+  }
+
+  const raw = await fs.readFile(fileAbs, "utf8");
+  let doc;
+  try {
+    doc = YAML.parse(raw);
+  } catch (e) {
+    throw new Error(`${path.relative(CWD, fileAbs)}: parse failed: ${String(e?.message ?? e)}`);
+  }
+
+  assert(isPlainObject(doc), `${path.relative(CWD, fileAbs)}: doc must be an object`, 2);
+  assert(doc.schema === 1, `${path.relative(CWD, fileAbs)}: schema must be 1`, 2);
+  assert(isPlainObject(doc.paras), `${path.relative(CWD, fileAbs)}: missing object key "paras"`, 2);
+
+  if (doc.page != null) {
+    const got = String(doc.page).replace(/^\/+/, "").replace(/\/+$/, "");
+    assert(got === pageKey, `${path.relative(CWD, fileAbs)}: page mismatch (page="${doc.page}" vs path="${pageKey}")`, 2);
+  } else {
+    doc.page = pageKey;
+  }
+
+  return doc;
+}
+
+function sortParasObject(paras, order) {
+  const keys = Object.keys(paras || {});
+  const idx = new Map();
+  if (Array.isArray(order)) order.forEach((id, i) => idx.set(String(id), i));
+
+  keys.sort((a, b) => {
+    const ha = idx.has(a);
+    const hb = idx.has(b);
+    if (ha && hb) return idx.get(a) - idx.get(b);
+    if (ha && !hb) return -1;
+    if (!ha && hb) return 1;
+
+    const ia = paraIndexFromId(a);
+    const ib = paraIndexFromId(b);
+    if (Number.isFinite(ia) && Number.isFinite(ib) && ia !== ib) return ia - ib;
+    return String(a).localeCompare(String(b));
+  });
+
+  const out = {};
+  for (const k of keys) out[k] = paras[k];
+  return out;
+}
+
+async function saveAnnoDocYaml(fileAbs, doc, order = null) {
+  await fs.mkdir(path.dirname(fileAbs), { recursive: true });
+
+  doc.paras = sortParasObject(doc.paras, order);
+
+  for (const e of Object.values(doc.paras || {})) {
+    if (!isPlainObject(e)) continue;
+    stableSortByTs(e.media);
+    stableSortByTs(e.refs);
+    stableSortByTs(e.comments_editorial);
+  }
+
+  const out = YAML.stringify(doc);
+  await fs.writeFile(fileAbs, out, "utf8");
+}
+
+/* ------------------------------ gitea helpers ------------------------------ */
+
+function apiBaseNorm(forgeApiBase) {
+  return forgeApiBase.replace(/\/+$/, "");
+}
+
+async function giteaGET(url, token) {
+  const res = await fetch(url, {
+    headers: {
+      Authorization: `token ${token}`,
+      Accept: "application/json",
+      "User-Agent": "archicratie-apply-annotation/1.0",
+    },
+  });
+  if (!res.ok) {
+    const t = await res.text().catch(() => "");
+    throw new Error(`HTTP ${res.status} GET ${url}\n${t}`);
+  }
+  return await res.json();
+}
+
+async function fetchIssue({ forgeApiBase, owner, repo, token, issueNum }) {
+  const url = `${apiBaseNorm(forgeApiBase)}/api/v1/repos/${owner}/${repo}/issues/${issueNum}`;
+  return await giteaGET(url, token);
+}
+
+async function fetchIssueAssets({ forgeApiBase, owner, repo, token, issueNum }) {
+  // Gitea: /issues/{index}/assets
+  const url = `${apiBaseNorm(forgeApiBase)}/api/v1/repos/${owner}/${repo}/issues/${issueNum}/assets`;
+  try {
+    const json = await giteaGET(url, token);
+    return Array.isArray(json) ? json : [];
+  } catch {
+    return [];
+  }
+}
+
+async function postIssueComment({ forgeApiBase, owner, repo, token, issueNum, comment }) {
+  const url = `${apiBaseNorm(forgeApiBase)}/api/v1/repos/${owner}/${repo}/issues/${issueNum}/comments`;
+  const res = await fetch(url, {
+    method: "POST",
+    headers: {
+      Authorization: `token ${token}`,
+      Accept: "application/json",
+      "Content-Type": "application/json",
+      "User-Agent": "archicratie-apply-annotation/1.0",
+    },
+    body: JSON.stringify({ body: comment }),
+  });
+  if (!res.ok) {
+    const t = await res.text().catch(() => "");
+    throw new Error(`HTTP ${res.status} POST comment ${url}\n${t}`);
+  }
+}
+
+async function closeIssue({ forgeApiBase, owner, repo, token, issueNum, comment }) {
+  if (comment) await postIssueComment({ forgeApiBase, owner, repo, token, issueNum, comment });
+
+  const url = `${apiBaseNorm(forgeApiBase)}/api/v1/repos/${owner}/${repo}/issues/${issueNum}`;
+  const res = await fetch(url, {
+    method: "PATCH",
+    headers: {
+      Authorization: `token ${token}`,
+      Accept: "application/json",
+      "Content-Type": "application/json",
+      "User-Agent": "archicratie-apply-annotation/1.0",
+    },
+    body: JSON.stringify({ state: "closed" }),
+  });
+  if (!res.ok) {
+    const t = await res.text().catch(() => "");
+    throw new Error(`HTTP ${res.status} closing issue: ${url}\n${t}`);
+  }
+}
+
+/* ------------------------------ media helpers ------------------------------ */
+
+function inferMediaTypeFromFilename(name) {
+  const n = String(name || "").toLowerCase();
+  if (/\.(png|jpe?g|webp|gif|svg)$/.test(n)) return "image";
+  if (/\.(mp4|webm|mov|m4v)$/.test(n)) return "video";
+  if (/\.(mp3|wav|ogg|m4a)$/.test(n)) return "audio";
+  return "link";
+}
+
+function sanitizeFilename(name) {
+  return String(name || "file")
+    .replace(/[\/\\]/g, "_")
+    .replace(/[^\w.\-]+/g, "_")
+    .replace(/_+/g, "_")
+    .slice(0, 180);
+}
+
+async function downloadToFile(url, token, destAbs) {
+  const res = await fetch(url, {
+    headers: {
+      Authorization: `token ${token}`,
+      "User-Agent": "archicratie-apply-annotation/1.0",
+    },
+    redirect: "follow",
+  });
+  if (!res.ok) {
+    const t = await res.text().catch(() => "");
+    throw new Error(`download failed HTTP ${res.status}: ${url}\n${t}`);
+  }
+  const buf = Buffer.from(await res.arrayBuffer());
+  await fs.mkdir(path.dirname(destAbs), { recursive: true });
+  await fs.writeFile(destAbs, buf);
+  return buf.length;
+}
+
+/* ------------------------------ type parsers ------------------------------ */
+
+function parseReferenceBlock(body) {
+  const block =
+    pickSection(body, ["Référence (à compléter):", "Reference (à compléter):"]) ||
+    pickSection(body, ["Référence:", "Reference:"]);
+
+  const lines = String(block || "").split(/\r?\n/).map((l) => l.trim());
+  const get = (k) => {
+    const re = new RegExp(`^[-*]\\s*${escapeRegExp(k)}\\s*:\\s*(.*)$`, "i");
+    const m = lines.map((l) => l.match(re)).find(Boolean);
+    return (m?.[1] ?? "").trim();
+  };
+
+  return {
+    url: get("URL") || "",
+    label: get("Label") || "",
+    kind: get("Kind") || "",
+    citation: get("Citation") || get("Passage") || get("Extrait") || "",
+    rawBlock: block || "",
+  };
+}
+
+/* ----------------------------------- main ---------------------------------- */
+
+async function main() {
+  const token = getEnv("FORGE_TOKEN");
+  assert(token, "❌ FORGE_TOKEN manquant.", 2);
+
+  const forgeApiBase = getEnv("FORGE_API") || getEnv("FORGE_BASE");
+  assert(forgeApiBase, "❌ FORGE_API (ou FORGE_BASE) manquant.", 2);
+
+  const inferred = inferOwnerRepoFromGit() || {};
+  const owner = getEnv("GITEA_OWNER", inferred.owner || "");
+  const repo = getEnv("GITEA_REPO", inferred.repo || "");
+  assert(owner && repo, "❌ Impossible de déterminer owner/repo. Fix: export GITEA_OWNER=... GITEA_REPO=...", 2);
+
+  console.log(`🔎 Fetch ticket #${issueNum} from ${owner}/${repo} …`);
+  const issue = await fetchIssue({ forgeApiBase, owner, repo, token, issueNum });
+
+  if (issue?.pull_request) {
+    console.error(`❌ #${issueNum} est une Pull Request, pas un ticket annotations.`);
+    process.exit(2);
+  }
+
+  const body = String(issue.body || "").replace(/\r\n/g, "\n");
+  const title = String(issue.title || "");
+
+  const type = pickLine(body, "Type").toLowerCase();
+  const chemin = normalizeChemin(pickLine(body, "Chemin"));
+  const ancre = normalizeAnchorId(pickLine(body, "Ancre"));
+
+  assert(chemin, "Ticket: Chemin manquant.", 2);
+  assert(ancre && /^p-\d+-/i.test(ancre), `Ticket: Ancre invalide ("${ancre}")`, 2);
+  assert(type, "Ticket: Type manquant.", 2);
+
+  const pageKey = normalizePageKeyFromChemin(chemin);
+  assert(pageKey, "Ticket: impossible de dériver pageKey.", 2);
+
+  const paraOrder = DO_VERIFY ? await loadParaOrderFromDist(pageKey) : null;
+
+  if (DO_VERIFY) {
+    const ok = await tryVerifyAnchor(pageKey, ancre);
+    if (ok === false) {
+      throw Object.assign(new Error(`Ticket verify: ancre introuvable pour page "${pageKey}" => ${ancre}`), { __exitCode: 2 });
+    }
+    if (ok === null) {
+      if (STRICT) {
+        throw Object.assign(
+          new Error(`Ticket verify (strict): impossible de vérifier (pas de dist/para-index.json ou baseline)`),
+          { __exitCode: 2 }
+        );
+      }
+      console.warn("⚠️  verify: impossible de vérifier (pas de dist/para-index.json ou baseline) — on continue.");
+    }
+  }
+
+  // ✅ shard path: src/annotations/<pageKey>/<paraId>.yml
+  const shardAbs = path.join(ANNO_DIR, ...pageKey.split("/"), `${ancre}.yml`);
+  const shardRel = path.relative(CWD, shardAbs).replace(/\\/g, "/");
+
+  // legacy monolith: src/annotations/<pageKey>.yml (read-only, for migration)
+  const legacyAbs = path.join(ANNO_DIR, `${pageKey}.yml`);
+
+  console.log("✅ Parsed:", { type, chemin, ancre: `#${ancre}`, pageKey, annoFile: shardRel });
+
+  // load shard doc
+  const doc = await loadAnnoDocYaml(shardAbs, pageKey);
+  if (!isPlainObject(doc.paras[ancre])) doc.paras[ancre] = {};
+  const entry = doc.paras[ancre];
+
+  // merge legacy entry into shard in-memory (non destructive) to keep compat + enable progressive migration
+  if (await exists(legacyAbs)) {
+    try {
+      const legacy = await loadAnnoDocYaml(legacyAbs, pageKey);
+      const legacyEntry = legacy?.paras?.[ancre];
+      if (isPlainObject(legacyEntry)) {
+        deepMergeEntry(entry, legacyEntry);
+      }
+    } catch {
+      // ignore legacy parse issues; shard still applies new data
+    }
+  }
+
+  const touchedFiles = [];
+  const notes = [];
+  let changed = false;
+  const nowIso = new Date().toISOString();
+
+  if (type === "type/comment") {
+    const comment = pickSection(body, ["Commentaire:", "Comment:", "Commentaires:"]) || "";
+    const text = comment.trim();
+    assert(text.length >= 3, "Ticket comment: bloc 'Commentaire:' introuvable ou trop court.", 2);
+
+    if (!Array.isArray(entry.comments_editorial)) entry.comments_editorial = [];
+    const item = { text, status: "new", ts: nowIso, fromIssue: issueNum };
+
+    const before = entry.comments_editorial.length;
+    entry.comments_editorial = uniqUnion(entry.comments_editorial, [item], keyComment);
+    if (entry.comments_editorial.length !== before) {
+      changed = true;
+      notes.push(`+ comment added (len=${text.length})`);
+    } else {
+      notes.push(`~ comment already present (dedup)`);
+    }
+    stableSortByTs(entry.comments_editorial);
+  }
+
+  else if (type === "type/reference") {
+    const ref = parseReferenceBlock(body);
+    assert(ref.url || ref.label, "Ticket reference: renseigne au moins - URL: ou - Label: dans le ticket.", 2);
+
+    if (STRICT && ref.url && !isHttpUrl(ref.url)) {
+      throw Object.assign(new Error(`Ticket reference (strict): URL invalide (http/https requis): "${ref.url}"`), { __exitCode: 2 });
+    }
+
+    if (!Array.isArray(entry.refs)) entry.refs = [];
+    const item = {
+      url: ref.url || "",
+      label: ref.label || (ref.url ? ref.url : "Référence"),
+      kind: ref.kind || "",
+      ts: nowIso,
+      fromIssue: issueNum,
+    };
+    if (ref.citation) item.citation = ref.citation;
+
+    const before = entry.refs.length;
+    entry.refs = uniqUnion(entry.refs, [item], keyRef);
+    if (entry.refs.length !== before) {
+      changed = true;
+      notes.push(`+ reference added (${item.url ? "url" : "label"})`);
+    } else {
+      notes.push(`~ reference already present (dedup)`);
+    }
+    stableSortByTs(entry.refs);
+  }
+
+  else if (type === "type/media") {
+    if (!Array.isArray(entry.media)) entry.media = [];
+
+    const caption = (title || "").trim();
+    if (STRICT && !caption) {
+      throw Object.assign(new Error("Ticket media (strict): caption vide (titre de ticket requis)."), { __exitCode: 2 });
+    }
+    const captionFinal = caption || ".";
+
+    const atts = NO_DOWNLOAD ? [] : await fetchIssueAssets({ forgeApiBase, owner, repo, token, issueNum });
+    if (!atts.length) notes.push("! no assets found (nothing to download).");
+
+    for (const a of atts) {
+      const name = sanitizeFilename(a?.name || `asset-${a?.id || "x"}`);
+      const dl = a?.browser_download_url || a?.download_url || "";
+      if (!dl) { notes.push(`! asset missing download url: ${name}`); continue; }
+
+      const mediaDirAbs = path.join(PUBLIC_DIR, "media", ...pageKey.split("/"), ancre);
+      const destAbs = path.join(mediaDirAbs, name);
+      const urlPath = `${MEDIA_URL_ROOT}/${pageKey}/${ancre}/${name}`.replace(/\/{2,}/g, "/");
+
+      if (await exists(destAbs)) {
+        notes.push(`~ media already exists: ${urlPath}`);
+      } else if (!DRY_RUN) {
+        const bytes = await downloadToFile(dl, token, destAbs);
+        notes.push(`+ downloaded ${name} (${bytes} bytes) -> ${urlPath}`);
+        touchedFiles.push(path.relative(CWD, destAbs).replace(/\\/g, "/"));
+        changed = true;
+      } else {
+        notes.push(`(dry) would download ${name} -> ${urlPath}`);
+        changed = true;
+      }
+
+      const item = {
+        type: inferMediaTypeFromFilename(name),
+        src: urlPath,
+        caption: captionFinal,
+        credit: "",
+        ts: nowIso,
+        fromIssue: issueNum,
+      };
+
+      const before = entry.media.length;
+      entry.media = uniqUnion(entry.media, [item], keyMedia);
+      if (entry.media.length !== before) changed = true;
+    }
+
+    stableSortByTs(entry.media);
+  }
+
+  else {
+    throw Object.assign(new Error(`Type non supporté: "${type}"`), { __exitCode: 2 });
+  }
+
+  if (!changed) {
+    console.log("ℹ️  No changes to apply.");
+    for (const n of notes) console.log("  ", n);
+    return;
+  }
+
+  if (DRY_RUN) {
+    console.log("\n--- DRY RUN (no write) ---");
+    console.log(`Would update: ${shardRel}`);
+    for (const n of notes) console.log("  ", n);
+    console.log("\nExcerpt (resulting entry):");
+    console.log(YAML.stringify({ [ancre]: doc.paras[ancre] }).trimEnd());
+    console.log("\n✅ Dry-run terminé.");
+    return;
+  }
+
+  await saveAnnoDocYaml(shardAbs, doc, paraOrder);
+  touchedFiles.unshift(shardRel);
+
+  console.log(`✅ Updated: ${shardRel}`);
+  for (const n of notes) console.log("  ", n);
+
+  if (DO_COMMIT) {
+    run("git", ["add", ...touchedFiles], { cwd: CWD });
+
+    if (!gitHasStagedChanges()) {
+      console.log("ℹ️ Nothing to commit (aucun changement staged).");
+      return;
+    }
+
+    const msg = `anno: apply ticket #${issueNum} (${pageKey}#${ancre} ${type})`;
+    run("git", ["commit", "-m", msg], { cwd: CWD });
+
+    const sha = runQuiet("git", ["rev-parse", "--short", "HEAD"], { cwd: CWD }).trim();
+    console.log(`✅ Committed: ${msg} (${sha})`);
+
+    if (DO_CLOSE) {
+      const comment = `✅ Appliqué par apply-annotation-ticket.\nCommit: ${sha}`;
+      await closeIssue({ forgeApiBase, owner, repo, token, issueNum, comment });
+      console.log(`✅ Ticket #${issueNum} fermé.`);
+    }
+  } else {
+    console.log("\nNext (manuel) :");
+    console.log(`  git diff -- ${touchedFiles[0]}`);
+    console.log(`  git add ${touchedFiles.join(" ")}`);
+    console.log(`  git commit -m "anno: apply ticket #${issueNum} (${pageKey}#${ancre} ${type})"`);
+  }
+}
+
+main().catch((e) => {
+  const code = e?.__exitCode || 1;
+  console.error("💥", e?.message || e);
+  process.exit(code);
+});

scripts/apply-ticket.mjs

@@ -9,8 +9,9 @@ import { spawnSync } from "node:child_process";
  *
  * Conçu pour:
  * - prendre un ticket [Correction]/[Fact-check] (issue) avec Chemin + Ancre + Proposition
- * - retrouver le bon paragraphe dans le .mdx
+ * - retrouver le bon paragraphe dans le .mdx/.md
  * - remplacer proprement
+ * - ne JAMAIS toucher au frontmatter
  * - optionnel: écrire un alias d’ancre old->new (build-time) dans src/anchors/anchor-aliases.json
  * - optionnel: committer automatiquement
  * - optionnel: fermer le ticket (après commit)
@@ -39,7 +40,7 @@ Env (recommandé):
 
 Notes:
   - Si dist/<chemin>/index.html est absent, le script lance "npm run build" sauf si --no-build.
-  - Sauvegarde automatique: <fichier>.bak.issue-<N> (uniquement si on écrit)
+  - Sauvegarde automatique: .tmp/apply-ticket/<fichier>.bak.issue-<N> (uniquement si on écrit)
   - Avec --alias : le script rebuild pour identifier le NOUVEL id, puis écrit l'alias old->new.
   - Refuse automatiquement les Pull Requests (PR) : ce ne sont pas des tickets éditoriaux.
 `);
@@ -89,6 +90,7 @@ const CWD = process.cwd();
 const CONTENT_ROOT = path.join(CWD, "src", "content");
 const DIST_ROOT = path.join(CWD, "dist");
 const ALIASES_FILE = path.join(CWD, "src", "anchors", "anchor-aliases.json");
+const BACKUP_ROOT = path.join(CWD, ".tmp", "apply-ticket");
 
 /* -------------------------- utils texte / matching -------------------------- */
 
@@ -136,31 +138,26 @@ function scoreText(candidate, targetText) {
   let hit = 0;
   for (const w of tgtSet) if (blkSet.has(w)) hit++;
 
-  // Bonus si un long préfixe ressemble
   const tgtNorm = normalizeText(stripMd(targetText));
   const blkNorm = normalizeText(stripMd(candidate));
   const prefix = tgtNorm.slice(0, Math.min(180, tgtNorm.length));
   const prefixBonus = prefix && blkNorm.includes(prefix) ? 1000 : 0;
 
-  // Ratio bonus (0..100)
   const ratio = hit / Math.max(1, tgtSet.size);
   const ratioBonus = Math.round(ratio * 100);
 
   return prefixBonus + hit + ratioBonus;
 }
 
-function bestBlockMatchIndex(blocks, targetText) {
-  let best = { i: -1, score: -1 };
-  for (let i = 0; i < blocks.length; i++) {
-    const sc = scoreText(blocks[i], targetText);
-    if (sc > best.score) best = { i, score: sc };
-  }
-  return best;
-}
-
-function splitParagraphBlocks(mdxText) {
-  const raw = String(mdxText ?? "").replace(/\r\n/g, "\n");
-  return raw.split(/\n{2,}/);
+function rankedBlockMatches(blocks, targetText, limit = 5) {
+  return blocks
+    .map((b, i) => ({
+      i,
+      score: scoreText(b, targetText),
+      excerpt: stripMd(b).slice(0, 140),
+    }))
+    .sort((a, b) => b.score - a.score)
+    .slice(0, limit);
 }
 
 function isLikelyExcerpt(s) {
@@ -172,6 +169,89 @@ function isLikelyExcerpt(s) {
   return false;
 }
 
+/* --------------------------- frontmatter / structure ------------------------ */
+
+function normalizeNewlines(s) {
+  return String(s ?? "").replace(/^\uFEFF/, "").replace(/\r\n/g, "\n");
+}
+
+function splitMdxFrontmatter(src) {
+  const text = normalizeNewlines(src);
+  const m = text.match(/^---\n[\s\S]*?\n---\n?/);
+
+  if (!m) {
+    return {
+      hasFrontmatter: false,
+      frontmatter: "",
+      body: text,
+    };
+  }
+
+  const frontmatter = m[0];
+  const body = text.slice(frontmatter.length);
+
+  return {
+    hasFrontmatter: true,
+    frontmatter,
+    body,
+  };
+}
+
+function joinMdxFrontmatter(frontmatter, body) {
+  if (!frontmatter) return String(body ?? "");
+  return String(frontmatter) + String(body ?? "");
+}
+
+function assertFrontmatterIntegrity({ hadFrontmatter, originalFrontmatter, finalText, filePath }) {
+  if (!hadFrontmatter) return;
+
+  const text = normalizeNewlines(finalText);
+
+  if (!text.startsWith("---\n")) {
+    throw new Error(`Frontmatter perdu pendant la mise à jour de ${filePath}`);
+  }
+
+  if (!text.startsWith(originalFrontmatter)) {
+    throw new Error(`Frontmatter altéré pendant la mise à jour de ${filePath}`);
+  }
+}
+
+function splitParagraphBlocksPreserve(bodyText) {
+  const text = normalizeNewlines(bodyText);
+
+  if (!text) {
+    return { blocks: [], separators: [] };
+  }
+
+  const blocks = [];
+  const separators = [];
+
+  const re = /(\n{2,})/g;
+  let last = 0;
+  let m;
+
+  while ((m = re.exec(text))) {
+    blocks.push(text.slice(last, m.index));
+    separators.push(m[1]);
+    last = m.index + m[1].length;
+  }
+
+  blocks.push(text.slice(last));
+
+  return { blocks, separators };
+}
+
+function joinParagraphBlocksPreserve(blocks, separators) {
+  if (!Array.isArray(blocks) || blocks.length === 0) return "";
+
+  let out = "";
+  for (let i = 0; i < blocks.length; i++) {
+    out += blocks[i];
+    if (i < separators.length) out += separators[i];
+  }
+  return out;
+}
+
 /* ------------------------------ utils système ------------------------------ */
 
 function run(cmd, args, opts = {}) {
@@ -251,7 +331,9 @@ function pickSection(body, markers) {
     .map((m) => ({ m, i: text.toLowerCase().indexOf(m.toLowerCase()) }))
     .filter((x) => x.i >= 0)
     .sort((a, b) => a.i - b.i)[0];
+
   if (!idx) return "";
+
   const start = idx.i + idx.m.length;
   const tail = text.slice(start);
 
@@ -266,11 +348,13 @@ function pickSection(body, markers) {
     "\n## Proposition",
     "\n## Problème",
   ];
+
   let end = tail.length;
   for (const s of stops) {
     const j = tail.toLowerCase().indexOf(s.toLowerCase());
     if (j >= 0 && j < end) end = j;
   }
+
   return tail.slice(0, end).trim();
 }
 
@@ -298,8 +382,6 @@ function extractAnchorIdAnywhere(text) {
 
 function extractCheminFromAnyUrl(text) {
   const s = String(text || "");
-  // Exemple: http://localhost:4321/archicratie/prologue/#p-3-xxxx
-  // ou: /archicratie/prologue/#p-3-xxxx
   const m = s.match(/(\/[a-z0-9\-]+\/[a-z0-9\-\/]+\/)#p-\d+-[0-9a-f]{8}/i);
   return m ? m[1] : "";
 }
@@ -400,7 +482,7 @@ async function fetchIssue({ forgeApiBase, owner, repo, token, issueNum }) {
     headers: {
       Authorization: `token ${token}`,
       Accept: "application/json",
-      "User-Agent": "archicratie-apply-ticket/2.0",
+      "User-Agent": "archicratie-apply-ticket/2.1",
     },
   });
   if (!res.ok) {
@@ -416,7 +498,7 @@ async function closeIssue({ forgeApiBase, owner, repo, token, issueNum, comment
     Authorization: `token ${token}`,
     Accept: "application/json",
     "Content-Type": "application/json",
-    "User-Agent": "archicratie-apply-ticket/2.0",
+    "User-Agent": "archicratie-apply-ticket/2.1",
   };
 
   if (comment) {
@@ -425,7 +507,11 @@ async function closeIssue({ forgeApiBase, owner, repo, token, issueNum, comment
   }
 
   const url = `${base}/api/v1/repos/${owner}/${repo}/issues/${issueNum}`;
-  const res = await fetch(url, { method: "PATCH", headers, body: JSON.stringify({ state: "closed" }) });
+  const res = await fetch(url, {
+    method: "PATCH",
+    headers,
+    body: JSON.stringify({ state: "closed" }),
+  });
 
   if (!res.ok) {
     const t = await res.text().catch(() => "");
@@ -529,10 +615,9 @@ async function main() {
   console.log(`🔎 Fetch ticket #${issueNum} from ${owner}/${repo} …`);
   const issue = await fetchIssue({ forgeApiBase, owner, repo, token, issueNum });
 
-  // Guard PR (Pull Request = "Demande d'ajout" = pas un ticket éditorial)
   if (issue?.pull_request) {
     console.error(`❌ #${issueNum} est une Pull Request (demande d’ajout), pas un ticket éditorial.`);
-    console.error(`➡️ Ouvre un ticket [Correction]/[Fact-check] depuis le site (Proposer), puis relance apply-ticket sur ce numéro.`);
+    console.error("➡️ Ouvre un ticket [Correction]/[Fact-check] depuis le site (Proposer), puis relance apply-ticket sur ce numéro.");
     process.exit(2);
   }
 
@@ -553,7 +638,6 @@ async function main() {
   ancre = (ancre || "").trim();
   if (ancre.startsWith("#")) ancre = ancre.slice(1);
 
-  // fallback si ticket mal formé
   if (!ancre) ancre = extractAnchorIdAnywhere(title) || extractAnchorIdAnywhere(body);
 
   chemin = normalizeChemin(chemin);
@@ -592,7 +676,6 @@ async function main() {
   const distHtmlPath = path.join(DIST_ROOT, chemin.replace(/^\/+|\/+$/g, ""), "index.html");
   await ensureBuildIfNeeded(distHtmlPath);
 
-  // Texte cible: préférence au texte complet (ticket), sinon dist si extrait probable
   let targetText = texteActuel;
   let distText = "";
 
@@ -609,21 +692,24 @@ async function main() {
     throw new Error("Impossible de reconstruire le texte du paragraphe (ni texte actuel, ni dist html).");
   }
 
-  const original = await fs.readFile(contentFile, "utf-8");
-  const blocks = splitParagraphBlocks(original);
+  const originalRaw = await fs.readFile(contentFile, "utf-8");
+  const { hasFrontmatter, frontmatter, body: originalBody } = splitMdxFrontmatter(originalRaw);
 
-  const best = bestBlockMatchIndex(blocks, targetText);
+  const split = splitParagraphBlocksPreserve(originalBody);
+  const blocks = split.blocks;
+  const separators = split.separators;
+
+  if (!blocks.length) {
+    throw new Error(`Aucun bloc éditorial exploitable dans ${path.relative(CWD, contentFile)}`);
+  }
+
+  const ranked = rankedBlockMatches(blocks, targetText, 5);
+  const best = ranked[0] || { i: -1, score: -1, excerpt: "" };
+  const runnerUp = ranked[1] || null;
 
-  // seuil de sécurité
   if (best.i < 0 || best.score < 40) {
     console.error("❌ Match trop faible: je refuse de remplacer automatiquement.");
     console.error(`➡️  Score=${best.score}. Recommandation: ticket avec 'Texte actuel (copie exacte du paragraphe)'.`);
-
-    const ranked = blocks
-      .map((b, i) => ({ i, score: scoreText(b, targetText), excerpt: stripMd(b).slice(0, 140) }))
-      .sort((a, b) => b.score - a.score)
-      .slice(0, 5);
-
     console.error("Top candidates:");
     for (const r of ranked) {
       console.error(`  #${r.i + 1} score=${r.score}  ${r.excerpt}${r.excerpt.length >= 140 ? "…" : ""}`);
@@ -631,12 +717,34 @@ async function main() {
     process.exit(2);
   }
 
+  if (runnerUp) {
+    const ambiguityGap = best.score - runnerUp.score;
+    if (ambiguityGap < 15) {
+      console.error("❌ Match ambigu: le meilleur candidat est trop proche du second.");
+      console.error(`➡️  best=${best.score} / second=${runnerUp.score} / gap=${ambiguityGap}`);
+      console.error("Top candidates:");
+      for (const r of ranked) {
+        console.error(`  #${r.i + 1} score=${r.score}  ${r.excerpt}${r.excerpt.length >= 140 ? "…" : ""}`);
+      }
+      process.exit(2);
+    }
+  }
+
   const beforeBlock = blocks[best.i];
   const afterBlock = proposition.trim();
 
   const nextBlocks = blocks.slice();
   nextBlocks[best.i] = afterBlock;
-  const updated = nextBlocks.join("\n\n");
+
+  const updatedBody = joinParagraphBlocksPreserve(nextBlocks, separators);
+  const updatedRaw = joinMdxFrontmatter(frontmatter, updatedBody);
+
+  assertFrontmatterIntegrity({
+    hadFrontmatter: hasFrontmatter,
+    originalFrontmatter: frontmatter,
+    finalText: updatedRaw,
+    filePath: path.relative(CWD, contentFile),
+  });
 
   console.log(`🧩 Matched block #${best.i + 1}/${blocks.length} score=${best.score}`);
 
@@ -650,13 +758,15 @@ async function main() {
     return;
   }
 
-  // backup uniquement si on écrit
-  const bakPath = `${contentFile}.bak.issue-${issueNum}`;
+  const relContentFile = path.relative(CWD, contentFile);
+  const bakPath = path.join(BACKUP_ROOT, `${relContentFile}.bak.issue-${issueNum}`);
+  await fs.mkdir(path.dirname(bakPath), { recursive: true });
+
   if (!(await fileExists(bakPath))) {
-    await fs.writeFile(bakPath, original, "utf-8");
+    await fs.writeFile(bakPath, originalRaw, "utf-8");
   }
 
-  await fs.writeFile(contentFile, updated, "utf-8");
+  await fs.writeFile(contentFile, updatedRaw, "utf-8");
   console.log("✅ Applied.");
 
   let aliasChanged = false;
@@ -677,13 +787,13 @@ async function main() {
 
     if (aliasChanged) {
       console.log(`✅ Alias ajouté: ${chemin} ${ancre} -> ${newId}`);
-      // MàJ dist sans rebuild complet (inject seulement)
       run("node", ["scripts/inject-anchor-aliases.mjs"], { cwd: CWD });
     } else {
       console.log(`ℹ️ Alias déjà présent ou inutile (${ancre} -> ${newId}).`);
     }
 
-    // garde-fous rapides
+    run("node", ["scripts/check-anchor-aliases.mjs"], { cwd: CWD });
+    run("node", ["scripts/verify-anchor-aliases-in-dist.mjs"], { cwd: CWD });
     run("npm", ["run", "test:anchors"], { cwd: CWD });
     run("node", ["scripts/check-inline-js.mjs"], { cwd: CWD });
   }
@@ -713,7 +823,6 @@ async function main() {
     return;
   }
 
-  // mode manuel
   console.log("Next (manuel) :");
   console.log(`  git diff -- ${path.relative(CWD, contentFile)}`);
   console.log(
@@ -730,4 +839,4 @@ async function main() {
 main().catch((e) => {
   console.error("💥", e?.message || e);
   process.exit(1);
-});
+});

scripts/build-annotations-index.mjs

@@ -1,28 +1,106 @@
+#!/usr/bin/env node
 // scripts/build-annotations-index.mjs
+// Construit dist/annotations-index.json à partir de src/annotations/**/*.yml
+// Supporte:
+//   - monolith : src/annotations/<pageKey>.yml
+//   - shard    : src/annotations/<pageKey>/<paraId>.yml   (paraId = p-<n>-...)
+// Invariants:
+//   - doc.schema === 1
+//   - doc.page (si présent) == pageKey déduit du chemin
+//   - shard: doc.paras doit contenir EXACTEMENT la clé paraId (sinon fail)
+//
+// Deep-merge non destructif (media/refs/comments dédupliqués), tri stable.
+
 import fs from "node:fs/promises";
 import path from "node:path";
 import YAML from "yaml";
 
-function parseArgs(argv) {
-  const out = {
-    inDir: "src/annotations",
-    outFile: "dist/annotations-index.json",
-  };
+const ROOT = process.cwd();
+const ANNO_ROOT = path.join(ROOT, "src", "annotations");
+const DIST_DIR = path.join(ROOT, "dist");
+const OUT = path.join(DIST_DIR, "annotations-index.json");
 
-  for (let i = 0; i < argv.length; i++) {
-    const a = argv[i];
+function assert(cond, msg) {
+  if (!cond) throw new Error(msg);
+}
 
-    if (a === "--in" && argv[i + 1]) out.inDir = argv[++i];
-    else if (a.startsWith("--in=")) out.inDir = a.slice("--in=".length);
+function isObj(x) {
+  return !!x && typeof x === "object" && !Array.isArray(x);
+}
+function isArr(x) {
+  return Array.isArray(x);
+}
 
-    if (a === "--out" && argv[i + 1]) out.outFile = argv[++i];
-    else if (a.startsWith("--out=")) out.outFile = a.slice("--out=".length);
+function normPath(s) {
+  return String(s || "")
+    .replace(/\\/g, "/")
+    .replace(/^\/+|\/+$/g, "");
+}
+
+function paraNum(pid) {
+  const m = String(pid).match(/^p-(\d+)-/i);
+  return m ? Number(m[1]) : Number.POSITIVE_INFINITY;
+}
+
+function stableSortByTs(arr) {
+  if (!Array.isArray(arr)) return;
+  arr.sort((a, b) => {
+    const ta = Date.parse(a?.ts || "") || 0;
+    const tb = Date.parse(b?.ts || "") || 0;
+    if (ta !== tb) return ta - tb;
+    return JSON.stringify(a).localeCompare(JSON.stringify(b));
+  });
+}
+
+function keyMedia(x) { return String(x?.src || ""); }
+function keyRef(x) {
+  return `${x?.url || ""}||${x?.label || ""}||${x?.kind || ""}||${x?.citation || ""}`;
+}
+function keyComment(x) { return String(x?.text || "").trim(); }
+
+function uniqUnion(dst, src, keyFn) {
+  const out = isArr(dst) ? [...dst] : [];
+  const seen = new Set(out.map((x) => keyFn(x)));
+  for (const it of (isArr(src) ? src : [])) {
+    const k = keyFn(it);
+    if (!k) continue;
+    if (!seen.has(k)) {
+      seen.add(k);
+      out.push(it);
+    }
   }
   return out;
 }
 
-async function exists(p) {
-  try { await fs.access(p); return true; } catch { return false; }
+function deepMergeEntry(dst, src) {
+  if (!isObj(dst) || !isObj(src)) return;
+
+  for (const [k, v] of Object.entries(src)) {
+    if (k === "media" && isArr(v)) { dst.media = uniqUnion(dst.media, v, keyMedia); continue; }
+    if (k === "refs" && isArr(v)) { dst.refs = uniqUnion(dst.refs, v, keyRef); continue; }
+    if (k === "comments_editorial" && isArr(v)) { dst.comments_editorial = uniqUnion(dst.comments_editorial, v, keyComment); continue; }
+
+    if (isObj(v)) {
+      if (!isObj(dst[k])) dst[k] = {};
+      deepMergeEntry(dst[k], v);
+      continue;
+    }
+
+    if (isArr(v)) {
+      const cur = isArr(dst[k]) ? dst[k] : [];
+      const seen = new Set(cur.map((x) => JSON.stringify(x)));
+      const out = [...cur];
+      for (const it of v) {
+        const s = JSON.stringify(it);
+        if (!seen.has(s)) { seen.add(s); out.push(it); }
+      }
+      dst[k] = out;
+      continue;
+    }
+
+    // scalar: set only if missing/empty
+    if (!(k in dst) || dst[k] == null || dst[k] === "") dst[k] = v;
+  }
 }
 
 async function walk(dir) {
@@ -30,111 +108,116 @@ async function walk(dir) {
   const ents = await fs.readdir(dir, { withFileTypes: true });
   for (const e of ents) {
     const p = path.join(dir, e.name);
-    if (e.isDirectory()) out.push(...(await walk(p)));
-    else out.push(p);
+    if (e.isDirectory()) out.push(...await walk(p));
+    else if (e.isFile() && /\.ya?ml$/i.test(e.name)) out.push(p);
   }
   return out;
 }
 
-function inferPageKeyFromFile(inDirAbs, fileAbs) {
-  // src/annotations/<page>.yml -> "<page>"
-  const rel = path.relative(inDirAbs, fileAbs).replace(/\\/g, "/");
-  return rel.replace(/\.(ya?ml|json)$/i, "");
+function inferExpectedFromRel(relNoExt) {
+  const parts = relNoExt.split("/").filter(Boolean);
+  const last = parts.at(-1) || "";
+  const isShard = parts.length > 1 && /^p-\d+-/i.test(last); // ✅ durcissement
+  const pageKey = isShard ? parts.slice(0, -1).join("/") : relNoExt;
+  const paraId = isShard ? last : null;
+  return { isShard, pageKey, paraId };
 }
 
-function assert(cond, msg) {
-  if (!cond) throw new Error(msg);
-}
+function validateAndNormalizeDoc(doc, relFile, expectedPageKey, expectedParaId) {
+  assert(isObj(doc), `${relFile}: doc must be an object`);
+  assert(doc.schema === 1, `${relFile}: schema must be 1`);
+  assert(isObj(doc.paras), `${relFile}: missing object key "paras"`);
 
-function isPlainObject(x) {
-  return !!x && typeof x === "object" && !Array.isArray(x);
-}
+  const gotPage = doc.page != null ? normPath(doc.page) : "";
+  const expPage = normPath(expectedPageKey);
 
-function normalizePageKey(s) {
-  // pas de / en tête/fin
-  return String(s || "").replace(/^\/+/, "").replace(/\/+$/, "");
-}
-
-function validateAndNormalizeDoc(doc, pageKey, fileRel) {
-  assert(isPlainObject(doc), `${fileRel}: document must be an object`);
-  assert(doc.schema === 1, `${fileRel}: schema must be 1`);
-  if (doc.page != null) {
+  if (gotPage) {
     assert(
-      normalizePageKey(doc.page) === pageKey,
-      `${fileRel}: page mismatch (page="${doc.page}" vs path="${pageKey}")`
+      gotPage === expPage,
+      `${relFile}: page mismatch (page="${doc.page}" vs path="${expectedPageKey}")`
+    );
+  } else {
+    doc.page = expPage;
+  }
+
+  if (expectedParaId) {
+    const keys = Object.keys(doc.paras || {}).map(String);
+    assert(
+      keys.includes(expectedParaId),
+      `${relFile}: shard mismatch: must contain paras["${expectedParaId}"]`
+    );
+    assert(
+      keys.length === 1 && keys[0] === expectedParaId,
+      `${relFile}: shard invariant violated: shard file must contain ONLY paras["${expectedParaId}"] (got: ${keys.join(", ")})`
     );
   }
-  assert(isPlainObject(doc.paras), `${fileRel}: missing object key "paras"`);
 
-  const parasOut = Object.create(null);
-
-  for (const [paraId, entry] of Object.entries(doc.paras)) {
-    assert(/^p-\d+-/i.test(paraId), `${fileRel}: invalid para id "${paraId}"`);
-
-    // entry peut être vide, mais doit être un objet si présent
-    assert(entry == null || isPlainObject(entry), `${fileRel}: paras.${paraId} must be an object`);
-
-    const e = entry ? { ...entry } : {};
-
-    // Sanity checks (non destructifs : on n’écrase pas, on vérifie juste les types)
-    if (e.refs != null) assert(Array.isArray(e.refs), `${fileRel}: paras.${paraId}.refs must be an array`);
-    if (e.authors != null) assert(Array.isArray(e.authors), `${fileRel}: paras.${paraId}.authors must be an array`);
-    if (e.quotes != null) assert(Array.isArray(e.quotes), `${fileRel}: paras.${paraId}.quotes must be an array`);
-    if (e.media != null) assert(Array.isArray(e.media), `${fileRel}: paras.${paraId}.media must be an array`);
-    if (e.comments_editorial != null) assert(Array.isArray(e.comments_editorial), `${fileRel}: paras.${paraId}.comments_editorial must be an array`);
-
-    parasOut[paraId] = e;
-  }
-
-  return parasOut;
-}
-
-async function readDoc(fileAbs) {
-  const raw = await fs.readFile(fileAbs, "utf8");
-  if (/\.json$/i.test(fileAbs)) return JSON.parse(raw);
-  return YAML.parse(raw);
+  return doc;
 }
 
 async function main() {
-  const { inDir, outFile } = parseArgs(process.argv.slice(2));
-  const CWD = process.cwd();
+  const pages = {};
+  const errors = [];
 
-  const inDirAbs = path.isAbsolute(inDir) ? inDir : path.join(CWD, inDir);
-  const outAbs = path.isAbsolute(outFile) ? outFile : path.join(CWD, outFile);
+  await fs.mkdir(DIST_DIR, { recursive: true });
 
-  // antifragile
-  if (!(await exists(inDirAbs))) {
-    console.log(`ℹ️  annotations-index: skip (input missing): ${inDir}`);
-    process.exit(0);
-  }
+  const files = await walk(ANNO_ROOT);
 
-  const files = (await walk(inDirAbs)).filter((p) => /\.(ya?ml|json)$/i.test(p));
-  if (!files.length) {
-    console.log(`ℹ️  annotations-index: skip (no .yml/.yaml/.json found in): ${inDir}`);
-    process.exit(0);
-  }
+  for (const fp of files) {
+    const rel = normPath(path.relative(ANNO_ROOT, fp));
+    const relNoExt = rel.replace(/\.ya?ml$/i, "");
+    const { isShard, pageKey, paraId } = inferExpectedFromRel(relNoExt);
 
-  const pages = Object.create(null);
-  let paraCount = 0;
-
-  for (const f of files) {
-    const fileRel = path.relative(CWD, f).replace(/\\/g, "/");
-    const pageKey = normalizePageKey(inferPageKeyFromFile(inDirAbs, f));
-    assert(pageKey, `${fileRel}: cannot infer page key`);
-
-    let doc;
     try {
-      doc = await readDoc(f);
+      const raw = await fs.readFile(fp, "utf8");
+      const doc = YAML.parse(raw) || {};
+
+      if (!isObj(doc) || doc.schema !== 1) continue;
+
+      validateAndNormalizeDoc(
+        doc,
+        `src/annotations/${rel}`,
+        pageKey,
+        isShard ? paraId : null
+      );
+
+      const pg = (pages[pageKey] ??= { paras: {} });
+
+      if (isShard) {
+        const entry = doc.paras[paraId];
+        if (!isObj(pg.paras[paraId])) pg.paras[paraId] = {};
+        if (isObj(entry)) deepMergeEntry(pg.paras[paraId], entry);
+
+        stableSortByTs(pg.paras[paraId].media);
+        stableSortByTs(pg.paras[paraId].refs);
+        stableSortByTs(pg.paras[paraId].comments_editorial);
+      } else {
+        for (const [pid, entry] of Object.entries(doc.paras || {})) {
+          const p = String(pid);
+          if (!isObj(pg.paras[p])) pg.paras[p] = {};
+          if (isObj(entry)) deepMergeEntry(pg.paras[p], entry);
+
+          stableSortByTs(pg.paras[p].media);
+          stableSortByTs(pg.paras[p].refs);
+          stableSortByTs(pg.paras[p].comments_editorial);
+        }
+      }
     } catch (e) {
-      throw new Error(`${fileRel}: parse failed: ${String(e?.message ?? e)}`);
+      errors.push({ file: `src/annotations/${rel}`, error: String(e?.message || e) });
     }
+  }
 
-    const paras = validateAndNormalizeDoc(doc, pageKey, fileRel);
-
-    // 1 fichier = 1 page (canon)
-    assert(!pages[pageKey], `${fileRel}: duplicate page "${pageKey}" (only one file per page)`);
-    pages[pageKey] = { paras };
-    paraCount += Object.keys(paras).length;
+  for (const [pageKey, pg] of Object.entries(pages)) {
+    const keys = Object.keys(pg.paras || {});
+    keys.sort((a, b) => {
+      const ia = paraNum(a);
+      const ib = paraNum(b);
+      if (Number.isFinite(ia) && Number.isFinite(ib) && ia !== ib) return ia - ib;
+      return String(a).localeCompare(String(b));
+    });
+    const next = {};
+    for (const k of keys) next[k] = pg.paras[k];
+    pg.paras = next;
   }
 
   const out = {
@@ -143,17 +226,21 @@ async function main() {
     pages,
     stats: {
       pages: Object.keys(pages).length,
-      paras: paraCount,
+      paras: Object.values(pages).reduce((n, p) => n + Object.keys(p.paras || {}).length, 0),
+      errors: errors.length,
     },
+    errors,
   };
 
-  await fs.mkdir(path.dirname(outAbs), { recursive: true });
-  await fs.writeFile(outAbs, JSON.stringify(out), "utf8");
+  if (errors.length) {
+    throw new Error(`${errors[0].file}: ${errors[0].error}`);
+  }
 
-  console.log(`✅ annotations-index: pages=${out.stats.pages} paras=${out.stats.paras} -> ${path.relative(CWD, outAbs)}`);
+  await fs.writeFile(OUT, JSON.stringify(out), "utf8");
+  console.log(`✅ annotations-index: pages=${out.stats.pages} paras=${out.stats.paras} -> dist/annotations-index.json`);
 }
 
 main().catch((e) => {
-  console.error("FAIL: build-annotations-index crashed:", e);
+  console.error(`FAIL: build-annotations-index crashed: ${e?.stack || e?.message || e}`);
   process.exit(1);
-});
+});

scripts/check-anchors.mjs

@@ -74,7 +74,24 @@ function loadAllowMissing() {
   return new Set(arr.map(String));
 }
 
+function loadAcceptedResets() {
+  const p = path.resolve("config/anchor-churn-allowlist.json");
+  if (!fssync.existsSync(p)) return {};
+  const raw = fssync.readFileSync(p, "utf8").trim();
+  if (!raw) return {};
+  const data = JSON.parse(raw);
+  if (!data || typeof data !== "object" || Array.isArray(data)) {
+    throw new Error("anchor-churn-allowlist.json must be an object");
+  }
+  const accepted = data.accepted_resets || {};
+  if (!accepted || typeof accepted !== "object" || Array.isArray(accepted)) {
+    throw new Error("anchor-churn-allowlist.json: accepted_resets must be an object");
+  }
+  return accepted;
+}
+
 const ALLOW_MISSING = loadAllowMissing();
+const ACCEPTED_RESETS = loadAcceptedResets();
 
 async function buildSnapshot() {
   const absDist = path.resolve(DIST_DIR);
@@ -139,6 +156,7 @@ function diffPage(prevIds, curIds) {
 
   let failed = false;
   let changedPages = 0;
+  let acceptedPages = 0;
 
   for (const p of pages) {
     const prevIds = base[p] || null;
@@ -172,6 +190,7 @@ function diffPage(prevIds, curIds) {
     const prevN = prevIds.length || 1;
     const churn = (added.length + removed.length) / prevN;
     const removedRatio = removed.length / prevN;
+    const acceptedReason = ACCEPTED_RESETS[p] || null;
 
     console.log(
       `~ ${p} prev=${prevIds.length} now=${curIds.length}` +
@@ -182,11 +201,23 @@ function diffPage(prevIds, curIds) {
       console.log(`  removed: ${removed.slice(0, 20).join(", ")}${removed.length > 20 ? " …" : ""}`);
     }
 
-    if (prevIds.length >= MIN_PREV && churn > THRESHOLD) failed = true;
-    if (prevIds.length >= MIN_PREV && removedRatio > THRESHOLD) failed = true;
+    const exceeds =
+      (prevIds.length >= MIN_PREV && churn > THRESHOLD) ||
+      (prevIds.length >= MIN_PREV && removedRatio > THRESHOLD);
+
+    if (exceeds && acceptedReason) {
+      acceptedPages += 1;
+      console.log(`  ✅ accepted reset: ${acceptedReason}`);
+      continue;
+    }
+
+    if (exceeds) failed = true;
   }
 
-  console.log(`\nSummary: pages compared=${pages.length}, pages changed=${changedPages}`);
+  console.log(
+    `\nSummary: pages compared=${pages.length}, pages changed=${changedPages}, accepted resets=${acceptedPages}`
+  );
+
   if (failed) {
     console.error(`FAIL: anchor churn above threshold (threshold=${pct(THRESHOLD)} minPrev=${MIN_PREV})`);
     process.exit(1);

scripts/check-annotations-media.mjs

@@ -48,6 +48,9 @@ async function main() {
   let missing = 0;
   const notes = [];
 
+  // Optim: éviter de vérifier 100 fois le même fichier media
+  const seenMedia = new Set(); // src string
+
   for (const f of files) {
     const rel = path.relative(CWD, f).replace(/\\/g, "/");
     const raw = await fs.readFile(f, "utf8");
@@ -70,6 +73,10 @@ async function main() {
         const src = String(m?.src || "");
         if (!src.startsWith("/media/")) continue; // externes ok, ou autres conventions futures
 
+        // dédupe
+        if (seenMedia.has(src)) continue;
+        seenMedia.add(src);
+
         checked++;
         const p = toPublicPathFromUrl(src);
         if (!p) continue;
@@ -94,4 +101,4 @@ async function main() {
 main().catch((e) => {
   console.error("FAIL: check-annotations-media crashed:", e);
   process.exit(1);
-});
+});

scripts/check-annotations.mjs

@@ -27,11 +27,6 @@ function escRe(s) {
   return String(s).replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
 }
 
-function inferPageKeyFromFile(fileAbs) {
-  const rel = path.relative(ANNO_DIR, fileAbs).replace(/\\/g, "/");
-  return rel.replace(/\.(ya?ml|json)$/i, "");
-}
-
 function normalizePageKey(s) {
   return String(s || "").replace(/^\/+/, "").replace(/\/+$/, "");
 }
@@ -40,6 +35,31 @@ function isPlainObject(x) {
   return !!x && typeof x === "object" && !Array.isArray(x);
 }
 
+function isParaId(s) {
+  return /^p-\d+-/i.test(String(s || ""));
+}
+
+/**
+ * Supporte:
+ * - monolith: src/annotations/<pageKey>.yml -> pageKey = rel sans ext
+ * - shard   : src/annotations/<pageKey>/<paraId>.yml -> pageKey = dirname(rel), paraId = basename
+ *
+ * shard seulement si le fichier est dans un sous-dossier (anti cas pathologique).
+ */
+function inferFromFile(fileAbs) {
+  const rel = path.relative(ANNO_DIR, fileAbs).replace(/\\/g, "/");
+  const relNoExt = rel.replace(/\.(ya?ml|json)$/i, "");
+  const parts = relNoExt.split("/").filter(Boolean);
+  const base = parts[parts.length - 1] || "";
+  const dirParts = parts.slice(0, -1);
+
+  const isShard = dirParts.length > 0 && isParaId(base);
+  const pageKey = isShard ? dirParts.join("/") : relNoExt;
+  const paraId = isShard ? base : "";
+
+  return { pageKey: normalizePageKey(pageKey), paraId };
+}
+
 async function loadAliases() {
   if (!(await exists(ALIASES_PATH))) return {};
   try {
@@ -60,10 +80,12 @@ function getAlias(aliases, pageKey, oldId) {
   // supporte:
   // 1) { "<pageKey>": { "<old>": "<new>" } }
   // 2) { "<old>": "<new>" }
-  const a1 = aliases?.[pageKey]?.[oldId];
-  if (a1) return a1;
+  const k1 = String(pageKey || "");
+  const k2 = k1 ? ("/" + k1.replace(/^\/+|\/+$/g, "") + "/") : "";
+  const a1 = (aliases?.[k1]?.[oldId]) || (k2 ? aliases?.[k2]?.[oldId] : "");
+  if (a1) return String(a1);
   const a2 = aliases?.[oldId];
-  if (a2) return a2;
+  if (a2) return String(a2);
   return "";
 }
 
@@ -81,7 +103,11 @@ async function main() {
   const aliases = await loadAliases();
   const files = (await walk(ANNO_DIR)).filter((p) => /\.(ya?ml|json)$/i.test(p));
 
-  let pages = 0;
+  // perf: cache HTML par page (shards = beaucoup de fichiers pour 1 page)
+  const htmlCache = new Map();        // pageKey -> html
+  const missingDistPage = new Set();  // pageKey
+
+  let pagesSeen = new Set();
   let checked = 0;
   let failures = 0;
   const notes = [];
@@ -105,7 +131,7 @@ async function main() {
       continue;
     }
 
-    const pageKey = normalizePageKey(inferPageKeyFromFile(f));
+    const { pageKey, paraId: shardParaId } = inferFromFile(f);
 
     if (doc.page != null && normalizePageKey(doc.page) !== pageKey) {
       failures++;
@@ -119,20 +145,44 @@ async function main() {
       continue;
     }
 
+    // shard invariant (fort) : doit contenir paras[paraId]
+    if (shardParaId) {
+      if (!Object.prototype.hasOwnProperty.call(doc.paras, shardParaId)) {
+        failures++;
+        notes.push(`- SHARD MISMATCH: ${rel} (expected paras["${shardParaId}"] present)`);
+        continue;
+      }
+      // si extras -> warning (non destructif)
+      const keys = Object.keys(doc.paras);
+      if (!(keys.length === 1 && keys[0] === shardParaId)) {
+        notes.push(`- WARN shard has extra paras: ${rel} (expected only "${shardParaId}", got ${keys.join(", ")})`);
+      }
+    }
+
+    pagesSeen.add(pageKey);
+
     const distFile = path.join(DIST_DIR, pageKey, "index.html");
     if (!(await exists(distFile))) {
-      failures++;
-      notes.push(`- MISSING PAGE: dist/${pageKey}/index.html (from ${rel})`);
+      if (!missingDistPage.has(pageKey)) {
+        missingDistPage.add(pageKey);
+        failures++;
+        notes.push(`- MISSING PAGE: dist/${pageKey}/index.html (from ${rel})`);
+      } else {
+        notes.push(`- WARN missing page already reported: dist/${pageKey}/index.html (from ${rel})`);
+      }
       continue;
     }
 
-    pages++;
-    const html = await fs.readFile(distFile, "utf8");
+    let html = htmlCache.get(pageKey);
+    if (!html) {
+      html = await fs.readFile(distFile, "utf8");
+      htmlCache.set(pageKey, html);
+    }
 
     for (const paraId of Object.keys(doc.paras)) {
       checked++;
 
-      if (!/^p-\d+-/i.test(paraId)) {
+      if (!isParaId(paraId)) {
         failures++;
         notes.push(`- INVALID ID: ${rel} (${paraId})`);
         continue;
@@ -156,6 +206,7 @@ async function main() {
   }
 
   const warns = notes.filter((x) => x.startsWith("- WARN"));
+  const pages = pagesSeen.size;
 
   if (failures > 0) {
     console.error(`FAIL: annotations invalid (pages=${pages} checked=${checked} failures=${failures})`);
@@ -170,4 +221,4 @@ async function main() {
 main().catch((e) => {
   console.error("FAIL: annotations check crashed:", e);
   process.exit(1);
-});
+});

scripts/import-docx.mjs

@@ -114,7 +114,6 @@ async function runMammoth(docxPath, assetsOutDirWebRoot) {
   );
 
   let html = result.value || "";
-
   // Mammoth gives relative src="image-xx.png" ; we will prefix later
   return html;
 }
@@ -182,6 +181,25 @@ async function exists(p) {
   try { await fs.access(p); return true; } catch { return false; }
 }
 
+/**
+ * ✅ compat:
+ * - ancien : collection="archicratie" + slug="archicrat-ia/chapitre-3"
+ * - nouveau : collection="archicrat-ia" + slug="chapitre-3"
+ *
+ * But : toujours écrire dans src/content/archicrat-ia/<slugSansPrefix>.mdx
+ */
+function normalizeDest(collection, slug) {
+  let outCollection = String(collection || "").trim();
+  let outSlug = String(slug || "").trim().replace(/^\/+|\/+$/g, "");
+
+  if (outCollection === "archicratie" && outSlug.startsWith("archicrat-ia/")) {
+    outCollection = "archicrat-ia";
+    outSlug = outSlug.replace(/^archicrat-ia\//, "");
+  }
+
+  return { outCollection, outSlug };
+}
+
 async function main() {
   const args = parseArgs(process.argv);
   const manifestPath = path.resolve(args.manifest);
@@ -203,11 +221,14 @@ async function main() {
 
   for (const it of selected) {
     const docxPath = path.resolve(it.source);
-    const outFile = path.resolve("src/content", it.collection, `${it.slug}.mdx`);
+
+    const { outCollection, outSlug } = normalizeDest(it.collection, it.slug);
+
+    const outFile = path.resolve("src/content", outCollection, `${outSlug}.mdx`);
     const outDir = path.dirname(outFile);
 
-    const assetsPublicDir = path.posix.join("/imported", it.collection, it.slug);
-    const assetsDiskDir = path.resolve("public", "imported", it.collection, it.slug);
+    const assetsPublicDir = path.posix.join("/imported", outCollection, outSlug);
+    const assetsDiskDir = path.resolve("public", "imported", outCollection, outSlug);
 
     if (!(await exists(docxPath))) {
       throw new Error(`Missing source docx: ${docxPath}`);
@@ -241,18 +262,20 @@ async function main() {
       html = rewriteLocalImageLinks(html, assetsPublicDir);
       body = html.trim() ? html : "<p>(Import vide)</p>";
     }
-  
+
     const defaultVersion = process.env.PUBLIC_RELEASE || "0.1.0";
 
+    // ✅ IMPORTANT: archicrat-ia partage edition/status avec archicratie (pas de migration frontmatter)
     const schemaDefaultsByCollection = {
-      archicratie: { edition: "archicratie", status: "modele_sociopolitique", level: 1 },
-      ia:         { edition: "ia",         status: "cas_pratique",           level: 1 },
-      traite:     { edition: "traite",     status: "ontodynamique",          level: 1 },
-      glossaire:  { edition: "glossaire",  status: "lexique",                level: 1 },
-      atlas:      { edition: "atlas",      status: "atlas",                  level: 1 },
+      archicratie:    { edition: "archicratie",  status: "modele_sociopolitique", level: 1 },
+      "archicrat-ia": { edition: "archicrat-ia", status: "essai_these",           level: 1 },
+      "cas-ia":       { edition: "cas-ia",       status: "application",           level: 1 },
+      traite:         { edition: "traite",       status: "ontodynamique",         level: 1 },
+      glossaire:      { edition: "glossaire",    status: "lexique",               level: 1 },
+      atlas:          { edition: "atlas",        status: "atlas",                 level: 1 },
     };
 
-    const defaults = schemaDefaultsByCollection[it.collection] || { edition: it.collection, status: "draft", level: 1 };
+    const defaults = schemaDefaultsByCollection[outCollection] || { edition: outCollection, status: "draft", level: 1 };
 
     const fm = [
       "---",
@@ -282,4 +305,4 @@ async function main() {
 main().catch((e) => {
   console.error("\nERROR:", e?.message || e);
   process.exit(1);
-});
+});

scripts/inject-anchor-aliases.mjs

@@ -14,6 +14,24 @@ const STRICT = argv.includes("--strict") || process.env.CI === "1" || process.en
 function escRe(s) {
   return String(s).replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
 }
+
+async function exists(p) {
+  try {
+    await fs.access(p);
+    return true;
+  } catch {
+    return false;
+  }
+}
+
+function normalizeRoute(route) {
+  let r = String(route || "").trim();
+  if (!r.startsWith("/")) r = "/" + r;
+  if (!r.endsWith("/")) r = r + "/";
+  r = r.replace(/\/{2,}/g, "/");
+  return r;
+}
+
 function countIdAttr(html, id) {
   const re = new RegExp(`\\bid=(["'])${escRe(id)}\\1`, "gi");
   let c = 0;
@@ -22,7 +40,6 @@ function countIdAttr(html, id) {
 }
 
 function findStartTagWithId(html, id) {
-  // 1er élément qui porte id="..."
   const re = new RegExp(
     `<([a-zA-Z0-9:-]+)\\b[^>]*\\bid=(["'])${escRe(id)}\\2[^>]*>`,
     "i"
@@ -36,34 +53,10 @@ function isInjectedAliasSpan(html, id) {
   const found = findStartTagWithId(html, id);
   if (!found) return false;
   if (found.tagName !== "span") return false;
-  // class="... para-alias ..."
   return /\bclass=(["'])(?:(?!\1).)*\bpara-alias\b(?:(?!\1).)*\1/i.test(found.tag);
 }
-  
-function normalizeRoute(route) {
-  let r = String(route || "").trim();
-  if (!r.startsWith("/")) r = "/" + r;
-  if (!r.endsWith("/")) r = r + "/";
-  r = r.replace(/\/{2,}/g, "/");
-  return r;
-}
-
-async function exists(p) {
-  try {
-    await fs.access(p);
-    return true;
-  } catch {
-    return false;
-  }
-}
-
-function hasId(html, id) {
-  const re = new RegExp(`\\bid=(["'])${escRe(id)}\\1`, "i");
-  return re.test(html);
-}
 
 function injectBeforeId(html, newId, injectHtml) {
-  // insère juste avant la balise qui porte id="newId"
   const re = new RegExp(
     `(<[^>]+\\bid=(["'])${escRe(newId)}\\2[^>]*>)`,
     "i"
@@ -82,6 +75,7 @@ async function main() {
   }
 
   const raw = await fs.readFile(ALIASES_PATH, "utf-8");
+
   /** @type {Record<string, Record<string,string>>} */
   let aliases;
   try {
@@ -89,6 +83,7 @@ async function main() {
   } catch (e) {
     throw new Error(`JSON invalide: ${ALIASES_PATH} (${e?.message || e})`);
   }
+
   if (!aliases || typeof aliases !== "object" || Array.isArray(aliases)) {
     throw new Error(`Format invalide: attendu { route: { oldId: newId } } dans ${ALIASES_PATH}`);
   }
@@ -114,10 +109,10 @@ async function main() {
       console.log(msg);
       warnCount++;
     }
-    
+
     if (entries.length === 0) continue;
 
-    const rel = route.replace(/^\/+|\/+$/g, ""); // sans slash
+    const rel = route.replace(/^\/+|\/+$/g, "");
     const htmlPath = path.join(DIST_ROOT, rel, "index.html");
 
     if (!(await exists(htmlPath))) {
@@ -135,24 +130,8 @@ async function main() {
       if (!oldId || !newId) continue;
 
       const oldCount = countIdAttr(html, oldId);
-      if (oldCount > 0) {
-        // ✅ déjà injecté (idempotent)
-        if (isInjectedAliasSpan(html, oldId)) continue;
 
-        // ⛔️ oldId existe déjà "en vrai" (ex: <p id="oldId">)
-        // => alias inutile / inversé / obsolète
-        const found = findStartTagWithId(html, oldId);
-        const where = found ? `<${found.tagName} … id="${oldId}" …>` : `id="${oldId}"`;
-        const msg =
-          `⚠️  alias inutile/inversé: oldId déjà présent dans la page (${where}). ` +
-          `Supprime l'alias ${oldId} -> ${newId} (ou corrige le sens) pour route=${route}`;
-        if (STRICT) throw new Error(msg);
-        console.log(msg);
-        warnCount++;
-        continue;
-      }
-
-      // juste après avoir calculé oldCount
+      // ✅ déjà injecté => idempotent
       if (oldCount > 0 && isInjectedAliasSpan(html, oldId)) {
         if (STRICT && oldCount !== 1) {
           throw new Error(`oldId dupliqué (${oldCount}) alors qu'il est censé être unique: ${route} id=${oldId}`);
@@ -160,18 +139,23 @@ async function main() {
         continue;
       }
 
-      // avant l'injection, après hasId(newId)
-      const newCount = countIdAttr(html, newId);
-      if (newCount !== 1) {
-        const msg = `⚠️  newId non-unique (${newCount}) : ${route} new=${newId} (injection ambiguë)`;
+      // ⛔️ oldId existe déjà "en vrai" => alias inutile/inversé
+      if (oldCount > 0) {
+        const found = findStartTagWithId(html, oldId);
+        const where = found ? `<${found.tagName} … id="${oldId}" …>` : `id="${oldId}"`;
+        const msg =
+          `⚠️  alias inutile/inversé: oldId déjà présent (${where}). ` +
+          `Supprime ${oldId} -> ${newId} (ou corrige le sens) pour route=${route}`;
         if (STRICT) throw new Error(msg);
         console.log(msg);
         warnCount++;
         continue;
       }
 
-      if (!hasId(html, newId)) {
-        const msg = `⚠️  newId introuvable: ${route} old=${oldId} -> new=${newId}`;
+      // newId doit exister UNE fois (sinon injection ambiguë)
+      const newCount = countIdAttr(html, newId);
+      if (newCount !== 1) {
+        const msg = `⚠️  newId non-unique (${newCount}) : ${route} new=${newId} (injection ambiguë)`;
         if (STRICT) throw new Error(msg);
         console.log(msg);
         warnCount++;

scripts/pick-proposer-issue.mjs

@@ -0,0 +1,241 @@
+#!/usr/bin/env node
+import process from "node:process";
+
+function getEnv(name, fallback = "") {
+  return String(process.env[name] ?? fallback).trim();
+}
+
+function sh(value) {
+  return JSON.stringify(String(value ?? ""));
+}
+
+function escapeRegExp(s) {
+  return String(s).replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
+}
+
+function pickLine(body, key) {
+  const re = new RegExp(`^\\s*${escapeRegExp(key)}\\s*:\\s*([^\\n\\r]+)`, "mi");
+  const m = String(body || "").match(re);
+  return m ? m[1].trim() : "";
+}
+
+function pickHeadingValue(body, headingKey) {
+  const re = new RegExp(
+    `^##\\s*${escapeRegExp(headingKey)}[^\\n]*\\n([\\s\\S]*?)(?=\\n##\\s|\\n\\s*$)`,
+    "mi"
+  );
+  const m = String(body || "").match(re);
+  if (!m) return "";
+  const lines = m[1].split(/\r?\n/).map((l) => l.trim());
+  for (const l of lines) {
+    if (!l) continue;
+    if (l.startsWith("<!--")) continue;
+    return l.replace(/^\/?/, "/").trim();
+  }
+  return "";
+}
+
+function normalizeChemin(chemin) {
+  let c = String(chemin || "").trim();
+  if (!c) return "";
+  if (!c.startsWith("/")) c = "/" + c;
+  if (!c.endsWith("/")) c += "/";
+  return c;
+}
+
+function extractCheminFromAnyUrl(text) {
+  const s = String(text || "");
+  const m = s.match(/(\/[a-z0-9\-]+\/[a-z0-9\-\/]+\/)#p-\d+-[0-9a-f]{8}/i);
+  return m ? m[1] : "";
+}
+
+function inferType(issue) {
+  const title = String(issue?.title || "");
+  const body = String(issue?.body || "").replace(/\r\n/g, "\n");
+  const fromBody = String(pickLine(body, "Type") || "").trim().toLowerCase();
+  if (fromBody) return fromBody;
+
+  if (title.startsWith("[Correction]")) return "type/correction";
+  if (title.startsWith("[Fact-check]") || title.startsWith("[Vérification]")) return "type/fact-check";
+  return "";
+}
+
+function inferChemin(issue) {
+  const title = String(issue?.title || "");
+  const body = String(issue?.body || "").replace(/\r\n/g, "\n");
+
+  return normalizeChemin(
+    pickLine(body, "Chemin") ||
+      pickHeadingValue(body, "Chemin") ||
+      extractCheminFromAnyUrl(body) ||
+      extractCheminFromAnyUrl(title)
+  );
+}
+
+function labelsOf(issue) {
+  return Array.isArray(issue?.labels)
+    ? issue.labels.map((l) => String(l?.name || "")).filter(Boolean)
+    : [];
+}
+
+function issueNumber(issue) {
+  return Number(issue?.number || issue?.index || 0);
+}
+
+function parseMeta(issue) {
+  const labels = labelsOf(issue);
+  const type = inferType(issue);
+  const chemin = inferChemin(issue);
+  const number = issueNumber(issue);
+
+  const hasApproved = labels.includes("state/approved");
+  const hasRejected = labels.includes("state/rejected");
+  const isProposer = type === "type/correction" || type === "type/fact-check";
+  const isOpen = String(issue?.state || "open") === "open";
+  const isPR = Boolean(issue?.pull_request);
+
+  const eligible =
+    number > 0 &&
+    isOpen &&
+    !isPR &&
+    hasApproved &&
+    !hasRejected &&
+    isProposer &&
+    Boolean(chemin);
+
+  return {
+    issue,
+    number,
+    type,
+    chemin,
+    labels,
+    hasApproved,
+    hasRejected,
+    eligible,
+  };
+}
+
+async function fetchJson(url, token) {
+  const res = await fetch(url, {
+    headers: {
+      Authorization: `token ${token}`,
+      Accept: "application/json",
+      "User-Agent": "archicratie-pick-proposer-issue/1.0",
+    },
+  });
+  if (!res.ok) {
+    const t = await res.text().catch(() => "");
+    throw new Error(`HTTP ${res.status} ${url}\n${t}`);
+  }
+  return await res.json();
+}
+
+async function fetchIssue(apiBase, owner, repo, token, n) {
+  const url = `${apiBase}/api/v1/repos/${owner}/${repo}/issues/${n}`;
+  return await fetchJson(url, token);
+}
+
+async function listOpenIssues(apiBase, owner, repo, token) {
+  const out = [];
+  let page = 1;
+  const limit = 100;
+
+  while (true) {
+    const url = `${apiBase}/api/v1/repos/${owner}/${repo}/issues?state=open&page=${page}&limit=${limit}`;
+    const batch = await fetchJson(url, token);
+    if (!Array.isArray(batch) || batch.length === 0) break;
+    out.push(...batch);
+    if (batch.length < limit) break;
+    page += 1;
+  }
+
+  return out;
+}
+
+function emitNone(reason) {
+  process.stdout.write(
+    [
+      `TARGET_FOUND="0"`,
+      `TARGET_REASON=${sh(reason)}`,
+      `TARGET_PRIMARY_ISSUE=""`,
+      `TARGET_ISSUES=""`,
+      `TARGET_COUNT="0"`,
+      `TARGET_CHEMIN=""`,
+    ].join("\n") + "\n"
+  );
+}
+
+async function main() {
+  const token = getEnv("FORGE_TOKEN");
+  const owner = getEnv("GITEA_OWNER");
+  const repo = getEnv("GITEA_REPO");
+  const apiBase = (getEnv("FORGE_API") || getEnv("FORGE_BASE")).replace(/\/+$/, "");
+  const explicit = Number(process.argv[2] || 0);
+
+  if (!token) throw new Error("Missing FORGE_TOKEN");
+  if (!owner || !repo) throw new Error("Missing GITEA_OWNER / GITEA_REPO");
+  if (!apiBase) throw new Error("Missing FORGE_API / FORGE_BASE");
+
+  let metas = [];
+
+  if (explicit > 0) {
+    const issue = await fetchIssue(apiBase, owner, repo, token, explicit);
+    const meta = parseMeta(issue);
+
+    if (!meta.eligible) {
+      emitNone(
+        !meta.hasApproved
+          ? "explicit_issue_not_approved"
+          : meta.hasRejected
+            ? "explicit_issue_rejected"
+            : !meta.type
+              ? "explicit_issue_missing_type"
+              : !meta.chemin
+                ? "explicit_issue_missing_chemin"
+                : "explicit_issue_not_eligible"
+      );
+      return;
+    }
+
+    const openIssues = await listOpenIssues(apiBase, owner, repo, token);
+    metas = openIssues.map(parseMeta).filter((m) => m.eligible && m.chemin === meta.chemin);
+  } else {
+    const openIssues = await listOpenIssues(apiBase, owner, repo, token);
+    metas = openIssues.map(parseMeta).filter((m) => m.eligible);
+
+    if (metas.length === 0) {
+      emitNone("no_open_approved_proposer_issue");
+      return;
+    }
+
+    metas.sort((a, b) => a.number - b.number);
+    const first = metas[0];
+    metas = metas.filter((m) => m.chemin === first.chemin);
+  }
+
+  metas.sort((a, b) => a.number - b.number);
+
+  if (metas.length === 0) {
+    emitNone("no_batch_for_path");
+    return;
+  }
+
+  const primary = metas[0];
+  const issues = metas.map((m) => String(m.number));
+
+  process.stdout.write(
+    [
+      `TARGET_FOUND="1"`,
+      `TARGET_REASON="ok"`,
+      `TARGET_PRIMARY_ISSUE=${sh(primary.number)}`,
+      `TARGET_ISSUES=${sh(issues.join(" "))}`,
+      `TARGET_COUNT=${sh(issues.length)}`,
+      `TARGET_CHEMIN=${sh(primary.chemin)}`,
+    ].join("\n") + "\n"
+  );
+}
+
+main().catch((e) => {
+  console.error("💥 pick-proposer-issue:", e?.message || e);
+  process.exit(1);
+});

scripts/purge-dist-dev-whoami.mjs

@@ -0,0 +1,31 @@
+// scripts/purge-dist-dev-whoami.mjs
+import fs from "node:fs/promises";
+import path from "node:path";
+
+const CWD = process.cwd();
+const targetDir = path.join(CWD, "dist", "_auth", "whoami");
+const targetIndex = path.join(CWD, "dist", "_auth", "whoami", "index.html");
+
+// Purge idempotente (force=true => pas d'erreur si absent)
+async function rmSafe(p) {
+  try {
+    await fs.rm(p, { recursive: true, force: true });
+    return true;
+  } catch {
+    return false;
+  }
+}
+
+async function main() {
+  const removedIndex = await rmSafe(targetIndex);
+  const removedDir = await rmSafe(targetDir);
+
+  // Optionnel: si dist/_auth devient vide, on laisse tel quel (pas besoin de toucher)
+  const any = removedIndex || removedDir;
+  console.log(`✅ purge-dist-dev-whoami: ${any ? "purged" : "nothing to purge"}`);
+}
+
+main().catch((e) => {
+  console.error("❌ purge-dist-dev-whoami failed:", e);
+  process.exit(1);
+});

scripts/verify-anchor-aliases-in-dist.mjs

@@ -205,7 +205,7 @@ for (const [route, mapping] of Object.entries(data)) {
         newId,
         htmlPath,
         msg:
-          `oldId present but is NOT an injected alias span (<span class="para-alias">).</n` +
+          `oldId present but is NOT an injected alias span (<span class="para-alias">).\n` +
           `Saw: ${seen}`,
       });
       continue;

scripts/write-dev-whoami.mjs

@@ -0,0 +1,26 @@
+import fs from "node:fs/promises";
+import path from "node:path";
+
+const OUT = path.join(process.cwd(), "public", "_auth", "whoami");
+
+const groupsRaw = process.env.PUBLIC_WHOAMI_GROUPS ?? "editors";
+const user = process.env.PUBLIC_WHOAMI_USER ?? "dev";
+const name = process.env.PUBLIC_WHOAMI_NAME ?? "Dev Local";
+const email = process.env.PUBLIC_WHOAMI_EMAIL ?? "area.technik@proton.me";
+
+const groups = groupsRaw
+  .split(/[;,]/)
+  .map((s) => s.trim())
+  .filter(Boolean)
+  .join(",");
+
+const body =
+  `Remote-User: ${user}\n` +
+  `Remote-Name: ${name}\n` +
+  `Remote-Email: ${email}\n` +
+  `Remote-Groups: ${groups}\n`;
+
+await fs.mkdir(path.dirname(OUT), { recursive: true });
+await fs.writeFile(OUT, body, "utf8");
+
+console.log(`✅ dev whoami written: ${path.relative(process.cwd(), OUT)} (${groups})`);

scripts/write-ops-health.mjs

@@ -0,0 +1,20 @@
+import fs from "node:fs";
+import path from "node:path";
+
+const root = process.cwd();
+const outDir = path.join(root, "public", "__ops");
+const outFile = path.join(outDir, "health.json");
+
+const payload = {
+  service: "archicratie-site",
+  env: process.env.PUBLIC_OPS_ENV || "unknown",
+  upstream: process.env.PUBLIC_OPS_UPSTREAM || "unknown",
+  buildSha: process.env.PUBLIC_BUILD_SHA || "unknown",
+  builtAt: process.env.PUBLIC_BUILD_TIME || new Date().toISOString(),
+};
+
+fs.mkdirSync(outDir, { recursive: true });
+fs.writeFileSync(outFile, `${JSON.stringify(payload, null, 2)}\n`, "utf8");
+
+console.log(`✅ ops health written: ${outFile}`);
+console.log(payload);

sources/manifest.yml

@@ -1,6 +1,15 @@
 version: 1
 
 docs:
+  # =========================
+  # Document d’entrée
+  # =========================
+  - source: sources/docx/commencer/document-de-presentation.docx
+    collection: commencer
+    slug: document-de-presentation
+    title: "Document de présentation"
+    order: 0
+
   # =========================
   # Archicratie — Essai-thèse "ArchiCraT-IA"
   # =========================
@@ -47,115 +56,68 @@ docs:
     order: 70
 
   # =========================
-  # IA — Cas pratique (1 page = 1 chapitre)
-  # NOTE: on n'inclut PAS le monolithe "Cas_IA-... .docx" dans le manifeste.
+  # Cas pratique — Gouvernance des systèmes IA
   # =========================
-  - source: sources/docx/cas-ia/Cas_IA-Archicratie_et_gouvernance_des_systemes_IA-Introduction_generale—Mettre_en_scene_un_systeme_IA.docx
-    collection: ia
-    slug: cas-pratique/introduction
-    title: "Cas pratique — Introduction générale : Mettre en scène un système IA"
+  - source: sources/docx/cas-ia/Cas_Pratique-Archicratie_et_gouvernance_des_systemes_IA-Introduction.docx
+    collection: cas-ia
+    slug: introduction
+    title: "Introduction générale — Mettre un système d’IA en scène"
     order: 110
 
-  - source: sources/docx/cas-ia/Cas_IA-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_I—Epreuve_de_detectabilite.docx
-    collection: ia
-    slug: cas-pratique/chapitre-1
-    title: "Cas pratique — Chapitre I : Épreuve de détectabilité"
+  - source: sources/docx/cas-ia/Cas_Pratique-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_1_Epreuve_de_detectabilite.docx
+    collection: cas-ia
+    slug: chapitre-1
+    title: "Chapitre I — Épreuve de détectabilité"
     order: 120
 
-  - source: sources/docx/cas-ia/Cas_IA-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_II—Epreuve_topologique.docx
-    collection: ia
-    slug: cas-pratique/chapitre-2
-    title: "Cas pratique — Chapitre II : Épreuve topologique"
+  - source: sources/docx/cas-ia/Cas_Pratique-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_2_Epreuve_Topologique.docx
+    collection: cas-ia
+    slug: chapitre-2
+    title: "Chapitre II — Épreuve topologique"
     order: 130
 
-  - source: sources/docx/cas-ia/Cas_IA-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_III—Epreuve_archeogenetique.docx
-    collection: ia
-    slug: cas-pratique/chapitre-3
-    title: "Cas pratique — Chapitre III : Épreuve archéogénétique"
+  - source: sources/docx/cas-ia/Cas_Pratique-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_3_Epreuve_archeogenetique.docx
+    collection: cas-ia
+    slug: chapitre-3
+    title: "Chapitre III — Épreuve archéogénétique"
     order: 140
 
-  - source: sources/docx/cas-ia/Cas_IA-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_IV—Epreuve_morphologique.docx
-    collection: ia
-    slug: cas-pratique/chapitre-4
-    title: "Cas pratique — Chapitre IV : Épreuve morphologique"
+  - source: sources/docx/cas-ia/Cas_Pratique-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_4_Epreuve_Morphologique.docx
+    collection: cas-ia
+    slug: chapitre-4
+    title: "Chapitre IV — Épreuve morphologique"
     order: 150
 
-  - source: sources/docx/cas-ia/Cas_IA-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_V—Epreuve_historique.docx
-    collection: ia
-    slug: cas-pratique/chapitre-5
-    title: "Cas pratique — Chapitre V : Épreuve historique"
+  - source: sources/docx/cas-ia/Cas_Pratique-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_5_Epreuve_Historique.docx
+    collection: cas-ia
+    slug: chapitre-5
+    title: "Chapitre V — Épreuve historique"
     order: 160
 
-  - source: sources/docx/cas-ia/Cas_IA-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_VI—Epreuve_de_co-viabilite.docx
-    collection: ia
-    slug: cas-pratique/chapitre-6
-    title: "Cas pratique — Chapitre VI : Épreuve de co-viabilité"
+  - source: sources/docx/cas-ia/Cas_Pratique-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_6_Epreuve_de_Co-viabilite.docx
+    collection: cas-ia
+    slug: chapitre-6
+    title: "Chapitre VI — Épreuve de co-viabilité"
     order: 170
 
-  - source: sources/docx/cas-ia/Cas_IA-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_VII—Gestes_archicratiques_concrets_pour_un_systeme_IA.docx
-    collection: ia
-    slug: cas-pratique/chapitre-7
-    title: "Cas pratique — Chapitre VII : Gestes archicratiques concrets"
+  - source: sources/docx/cas-ia/Cas_Pratique-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_7_Gestes_archicratiques_concrets_pour_un_systeme_IA.docx
+    collection: cas-ia
+    slug: chapitre-7
+    title: "Chapitre VII — Gestes archicratiques concrets pour un système d’IA"
     order: 180
 
-  - source: sources/docx/cas-ia/Cas_IA-Archicratie_et_gouvernance_des_systemes_IA-Conclusion.docx
-    collection: ia
-    slug: cas-pratique/conclusion
-    title: "Cas pratique — Conclusion"
+  - source: sources/docx/cas-ia/Cas_Pratique-Archicratie_et_gouvernance_des_systemes_IA-Conclusion.docx
+    collection: cas-ia
+    slug: conclusion
+    title: "Conclusion"
     order: 190
 
-  - source: sources/docx/cas-ia/Cas_IA-Archicratie_et_gouvernance_des_systemes_IA-Annexe—Glossaire_archicratique_pour_audit_des_systemes_IA.docx
-    collection: ia
-    slug: cas-pratique/annexe-glossaire-audit
-    title: "Cas pratique — Annexe : Glossaire archicratique pour audit des systèmes IA"
+  - source: sources/docx/cas-ia/Cas_Pratique-Archicratie_et_gouvernance_des_systemes_IA-Annexe_Glossaire_Archicratique_Cas_IA.docx
+    collection: cas-ia
+    slug: annexe-glossaire-audit
+    title: "Annexe — Glossaire archicratique pour l’audit des systèmes d’IA"
     order: 195
 
-  # =========================
-  # Traité — Ontodynamique générative (1 page = 1 chapitre)
-  # NOTE: on n'inclut PAS le monolithe "Traite-...-version_officielle.docx" dans le manifeste.
-  # =========================
-  - source: sources/docx/traite/Traite-Ontodynamique_Generative-Fondements_Archicratie-Introduction-version_officielle.docx
-    collection: traite
-    slug: ontodynamique/introduction
-    title: "Traité — Introduction"
-    order: 210
-
-  - source: sources/docx/traite/Traite-Ontodynamique_Generative-Fondements_Archicratie-Chapitre_1—Le_flux_ontogenetique-version_officielle.docx
-    collection: traite
-    slug: ontodynamique/chapitre-1
-    title: "Traité — Chapitre 1 : Le flux ontogénétique"
-    order: 220
-
-  - source: sources/docx/traite/Traite-Ontodynamique_Generative-Fondements_Archicratie-Chapitre_2—economie_du_reel-version_officielle.docx
-    collection: traite
-    slug: ontodynamique/chapitre-2
-    title: "Traité — Chapitre 2 : Économie du réel"
-    order: 230
-
-  - source: sources/docx/traite/Traite-Ontodynamique_Generative-Fondements_Archicratie-Chapitre_3—Le_reel_comme_systeme_regulateur-version_officielle.docx
-    collection: traite
-    slug: ontodynamique/chapitre-3
-    title: "Traité — Chapitre 3 : Le réel comme système régulateur"
-    order: 240
-
-  - source: sources/docx/traite/Traite-Ontodynamique_Generative-Fondements_Archicratie-Chapitre_4—Arcalite-structures_formes_invariants-version_officielle.docx
-    collection: traite
-    slug: ontodynamique/chapitre-4
-    title: "Traité — Chapitre 4 : Arcalité — structures, formes, invariants"
-    order: 250
-
-  - source: sources/docx/traite/Traite-Ontodynamique_Generative-Fondements_Archicratie-Chapitre_5-Cratialite-forces_flux_gradients-version_officielle.docx
-    collection: traite
-    slug: ontodynamique/chapitre-5
-    title: "Traité — Chapitre 5 : Cratialité — forces, flux, gradients"
-    order: 260
-
-  - source: sources/docx/traite/Traite-Ontodynamique_Generative-Fondements_Archicratie-Chapitre_6—Archicration-version_officielle.docx
-    collection: traite
-    slug: ontodynamique/chapitre-6
-    title: "Traité — Chapitre 6 : Archicration"
-    order: 270
-
   # =========================
   # Glossaire / Lexique
   # =========================
@@ -169,4 +131,4 @@ docs:
     collection: glossaire
     slug: mini-glossaire-verbes
     title: "Mini-glossaire des verbes de la scène archicratique"
-    order: 910
+    order: 910

src/anchors/anchor-aliases.json

@@ -1,2 +1,11 @@
-{}
-  
+{
+  "/archicrat-ia/prologue/": {
+    "p-0-d7974f88": "p-0-e729df02",
+    "p-17-b8c5bf21": "p-17-3deef56b",
+    "p-22-a416d473": "p-22-5bfa283b",
+    "p-23-d91a7b78": "p-23-0e7b37e9",
+    "p-4-8ed4f807": "p-4-90b2a1cc",
+    "p-5-85126fa5": "p-5-d788c546",
+    "p-7-64a0ca9c": "p-7-4efdb1d4"
+  }
+}

src/annotations/archicrat-ia/prologue.yml

@@ -1,59 +0,0 @@
-schema: 1
-
-# optionnel (si présent, doit matcher le chemin du fichier)
-page: archicratie/archicrat-ia/prologue
-
-paras:
-  p-0-d7974f88:
-    refs:
-      - label: "Happycratie — (Cabanas & Illouz) via Cairn"
-        url: "https://shs.cairn.info/revue-ethnologie-francaise-2019-4-page-813?lang=fr"
-        kind: "article"
-      - label: "Techno-féodalisme — Variations (OpenEdition)"
-        url: "https://journals.openedition.org/variations/2290"
-        kind: "article"
-
-    authors:
-      - "Eva Illouz"
-      - "Yanis Varoufakis"
-
-    quotes:
-      - text: "Dans Happycratie, Edgar Cabanas et Eva Illouz..."
-        source: "Happycratie, p.1"
-      - text: "En eux-mêmes, les actifs ne sont ni féodaux ni capitalistes..."
-        source: "Entretien Morozov/Varoufakis — techno-féodalisme"
-
-    media:
-      - type: "image"
-        src: "/public/media/archicratie/archicrat-ia/prologue/p-0-d7974f88/schema-1.svg"
-        caption: "Tableau explicatif"
-        credit: "ChatGPT"
-      - type: "image"
-        src: "/public/media/archicratie/archicrat-ia/prologue/p-0-d7974f88/schema-2.svg"
-        caption: "Diagramme d’évolution"
-        credit: "Yanis Varoufakis"
-
-    comments_editorial:
-      - text: "TODO: nuancer / préciser — commentaire éditorial versionné (pas public)."
-        status: "draft"
-
-  p-1-2ef25f29:
-    refs:
-      - label: "Kafka et le pouvoir — Bernard Lahire (Cairn)"
-        url: "https://shs.cairn.info/franz-kafka--9782707159410-page-475?lang=fr"
-        kind: "book"
-
-    authors:
-      - "Bernard Lahire"
-
-    quotes:
-      - text: "Si l’on voulait chercher quelque chose comme une vision du monde chez Kafka..."
-        source: "Bernard Lahire, Franz Kafka, p.475+"
-
-    media:
-      - type: "video"
-        src: "/media/prologue/p-1-2ef25f29/bien_commun.mp4"
-        caption: "Entretien avec Bernard Lahire"
-        credit: "Cairn.info"
-
-    comments_editorial: []

src/components/EditionToc.astro

@@ -1,29 +1,42 @@
 ---
 import { getCollection } from "astro:content";
 
-const { currentSlug } = Astro.props;
+const {
+  currentSlug,
+  collection = "archicrat-ia",
+  basePath = "/archicrat-ia",
+  label = "Table des matières"
+} = Astro.props;
 
-const entries = (await getCollection("archicratie"))
-  .filter((e) => e.slug.startsWith("archicrat-ia/"))
-  .sort((a, b) => (a.data.order ?? 0) - (b.data.order ?? 0));
+const slugOf = (entry) => String(entry.id).replace(/\.(md|mdx)$/i, "");
+const hrefOf = (entry) => `${basePath}/${slugOf(entry)}/`;
 
-// ✅ On route l’Essai-thèse sur /archicrat-ia/<slug-sans-prefix>/
-// (Astro trailingSlash = always → on garde le "/" final)
-const strip = (s) => String(s || "").replace(/^archicrat-ia\//, "");
-const href = (slug) => `/archicrat-ia/${strip(slug)}/`;
+const collator = new Intl.Collator("fr", { sensitivity: "base", numeric: true });
+
+const entries = [...await getCollection(collection)].sort((a, b) => {
+  const ao = Number(a.data.order ?? 9999);
+  const bo = Number(b.data.order ?? 9999);
+  if (ao !== bo) return ao - bo;
+
+  const at = String(a.data.title ?? a.data.term ?? slugOf(a));
+  const bt = String(b.data.title ?? b.data.term ?? slugOf(b));
+  return collator.compare(at, bt);
+});
 ---
 
-<nav class="toc-global" aria-label="Table des matières — ArchiCraT-IA">
+<nav class="toc-global" aria-label={label}>
   <div class="toc-global__head">
-    <div class="toc-global__title">Table des matières</div>
+    <div class="toc-global__title">{label}</div>
   </div>
 
   <ol class="toc-global__list">
     {entries.map((e) => {
-      const active = e.slug === currentSlug;
+      const slug = slugOf(e);
+      const active = slug === currentSlug;
+
       return (
         <li class={`toc-item ${active ? "is-active" : ""}`}>
-          <a class="toc-link" href={href(e.slug)} aria-current={active ? "page" : undefined}>
+          <a class="toc-link" href={hrefOf(e)} aria-current={active ? "page" : undefined}>
             <span class="toc-link__row">
               {active ? (
                 <span class="toc-active-indicator" aria-hidden="true">👉</span>
@@ -163,4 +176,4 @@ const href = (slug) => `/archicrat-ia/${strip(slug)}/`;
   const active = document.querySelector(".toc-global .toc-item.is-active");
   if (active) active.scrollIntoView({ block: "nearest" });
 })();
-</script>
+</script>

src/components/GlossaryAside.astro

@@ -0,0 +1,237 @@
+---
+import {
+  getGlossaryEntryAsideData,
+  getGlossaryPortalLinks,
+  hrefOfGlossaryEntry,
+  slugOfGlossaryEntry,
+} from "../lib/glossary";
+
+const {
+  currentEntry,
+  allEntries = [],
+} = Astro.props;
+
+const currentSlug = slugOfGlossaryEntry(currentEntry);
+
+const {
+  displayFamily,
+  displayDomain,
+  displayLevel,
+  showNoyau,
+  showSameFamily,
+  fondamentaux,
+  sameFamilyTitle,
+  sameFamilyEntries,
+  relationSections,
+  contextualTheory,
+} = getGlossaryEntryAsideData(currentEntry, allEntries);
+
+const portalLinks = getGlossaryPortalLinks();
+---
+
+<nav class="glossary-aside" aria-label="Navigation du glossaire">
+  <div class="glossary-aside__block glossary-aside__block--intro">
+    <a class="glossary-aside__back" href="/glossaire/">← Retour au glossaire</a>
+    <div class="glossary-aside__title">Glossaire archicratique</div>
+
+    <div class="glossary-aside__pills" aria-label="Repères de lecture">
+      <span class="glossary-aside__pill glossary-aside__pill--family">
+        {displayFamily}
+      </span>
+
+      {displayDomain && (
+        <span class="glossary-aside__pill">{displayDomain}</span>
+      )}
+
+      {displayLevel && (
+        <span class="glossary-aside__pill">{displayLevel}</span>
+      )}
+    </div>
+  </div>
+
+  <section class="glossary-aside__block">
+    <h2 class="glossary-aside__heading">Portails</h2>
+    <ul class="glossary-aside__list">
+      {portalLinks.map((item) => (
+        <li><a href={item.href}>{item.label}</a></li>
+      ))}
+    </ul>
+  </section>
+
+  {showNoyau && (
+    <section class="glossary-aside__block">
+      <h2 class="glossary-aside__heading">Noyau archicratique</h2>
+      <ul class="glossary-aside__list">
+        {fondamentaux.map((entry) => {
+          const active = slugOfGlossaryEntry(entry) === currentSlug;
+          return (
+            <li>
+              <a
+                href={hrefOfGlossaryEntry(entry)}
+                aria-current={active ? "page" : undefined}
+                class={active ? "is-active" : undefined}
+              >
+                {entry.data.term}
+              </a>
+            </li>
+          );
+        })}
+      </ul>
+    </section>
+  )}
+
+  {showSameFamily && (
+    <section class="glossary-aside__block">
+      <h2 class="glossary-aside__heading">{sameFamilyTitle}</h2>
+      <ul class="glossary-aside__list">
+        {sameFamilyEntries.map((entry) => {
+          const active = slugOfGlossaryEntry(entry) === currentSlug;
+          return (
+            <li>
+              <a
+                href={hrefOfGlossaryEntry(entry)}
+                aria-current={active ? "page" : undefined}
+                class={active ? "is-active" : undefined}
+              >
+                {entry.data.term}
+              </a>
+            </li>
+          );
+        })}
+      </ul>
+    </section>
+  )}
+
+  {relationSections.length > 0 && (
+    <section class="glossary-aside__block">
+      <h2 class="glossary-aside__heading">Autour de cette fiche</h2>
+
+      {relationSections.map((section) => (
+        <>
+          <h3 class="glossary-aside__subheading">{section.title}</h3>
+          <ul class="glossary-aside__list">
+            {section.items.map((entry) => (
+              <li><a href={hrefOfGlossaryEntry(entry)}>{entry.data.term}</a></li>
+            ))}
+          </ul>
+        </>
+      ))}
+    </section>
+  )}
+
+  {contextualTheory.length > 0 && (
+    <section class="glossary-aside__block">
+      <h2 class="glossary-aside__heading">Paysage théorique</h2>
+      <ul class="glossary-aside__list">
+        {contextualTheory.map((entry) => (
+          <li><a href={hrefOfGlossaryEntry(entry)}>{entry.data.term}</a></li>
+        ))}
+      </ul>
+    </section>
+  )}
+</nav>
+
+<style>
+  .glossary-aside{
+    display: flex;
+    flex-direction: column;
+    gap: 14px;
+  }
+
+  .glossary-aside__block{
+    border: 1px solid rgba(127,127,127,0.22);
+    border-radius: 16px;
+    padding: 14px;
+    background: rgba(127,127,127,0.05);
+  }
+
+  .glossary-aside__block--intro{
+    padding-top: 13px;
+    padding-bottom: 13px;
+  }
+
+  .glossary-aside__back{
+    display: inline-block;
+    margin-bottom: 10px;
+    font-size: 14px;
+    font-weight: 700;
+    line-height: 1.35;
+    text-decoration: none;
+  }
+
+  .glossary-aside__title{
+    font-size: 16px;
+    font-weight: 800;
+    letter-spacing: .2px;
+    line-height: 1.3;
+  }
+
+  .glossary-aside__pills{
+    display: flex;
+    flex-wrap: wrap;
+    gap: 7px;
+    margin-top: 10px;
+  }
+
+  .glossary-aside__pill{
+    display: inline-flex;
+    align-items: center;
+    padding: 5px 10px;
+    border: 1px solid rgba(127,127,127,0.24);
+    border-radius: 999px;
+    background: rgba(127,127,127,0.04);
+    font-size: 13px;
+    line-height: 1.35;
+    opacity: .92;
+  }
+
+  .glossary-aside__pill--family{
+    border-color: rgba(127,127,127,0.38);
+    font-weight: 800;
+  }
+
+  .glossary-aside__heading{
+    margin: 0 0 11px;
+    font-size: 14px;
+    font-weight: 800;
+    line-height: 1.35;
+    opacity: .94;
+  }
+
+  .glossary-aside__subheading{
+    margin: 13px 0 8px;
+    font-size: 12.5px;
+    font-weight: 800;
+    line-height: 1.35;
+    opacity: .82;
+    text-transform: uppercase;
+    letter-spacing: .04em;
+  }
+
+  .glossary-aside__list{
+    list-style: none;
+    margin: 0;
+    padding: 0;
+  }
+
+  .glossary-aside__list li{
+    margin: 7px 0;
+  }
+
+  .glossary-aside__list a{
+    text-decoration: none;
+    font-size: 14px;
+    line-height: 1.4;
+  }
+
+  .glossary-aside__list a.is-active{
+    font-weight: 800;
+  }
+
+  @media (prefers-color-scheme: dark){
+    .glossary-aside__block,
+    .glossary-aside__pill{
+      background: rgba(255,255,255,0.04);
+    }
+  }
+</style>

src/components/GlossaryCardGrid.astro

@@ -0,0 +1,83 @@
+---
+import { hrefOfGlossaryEntry, type GlossaryEntry } from "../lib/glossary";
+
+export interface Props {
+  entries?: GlossaryEntry[];
+  wide?: boolean;
+}
+
+const {
+  entries = [],
+  wide = false,
+} = Astro.props;
+---
+
+<div class="glossary-cards">
+  {entries.map((entry) => (
+    <a
+      class:list={[
+        "glossary-card",
+        wide && "glossary-card--wide",
+      ]}
+      href={hrefOfGlossaryEntry(entry)}
+    >
+      <strong>{entry.data.term}</strong>
+      <span>{entry.data.definitionShort}</span>
+    </a>
+  ))}
+</div>
+
+<style>
+  .glossary-cards{
+    display: grid;
+    grid-template-columns: repeat(auto-fit, minmax(220px, 1fr));
+    gap: 12px;
+    margin-top: 14px;
+  }
+
+  .glossary-card{
+    display: flex;
+    flex-direction: column;
+    gap: 8px;
+    padding: 14px 16px;
+    border: 1px solid var(--glossary-border);
+    border-radius: 18px;
+    background: var(--glossary-bg-soft);
+    text-decoration: none;
+    transition: transform 120ms ease, background 120ms ease, border-color 120ms ease;
+  }
+
+  .glossary-card:hover{
+    transform: translateY(-1px);
+    background: var(--glossary-bg-soft-strong);
+    border-color: rgba(0,217,255,0.16);
+    text-decoration: none;
+  }
+
+  .glossary-card--wide{
+    grid-column: 1 / -1;
+  }
+
+  .glossary-card strong{
+    color: var(--glossary-accent);
+    font-size: 1.04rem;
+    line-height: 1.28;
+  }
+
+  .glossary-card span{
+    color: inherit;
+    font-size: 1rem;
+    line-height: 1.5;
+    opacity: .94;
+  }
+
+  @media (prefers-color-scheme: dark){
+    .glossary-card{
+      background: rgba(255,255,255,0.04);
+    }
+
+    .glossary-card:hover{
+      background: rgba(255,255,255,0.07);
+    }
+  }
+</style>

src/components/GlossaryEntryBody.astro

@@ -0,0 +1,16 @@
+<div class="glossary-entry-body">
+  <slot />
+</div>
+
+<style>
+  .glossary-entry-body{
+    margin-bottom: 28px;
+  }
+
+  :global(.glossary-entry-body h2),
+  :global(.glossary-entry-body h3),
+  :global(.glossary-relations h2),
+  :global(.glossary-relations h3){
+    scroll-margin-top: calc(var(--sticky-offset-px, 96px) + 18px);
+  }
+</style>

src/components/GlossaryEntryHero.astro

@@ -0,0 +1,203 @@
+---
+interface Props {
+  term: string;
+  definitionShort: string;
+  displayFamily: string;
+  displayDomain?: string;
+  displayLevel?: string;
+  mobilizedAuthors?: string[];
+  comparisonTraditions?: string[];
+}
+
+const {
+  term,
+  definitionShort,
+  displayFamily,
+  displayDomain = "",
+  displayLevel = "",
+  mobilizedAuthors = [],
+  comparisonTraditions = [],
+} = Astro.props;
+
+const hasScholarlyMeta =
+  mobilizedAuthors.length > 0 ||
+  comparisonTraditions.length > 0;
+---
+
+<header class="glossary-entry-head" data-ge-hero>
+  <div class="glossary-entry-head__title">
+    <h1>{term}</h1>
+  </div>
+
+  <div class="glossary-entry-summary">
+    <p class="glossary-entry-dek">
+      <em>{definitionShort}</em>
+    </p>
+
+    <div class="glossary-entry-signals" aria-label="Repères de lecture">
+      <span class="glossary-pill glossary-pill--family">
+        <strong>Famille :</strong> {displayFamily}
+      </span>
+
+      {displayDomain && (
+        <span class="glossary-pill">
+          <strong>Domaine :</strong> {displayDomain}
+        </span>
+      )}
+
+      {displayLevel && (
+        <span class="glossary-pill">
+          <strong>Niveau :</strong> {displayLevel}
+        </span>
+      )}
+    </div>
+
+    {hasScholarlyMeta && (
+      <div class="glossary-entry-meta">
+        {mobilizedAuthors.length > 0 && (
+          <p>
+            <strong>Auteurs mobilisés :</strong> {mobilizedAuthors.join(" / ")}
+          </p>
+        )}
+
+        {comparisonTraditions.length > 0 && (
+          <p>
+            <strong>Traditions de comparaison :</strong> {comparisonTraditions.join(" / ")}
+          </p>
+        )}
+      </div>
+    )}
+  </div>
+</header>
+
+<style>
+  .glossary-entry-head{
+    position: sticky;
+    top: calc(var(--sticky-header-h, 0px) + var(--page-gap, 12px));
+    z-index: 11;
+    margin: 0 0 24px;
+    border: 1px solid rgba(127,127,127,0.18);
+    border-radius: 28px;
+    background:
+      linear-gradient(180deg, rgba(0,0,0,0.60), rgba(0,0,0,0.92)),
+      radial-gradient(900px 240px at 20% 0%, rgba(0,217,255,0.08), transparent 60%);
+    backdrop-filter: blur(10px);
+    -webkit-backdrop-filter: blur(10px);
+    overflow: hidden;
+    transition:
+      border-radius 180ms ease,
+      box-shadow 180ms ease,
+      border-color 180ms ease;
+  }
+
+  .glossary-entry-head__title{
+    padding: 18px 18px 16px;
+  }
+
+  .glossary-entry-head h1{
+    margin: 0;
+    font-size: clamp(2.2rem, 4vw, 3.15rem);
+    line-height: 1.02;
+    letter-spacing: -.04em;
+    font-weight: 850;
+  }
+
+  .glossary-entry-summary{
+    display: grid;
+    gap: 14px;
+    padding: 16px 18px 18px;
+    border-top: 1px solid rgba(127,127,127,0.14);
+    background: rgba(255,255,255,0.02);
+  }
+
+  .glossary-entry-dek{
+    margin: 0;
+    max-width: 76ch;
+    font-size: 1.04rem;
+    line-height: 1.55;
+    opacity: .94;
+  }
+
+  .glossary-entry-signals{
+    display: flex;
+    flex-wrap: wrap;
+    gap: 8px;
+    margin: 0;
+  }
+
+  .glossary-pill{
+    display: inline-flex;
+    align-items: center;
+    gap: 6px;
+    padding: 5px 10px;
+    border: 1px solid rgba(127,127,127,0.24);
+    border-radius: 999px;
+    background: rgba(127,127,127,0.05);
+    font-size: 13px;
+    line-height: 1.35;
+  }
+
+  .glossary-pill--family{
+    border-color: rgba(127,127,127,0.36);
+    font-weight: 700;
+  }
+
+  .glossary-entry-meta{
+    margin: 0;
+    padding: 10px 12px;
+    border: 1px solid rgba(127,127,127,0.18);
+    border-radius: 12px;
+    background: rgba(127,127,127,0.04);
+  }
+
+  .glossary-entry-meta p{
+    margin: 0;
+    font-size: 14px;
+    line-height: 1.5;
+  }
+
+  .glossary-entry-meta p + p{
+    margin-top: 6px;
+  }
+
+  @media (max-width: 720px){
+    .glossary-entry-signals{
+      gap: 6px;
+    }
+
+    .glossary-pill{
+      font-size: 12px;
+    }
+  }
+
+  @media (max-width: 860px){
+    .glossary-entry-head{
+      position: static;
+      border-radius: 22px;
+      margin-bottom: 20px;
+    }
+
+    .glossary-entry-head__title{
+      padding: 14px 14px 12px;
+    }
+
+    .glossary-entry-summary{
+      gap: 12px;
+      padding: 14px;
+    }
+
+    .glossary-entry-dek{
+      max-width: none;
+    }
+  }
+
+  @media (prefers-color-scheme: dark){
+    .glossary-entry-meta{
+      background: rgba(255,255,255,0.03);
+    }
+
+    .glossary-pill{
+      background: rgba(255,255,255,0.04);
+    }
+  }
+</style>

src/components/GlossaryEntryLegacyNote.astro

@@ -0,0 +1,31 @@
+---
+interface Props {
+  canonicalHref: string;
+  term: string;
+}
+
+const { canonicalHref, term } = Astro.props;
+---
+
+<p class="glossary-legacy-note">
+  Cette entrée a été renommée. L’intitulé canonique est :
+  <a href={canonicalHref}>{term}</a>.
+</p>
+
+<style>
+  .glossary-legacy-note{
+    padding: 10px 12px;
+    border: 1px solid rgba(127,127,127,0.22);
+    border-radius: 12px;
+    background: rgba(127,127,127,0.05);
+    font-size: 14px;
+    line-height: 1.45;
+    margin-bottom: 18px;
+  }
+
+  @media (prefers-color-scheme: dark){
+    .glossary-legacy-note{
+      background: rgba(255,255,255,0.04);
+    }
+  }
+</style>

src/components/GlossaryEntryStickySync.astro

@@ -0,0 +1,172 @@
+<script is:inline>
+  (() => {
+    const boot = () => {
+      const body = document.body;
+      const root = document.documentElement;
+      const hero = document.querySelector("[data-ge-hero]");
+      const follow = document.getElementById("reading-follow");
+      const mqMobile = window.matchMedia("(max-width: 860px)");
+
+      if (!body || !root || !hero || !follow) return;
+
+      const BODY_CLASS = "is-glossary-entry-page";
+      const FOLLOW_ON_CLASS = "glossary-entry-follow-on";
+
+      let lastHeight = -1;
+      let lastFollowOn = null;
+      let raf = 0;
+
+      body.classList.add(BODY_CLASS);
+
+      const heroHeight = () =>
+        Math.max(0, Math.round(hero.getBoundingClientRect().height || 0));
+
+      const computeFollowOn = () =>
+        !mqMobile.matches &&
+        follow.classList.contains("is-on") &&
+        follow.style.display !== "none" &&
+        follow.getAttribute("aria-hidden") !== "true";
+
+      const stripLocalSticky = () => {
+        document
+          .querySelectorAll(
+            ".glossary-entry-body h2, .glossary-entry-body h3, .glossary-relations h2, .glossary-relations h3"
+          )
+          .forEach((el) => {
+            el.classList.remove("is-sticky");
+            el.removeAttribute("data-sticky-active");
+          });
+      };
+
+      const applyLocalStickyHeight = () => {
+        const h = mqMobile.matches ? 0 : heroHeight();
+        if (h === lastHeight) return;
+        lastHeight = h;
+
+        if (typeof window.__archiSetLocalStickyHeight === "function") {
+          window.__archiSetLocalStickyHeight(h);
+        } else {
+          root.style.setProperty("--glossary-local-sticky-h", `${h}px`);
+        }
+      };
+
+      const syncFollowState = () => {
+        const on = computeFollowOn();
+        if (on === lastFollowOn) return;
+        lastFollowOn = on;
+        body.classList.toggle(FOLLOW_ON_CLASS, on);
+      };
+
+      const syncAll = () => {
+        stripLocalSticky();
+        syncFollowState();
+        applyLocalStickyHeight();
+      };
+
+      const schedule = () => {
+        if (raf) return;
+        raf = requestAnimationFrame(() => {
+          raf = 0;
+          syncAll();
+        });
+      };
+
+      const followObserver = new MutationObserver(schedule);
+      followObserver.observe(follow, {
+        attributes: true,
+        attributeFilter: ["class", "style", "aria-hidden"],
+        subtree: false,
+      });
+
+      const heroResizeObserver =
+        typeof ResizeObserver !== "undefined"
+          ? new ResizeObserver(schedule)
+          : null;
+
+      heroResizeObserver?.observe(hero);
+
+      window.addEventListener("resize", schedule);
+      window.addEventListener("pageshow", schedule);
+
+      if (document.fonts?.ready) {
+        document.fonts.ready.then(schedule).catch(() => {});
+      }
+
+      if (mqMobile.addEventListener) {
+        mqMobile.addEventListener("change", schedule);
+      } else if (mqMobile.addListener) {
+        mqMobile.addListener(schedule);
+      }
+
+      schedule();
+    };
+
+    if (document.readyState === "loading") {
+      document.addEventListener("DOMContentLoaded", boot, { once: true });
+    } else {
+      boot();
+    }
+  })();
+</script>
+
+<style>
+  :global(body.is-glossary-entry-page #reading-follow){
+    z-index: 10;
+  }
+
+  :global(body.is-glossary-entry-page.glossary-entry-follow-on .glossary-entry-head){
+    margin-bottom: 0;
+    border-bottom-left-radius: 0;
+    border-bottom-right-radius: 0;
+  }
+
+  :global(body.is-glossary-entry-page.glossary-entry-follow-on .glossary-entry-summary){
+    gap: 10px;
+    padding-top: 12px;
+    padding-bottom: 10px;
+  }
+
+  :global(body.is-glossary-entry-page.glossary-entry-follow-on .glossary-entry-signals){
+    gap: 6px;
+  }
+
+  :global(body.is-glossary-entry-page.glossary-entry-follow-on .glossary-entry-meta){
+    padding: 8px 10px;
+  }
+
+  :global(body.is-glossary-entry-page.glossary-entry-follow-on #reading-follow){
+    transform: translateY(-1px);
+  }
+
+  :global(body.is-glossary-entry-page.glossary-entry-follow-on #reading-follow .reading-follow__inner){
+    margin-top: -1px;
+    border-top-left-radius: 0;
+    border-top-right-radius: 0;
+  }
+
+  :global(body.is-glossary-entry-page .glossary-entry-body h2.is-sticky),
+  :global(body.is-glossary-entry-page .glossary-entry-body h2[data-sticky-active="true"]),
+  :global(body.is-glossary-entry-page .glossary-entry-body h3.is-sticky),
+  :global(body.is-glossary-entry-page .glossary-entry-body h3[data-sticky-active="true"]),
+  :global(body.is-glossary-entry-page .glossary-relations h2.is-sticky),
+  :global(body.is-glossary-entry-page .glossary-relations h2[data-sticky-active="true"]),
+  :global(body.is-glossary-entry-page .glossary-relations h3.is-sticky),
+  :global(body.is-glossary-entry-page .glossary-relations h3[data-sticky-active="true"]){
+    position: static !important;
+    top: auto !important;
+    z-index: auto !important;
+    padding: 0 !important;
+    border: 0 !important;
+    background: transparent !important;
+    box-shadow: none !important;
+    backdrop-filter: none !important;
+    -webkit-backdrop-filter: none !important;
+  }
+
+  @media (max-width: 860px){
+    :global(body.is-glossary-entry-page.glossary-entry-follow-on .glossary-entry-head){
+      margin-bottom: 20px;
+      border-radius: 22px;
+    }
+  }
+</style>

src/components/GlossaryHomeAside.astro

@@ -0,0 +1,143 @@
+---
+import {
+  getFondamentaux,
+  getGlossaryHomeStats,
+  getGlossaryPortalLinks,
+  hrefOfGlossaryEntry,
+} from "../lib/glossary";
+
+const {
+  allEntries = [],
+} = Astro.props;
+
+const fondamentaux = getFondamentaux(allEntries);
+const portalLinks = getGlossaryPortalLinks();
+
+const {
+  totalEntries,
+  paradigmesCount,
+  doctrinesCount,
+  metaRegimesCount,
+} = getGlossaryHomeStats(allEntries);
+---
+
+<nav class="glossary-home-aside" aria-label="Navigation du portail du glossaire">
+  <div class="glossary-home-aside__block glossary-home-aside__block--intro">
+    <div class="glossary-home-aside__title">Glossaire archicratique</div>
+    <div class="glossary-home-aside__meta">
+      portail de lecture · cartographie conceptuelle
+    </div>
+
+    <div class="glossary-home-aside__pills" aria-label="Repères de navigation">
+      <span class="glossary-home-aside__pill">{totalEntries} entrées</span>
+      <span class="glossary-home-aside__pill">{metaRegimesCount} méta-régimes</span>
+      <span class="glossary-home-aside__pill">
+        {doctrinesCount} doctrine{doctrinesCount > 1 ? "s" : ""} · {paradigmesCount} paradigme{paradigmesCount > 1 ? "s" : ""}
+      </span>
+    </div>
+  </div>
+
+  <section class="glossary-home-aside__block">
+    <h2 class="glossary-home-aside__heading">Parcours du glossaire</h2>
+    <ul class="glossary-home-aside__list">
+      {portalLinks.map((item) => (
+        <li><a href={item.href}>{item.label}</a></li>
+      ))}
+    </ul>
+  </section>
+
+  {fondamentaux.length > 0 && (
+    <section class="glossary-home-aside__block">
+      <h2 class="glossary-home-aside__heading">Noyau archicratique</h2>
+      <ul class="glossary-home-aside__list">
+        {fondamentaux.map((entry) => (
+          <li><a href={hrefOfGlossaryEntry(entry)}>{entry.data.term}</a></li>
+        ))}
+      </ul>
+    </section>
+  )}
+</nav>
+
+<style>
+  .glossary-home-aside{
+    display: flex;
+    flex-direction: column;
+    gap: 14px;
+  }
+
+  .glossary-home-aside__block{
+    border: 1px solid rgba(127,127,127,0.22);
+    border-radius: 16px;
+    padding: 14px;
+    background: rgba(127,127,127,0.05);
+  }
+
+  .glossary-home-aside__block--intro{
+    padding-top: 13px;
+    padding-bottom: 13px;
+  }
+
+  .glossary-home-aside__title{
+    font-size: 16px;
+    font-weight: 800;
+    letter-spacing: .2px;
+    line-height: 1.3;
+  }
+
+  .glossary-home-aside__meta{
+    margin-top: 8px;
+    font-size: 13px;
+    line-height: 1.4;
+    opacity: .8;
+  }
+
+  .glossary-home-aside__pills{
+    display: flex;
+    flex-wrap: wrap;
+    gap: 7px;
+    margin-top: 11px;
+  }
+
+  .glossary-home-aside__pill{
+    display: inline-flex;
+    align-items: center;
+    padding: 5px 10px;
+    border: 1px solid rgba(127,127,127,0.24);
+    border-radius: 999px;
+    background: rgba(127,127,127,0.04);
+    font-size: 13px;
+    line-height: 1.35;
+    opacity: .92;
+  }
+
+  .glossary-home-aside__heading{
+    margin: 0 0 11px;
+    font-size: 14px;
+    font-weight: 800;
+    line-height: 1.35;
+    opacity: .94;
+  }
+
+  .glossary-home-aside__list{
+    list-style: none;
+    margin: 0;
+    padding: 0;
+  }
+
+  .glossary-home-aside__list li{
+    margin: 7px 0;
+  }
+
+  .glossary-home-aside__list a{
+    text-decoration: none;
+    font-size: 14px;
+    line-height: 1.4;
+  }
+
+  @media (prefers-color-scheme: dark){
+    .glossary-home-aside__block,
+    .glossary-home-aside__pill{
+      background: rgba(255,255,255,0.04);
+    }
+  }
+</style>

src/components/GlossaryHomeHero.astro

@@ -0,0 +1,103 @@
+---
+export interface Props {
+  kicker?: string;
+  title?: string;
+  intro?: string;
+}
+
+const {
+  kicker = "Référentiel terminologique",
+  title = "Glossaire archicratique",
+  intro = "Ce glossaire n’est pas seulement un index de définitions. Il constitue une porte d’entrée dans la pensée archicratique : une cartographie raisonnée des concepts fondamentaux, des scènes, des dynamiques et des méta-régimes à partir desquels une société peut être décrite comme organisation de tensions et recherche de co-viabilité.",
+} = Astro.props;
+---
+
+<header class="glossary-hero" id="glossary-hero">
+  <p class="glossary-kicker">{kicker}</p>
+  <h1>{title}</h1>
+  <p class="glossary-intro">{intro}</p>
+  <h2
+    class="glossary-hero-follow"
+    id="glossary-hero-follow"
+    aria-hidden="true"
+  ></h2>
+</header>
+
+<style>
+  .glossary-hero{
+    position: sticky;
+    top: var(--glossary-sticky-top);
+    z-index: 12;
+    margin-bottom: 28px;
+    padding: 14px 16px 18px;
+    border: 1px solid rgba(127,127,127,0.18);
+    border-radius: 28px;
+    background:
+      linear-gradient(180deg, rgba(0,0,0,0.60), rgba(0,0,0,0.90)),
+      radial-gradient(900px 240px at 20% 0%, rgba(0,217,255,0.08), transparent 60%);
+    transition:
+      background 300ms cubic-bezier(.22,.8,.22,1),
+      border-color 300ms cubic-bezier(.22,.8,.22,1),
+      box-shadow 300ms cubic-bezier(.22,.8,.22,1);
+    backdrop-filter: blur(10px);
+    -webkit-backdrop-filter: blur(10px);
+    display: grid;
+    row-gap: 12px;
+  }
+
+  .glossary-kicker{
+    margin: 0;
+    font-size: 12px;
+    letter-spacing: .12em;
+    text-transform: uppercase;
+    opacity: .72;
+  }
+
+  .glossary-hero h1{
+    margin: 0;
+    font-size: clamp(2.2rem, 4vw, 3.15rem);
+    line-height: 1.02;
+    letter-spacing: -.04em;
+    font-weight: 850;
+  }
+
+  .glossary-intro{
+    margin: 0;
+    max-width: 72ch;
+    font-size: 1.05rem;
+    line-height: 1.55;
+    opacity: .94;
+  }
+
+  .glossary-hero-follow{
+    margin: 2px 0 0;
+    min-height: var(--glossary-follow-height);
+    display: flex;
+    align-items: flex-end;
+    opacity: 0;
+    transform: translateY(10px) scale(.985);
+    filter: blur(6px);
+    transition:
+      opacity 220ms cubic-bezier(.22,1,.36,1),
+      transform 320ms cubic-bezier(.22,1,.36,1),
+      filter 320ms cubic-bezier(.22,1,.36,1);
+    pointer-events: none;
+    white-space: nowrap;
+    overflow: hidden;
+    text-overflow: ellipsis;
+    will-change: opacity, transform, filter;
+  }
+
+  .glossary-hero-follow.is-visible{
+    opacity: 1;
+    transform: translateY(0) scale(1);
+    filter: blur(0);
+  }
+
+  @media (max-width: 760px){
+    .glossary-hero{
+      top: calc(var(--glossary-sticky-top) - 2px);
+      padding: 12px 14px 16px;
+    }
+  }
+</style>

src/components/GlossaryHomeSection.astro

@@ -0,0 +1,109 @@
+---
+export interface Props {
+  id?: string;
+  title: string;
+  intro?: string;
+  followSection?: string;
+  ctaHref?: string;
+  ctaLabel?: string;
+}
+
+const {
+  id,
+  title,
+  intro,
+  followSection,
+  ctaHref,
+  ctaLabel,
+} = Astro.props;
+
+const resolvedFollowSection = (followSection || title || "").trim();
+const showCta = Boolean(ctaHref && ctaLabel);
+---
+
+<section id={id} class="glossary-section">
+  <div class="glossary-section__head">
+    <div>
+      <h2 data-follow-section={resolvedFollowSection}>{title}</h2>
+
+      {intro && (
+        <p class="glossary-intro">{intro}</p>
+      )}
+    </div>
+
+    {showCta && (
+      <a class="glossary-cta" href={ctaHref}>
+        {ctaLabel}
+      </a>
+    )}
+  </div>
+
+  <slot />
+</section>
+
+<style>
+  .glossary-section{
+    margin-top: 42px;
+    scroll-margin-top: calc(var(--glossary-sticky-top) + 190px);
+  }
+
+  .glossary-section__head{
+    display: flex;
+    justify-content: space-between;
+    align-items: start;
+    gap: 16px;
+    flex-wrap: wrap;
+    margin-bottom: 14px;
+  }
+
+  .glossary-section h2{
+    margin: 0;
+    font-size: clamp(2rem, 3vw, 2.55rem);
+    line-height: 1.06;
+    letter-spacing: -.03em;
+    font-weight: 800;
+  }
+
+  .glossary-intro{
+    margin: 0;
+    max-width: 72ch;
+    font-size: 1.05rem;
+    line-height: 1.55;
+    opacity: .94;
+  }
+
+  .glossary-section__head .glossary-intro{
+    margin-top: 10px;
+  }
+
+  .glossary-cta{
+    display: inline-flex;
+    align-items: center;
+    justify-content: center;
+    min-height: 40px;
+    border: 1px solid var(--glossary-border-strong);
+    border-radius: 999px;
+    padding: 7px 14px;
+    color: var(--glossary-accent);
+    text-decoration: none;
+    white-space: nowrap;
+    transition: transform 120ms ease, background 120ms ease;
+  }
+
+  .glossary-cta:hover{
+    background: var(--glossary-bg-soft-strong);
+    text-decoration: none;
+    transform: translateY(-1px);
+  }
+
+  @media (max-width: 760px){
+    .glossary-section__head{
+      flex-direction: column;
+      align-items: stretch;
+    }
+
+    .glossary-cta{
+      width: fit-content;
+    }
+  }
+</style>

src/components/GlossaryPortalAside.astro

@@ -0,0 +1,122 @@
+---
+interface LinkItem {
+  href: string;
+  label: string;
+}
+
+interface Props {
+  ariaLabel: string;
+  title: string;
+  meta?: string;
+  backHref?: string;
+  backLabel?: string;
+  pageItems?: LinkItem[];
+  usefulLinks?: LinkItem[];
+}
+
+const {
+  ariaLabel,
+  title,
+  meta,
+  backHref = "/glossaire/",
+  backLabel = "← Retour au glossaire",
+  pageItems = [],
+  usefulLinks = [],
+} = Astro.props;
+---
+
+<nav class="glossary-portal-aside" aria-label={ariaLabel}>
+  <div class="glossary-portal-aside__block">
+    <a class="glossary-portal-aside__back" href={backHref}>{backLabel}</a>
+    <div class="glossary-portal-aside__title">{title}</div>
+    {meta && <div class="glossary-portal-aside__meta">{meta}</div>}
+  </div>
+
+  {pageItems.length > 0 && (
+    <div class="glossary-portal-aside__block">
+      <h2 class="glossary-portal-aside__heading">Dans cette page</h2>
+      <ul class="glossary-portal-aside__list">
+        {pageItems.map((item) => (
+          <li><a href={item.href}>{item.label}</a></li>
+        ))}
+      </ul>
+    </div>
+  )}
+
+  {usefulLinks.length > 0 && (
+    <div class="glossary-portal-aside__block">
+      <h2 class="glossary-portal-aside__heading">Renvois utiles</h2>
+      <ul class="glossary-portal-aside__list">
+        {usefulLinks.map((item) => (
+          <li><a href={item.href}>{item.label}</a></li>
+        ))}
+      </ul>
+    </div>
+  )}
+</nav>
+
+<style>
+  .glossary-portal-aside{
+    display: flex;
+    flex-direction: column;
+    gap: 14px;
+  }
+
+  .glossary-portal-aside__block{
+    border: 1px solid rgba(127,127,127,0.22);
+    border-radius: 16px;
+    padding: 12px;
+    background: rgba(127,127,127,0.05);
+  }
+
+  .glossary-portal-aside__back{
+    display: inline-block;
+    margin-bottom: 8px;
+    font-size: 13px;
+    font-weight: 700;
+    text-decoration: none;
+  }
+
+  .glossary-portal-aside__title{
+    font-size: 14px;
+    font-weight: 800;
+    letter-spacing: .2px;
+    line-height: 1.25;
+  }
+
+  .glossary-portal-aside__meta{
+    margin-top: 8px;
+    font-size: 12px;
+    line-height: 1.35;
+    opacity: .78;
+  }
+
+  .glossary-portal-aside__heading{
+    margin: 0 0 10px;
+    font-size: 13px;
+    font-weight: 800;
+    opacity: .9;
+  }
+
+  .glossary-portal-aside__list{
+    list-style: none;
+    margin: 0;
+    padding: 0;
+  }
+
+  .glossary-portal-aside__list li{
+    margin: 6px 0;
+  }
+
+  .glossary-portal-aside__list a{
+    text-decoration: none;
+    font-size: 13px;
+    line-height: 1.3;
+  }
+
+  @media (prefers-color-scheme: dark){
+    .glossary-portal-aside__block{
+      background: rgba(255,255,255,0.04);
+    }
+  }
+</style>

src/components/GlossaryPortalCta.astro

@@ -0,0 +1,87 @@
+---
+export interface Props {
+  href: string;
+  label: string;
+  icon?: string;
+  className?: string;
+}
+
+const {
+  href,
+  label,
+  icon = "↗",
+  className,
+} = Astro.props;
+---
+
+<a class:list={["glossary-portal-cta", className]} href={href}>
+  <span>{label}</span>
+  <span aria-hidden="true">{icon}</span>
+</a>
+
+<style>
+  .glossary-portal-cta{
+    display: inline-flex;
+    align-items: center;
+    justify-content: center;
+    gap: 8px;
+    min-height: 40px;
+    padding: 0 14px;
+    border: 1px solid rgba(0,217,255,0.24);
+    border-radius: 999px;
+    background:
+      linear-gradient(180deg, rgba(0,217,255,0.10), rgba(0,217,255,0.04)),
+      rgba(127,127,127,0.06);
+    box-shadow:
+      inset 0 1px 0 rgba(255,255,255,0.05),
+      0 0 0 1px rgba(0,217,255,0.04);
+    text-decoration: none;
+    font-size: 12px;
+    font-weight: 800;
+    letter-spacing: .01em;
+    white-space: nowrap;
+    transition:
+      transform 120ms ease,
+      background 120ms ease,
+      border-color 120ms ease,
+      box-shadow 120ms ease;
+  }
+
+  .glossary-portal-cta:hover{
+    transform: translateY(-1px);
+    border-color: rgba(0,217,255,0.34);
+    background:
+      linear-gradient(180deg, rgba(0,217,255,0.14), rgba(0,217,255,0.06)),
+      rgba(127,127,127,0.08);
+    box-shadow:
+      inset 0 1px 0 rgba(255,255,255,0.06),
+      0 0 0 1px rgba(0,217,255,0.08),
+      0 10px 28px rgba(0,0,0,0.18);
+    text-decoration: none;
+  }
+
+  .glossary-portal-cta:focus-visible{
+    outline: 2px solid rgba(0,217,255,0.28);
+    outline-offset: 4px;
+  }
+
+  @media (max-width: 720px){
+    .glossary-portal-cta{
+      width: 100%;
+    }
+  }
+
+  @media (prefers-color-scheme: dark){
+    .glossary-portal-cta{
+      background:
+        linear-gradient(180deg, rgba(0,217,255,0.12), rgba(0,217,255,0.05)),
+        rgba(255,255,255,0.04);
+    }
+
+    .glossary-portal-cta:hover{
+      background:
+        linear-gradient(180deg, rgba(0,217,255,0.16), rgba(0,217,255,0.07)),
+        rgba(255,255,255,0.06);
+    }
+  }
+</style>

src/components/GlossaryPortalGrid.astro

@@ -0,0 +1,91 @@
+---
+export type GlossaryPortalGridItem = {
+  href: string;
+  title: string;
+  description: string;
+  meta: string;
+};
+
+export interface Props {
+  items?: GlossaryPortalGridItem[];
+  secondary?: boolean;
+}
+
+const {
+  items = [],
+  secondary = false,
+} = Astro.props;
+---
+
+<div
+  class:list={[
+    "glossary-portals",
+    secondary && "glossary-portals--secondary",
+  ]}
+>
+  {items.map((item) => (
+    <a class="glossary-portal-card" href={item.href}>
+      <strong>{item.title}</strong>
+      <span>{item.description}</span>
+      <small>{item.meta}</small>
+    </a>
+  ))}
+</div>
+
+<style>
+  .glossary-portals{
+    display: grid;
+    grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
+    gap: 14px;
+    margin-top: 14px;
+  }
+
+  .glossary-portal-card{
+    display: flex;
+    flex-direction: column;
+    gap: 8px;
+    padding: 16px 18px;
+    border: 1px solid var(--glossary-border);
+    border-radius: 18px;
+    background: var(--glossary-bg-soft);
+    text-decoration: none;
+    transition: transform 120ms ease, background 120ms ease, border-color 120ms ease;
+  }
+
+  .glossary-portal-card:hover{
+    transform: translateY(-1px);
+    background: var(--glossary-bg-soft-strong);
+    border-color: rgba(0,217,255,0.16);
+    text-decoration: none;
+  }
+
+  .glossary-portal-card strong{
+    color: var(--glossary-accent);
+    font-size: 1.08rem;
+    line-height: 1.28;
+  }
+
+  .glossary-portal-card span{
+    color: inherit;
+    font-size: 1rem;
+    line-height: 1.5;
+    opacity: .94;
+  }
+
+  .glossary-portal-card small{
+    color: var(--glossary-accent);
+    font-size: .94rem;
+    line-height: 1.35;
+    opacity: .9;
+  }
+
+  @media (prefers-color-scheme: dark){
+    .glossary-portal-card{
+      background: rgba(255,255,255,0.04);
+    }
+
+    .glossary-portal-card:hover{
+      background: rgba(255,255,255,0.07);
+    }
+  }
+</style>

src/components/GlossaryPortalHero.astro

@@ -0,0 +1,190 @@
+---
+interface Props {
+  prefix: string;
+  kicker: string;
+  title: string;
+  intro: string;
+  moreParagraphs?: string[];
+  introMaxWidth?: string;
+  followIntroMaxWidth?: string;
+  moreMaxHeight?: string;
+}
+
+const {
+  prefix,
+  kicker,
+  title,
+  intro,
+  moreParagraphs = [],
+  introMaxWidth = "72ch",
+  followIntroMaxWidth = "68ch",
+  moreMaxHeight = "18rem",
+} = Astro.props;
+---
+
+<div
+  class="glossary-portal-hero glossary-page-hero"
+  data-glossary-portal-hero
+  style={`--portal-hero-intro-max-w:${introMaxWidth}; --portal-hero-follow-intro-max-w:${followIntroMaxWidth}; --portal-hero-more-max-h:${moreMaxHeight};`}
+>
+  <p class="glossary-portal-hero__kicker">{kicker}</p>
+  <h1>{title}</h1>
+
+  <p class="glossary-portal-hero__intro">
+    {intro}
+  </p>
+
+  {moreParagraphs.length > 0 && (
+    <div class="glossary-portal-hero__collapsible">
+      <div
+        class="glossary-portal-hero__more"
+        id={`${prefix}-hero-more`}
+        data-glossary-portal-more
+        aria-hidden="false"
+      >
+        {moreParagraphs.map((paragraph) => (
+          <p class="glossary-portal-hero__intro">{paragraph}</p>
+        ))}
+      </div>
+
+      <button
+        class="glossary-portal-hero__toggle"
+        id={`${prefix}-hero-toggle`}
+        data-glossary-portal-toggle
+        type="button"
+        aria-controls={`${prefix}-hero-more`}
+        aria-expanded="false"
+        hidden
+      >
+        lire la suite
+      </button>
+    </div>
+  )}
+</div>
+
+<style>
+  .glossary-portal-hero{
+    position: sticky;
+    top: calc(var(--sticky-header-h, 0px) + var(--page-gap, 12px));
+    z-index: 11;
+    margin: 0 0 24px;
+    padding: 18px 18px 20px;
+    border: 1px solid rgba(127,127,127,0.18);
+    border-radius: 28px;
+    background:
+      linear-gradient(180deg, rgba(0,0,0,0.60), rgba(0,0,0,0.92)),
+      radial-gradient(900px 240px at 20% 0%, rgba(0,217,255,0.08), transparent 60%);
+    backdrop-filter: blur(10px);
+    -webkit-backdrop-filter: blur(10px);
+    display: grid;
+    row-gap: 14px;
+    transition:
+      margin-bottom 180ms ease,
+      border-radius 180ms ease,
+      padding 180ms ease,
+      row-gap 180ms ease;
+  }
+
+  .glossary-portal-hero__kicker{
+    margin: 0;
+    font-size: 12px;
+    letter-spacing: .08em;
+    text-transform: uppercase;
+    opacity: .72;
+  }
+
+  .glossary-portal-hero h1{
+    margin: 0;
+    font-size: clamp(2.2rem, 4vw, 3.15rem);
+    line-height: 1.02;
+    letter-spacing: -.04em;
+    font-weight: 850;
+    transition: font-size 180ms ease;
+  }
+
+  .glossary-portal-hero__intro{
+    margin: 0;
+    max-width: var(--portal-hero-intro-max-w);
+    font-size: 1.04rem;
+    line-height: 1.55;
+    opacity: .94;
+    transition:
+      font-size 180ms ease,
+      line-height 180ms ease,
+      max-width 180ms ease;
+  }
+
+  .glossary-portal-hero__collapsible{
+    display: grid;
+    row-gap: 6px;
+  }
+
+  .glossary-portal-hero__more{
+    display: grid;
+    row-gap: 14px;
+    max-height: var(--portal-hero-more-max-h);
+    overflow: hidden;
+    opacity: 1;
+    transition:
+      max-height 220ms ease,
+      opacity 180ms ease;
+  }
+
+  .glossary-portal-hero__toggle{
+    display: none;
+    align-self: flex-start;
+    width: fit-content;
+    margin: 0;
+    padding: 0;
+    border: 0;
+    background: transparent;
+    color: inherit;
+    font: inherit;
+    font-size: 11px;
+    line-height: 1.2;
+    letter-spacing: .01em;
+    opacity: .56;
+    cursor: pointer;
+    text-decoration: underline;
+    text-underline-offset: .12em;
+    text-decoration-thickness: 1px;
+  }
+
+  .glossary-portal-hero__toggle:hover{
+    opacity: .84;
+  }
+
+  .glossary-portal-hero__toggle:focus-visible{
+    outline: 2px solid rgba(0,217,255,0.24);
+    outline-offset: 4px;
+    border-radius: 4px;
+  }
+
+  .glossary-portal-hero__toggle[hidden]{
+    display: none !important;
+  }
+
+  @media (max-width: 860px){
+    .glossary-portal-hero{
+      position: static;
+      border-radius: 22px;
+      margin-bottom: 20px;
+      padding: 14px 14px 16px;
+      row-gap: 12px;
+    }
+
+    .glossary-portal-hero__intro{
+      max-width: none;
+    }
+
+    .glossary-portal-hero__more{
+      max-height: none;
+      opacity: 1;
+      overflow: visible;
+    }
+
+    .glossary-portal-hero__toggle{
+      display: none !important;
+    }
+  }
+</style>

src/components/GlossaryPortalPanel.astro

@@ -0,0 +1,96 @@
+---
+export interface Props {
+  id?: string;
+  title: string;
+  count?: string;
+  intro?: string;
+  surface?: boolean;
+  className?: string;
+}
+
+const {
+  id,
+  title,
+  count,
+  intro,
+  surface = false,
+  className,
+} = Astro.props;
+---
+
+<div
+  class:list={[
+    "glossary-portal-panel",
+    surface && "glossary-portal-panel--surface",
+    className,
+  ]}
+>
+  <div class="glossary-portal-panel__head">
+    <h3 id={id}>{title}</h3>
+    {count && <span class="glossary-portal-panel__count">{count}</span>}
+  </div>
+
+  {intro && <p class="glossary-portal-panel__intro">{intro}</p>}
+
+  <slot />
+</div>
+
+<style>
+  .glossary-portal-panel{
+    display: grid;
+    gap: 12px;
+  }
+
+  .glossary-portal-panel--surface{
+    padding: 18px 18px 16px;
+    border: 1px solid var(--glossary-border, rgba(127,127,127,0.18));
+    border-radius: 18px;
+    background:
+      linear-gradient(180deg, rgba(255,255,255,0.02), rgba(255,255,255,0.01)),
+      var(--glossary-bg-soft, rgba(127,127,127,0.035));
+  }
+
+  .glossary-portal-panel__head{
+    display: flex;
+    align-items: baseline;
+    justify-content: space-between;
+    gap: 12px;
+    flex-wrap: wrap;
+  }
+
+  .glossary-portal-panel__head h3{
+    margin: 0;
+    font-size: 15px;
+    line-height: 1.3;
+    scroll-margin-top: calc(var(--sticky-offset-px, 96px) + 36px);
+  }
+
+  .glossary-portal-panel__count{
+    display: inline-flex;
+    align-items: center;
+    min-height: 24px;
+    padding: 0 10px;
+    border: 1px solid rgba(127,127,127,0.22);
+    border-radius: 999px;
+    font-size: 12px;
+    line-height: 1.2;
+    opacity: .78;
+    white-space: nowrap;
+  }
+
+  .glossary-portal-panel__intro{
+    max-width: 78ch;
+    margin: 0;
+    font-size: 14px;
+    line-height: 1.5;
+    opacity: .9;
+  }
+
+  @media (prefers-color-scheme: dark){
+    .glossary-portal-panel--surface{
+      background:
+        linear-gradient(180deg, rgba(255,255,255,0.02), rgba(255,255,255,0.01)),
+        rgba(255,255,255,0.04);
+    }
+  }
+</style>

src/components/GlossaryPortalSection.astro

@@ -0,0 +1,67 @@
+---
+interface Props {
+  id: string;
+  title: string;
+  count?: string;
+  intro?: string;
+  final?: boolean;
+  className?: string;
+}
+
+const {
+  id,
+  title,
+  count,
+  intro,
+  final = false,
+  className,
+} = Astro.props;
+---
+
+<section class:list={["glossary-portal-section", final && "glossary-portal-section--final", className]}>
+  <div class="glossary-portal-section__head">
+    <h2 id={id}>{title}</h2>
+    {count && <span class="glossary-portal-section__count">{count}</span>}
+  </div>
+
+  {intro && <p class="glossary-portal-section__intro">{intro}</p>}
+
+  <slot />
+</section>
+
+<style>
+  .glossary-portal-section{
+    margin-top: 34px;
+    scroll-margin-top: calc(var(--sticky-offset-px, 96px) + 28px);
+  }
+
+  .glossary-portal-section h2{
+    scroll-margin-top: calc(var(--sticky-offset-px, 96px) + 28px);
+  }
+
+  .glossary-portal-section__head{
+    display: flex;
+    align-items: baseline;
+    justify-content: space-between;
+    gap: 12px;
+    flex-wrap: wrap;
+    margin-bottom: 10px;
+    position: static;
+  }
+
+  .glossary-portal-section__count{
+    font-size: 13px;
+    opacity: .72;
+    white-space: nowrap;
+  }
+
+  .glossary-portal-section__intro{
+    max-width: 78ch;
+    margin: 0;
+    opacity: .92;
+  }
+
+  .glossary-portal-section--final{
+    margin-top: 42px;
+  }
+</style>

src/components/GlossaryPortalStickySync.astro

@@ -0,0 +1,294 @@
+---
+interface Props {
+  heroMoreId: string;
+  heroToggleId: string;
+  sectionHeadSelector?: string;
+  mobileBreakpoint?: number;
+  autoCollapseDelta?: number;
+}
+
+const {
+  heroMoreId,
+  heroToggleId,
+  sectionHeadSelector = ".glossary-portal-section__head",
+  mobileBreakpoint = 860,
+  autoCollapseDelta = 160,
+} = Astro.props;
+---
+
+<script
+  is:inline
+  define:vars={{ heroMoreId, heroToggleId, sectionHeadSelector, mobileBreakpoint, autoCollapseDelta }}
+>
+  (() => {
+    const boot = () => {
+      const body = document.body;
+      const root = document.documentElement;
+      const hero = document.querySelector("[data-glossary-portal-hero]");
+      const follow = document.getElementById("reading-follow");
+      const heroMore = document.getElementById(heroMoreId);
+      const heroToggle = document.getElementById(heroToggleId);
+
+      if (!body || !root || !hero || !follow) return;
+
+      const BODY_CLASS = "is-glossary-portal-page";
+      const FOLLOW_ON_CLASS = "glossary-portal-follow-on";
+      const EXPANDED_CLASS = "glossary-portal-hero-expanded";
+      const mqMobile = window.matchMedia(`(max-width: ${mobileBreakpoint}px)`);
+
+      let expandedAtY = null;
+      let lastScrollY = window.scrollY || 0;
+      let raf = 0;
+
+      body.classList.add(BODY_CLASS);
+
+      const heroHeight = () =>
+        Math.max(0, Math.round(hero.getBoundingClientRect().height || 0));
+
+      const stripLocalSticky = () => {
+        document.querySelectorAll(sectionHeadSelector).forEach((el) => {
+          el.classList.remove("is-sticky");
+          el.removeAttribute("data-sticky-active");
+        });
+      };
+
+      const computeFollowOn = () =>
+        !mqMobile.matches &&
+        follow.classList.contains("is-on") &&
+        follow.style.display !== "none" &&
+        follow.getAttribute("aria-hidden") !== "true";
+
+      const applyLocalStickyHeight = () => {
+        const h = mqMobile.matches ? 0 : heroHeight();
+
+        if (typeof window.__archiSetLocalStickyHeight === "function") {
+          window.__archiSetLocalStickyHeight(h);
+        } else {
+          root.style.setProperty("--glossary-local-sticky-h", `${h}px`);
+        }
+      };
+
+      const syncFollowState = () => {
+        const on = computeFollowOn();
+        body.classList.toggle(FOLLOW_ON_CLASS, on);
+        return on;
+      };
+
+      const collapseHero = () => {
+        if (!body.classList.contains(EXPANDED_CLASS)) return;
+
+        body.classList.remove(EXPANDED_CLASS);
+        expandedAtY = null;
+
+        if (heroMore) {
+          heroMore.setAttribute("aria-hidden", "true");
+        }
+
+        if (heroToggle) {
+          heroToggle.hidden = false;
+          heroToggle.setAttribute("aria-expanded", "false");
+        }
+
+        try {
+          window.__archiUpdateFollow?.();
+        } catch {}
+
+        schedule();
+      };
+
+      const expandHero = () => {
+        body.classList.add(EXPANDED_CLASS);
+        expandedAtY = window.scrollY || 0;
+
+        if (heroMore) {
+          heroMore.setAttribute("aria-hidden", "false");
+        }
+
+        if (heroToggle) {
+          heroToggle.hidden = true;
+          heroToggle.setAttribute("aria-expanded", "true");
+        }
+
+        try {
+          window.__archiUpdateFollow?.();
+        } catch {}
+
+        schedule();
+      };
+
+      const syncHeroState = () => {
+        const followOn = computeFollowOn();
+        const expanded = body.classList.contains(EXPANDED_CLASS);
+        const collapsed = followOn && !expanded;
+
+        if (!followOn || mqMobile.matches) {
+          body.classList.remove(EXPANDED_CLASS);
+          expandedAtY = null;
+
+          if (heroMore) {
+            heroMore.setAttribute("aria-hidden", "false");
+          }
+
+          if (heroToggle) {
+            heroToggle.hidden = true;
+            heroToggle.setAttribute("aria-expanded", "false");
+          }
+
+          return;
+        }
+
+        if (heroMore) {
+          heroMore.setAttribute("aria-hidden", collapsed ? "true" : "false");
+        }
+
+        if (heroToggle) {
+          heroToggle.hidden = !collapsed;
+          heroToggle.setAttribute("aria-expanded", expanded ? "true" : "false");
+        }
+      };
+
+      const maybeAutoCollapseOnScroll = () => {
+        if (mqMobile.matches) {
+          lastScrollY = window.scrollY || 0;
+          return;
+        }
+
+        if (!computeFollowOn()) {
+          lastScrollY = window.scrollY || 0;
+          return;
+        }
+
+        if (!body.classList.contains(EXPANDED_CLASS)) {
+          lastScrollY = window.scrollY || 0;
+          return;
+        }
+
+        if (expandedAtY == null) {
+          lastScrollY = window.scrollY || 0;
+          return;
+        }
+
+        const currentY = window.scrollY || 0;
+        const scrollingDown = currentY > lastScrollY;
+        const delta = currentY - expandedAtY;
+
+        if (scrollingDown && delta >= autoCollapseDelta) {
+          collapseHero();
+        }
+
+        lastScrollY = currentY;
+      };
+
+      const syncAll = () => {
+        stripLocalSticky();
+        syncFollowState();
+        syncHeroState();
+        applyLocalStickyHeight();
+      };
+
+      const schedule = () => {
+        if (raf) return;
+        raf = requestAnimationFrame(() => {
+          raf = 0;
+          requestAnimationFrame(syncAll);
+        });
+      };
+
+      heroToggle?.addEventListener("click", expandHero);
+
+      const onScroll = () => {
+        maybeAutoCollapseOnScroll();
+        schedule();
+      };
+
+      const followObserver = new MutationObserver(schedule);
+      followObserver.observe(follow, {
+        attributes: true,
+        attributeFilter: ["class", "style", "aria-hidden"],
+        subtree: false,
+      });
+
+      const heroResizeObserver =
+        typeof ResizeObserver !== "undefined"
+          ? new ResizeObserver(schedule)
+          : null;
+
+      heroResizeObserver?.observe(hero);
+
+      window.addEventListener("scroll", onScroll, { passive: true });
+      window.addEventListener("resize", schedule);
+      window.addEventListener("pageshow", schedule);
+
+      if (document.fonts?.ready) {
+        document.fonts.ready.then(schedule).catch(() => {});
+      }
+
+      if (mqMobile.addEventListener) {
+        mqMobile.addEventListener("change", schedule);
+      } else if (mqMobile.addListener) {
+        mqMobile.addListener(schedule);
+      }
+
+      schedule();
+    };
+
+    if (document.readyState === "loading") {
+      document.addEventListener("DOMContentLoaded", boot, { once: true });
+    } else {
+      boot();
+    }
+  })();
+</script>
+
+<style>
+  :global(body.is-glossary-portal-page #reading-follow){
+    z-index: 10;
+  }
+
+  :global(body.is-glossary-portal-page.glossary-portal-follow-on .glossary-portal-hero){
+    margin-bottom: 0;
+    padding: 12px 16px 14px;
+    row-gap: 10px;
+    border-bottom-left-radius: 0;
+    border-bottom-right-radius: 0;
+  }
+
+  :global(body.is-glossary-portal-page.glossary-portal-follow-on .glossary-portal-hero h1){
+    font-size: clamp(1.9rem, 3.2vw, 2.55rem);
+  }
+
+  :global(body.is-glossary-portal-page.glossary-portal-follow-on .glossary-portal-hero__intro){
+    max-width: var(--portal-hero-follow-intro-max-w, 68ch);
+    font-size: .98rem;
+    line-height: 1.48;
+  }
+
+  :global(body.is-glossary-portal-page.glossary-portal-follow-on:not(.glossary-portal-hero-expanded) .glossary-portal-hero__more){
+    max-height: 0;
+    opacity: 0;
+    overflow: hidden;
+    pointer-events: none;
+  }
+
+  :global(body.is-glossary-portal-page.glossary-portal-follow-on:not(.glossary-portal-hero-expanded) .glossary-portal-hero__toggle){
+    display: inline-flex;
+  }
+
+  :global(body.is-glossary-portal-page.glossary-portal-follow-on #reading-follow .reading-follow__inner){
+    border-top-left-radius: 0;
+    border-top-right-radius: 0;
+  }
+
+  :global(body.is-glossary-portal-page .glossary-portal-section__head.is-sticky),
+  :global(body.is-glossary-portal-page .glossary-portal-section__head[data-sticky-active="true"]){
+    position: static !important;
+    top: auto !important;
+    z-index: auto !important;
+    padding: 0 !important;
+    border: 0 !important;
+    background: transparent !important;
+    box-shadow: none !important;
+    backdrop-filter: none !important;
+    -webkit-backdrop-filter: none !important;
+  }
+</style>

src/components/GlossaryRelationCards.astro

@@ -0,0 +1,89 @@
+---
+import type { GlossaryRelationBlock } from "../lib/glossary";
+import { hrefOfGlossaryEntry } from "../lib/glossary";
+
+interface Props {
+  relationBlocks: GlossaryRelationBlock[];
+}
+
+const { relationBlocks = [] } = Astro.props;
+---
+
+{relationBlocks.length > 0 && (
+  <section class="glossary-relations" aria-label="Relations conceptuelles">
+    <h2>Relations conceptuelles</h2>
+
+    <div class="glossary-relations-grid">
+      {relationBlocks.map((block) => (
+        <section class={`glossary-relations-card ${block.className}`}>
+          <h3>{block.title}</h3>
+          <ul>
+            {block.items.map((item) => (
+              <li>
+                <a href={hrefOfGlossaryEntry(item)}>{item.data.term}</a>
+                <span> — {item.data.definitionShort}</span>
+              </li>
+            ))}
+          </ul>
+        </section>
+      ))}
+    </div>
+  </section>
+)}
+
+<style>
+  .glossary-relations{
+    margin-top: 26px;
+    padding-top: 18px;
+    border-top: 1px solid rgba(127,127,127,0.18);
+  }
+
+  .glossary-relations h2{
+    margin-bottom: 14px;
+  }
+
+  .glossary-relations-grid{
+    display: grid;
+    grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
+    gap: 12px;
+  }
+
+  .glossary-relations-card{
+    border: 1px solid rgba(127,127,127,0.22);
+    border-radius: 16px;
+    padding: 14px 16px;
+    background: rgba(127,127,127,0.05);
+  }
+
+  .glossary-relations-card h3{
+    margin-top: 0;
+    margin-bottom: 10px;
+    font-size: 15px;
+    line-height: 1.35;
+  }
+
+  .glossary-relations-card ul{
+    margin: 0;
+    padding-left: 18px;
+  }
+
+  .glossary-relations-card li{
+    margin-bottom: 8px;
+    font-size: 14px;
+    line-height: 1.45;
+  }
+
+  .glossary-relations-card li:last-child{
+    margin-bottom: 0;
+  }
+
+  .glossary-relations-card span{
+    opacity: .9;
+  }
+
+  @media (prefers-color-scheme: dark){
+    .glossary-relations-card{
+      background: rgba(255,255,255,0.04);
+    }
+  }
+</style>

src/components/SidePanel.astro

@@ -25,12 +25,12 @@
 
     {/* ✅ actions références en haut (niveau 2 uniquement) */}
     <div class="panel-top-actions level-2" aria-label="Actions références">
-    <div class="panel-actions">
+      <div class="panel-actions">
         <button class="panel-btn panel-btn--primary" id="panel-ref-submit" type="button">
-        Soumettre une référence (Gitea)
+          Soumettre une référence (Gitea)
         </button>
-    </div>
-    <div class="panel-msg" id="panel-ref-msg" hidden></div>
+      </div>
+      <div class="panel-msg" id="panel-ref-msg" hidden></div>
     </div>
 
     <section class="panel-block level-2" aria-label="Références et auteurs">
@@ -60,7 +60,7 @@
     </section>
   </div>
 
-  {/* ✅ Lightbox media (pop-up au-dessus du panel) */}
+  {/* ✅ Lightbox media (plein écran) */}
   <div class="panel-lightbox" id="panel-lightbox" hidden aria-hidden="true">
     <div class="panel-lightbox__overlay" data-close="1"></div>
     <div class="panel-lightbox__dialog" role="dialog" aria-modal="true" aria-label="Aperçu du média">
@@ -93,6 +93,9 @@
   const btnMediaSubmit = root.querySelector("#panel-media-submit");
   const msgMedia = root.querySelector("#panel-media-msg");
 
+  const btnRefSubmit = root.querySelector("#panel-ref-submit");
+  const msgRef = root.querySelector("#panel-ref-msg");
+
   const taComment = root.querySelector("#panel-comment-text");
   const btnSend = root.querySelector("#panel-comment-send");
   const msgComment = root.querySelector("#panel-comment-msg");
@@ -101,9 +104,6 @@
   const lbContent = root.querySelector("#panel-lightbox-content");
   const lbCaption = root.querySelector("#panel-lightbox-caption");
 
-  const btnRefSubmit = root.querySelector("#panel-ref-submit");
-  const msgRef = root.querySelector("#panel-ref-msg");
-
   const docTitle = document.body?.dataset?.docTitle || document.title || "Archicratie";
   const docVersion = document.body?.dataset?.docVersion || "";
 
@@ -114,6 +114,16 @@
   let currentParaId = "";
   let mediaShowAll = (localStorage.getItem("archicratie:panel:mediaAll") === "1");
 
+  // ===== cosmetics: micro flash “update” =====
+  let _flashT = 0;
+  function flashUpdate(){
+    try {
+      root.classList.add("is-updating");
+      if (_flashT) clearTimeout(_flashT);
+      _flashT = setTimeout(() => root.classList.remove("is-updating"), 180);
+    } catch {}
+  }
+
   // ===== globals =====
   function getG() {
     return window.__archiGitea || { ready: false, base: "", owner: "", repo: "" };
@@ -121,9 +131,6 @@
   function getAuthInfoP() {
     return window.__archiAuthInfoP || Promise.resolve({ ok: false, groups: [] });
   }
-  function isDev() {
-    return Boolean((window.__archiFlags && window.__archiFlags.dev) || /^(localhost|127\.0\.0\.1|\[::1\])$/i.test(location.hostname));
-  }
 
   const access = { ready: false, canUsers: false };
 
@@ -137,23 +144,20 @@
     return Array.isArray(groups) && groups.some((x) => String(x).toLowerCase() === gg);
   }
 
-  // ✅ règle mission : readers + editors peuvent soumettre médias + commentaires
-  // ✅ dev fallback : si /_auth/whoami n’existe pas, on autorise pour tester
+  // ✅ readers + editors peuvent soumettre médias + commentaires + refs
   getAuthInfoP().then((info) => {
     const groups = Array.isArray(info?.groups) ? info.groups : [];
     const canReaders = inGroup(groups, "readers");
     const canEditors = inGroup(groups, "editors");
 
-    access.canUsers = Boolean((info?.ok && (canReaders || canEditors)) || (isDev() && !info?.ok));
+    const whoamiSkipped = Boolean(window.__archiFlags && window.__archiFlags.whoamiSkipped);
+    access.canUsers = Boolean((info?.ok && (canReaders || canEditors)) || whoamiSkipped);
     access.ready = true;
 
     if (btnMediaSubmit) btnMediaSubmit.disabled = !access.canUsers;
     if (btnSend) btnSend.disabled = !access.canUsers;
-
     if (btnRefSubmit) btnRefSubmit.disabled = !access.canUsers;
 
-
-    // si pas d'accès, on informe (soft)
     if (!access.canUsers) {
       if (msgHead) {
         msgHead.hidden = false;
@@ -162,12 +166,12 @@
       }
     }
   }).catch(() => {
-    // fallback dev
     access.ready = true;
-    if (isDev()) {
+    if (Boolean(window.__archiFlags && window.__archiFlags.whoamiSkipped)) {
       access.canUsers = true;
       if (btnMediaSubmit) btnMediaSubmit.disabled = false;
       if (btnSend) btnSend.disabled = false;
+      if (btnRefSubmit) btnRefSubmit.disabled = false;
     }
   });
 
@@ -209,8 +213,11 @@
   async function loadIndex() {
     if (_idxP) return _idxP;
     _idxP = (async () => {
-      const res = await fetch("/annotations-index.json?_=" + Date.now(), { cache: "no-store" }).catch(() => null);
-      if (res && res.ok) return await res.json();
+      try {
+        const res = await fetch("/annotations-index.json?_=" + Date.now(), { cache: "no-store" });
+        if (res && res.ok) return await res.json();
+      } catch {}
+      _idxP = null;
       return null;
     })();
     return _idxP;
@@ -251,24 +258,22 @@
     return issue.toString();
   }
 
-  // Ouvre un nouvel onglet UNE SEULE FOIS (évite le double-open Safari/Firefox + noopener).
-    function openNewTab(url) {
-        try {
-            const a = document.createElement("a");
-            a.href = url;
-            a.target = "_blank";
-            a.rel = "noopener noreferrer";
-            a.style.display = "none";
-            document.body.appendChild(a);
-            a.click();
-            a.remove();
-            return true; // on ne peut pas détecter proprement un blocage sans retomber dans le double-open
-        } catch {
-            return false;
-        }
+  function openNewTab(url) {
+    try {
+      const a = document.createElement("a");
+      a.href = url;
+      a.target = "_blank";
+      a.rel = "noopener noreferrer";
+      a.style.display = "none";
+      document.body.appendChild(a);
+      a.click();
+      a.remove();
+      return true;
+    } catch {
+      return false;
     }
+  }
 
-  // ====== GARDES ANTI-DOUBLONS ======
   const _openStamp = new Map();
   function openOnce(key, fn) {
     const now = Date.now();
@@ -297,13 +302,21 @@
   }
 
   // ===== Lightbox =====
+  function lockScroll(on) {
+    try {
+      document.documentElement.classList.toggle("archi-lb-open", !!on);
+    } catch {}
+  }
+
   function closeLightbox() {
     if (!lb) return;
     lb.hidden = true;
     lb.setAttribute("aria-hidden", "true");
     if (lbContent) clear(lbContent);
     if (lbCaption) { lbCaption.hidden = true; lbCaption.textContent = ""; }
+    lockScroll(false);
   }
+
   function openLightbox({ type, src, caption }) {
     if (!lb || !lbContent) return;
     clear(lbContent);
@@ -342,6 +355,7 @@
       else { lbCaption.hidden = true; lbCaption.textContent = ""; }
     }
 
+    lockScroll(true);
     lb.hidden = false;
     lb.setAttribute("aria-hidden", "false");
   }
@@ -359,7 +373,6 @@
     });
   }
 
-  // ===== Renders =====
   function renderLevel2(data) {
     clear(elL2);
     if (!elL2) return;
@@ -369,7 +382,7 @@
       return;
     }
 
-    if (Array.isArray(data.authors) && data.authors.length) {
+    if (Array.isArray(data.mobilizedAuthors) && data.mobilizedAuthors.length) {
       const h = document.createElement("h3");
       h.className = "panel-subtitle";
       h.textContent = "Auteurs";
@@ -377,7 +390,7 @@
 
       const ul = document.createElement("ul");
       ul.className = "panel-list";
-      for (const a of data.authors) {
+      for (const a of data.mobilizedAuthors) {
         const li = document.createElement("li");
         li.textContent = esc(a);
         ul.appendChild(li);
@@ -559,11 +572,22 @@
   async function updatePanel(paraId) {
     currentParaId = paraId || currentParaId || "";
     if (elId) elId.textContent = currentParaId || "—";
+
+    flashUpdate();
+
     hideMsg(msgHead);
     hideMsg(msgMedia);
     hideMsg(msgComment);
+    hideMsg(msgRef);
 
     const idx = await loadIndex();
+
+    if (!idx && msgHead && msgHead.hidden) {
+      msgHead.hidden = false;
+      msgHead.textContent = "Index annotations indisponible (annotations-index.json).";
+      msgHead.dataset.kind = "info";
+    }
+
     const data = idx?.pages?.[pageKey]?.paras?.[currentParaId] || null;
 
     renderLevel2(data);
@@ -571,7 +595,6 @@
     renderLevel4(data);
   }
 
-  // ===== media "voir tous" =====
   if (btnMediaAll) {
     bindClickOnce(btnMediaAll, (ev) => {
       ev.preventDefault();
@@ -583,7 +606,6 @@
     btnMediaAll.textContent = mediaShowAll ? "Réduire la liste" : "Voir tous les éléments";
   }
 
-  // ===== media submit (readers + editors) =====
   if (btnMediaSubmit) {
     bindClickOnce(btnMediaSubmit, (ev) => {
       ev.preventDefault();
@@ -626,27 +648,26 @@
     });
   }
 
-  // ===== référence submit (readers + editors) =====
-    if (btnRefSubmit) {
+  if (btnRefSubmit) {
     bindClickOnce(btnRefSubmit, (ev) => {
-        ev.preventDefault();
-        hideMsg(msgRef);
+      ev.preventDefault();
+      hideMsg(msgRef);
 
-        if (guardEventOnce(ev, "gitea_open_ref")) return;
+      if (guardEventOnce(ev, "gitea_open_ref")) return;
 
-        if (!currentParaId) return showMsg(msgRef, "Choisis d’abord un paragraphe (scroll / survol).", "warn");
-        if (!getG().ready) return showMsg(msgRef, "Gitea non configuré (PUBLIC_GITEA_*).", "error");
-        if (btnRefSubmit.disabled) return showMsg(msgRef, "Connexion requise (readers/editors).", "error");
+      if (!currentParaId) return showMsg(msgRef, "Choisis d’abord un paragraphe (scroll / survol).", "warn");
+      if (!getG().ready) return showMsg(msgRef, "Gitea non configuré (PUBLIC_GITEA_*).", "error");
+      if (btnRefSubmit.disabled) return showMsg(msgRef, "Connexion requise (readers/editors).", "error");
 
-        const pageUrl = new URL(location.href);
-        pageUrl.search = "";
-        pageUrl.hash = currentParaId;
+      const pageUrl = new URL(location.href);
+      pageUrl.search = "";
+      pageUrl.hash = currentParaId;
 
-        const paraTxt = getParaText(currentParaId);
-        const excerpt = paraTxt.length > FULL_TEXT_SOFT_LIMIT ? (paraTxt.slice(0, FULL_TEXT_SOFT_LIMIT) + "…") : paraTxt;
+      const paraTxt = getParaText(currentParaId);
+      const excerpt = paraTxt.length > FULL_TEXT_SOFT_LIMIT ? (paraTxt.slice(0, FULL_TEXT_SOFT_LIMIT) + "…") : paraTxt;
 
-        const title = `[Reference] ${currentParaId} — ${docTitle}`;
-        const body = [
+      const title = `[Reference] ${currentParaId} — ${docTitle}`;
+      const body = [
         `Chemin: ${location.pathname}`,
         `URL: ${pageUrl.toString()}`,
         `Ancre: #${currentParaId}`,
@@ -664,18 +685,16 @@
         ``,
         `---`,
         `Note: issue générée depuis le site (pré-remplissage).`,
-        ].join("\n");
+      ].join("\n");
 
-        const url = buildIssueURL({ title, body });
-        if (!url) return showMsg(msgRef, "Impossible de générer l’issue.", "error");
+      const url = buildIssueURL({ title, body });
+      if (!url) return showMsg(msgRef, "Impossible de générer l’issue.", "error");
 
-        const ok = openOnce(`ref:${currentParaId}`, () => openNewTab(url));
-        if (!ok) showMsg(msgRef, "Si rien ne s’ouvre : autorise les popups pour ce site.", "error");
+      const ok = openOnce(`ref:${currentParaId}`, () => openNewTab(url));
+      if (!ok) showMsg(msgRef, "Si rien ne s’ouvre : autorise les popups pour ce site.", "error");
     });
-    }
+  }
 
-
-  // ===== commentaire (readers + editors) =====
   if (btnSend) {
     bindClickOnce(btnSend, (ev) => {
       ev.preventDefault();
@@ -727,60 +746,31 @@
     });
   }
 
-  // ===== wiring: para courant (aligné sur le paragraphe sous le reading-follow) =====
-  function isPara(el) {
-    return Boolean(el && el.nodeType === 1 && el.matches && el.matches('.reading p[id^="p-"]'));
+  // ===== wiring: para courant (SOURCE OF TRUTH = EditionLayout) =====
+  function onCurrentPara(ev) {
+    try {
+      const id = ev?.detail?.id ? String(ev.detail.id) : "";
+      if (!id || !/^p-\d+-/i.test(id)) return;
+      if (id === currentParaId) return;
+      updatePanel(id);
+    } catch {}
   }
+  window.addEventListener("archicratie:currentPara", onCurrentPara);
 
-  function pickParaAtY(y) {
-    const x = Math.max(0, Math.round(window.innerWidth * 0.5));
-    const candidates = [
-      document.elementFromPoint(x, y),
-      document.elementFromPoint(Math.min(window.innerWidth - 1, x + 60), y),
-      document.elementFromPoint(Math.max(0, x - 60), y),
-    ].filter(Boolean);
+  const initial = String(location.hash || "").replace(/^#/, "").trim();
 
-    for (const c of candidates) {
-      if (isPara(c)) return c;
-      const p = c.closest ? c.closest('.reading p[id^="p-"]') : null;
-      if (isPara(p)) return p;
-    }
-    return null;
+  if (/^p-\d+-/i.test(initial)) {
+    updatePanel(initial);
+  } else if (window.__archiCurrentParaId && /^p-\d+-/i.test(String(window.__archiCurrentParaId))) {
+    updatePanel(String(window.__archiCurrentParaId));
+  } else {
+    setTimeout(() => {
+      try {
+        const id = String(window.__archiCurrentParaId || "").trim();
+        if (/^p-\d+-/i.test(id)) updatePanel(id);
+      } catch {}
+    }, 0);
   }
-
-  let _lastPicked = "";
-  function syncFromFollowLine() {
-    const off = Number(document.documentElement.style.getPropertyValue("--sticky-offset-px")) || 0;
-    const y = Math.round(off + 8);
-    const p = pickParaAtY(y);
-    if (!p || !p.id) return;
-    if (p.id === _lastPicked) return;
-    _lastPicked = p.id;
-
-    // met à jour l'app global (EditionLayout écoute déjà currentPara)
-    try { window.dispatchEvent(new CustomEvent("archicratie:currentPara", { detail: { id: p.id } })); } catch {}
-
-    // et met à jour le panel immédiatement (sans attendre)
-    updatePanel(p.id);
-  }
-
-  let ticking = false;
-  function onScroll() {
-    if (ticking) return;
-    ticking = true;
-    requestAnimationFrame(() => {
-      ticking = false;
-      syncFromFollowLine();
-    });
-  }
-
-  window.addEventListener("scroll", onScroll, { passive: true });
-  window.addEventListener("resize", onScroll);
-
-  // Initial: hash > sinon calc
-  const initial = String(location.hash || "").replace(/^#/, "");
-  if (/^p-\d+-/i.test(initial)) updatePanel(initial);
-  else setTimeout(() => { try { syncFromFollowLine(); } catch {} }, 0);
 })();
 </script>
 
@@ -793,6 +783,8 @@
     position: sticky;
     top: calc(var(--sticky-header-h) + var(--page-gap));
     align-self: start;
+
+    --thumb: 92px; /* ✅ taille des vignettes (80–110 selon goût) */
   }
 
   :global(body[data-reading-level="3"]) .page-panel{
@@ -910,28 +902,33 @@
   /* actions médias en haut */
   .panel-top-actions{ margin-top: 8px; }
 
-  /* ===== media thumbnails (150x150) ===== */
+  /* ===== media thumbnails (plus petits + plus denses) ===== */
   .panel-media-grid{
     display: grid;
-    grid-template-columns: repeat(auto-fill, minmax(150px, 1fr));
+    grid-template-columns: repeat(auto-fill, minmax(var(--thumb), 1fr));
     gap: 10px;
   }
 
   .panel-media-tile{
-    width: 150px;
-    max-width: 100%;
+    width: 100%;
     border: 1px solid rgba(127,127,127,.20);
     border-radius: 14px;
     padding: 8px;
     background: rgba(127,127,127,0.04);
     cursor: pointer;
     text-align: left;
+    transition: transform 120ms ease, background 120ms ease, border-color 120ms ease;
+  }
+
+  .panel-media-tile:hover{
+    transform: translateY(-1px);
+    background: rgba(127,127,127,0.07);
+    border-color: rgba(127,127,127,.32);
   }
 
   .panel-media-tile img{
-    width: 150px;
-    height: 150px;
-    max-width: 100%;
+    width: 100%;
+    height: var(--thumb);
     object-fit: cover;
     display: block;
     border-radius: 10px;
@@ -939,8 +936,8 @@
   }
 
   .panel-media-ph{
-    width: 150px;
-    height: 150px;
+    width: 100%;
+    height: var(--thumb);
     border-radius: 10px;
     display: grid;
     place-items: center;
@@ -983,7 +980,11 @@
     resize: vertical;
   }
 
-  /* ===== Lightbox ===== */
+  /* ===== Lightbox (plein écran “cinéma”) ===== */
+  :global(html.archi-lb-open){
+    overflow: hidden; /* ✅ empêche le scroll derrière */
+  }
+
   .panel-lightbox{
     position: fixed;
     inset: 0;
@@ -993,58 +994,66 @@
   .panel-lightbox__overlay{
     position: absolute;
     inset: 0;
-    background: rgba(0,0,0,0.80);
-    backdrop-filter: blur(6px);
-    -webkit-backdrop-filter: blur(6px);
+    background: rgba(0,0,0,0.84);
+    backdrop-filter: blur(10px);
+    -webkit-backdrop-filter: blur(10px);
   }
 
   .panel-lightbox__dialog{
     position: absolute;
-    right: 24px;
-    top: calc(var(--sticky-header-h) + 16px);
-    width: min(520px, calc(100vw - 48px));
-    max-height: calc(100vh - (var(--sticky-header-h) + 32px));
+    left: 50%;
+    top: 50%;
+    transform: translate(-50%, -50%);
+
+    width: min(1100px, 92vw);
+    max-height: 92vh;
     overflow: auto;
 
-    border: 1px solid rgba(127,127,127,0.22);
-    border-radius: 16px;
-    background: rgba(255,255,255,0.10);
-    backdrop-filter: blur(10px);
-    -webkit-backdrop-filter: blur(10px);
-    padding: 12px;
-  }
+    border: 1px solid rgba(255,255,255,0.14);
+    border-radius: 18px;
 
-  @media (prefers-color-scheme: dark){
-    .panel-lightbox__dialog{
-      background: rgba(0,0,0,0.28);
-    }
+    background: rgba(20,20,20,0.55);
+    backdrop-filter: blur(14px);
+    -webkit-backdrop-filter: blur(14px);
+
+    padding: 16px;
+    box-shadow: 0 24px 70px rgba(0,0,0,0.55);
   }
 
   .panel-lightbox__close{
-    position: sticky;
-    top: 0;
-    margin-left: auto;
+    position: absolute;
+    top: 12px;
+    right: 12px;
+
     display: inline-flex;
     align-items: center;
     justify-content: center;
-    width: 34px;
-    height: 30px;
-    border-radius: 10px;
-    border: 1px solid rgba(127,127,127,0.35);
-    background: rgba(127,127,127,0.10);
+
+    width: 44px;
+    height: 40px;
+
+    border-radius: 14px;
+    border: 1px solid rgba(255,255,255,0.22);
+    background: rgba(255,255,255,0.10);
+
     cursor: pointer;
-    font-size: 18px;
+    font-size: 22px;
     font-weight: 900;
   }
 
+  .panel-lightbox__content{
+    margin-top: 36px;
+  }
+
   .panel-lightbox__content img,
   .panel-lightbox__content video{
     display: block;
     width: 100%;
-    height: auto;
-    max-width: 1400px;
-    margin: 0 auto;
-    border-radius: 12px;
+    max-height: calc(92vh - 160px);
+    object-fit: contain;
+
+    background: rgba(0,0,0,0.22);
+    border-radius: 14px;
   }
 
   .panel-lightbox__content audio{
@@ -1052,13 +1061,14 @@
   }
 
   .panel-lightbox__caption{
-    margin-top: 10px;
+    margin-top: 12px;
     font-size: 12px;
     font-weight: 800;
     opacity: .92;
+    color: rgba(255,255,255,0.92);
   }
 
   @media (max-width: 1100px){
     .page-panel{ display: none; }
   }
-</style>
+</style>

src/components/SiteNav.astro

@@ -1,11 +1,17 @@
 <nav class="site-nav" aria-label="Navigation principale">
-  <a href="/">Accueil</a><span aria-hidden="true"> · </span>
-  <a href="/editions/">Carte des œuvres</a><span aria-hidden="true"> · </span>
-  <a href="/methode/">Méthode</a><span aria-hidden="true"> · </span>
-  <a href="/recherche/">Recherche</a><span aria-hidden="true"> · </span>
-  <a href="/archicrat-ia/">Essai-thèse</a><span aria-hidden="true"> · </span>
-  <a href="/traite/">Traité</a><span aria-hidden="true"> · </span>
-  <a href="/ia/">Cas IA</a><span aria-hidden="true"> · </span>
-  <a href="/glossaire/">Glossaire</a><span aria-hidden="true"> · </span>
-  <a href="/atlas/">Atlas</a>
-</nav>
+
+<a href="/">Accueil</a>
+<span aria-hidden="true"> · </span>
+
+<a href="/archicrat-ia/">Essai-thèse</a>
+<span aria-hidden="true"> · </span>
+
+<a href="/cas-ia/">Cas IA</a>
+<span aria-hidden="true"> · </span>
+
+<a href="/glossaire/">Glossaire</a>
+<span aria-hidden="true"> · </span>
+
+<a href="/recherche/">Recherche</a>
+
+</nav>

src/content.config.ts

@@ -0,0 +1,112 @@
+import { defineCollection, z } from "astro:content";
+
+const linkSchema = z.object({
+  type: z.enum(["definition", "appui", "transposition"]),
+  target: z.string().min(1),
+  note: z.string().optional()
+});
+
+const baseTextSchema = z.object({
+  title: z.string().min(1),
+  level: z.union([z.literal(1), z.literal(2), z.literal(3)]).default(1),
+  version: z.string().min(1),
+  concepts: z.array(z.string().min(1)).default([]),
+  links: z.array(linkSchema).default([]),
+  order: z.number().int().nonnegative().optional(),
+  summary: z.string().optional()
+});
+
+// Éditions (séparation stricte : edition + status verrouillés par collection)
+
+const casIa = defineCollection({
+  type: "content",
+  schema: baseTextSchema.extend({
+    edition: z.literal("cas-ia"),
+    status: z.literal("application")
+  })
+});
+
+const commencer = defineCollection({
+  type: "content",
+  schema: baseTextSchema.extend({
+    edition: z.literal("commencer"),
+    status: z.union([z.literal("presentation"), z.literal("draft")])
+  })
+});
+
+// ✅ NOUVELLE collection : archicrat-ia (Essai-thèse)
+// NOTE : on accepte temporairement edition/status "archicratie/modele_sociopolitique"
+// si tes MDX n’ont pas encore été normalisés.
+// Quand tu voudras "strict", on passera à edition="archicrat-ia" status="essai_these"
+// + update frontmatter des 7 fichiers.
+const archicratIa = defineCollection({
+  type: "content",
+  schema: baseTextSchema.extend({
+    edition: z.union([z.literal("archicrat-ia"), z.literal("archicratie")]),
+    status: z.union([z.literal("essai_these"), z.literal("modele_sociopolitique")])
+  })
+});
+
+// Glossaire (référentiel terminologique)
+const glossaire = defineCollection({
+  type: "content",
+  schema: z.object({
+    title: z.string().min(1),
+    term: z.string().min(1),
+    aliases: z.array(z.string().min(1)).default([]),
+    urlAliases: z
+      .array(z.string().regex(/^[a-z0-9]+(?:-[a-z0-9]+)*$/))
+      .default([]),
+    mobilizedAuthors: z.array(z.string().min(1)).default([]),
+    comparisonTraditions: z.array(z.string().min(1)).default([]),
+    edition: z.literal("glossaire"),
+    status: z.literal("referentiel"),
+    version: z.string().min(1),
+    definitionShort: z.string().min(1),
+    concepts: z.array(z.string().min(1)).default([]),
+    links: z.array(linkSchema).default([]),
+
+    kind: z.enum([
+      "concept",
+      "topologie",
+      "diagnostic",
+      "verbe",
+      "paradigme",
+      "doctrine",
+      "dispositif",
+      "figure",
+      "qualification",
+      "epistemologie",
+    ]),
+    family: z.enum([
+        "concept-fondamental",
+        "scene",
+        "dynamique",
+        "pathologie",
+        "topologie",
+        "meta-regime",
+        "paradigme",
+        "doctrine",
+        "verbe",
+        "dispositif-ia",
+        "tension-irreductible",
+        "figure",
+        "qualification",
+        "epistemologie",
+      ]
+    )
+    .optional(),
+    domain: z.enum(["transversal", "theorie", "cas-ia"]),
+    level: z.enum(["fondamental", "intermediaire", "avance"]),
+    related: z.array(z.string().min(1)).default([]),
+    opposedTo: z.array(z.string().min(1)).default([]),
+    seeAlso: z.array(z.string().min(1)).default([])
+  })
+});
+
+export const collections = {
+  commencer,
+  "archicrat-ia": archicratIa,
+  "cas-ia": casIa,
+  glossaire,
+};

src/content/archicrat-ia/chapitre-1.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Chapitre 1 — Fondements épistémologiques et modélisation"
-edition: "archicratie"
+edition: "archicrat-ia"
 status: "modele_sociopolitique"
 level: 1
 version: "0.1.0"
@@ -14,35 +14,41 @@ source:
 ---
 Si les sciences politiques ont longtemps trouvé leur ancrage et leur légitimité dans l’analyse des institutions formelles du pouvoir – souveraineté, contrat, autorité, représentation – c’est que le politique y était toujours présumé se manifester à travers une scène, un lieu, un sujet, un régime. Le pouvoir y avait des signes, des corps, des textes ; il procédait d’un fondement — Dieu, la volonté générale, la loi, la nation — et d’un opérateur identifié : le prince, le peuple, le juge, l’État. De la théorie de Hobbes à celle de Rawls, en passant par Rousseau, Kant ou Habermas, les paradigmes de légitimation sont fondés sur une ontologie de la centralité, de la scène constituante, et d’un sujet instituant dont l’autonomie garantit la normativité du pouvoir.
 
-Or, ce que nos régimes contemporains de régulation mettent désormais en crise, ce n’est pas tant la scène elle-même, que la possibilité de sa tenue effective. La scène subsiste, peut-être, mais elle est vidée, ritualisée, simulée, remplacée, saturée ou dissoute dans des procédures techniques, des protocoles logistiques, des décisions sans auteurs, des gouvernances algorithmiques. Le pouvoir opère sans se déclarer, régule sans se justifier, agit sans se mettre en débat. Il est devenu ce que nous proposons de nommer *archicratistique* — c’est-à-dire qu’il agit selon un régime de régulation autonome sans scène, sans justification visible, sans délai institué pour la dispute, sans temporalité contradictoire. Non pas qu’il soit tyrannique, autoritaire ou caché au sens classique, mais parce qu’il *ne se donne plus à la critique* selon les formes instituées de l’opposabilité politique.
+Or, ce que nos régimes contemporains de régulation mettent désormais en crise, ce n’est pas tant la scène elle-même, que la possibilité de sa tenue effective. La scène subsiste, peut-être, mais elle est vidée, ritualisée, simulée, remplacée, saturée ou dissoute dans des procédures techniques, des protocoles logistiques, des décisions sans auteurs, des gouvernances algorithmiques. Le pouvoir opère comme s’il n’avait plus à se déclarer, régule sur des justifications faiblement exposables, et agit dans des configurations où la mise en débat est neutralisée, comprimée ou vidée de prise. Il est devenu ce que nous proposons de nommer archicratistique — c’est-à-dire qu’il agit selon un régime de régulation autonome où la scène d’épreuve se trouve neutralisée, mimée, relocalisée hors d’atteinte ou rendue pratiquement inopérante ; où les justifications demeurent faiblement exposables ou inopposables pour les affectés ; où le délai de la dispute est comprimé, fictif ou supprimé dans les faits ; et où la temporalité contradictoire n’est plus tenue comme scène praticable de reprise. Non pas qu’il soit tyrannique, autoritaire ou caché au sens classique, mais parce qu’il ne se donne plus à la critique selon les formes instituées de l’opposabilité politique.
 
-L’ambition de ce chapitre est donc de fonder ce paradigme nouveau, ou plus exactement, de nommer et d’outiller une forme ancienne mais non encore pensée du pouvoir — la régulation contradictoire institué. Cette forme, nous la nommons *archicratie*, non pour désigner un régime de plus, mais pour désigner un méta-régime viable de régulation lorsqu’une triade — *arcalité* (fondation déclarable), *cratialité* (opération traçable), *archicration* (épreuve instituée différée) — se tient en tenségrité, c’est-à-dire en tension dynamique métastable l’un à l’autre.
+L’ambition de ce chapitre est donc de fonder ce paradigme nouveau, ou plus exactement, de nommer et d’outiller une forme ancienne mais non encore pensée du pouvoir — la régulation contradictoire instituée. Cette forme, nous la nommons *archicratie*, non pour désigner un régime de plus, mais pour désigner un méta-régime viable de régulation lorsqu’une triade — *arcalité* (fondation déclarable), *cratialité* (opération traçable), *archicration* (épreuve instituée différée) — se tient en tenségrité, c’est-à-dire en tension dynamique métastable l’un à l’autre.
 
-À rebours de l’*archicratie*, nous appelons désarchicration la configuration où la scène est dissoute, court-circuitée ou relocalisée hors d’atteinte, tandis que les régulations se poursuivent néanmoins. Il ne s’agit pas de prétendre que tout deviendrait opaque, mais de constater que l’opacité est structurelle aux dispositifs : non comme accident, mais comme condition de fonctionnement (secret industriel, non-auditabilité des modèles, dilution des responsabilités). Les algorithmes de notation d’allocataires, les règles budgétaires qui déclenchent mécaniquement des fermetures, les protocoles d’ajustement fiscal ou de police sanitaire sont légalement institués, techniquement rationalisés, mais politiquement indisponibles à l’opposition procédurale. Cette indisponibilité se mesure : absence de canal de saisine opposable, délai non garanti pour contester, motifs non accessibles ni réutilisables par les contestataires, paramètres non traçables ni réversibles. Ce n’est pas une archicratie (qui suppose la tenue d’une scène), mais son inverse : une désarchicration où la cratialité et l’arcalité se conjuguent sans archicration, produisant des décisions *indiscutables* de fait, parce que non opposables en temps et en raison.
+À rebours de l’archicratie, nous appelons désarchicration la configuration où la scène est dissoute, court-circuitée ou relocalisée hors d’atteinte, tandis que les régulations se poursuivent néanmoins. Il ne s’agit pas de prétendre que tout deviendrait opaque, mais de constater que l’opacité est structurelle à certains dispositifs : non comme accident, mais comme condition de fonctionnement. Les algorithmes de notation d’allocataires, les règles budgétaires qui déclenchent mécaniquement des fermetures, les protocoles d’ajustement fiscal ou de police sanitaire sont légalement institués, techniquement rationalisés, mais politiquement indisponibles à l’opposition procédurale. Cette indisponibilité se mesure : absence de canal de saisine opposable, délai non garanti pour contester, motifs non accessibles ni réutilisables par les contestataires, paramètres non traçables ni réversibles. Ce n’est pas une archicratie, qui suppose la tenue d’une scène, mais son inverse : une désarchicration dans laquelle l’arcalité et la cratialité continuent d’opérer tandis que l’archicration se trouve neutralisée, relocalisée hors d’atteinte, ou rendue pratiquement inopérante, produisant des décisions indiscutables de fait parce que non opposables en temps et en raison.
 
 Les paradigmes classiques — qu’ils soient contractualistes, décisionnistes ou délibératifs — échouent désormais à rendre compte de ces formes. Le pouvoir n’est plus localisé dans un lieu, il ne procède plus d’une scène constituante unique, il n’est plus incarné par un sujet identifiable. Il opère à travers une multiplicité de dispositifs hétérogènes, qui se soutiennent les uns les autres sans principe transcendant, selon une logique de capture, de redondance, de saturation ou d’euphémisation. Michel Foucault l’avait annoncé dès la fin des années 1970 avec son analyse de la gouvernementalité : « ce qui se met en place, ce n’est plus le droit de faire mourir ou de laisser vivre, mais le pouvoir de faire vivre et de laisser mourir » (1976). Hannah Arendt, bien avant lui, avait déjà diagnostiqué que « la disparition de la scène publique, c’est la disparition de la politique elle-même » (1958). Claude Lefort, dans *L’Invention démocratique*, avait désigné le pouvoir démocratique comme un lieu vide — précisément parce que sa légitimité dépend de la possibilité constante de remise en scène, de re-questionnement, de re-distribution. Mais que reste-t-il lorsque cette vacance est non plus instituante, mais neutralisée par des automatismes ? Lorsque la scène est formellement prévue mais substantiellement empêchée ? Lorsque les voies de recours sont techniques, absconses, et différées jusqu’à l’oubli ?
 
-Ce que nous vivons, ce que nous subissons parfois, ce que nous habitons souvent sans le voir, c’est la montée silencieuse des régimes archicratiques : dispositifs de régulation où la scène est inaccessible, où les fondements ne sont plus invoqués, où les décisions ne sont plus motivées, où le temps du différé est supprimé. Ce ne sont pas des régimes de domination au sens fort ; ce sont des régimes d’administration sans épreuve, des formes d’ordonnancement sans théâtre. L’archicratie ne se pense ni contre la démocratie, ni comme sa dégénérescence, mais comme sa marginalisation structurelle : elle s’installe dans les interstices, dans les écarts, dans les non-lieux du politique. Elle est l’administration algorithmique des droits, la codification silencieuse des trajectoires, la performativité sans contradictoire des normes automatiques.
+Ce que nous vivons, ce que nous subissons parfois, ce que nous habitons souvent sans le voir, ce n’est pas la montée silencieuse de “régimes archicratiques” au sens fort, mais la prolifération de configurations désarchicratiques et archicratistiques, parfois portées jusqu’à la dérive autarchicratique. Il s’agit de dispositifs de régulation où la scène devient difficilement praticable, neutralisée ou relocalisée hors d’atteinte ; où les fondements deviennent faiblement invoqués, euphémisés ou difficilement exposables ; où les décisions sont de moins en moins motivées de manière opposable ; et où le temps du différé se trouve comprimé, vidé de sa prise ou rendu fictif.
 
-Il nous faut alors un paradigme, non pour idéaliser une alternative, mais pour diagnostiquer cette configuration, pour la rendre visible, pensable, opposable. Car c’est bien cela qui définit un paradigme : sa capacité à faire apparaître ce qui était jusque-là neutralisé. Le paradigme archicratique ne vise pas à remplacer les théories classiques du pouvoir, mais à leur adjoindre une grammaire supplémentaire, permettant de nommer ce qui échappait à leurs catégories. Il ne s’agit plus seulement de savoir *qui* gouverne, mais *comment* se tiennent les régulations, *malgré* l’absence de légitimation visible, *malgré* l’effondrement des scènes instituées, *malgré* la disparition des temporalités différées de la décision. Il s’agit de rendre compte des zones grises, des seuils, des bifurcations, des objets métonymiques de l’ordre, des fonctions qui régulent sans jamais statuer.
+Il ne s’agit pas nécessairement de régimes de domination au sens classique, mais de formes de régulation administrative dans lesquelles l’épreuve est neutralisée, mimée ou rendue pratiquement inopérante, tandis que le théâtre politique s’affaiblit, se vide de sa prise ou se trouve relocalisé hors d’atteinte. Il ne s’agit donc pas ici de l’archicratie comme méta-régime viable de régulation, mais de son envers pratique : des dispositifs qui continuent d’opérer tout en neutralisant les conditions de leur propre mise en discussion. Se déploient ainsi des chaînes de décision où l’administration algorithmique des droits, la codification silencieuse des trajectoires et la performativité de normes automatiques dont le contradictoire est neutralisé ou vidé de prise tendent à soustraire la régulation à l’épreuve plutôt qu’à l’instituer.
+
+Il nous faut alors un paradigme, non pour idéaliser une alternative, mais pour diagnostiquer cette configuration, pour la rendre visible, pensable, opposable. Car c’est bien cela qui définit un paradigme : sa capacité à faire apparaître ce qui était jusque-là neutralisé. Le paradigme archicratique ne vise pas à remplacer les théories classiques du pouvoir, mais à leur adjoindre une grammaire supplémentaire, permettant de nommer ce qui échappait à leurs catégories. Il ne s’agit plus seulement de savoir qui gouverne, mais comment se tiennent les régulations lorsque les légitimations deviennent faiblement visibles, lorsque les scènes instituées sont neutralisées, vidées ou relocalisées hors d’atteinte, et lorsque les temporalités différées de la décision se trouvent comprimées, fictives ou pratiquement supprimées. Il s’agit de rendre compte des zones grises, des seuils, des bifurcations, des objets métonymiques de l’ordre, des fonctions qui régulent sans jamais statuer.
 
 Dans cette perspective, ce chapitre se donne pour tâche de poser les fondements épistémologiques, conceptuels et politiques du paradigme archicratique. Nous y exposerons son architecture théorique tripolaire — *arcalité* (ce qui fonde), *cratialité* (ce qui opère), *archicration* (ce qui permet la dispute) — ainsi que sa grammaire topologique interne/externe, ses objets de repérage concrets (fonctions, seuils, porteurs, signes, temporalités), et enfin ses critères de validité. Nous chercherons à produire une cartographie intelligible des formes de régulation contemporaine, sans tomber dans le cynisme ni dans l’utopie, mais en nommant avec précision les tensions, les prises, les scènes, les ruptures, les points aveugles.
 
-Car penser l’archicratie, ce n’est pas inventer un concept : c’est l’extraire du réel pour en faire un outil de diagnostic, un test de viabilité des régulations, un instrument de critique effective des dispositifs. C’est interroger ce qui gouverne sans débat, ce qui ordonne sans justification, ce qui affecte sans se montrer. C’est rouvrir la possibilité d’une pensée politique critique du réel.
+Car penser l’archicratie, ce n’est pas inventer un concept : c’est l’extraire du réel pour en faire un outil de diagnostic, un test de viabilité des régulations, un instrument de critique effective des dispositifs. C’est interroger ce qui gouverne à débat neutralisé, ce qui ordonne sur des justifications difficilement exposables, ce qui affecte en se soustrayant aux formes ordinaires de visibilité, de contestation et de reprise. C’est rouvrir la possibilité d’une pensée politique critique du réel.
 
-Si la modernité politique a trouvé dans la souveraineté représentative son axe structurant, sa fiction fondatrice et sa promesse régulatrice, cette architecture intellectuelle et institutionnelle semble aujourd’hui en proie à une désynchronisation profonde avec les formes effectives de la régulation contemporaine. La souveraineté, dans sa formulation classique — qu’elle s’incarne dans le peuple, la nation, l’État, le contrat ou la loi — présuppose une centralité décisionnelle, une légitimité visible, une continuité symbolique entre le fondement et l’exercice du pouvoir. Or, ce que nous observons aujourd’hui dans la majorité des dispositifs régulateurs, c’est une crise de cette souveraineté représentative non pas tant dans sa légitimité que dans sa capacité à structurer les prises réelles sur le monde. La scène parlementaire subsiste, mais elle est fréquemment contournée ; les mécanismes électoraux se perpétuent, mais ils échouent à produire une autorité agissante sur les déterminations majeures ; les figures institutionnelles traditionnelles persistent, mais elles ne sont plus les lieux d’où se décident ni les normes, ni les trajectoires. Ce déphasage — structurel, et non conjoncturel — signe l’obsolescence progressive d’un régime de pensée : celui qui identifie le pouvoir à une source souveraine, incarnée, stable, légitimée.
+Si la modernité politique a trouvé dans la souveraineté représentative son axe structurant, sa fiction fondatrice et sa promesse régulatrice, cette architecture intellectuelle et institutionnelle semble aujourd’hui en proie à une désynchronisation profonde avec les formes effectives de la régulation contemporaine. La souveraineté, dans sa formulation classique — qu’elle s’incarne dans le peuple, la nation, l’État, le contrat ou la loi — présuppose une centralité décisionnelle, une légitimité visible, une continuité symbolique entre le fondement et l’exercice du pouvoir.
 
-À cette crise de la souveraineté s’ajoute l’épuisement des grilles de lecture fondées sur le sujet autonome, contractuel, rationnel — figure centrale de la philosophie politique moderne. La fiction du citoyen-individu, maître de lui-même, capable d’entrer en délibération avec autrui, producteur d’une volonté générale informée, n’a plus de prise réelle sur les architectures décisionnelles automatisées, sur les normes codifiées par délégation, sur les processus algorithmiques opérant sans concertation. L’idéal contractualiste — au fondement des démocraties libérales occidentales — repose sur une scène d’égalité juridique, d’information partagée, de temporalité différée. Or les régulations actuelles, dans le champ fiscal, sanitaire, technologique, éducatif ou même sécuritaire, se déploient sans que ces conditions soient réunies. Le sujet y est affecté avant même d’avoir été informé ; il y est inclus sans qu’on le consulte ; il y est contraint sans avoir la possibilité d’émettre un désaccord opposable. La subjectivité politique classique — cette figure du citoyen capable de comprendre, d’argumenter, de consentir ou de refuser — est contournée par des formats de décision qui n’appellent plus ni la volonté, ni la délibération, ni même la conscience. L’archicratie commence précisément là où le pouvoir ne passe plus par le sujet.
+Or, ce que nous observons aujourd’hui dans la majorité des dispositifs régulateurs, c’est une crise de la souveraineté représentative non pas tant dans sa légitimité déclarée que dans sa capacité à structurer les prises réelles sur le monde. La scène parlementaire subsiste, mais elle est fréquemment contournée ; les mécanismes électoraux se perpétuent, mais ils échouent souvent à peser sur les déterminations majeures ; les figures institutionnelles traditionnelles persistent, mais elles ne sont plus toujours les lieux effectifs de production, de justification et de révision des normes. Ce déphasage — structurel, et non conjoncturel — ne signifie pas la disparition du politique, mais la transformation de ses modes de régulation.
 
-Mais cette crise des catégories héritées n’est pas une vacance : elle est immédiatement occupée par des formes nouvelles de régulation — que nous appelons ici *archicratiques*. Car ce n’est pas l’absence de pouvoir qui domine, mais sa redistribution silencieuse selon des régimes techno-fonctionnels. Nous assistons à une montée en régime de ce que Foucault nommait déjà *les dispositifs de gouvernementalité* : régulations discrètes, réparties, non centralisées, opérant par la norme, le calcul, la procédure, le protocole, l’interface, le flux. Ce sont des décisions sans fondement visible, sans discours justificatif, sans énonciateur identifiable. La décision se donne comme évidence procédurale, comme injonction technique, comme impératif statistique. L’ordre n’est plus commandé, il est implémenté ; il ne se fonde plus dans la loi, mais dans l’algorithme ; il ne se légitime plus par le débat, mais par le chiffre.
+À cette crise de la souveraineté s’ajoute l’épuisement des grilles de lecture fondées sur le sujet autonome, contractuel et rationnel, figure centrale de la philosophie politique moderne. La fiction du citoyen-individu, maître de lui-même, capable d’entrer en délibération avec autrui et de participer à une volonté générale informée, n’a plus de prise suffisante sur des architectures décisionnelles automatisées, sur des normes codifiées par délégation, sur des processus algorithmiques opérant à distance ou sans concertation réelle. Le sujet y est souvent affecté avant même d’avoir été informé ; inclus sans être consulté ; contraint sans pouvoir formuler un désaccord effectivement opposable. La subjectivité politique classique se trouve ainsi contournée par des formats de décision qui n’appellent plus nécessairement ni la volonté, ni la délibération, ni même la conscience explicite des sujets affectés.
 
-Cette montée archicratique s’observe dans la prolifération de gouvernances sans contre-pouvoir : agences indépendantes, plateformes numériques, circuits de certification, autorités administratives sans délibération parlementaire. Ce sont des formes de régulation qui ne sont pas illégales, mais qui échappent à toute mise en scène démocratique. Le débat n’est pas supprimé : il est rendu impossible. Les délais ne sont pas raccourcis : ils sont supprimés. Les voies de recours ne sont pas fermées : elles sont devenues impraticables. L’archicratie est ce régime où la décision opère sans justification explicite, où l’ordre normatif n’a plus besoin de fondation symbolique, et où le politique est remplacé par la régulation performative.
+Mais cette crise des catégories héritées n’est pas une vacance. Elle signale au contraire l’émergence de formes de régulation dont les prises réelles se redistribuent selon des logiques techno-fonctionnelles, administratives, protocolaires ou computationnelles. Ce ne sont pas des formes qu’il faut appeler archicratiques au sens fort, dès lors qu’elles tendent précisément à soustraire la régulation à la scène d’épreuve ; elles relèvent plutôt de dynamiques de désarchicration, d’archicratistique, ou, lorsqu’elles se referment durablement sur leur propre logique d’exécution, de dérives autarchicratiques.
 
-Dès lors, ce que ce chapitre propose, c’est un paradigme non pas alternatif mais *diagnostic* : il ne s’agit pas d’imaginer une nouvelle utopie du pouvoir juste, mais de produire une grille d’intelligibilité critique des régulations sans scène. Car un paradigme n’est pas une hypothèse théorique isolée ; il est une manière de rendre pensable ce qui échappait jusqu’alors aux catégories existantes. Dans notre cas, il s’agit de rendre visibles, pensables et opposables les formes de régulation qui opèrent *en dehors* des critères classiques du politique. Le paradigme archicratique est un paradigme de la non-scène : il suppose l’effectivité sans justification, la décision sans énonciateur, la procédure sans fondement, la régulation sans contradictoire.
+Ce que nous voyons proliférer, ce sont des régulations discrètes, réparties, non centralisées, opérant par la norme, le calcul, la procédure, le protocole, l’interface ou le flux : décisions à fondement peu visible, à justification faible, à énonciateur diffus, qui se donnent comme évidences procédurales, injonctions techniques ou impératifs statistiques. L’ordre n’y est plus principalement commandé ; il est implémenté. Il ne se fonde plus toujours dans une loi explicitement débattue ; il s’inscrit dans des chaînes opératoires, des standards, des métriques, des architectures logicielles ou des agencements institutionnels partiellement soustraits à l’épreuve.
 
-Or, pour être valide, un tel paradigme doit être opposable. C’est-à-dire qu’il doit permettre de formuler un diagnostic vérifiable, contestable, falsifiable, reproductible. Il doit désigner des objets de repérage : scènes absentes, fondements éteints, délais supprimés, procédures automatiques, figures d’intercession techniques. Il doit nommer des configurations typiques : régimes où tout semble fonctionnel, mais où rien ne peut plus être remis en cause. Il doit permettre une lecture différenciée du réel, et non une généralisation rhétorique. C’est à cette condition — à la fois théorique, épistémique et politique — que le paradigme archicratique peut s’imposer comme une nouvelle grammaire critique de la régulation contemporaine.
+Cette montée autarchicratique s’observe dans la prolifération de gouvernances sans contre-pouvoir : agences indépendantes, plateformes numériques, circuits de certification, autorités administratives sans délibération parlementaire effective. Ce sont des formes de régulation qui ne sont pas nécessairement illégales, mais qui échappent progressivement à une mise en scène démocratique substantielle. Le débat n’y est pas frontalement supprimé : il est rendu inopérant. Les délais ne sont pas toujours abolis : ils deviennent insuffisants, fictifs ou impraticables. Les voies de recours ne sont pas nécessairement closes en droit : elles cessent d’être effectivement opposables. L’autarchicratie ne désigne donc pas ici un méta-régime symétrique de l’archicratie, mais la dérive par laquelle des architectures régulatrices continuent d’opérer tout en se soustrayant à la scène d’épreuve, en affaiblissant l’exposition de leurs fondements et en comprimant le politique dans l’exécution performative de leurs propres procédures.
 
-La crise sanitaire du COVID-19, à cet égard, a constitué une épreuve paradigmatique : décisions exceptionnelles prises en Conseil de défense, sans publication des débats, sans délais, sans contradictoire ; régulations sociales massives imposées par décret, par indicateurs, par plateformes ; gouvernance par courbe épidémique, sans justification autre que l’anticipation algorithmique. Dans ce moment extrême, le paradigme archicratique a révélé sa capacité à lire ce que les catégories classiques ne permettaient plus d’interpréter. De même, dans la gouvernance algorithmique des aides sociales, dans la notation automatique des élèves ou dans la gestion budgétaire par règles européennes automatiques, nous observons des dispositifs où *la régulation opère sans pouvoir visible, sans scène explicite, sans fondement justifié*. Ce n’est pas la fin du politique, c’est sa mutation silencieuse. Et c’est cette mutation que l’archicratie nous permet de penser, de cartographier, de critiquer — à condition que le paradigme se dote d’une architecture rigoureuse, d’une typologie opératoire, d’une exigence de validation, et d’un langage partagé. Ce chapitre en jette les fondements.
+Dès lors, ce que ce chapitre propose, ce n’est pas de rebaptiser “archicratie” la non-scène contemporaine, mais de construire un paradigme capable de la diagnostiquer. Le paradigme archicratique n’est pas un paradigme de la non-scène ; il est une grammaire critique permettant de repérer les conditions sous lesquelles une régulation devient fondée, opérante et révisable — ou, au contraire, dérive vers l’opacité, l’indisputabilité et la fermeture, c’est-à-dire l’autarchicratie. Il ne vise donc pas à célébrer une mutation silencieuse du pouvoir, mais à rendre visibles, pensables et opposables les écarts entre une régulation pleinement archicratique, articulant arcalité, cratialité et archicration, et des dispositifs qui, tout en continuant d’opérer, se soustraient à la scène de leur propre épreuve. C’est à cette condition qu’un tel paradigme peut prétendre à une véritable portée diagnostique, critique et politique.
+
+Or, pour être valide, un tel paradigme doit être opposable. C’est-à-dire qu’il doit permettre de formuler un diagnostic vérifiable, contestable, falsifiable, reproductible. Il doit désigner des objets de repérage : scènes neutralisées, mimées ou relocalisées hors d’atteinte ; fondements opacifiés, euphémisés ou difficilement exposables ; délais comprimés, fictifs ou pratiquement supprimés, procédures automatiques, figures d’intercession techniques. Il doit nommer des configurations typiques : régimes où tout semble fonctionnel, mais où rien ne peut plus être remis en cause. Il doit permettre une lecture différenciée du réel, et non une généralisation rhétorique. C’est à cette condition — à la fois théorique, épistémique et politique — que le paradigme archicratique peut s’imposer comme une nouvelle grammaire critique de la régulation contemporaine.
+
+La crise sanitaire du COVID-19, à cet égard, a constitué une épreuve paradigmatique : décisions exceptionnelles prises en Conseil de défense, sans publication des débats, avec des délais comprimés et un contradictoire fortement réduit ; régulations sociales massives imposées par décret, par indicateurs, par plateformes ; gouvernance par courbe épidémique, avec des justifications largement internalisées dans la logique de l’anticipation sanitaire. Dans ce moment extrême, le paradigme archicratique a révélé sa capacité à lire ce que les catégories classiques ne permettaient plus d’interpréter. De même, dans la gouvernance algorithmique des aides sociales, dans la notation automatique des élèves ou dans la gestion budgétaire par règles européennes automatiques, nous observons des dispositifs où la régulation opère à travers des chaînes de décision faiblement visibles, à scène d’épreuve comprimée ou relocalisée, et à fondements difficilement exposables pour ceux qu’ils affectent. Ce n’est pas la fin du politique, c’est sa mutation silencieuse. Et c’est cette mutation que le paradigme archicratique nous permet de penser, de cartographier et de critiquer — à condition qu’il se dote d’une architecture rigoureuse, d’une typologie opératoire, d’une exigence de validation et d’un langage partagé.
 
 ## 1.1 — Hypothèse fondatrice : L’archicratie comme paradigme triadique de régulation
 
@@ -52,11 +58,11 @@ Le premier pôle est celui de *l’arcalité*. L’arcalité n’est ni une simp
 
 Le second pôle est celui de *la cratialité*. La cratialité désigne la capacité effective d’un dispositif à produire des effets dans le monde : son opérativité, sa puissance d’action, sa capacité à structurer, à contraindre, à transformer. Elle inclut les infrastructures matérielles (bâtiments, réseaux, plateformes), les dispositifs techniques (logiciels, bases de données, interfaces), les procédures (circulaires, décrets, codifications), les corps organisés (administrations, directions, opérateurs), ainsi que les flux (budgétaires, logistiques, cognitifs) qui permettent à la régulation de s’effectuer. La cratialité n’est pas nécessairement visible, mais elle est toujours active. Elle est la force sans laquelle la norme reste lettre morte, la capacité sans laquelle le fondement demeure incantation. C’est la force de transformation, mais aussi, potentiellement, celle de capture, de verrouillage ou d’effacement de la scène politique.
 
-Le troisième pôle, enfin, est celui de *l’archicration*. Ce néologisme désigne la capacité d’un ordre à se rendre *disputable* : c’est-à-dire à instituer une scène, un moment, un dispositif, où l’ordre peut être mis en épreuve, critiqué, reformulé, contesté, amendé. L’archicration est ce qui rend le pouvoir *opposable*, non dans un sens antagonique, mais dans un sens procédural, différé, dialogique. Elle prend la forme d’un contradictoire institué, d’un recours possible, d’un délai interprétatif, d’un droit de parole, d’un espace de reconfiguration. Là où l’arcalité fonde, où la cratialité opère, l’archicration dispute — et en disputant, elle garantit la *viabilité politique* du dispositif. Sans elle, la régulation devient une pure mécanique ; avec elle, elle devient une architecture habitable.
+Le troisième pôle, enfin, est celui de *l’archicration*. Ce néologisme désigne la capacité d’un ordre à se rendre *disputable* : c’est-à-dire à instituer une scène, un moment, un dispositif, où l’ordre peut être mis en épreuve, critiqué, reformulé, contesté, amendé. L’archicration est ce qui rend le pouvoir *opposable*, non dans un sens antagonique, mais dans un sens procédural, différé, dialogique. Elle prend la forme d’un contradictoire institué, d’un recours possible, d’un délai interprétatif, d’un droit de parole, d’un espace de reconfiguration. Là où l’arcalité fonde, où la cratialité opère, l’archicration dispute — et en disputant, elle garantit la *viabilité politique* du dispositif.
 
-Mais ce qui fait la force heuristique du paradigme archicratique, c’est que ces trois pôles ne sont pas des catégories séparées, ni des moments successifs, mais des *dimensions co-présentes* de tout dispositif. Chacun peut dominer, se retrancher, se dissoudre, ou se substituer aux autres, mais leur tension constitue le *champ de régulation*. Ce trépied constitue ainsi une véritable *grille différentielle de lecture* des régulations : il permet de repérer ce qui fonde sans agir, ce qui agit sans fonder, ce qui opère sans être disputé — et, symétriquement, ce qui fonde tout en opérant, ce qui opère tout en permettant la contestation, ce qui conteste à partir d’un fondement consistant.
+Mais ce qui fait la force heuristique du paradigme archicratique, c’est que ces trois pôles ne sont pas des catégories séparées, ni des moments successifs, mais des *dimensions co-présentes* de tout dispositif. Chacun peut dominer, se retrancher, se dissoudre, ou se substituer aux autres, mais leur tension constitue le *champ de régulation*. Ce trépied constitue ainsi une véritable *grille différentielle de lecture* des régulations : il permet de repérer ce qui fonde sans prise opératoire suffisante, ce qui agit sur fondement peu exposable, ce qui opère sous archicration neutralisée ou rendue pratiquement inopérante — et, symétriquement, ce qui fonde tout en opérant, ce qui opère tout en laissant place à la contestation, ce qui conteste à partir d’un fondement consistant.
 
-Ce paradigme triadique ne repose donc pas sur une essence du politique, mais sur une condition de possibilité de la régulation. Il ne dit pas ce que *doit être* un bon régime, mais ce qui fait qu’un ordre peut être dit *politique*, c’est-à-dire exposé à l’épreuve, fondé dans un sens, et transformateur d’une réalité. Dans un contexte où la scène politique se disloque, où les régulations deviennent silencieuses, où les fondements sont euphémisés et les disputes neutralisées, la force de ce paradigme est de *restituer une cartographie* du fait politique. Il ne suffit plus d’invoquer la légitimité, ni de dénoncer la technicisation : il faut *déplier* chaque dispositif en ses composantes fondamentales — fondation, opération, régulation — et en comprendre les combinaisons, les déséquilibres, les absences, les ruptures.
+Ce paradigme triadique ne repose donc pas sur une essence du politique, mais sur une condition de possibilité de la régulation. Il ne dit pas ce que *doit être* un bon régime, mais ce qui fait qu’un ordre peut être dit *politique*, c’est-à-dire exposé à l’épreuve, fondé dans un sens, et transformateur d’une réalité. Dans un contexte où la scène politique se disloque, où les régulations deviennent silencieuses, où les fondements sont euphémisés et les disputes neutralisées, la force de ce paradigme est de *restituer une cartographie* du fait politique. Il ne suffit plus d’invoquer la légitimité, ni de dénoncer la technicisation : il faut *déplier* chaque dispositif en ses composantes fondamentales — fondation, opération, régulation — et en comprendre les combinaisons, les déséquilibres, les mises en latence, les neutralisations et les ruptures d’articulation.
 
 C’est sur cette base que se construiront, dans les sections suivantes, une typologie des arcalités, des cratialités et des archicrations, une cartographie interne/externe de leurs interactions, ainsi qu’une analyse critique de leurs configurations pathologiques. Ce triptyque constitue la structure paradigmatique minimale pour analyser les dispositifs politiques en dehors des grilles souverainistes, contractualistes ou fonctionnalistes. Et c’est précisément en les confrontant à la réalité — textes, objets, fonctions, temporalités, cas d’usage — que nous en testerons la robustesse.
 
@@ -92,7 +98,7 @@ Le terme de cratialité comme nous l’avons vu en préambule dérive ici du rad
 
 Dans les régimes politiques classiques, on identifie la *cratialité* à l’exécutif : ministère, force publique, budget, bras armé. Mais cette lecture est à la fois trop réductrice et historiquement datée. La *cratialité* contemporaine excède largement les figures classiques du pouvoir d’État. Elle s’incarne dans des *algorithmes*, des *tableaux de bord*, des *logiciels d’évaluation*, des *systèmes de logistique globale*, des *normes ISO*, des *actes administratifs unilatéraux*, des *marchés publics automatisés*, des *protocoles cryptés*, des *formulaires numériques inaccessibles*. Elle peut être discrète, discrétionnaire, distribuée, voire disséminée jusqu’à devenir opaque. Mais elle est toujours active : elle fait advenir un effet de régulation.
 
-C’est pourquoi la *cratialité* ne saurait être conçue comme un simple rouage intermédiaire entre la fondation (*arcalité*) et la révision (*archicration*). Elle n’est ni instrument, ni exécution pure. Elle possède sa logique propre, ses effets d’autonomisation, ses inerties internes, ses formes d’expansion ou de court-circuit. Elle peut fonctionner sans justification — c’est le cas des algorithmes non documentés — et sans épreuve — c’est le cas des procédures automatiques non opposables. C’est en cela qu’elle constitue l’un des points névralgiques du basculement archicratique : là où la *cratialité* devient *indépendante*, *autosuffisante*, *désarrimée*, elle cesse d’être un vecteur de régulation pour devenir un vecteur de domination silencieuse.
+C’est pourquoi la *cratialité* ne saurait être conçue comme un simple rouage intermédiaire entre la fondation (*arcalité*) et la révision (*archicration*). Elle n’est ni instrument, ni exécution pure. Elle possède sa logique propre, ses effets d’autonomisation, ses inerties internes, ses formes d’expansion ou de court-circuit. Elle peut fonctionner comme si elle n’avait plus à répondre explicitement de ses justifications — c’est le cas des algorithmes non documentés — et comme si la scène d’épreuve n’avait plus de prise effective sur son cours ordinaire — c’est le cas des procédures automatiques rendues pratiquement non opposables. C’est en cela qu’elle constitue l’un des points névralgiques du basculement archicratique : là où la *cratialité* devient *indépendante*, *autosuffisante*, *désarrimée*, elle cesse d’être un vecteur de régulation pour devenir un vecteur de domination silencieuse.
 
 Or, comme l’*arcalité*, la *cratialité* se donne elle aussi selon une double topologie : interne et externe. Une *cratialité* est dite *interne* lorsqu’elle repose sur les moyens d’action propres au dispositif : administration, personnels, processus décisionnels, procédures codifiées, infrastructures spécifiques. Elle est dite *externe* lorsqu’elle mobilise des ressources extérieures : cabinets de conseil, normes transnationales, plateformes numériques privées, logistiques externalisées, financements conditionnés, technologies exogènes. Ce clivage interne/externe n’est pas secondaire : il est décisif pour comprendre les asymétries de pouvoir, les dépendances structurelles, les logiques de capture. Un hôpital, par exemple, peut être cratialisé de l’intérieur par son système de codage et ses tableaux d’affectation, ou de l’extérieur par des normes budgétaires européennes ou des logiciels achetés à des firmes privées.
 
@@ -108,11 +114,11 @@ Ce n’est pas la performance qui fait la validité politique d’une *cratialit
 
 #### **L’*archicration* : ce qui dispute, conteste, met en épreuve, arbitre**
 
-L’*archicration* constitue le troisième pôle du paradigme archicratique et, à bien des égards, son point d’incandescence politique : c’est elle qui transforme une régulation en un ordre véritablement *politique*. Là où l’*arcalité* fonde et où la *cratialité* opère, l’*archicration* institue l’épreuve, ouvre la dispute, rend possible la contestation organisée, et par là confère à l’ordre de régulation une dimension dialogique et réflexive. Sans *archicration*, une régulation n’est qu’un flux ; le pouvoir n’est qu’un automatisme ; le politique s’efface derrière la procédure. L’*archicration* est donc la scène instituée du différé, du contradictoire, du droit de regard et de la reprise.
+L’archicration constitue le troisième pôle du paradigme archicratique et, à bien des égards, son point d’incandescence politique : c’est elle qui transforme une régulation en un ordre véritablement politique. Là où l’arcalité fonde et où la cratialité opère, l’archicration institue l’épreuve, ouvre la dispute, rend possible la contestation organisée, et confère à l’ordre de régulation une dimension dialogique et réflexive. Lorsqu’elle est neutralisée, mimée, relocalisée hors d’atteinte ou rendue pratiquement inopérante, la régulation tend à devenir une pure mécanique ; lorsqu’elle est tenue comme scène effective de reprise, elle devient une architecture habitable.
 
 Le terme lui-même est construit à partir de *ἀρχὴ* (principe, origine, autorité) et *κρατέω* (être ou devenir le maître). Il désigne donc la capacité d’un dispositif de régulation à se rendre *opposable et amendable* dans un cadre institué : une instance, un rituel, une temporalité qui permet aux acteurs concernés de formuler, argumenter, contester, reconfigurer. C’est l’anti-mimétisme de la scène : non pas faire semblant d’écouter, mais *produire les conditions réelles* de l’écoute, du délai, du recours, de la révision. L’*archicration* n’est pas une option morale, ni un supplément d’âme procédural ; elle est la condition même de l’habitation politique d’un ordre, le fait d’en être maître, d’en devenir autorité.
 
-Historiquement, les sociétés se sont dotées de formes d’*archicration* très variées : tribunaux, parlements, assemblées populaires, chambres de recours, médiations rituelles, procédures de droit coutumier, juridictions supra-étatiques. Ce sont des *scènes instituantes* qui ralentissent l’acte, l’exposent, l’ouvrent à la pluralité, et, ce faisant, lui confèrent une légitimité durable. Mais ces scènes peuvent se fermer, se vider, se fragmenter, ou être capturées. Dans les dispositifs archicratiques contemporains, l’*archicration* est souvent absente, mimée ou neutralisée. On convoque une « consultation publique » dont les résultats sont déjà fixés ; on ouvre une « plateforme participative » dont les algorithmes filtrent les réponses ; on institue des « délais de recours » dont la brièveté ou la complexité les rend impraticables. Il en résulte un effet d’évanescence de la scène : elle est là en apparence, mais elle n’opère plus en réalité.
+Historiquement, les sociétés se sont dotées de formes d’*archicration* très variées : tribunaux, parlements, assemblées populaires, chambres de recours, médiations rituelles, procédures de droit coutumier, juridictions supra-étatiques. Ce sont des *scènes instituantes* qui ralentissent l’acte, l’exposent, l’ouvrent à la pluralité, et, ce faisant, lui confèrent une légitimité durable. Mais ces scènes peuvent se fermer, se vider, se fragmenter, ou être capturées. Dans les dispositifs archicratiques contemporains, l’archicration est souvent neutralisée, mimée, relocalisée hors d’atteinte ou rendue pratiquement inopérante. On convoque une « consultation publique » dont les résultats sont déjà fixés ; on ouvre une « plateforme participative » dont les algorithmes filtrent les réponses ; on institue des « délais de recours » dont la brièveté ou la complexité les rend impraticables. Il en résulte un effet d’évanescence de la scène : elle est là en apparence, mais elle n’opère plus en réalité.
 
 C’est pourquoi l’analyse archicratique exige de penser l’*archicration* en tant que *dimension constitutive*, et non comme simple accessoire. Comme pour l’*arcalité* et la *cratialité*, l’*archicration* se déploie selon une double topologie : elle peut être interne — lorsqu’un dispositif institue en son sein des mécanismes de contestation et d’ajustement (conseils délibératifs, commissions de médiation, audits internes, organes de gouvernance participative) — ou externe — lorsqu’il est soumis à des scènes de contrôle ou d’épreuve extérieures (juridictions supranationales, contre-pouvoirs citoyens, presse, ONG, instances internationales). Ces deux modalités sont cruciales : un dispositif peut être très opposable en externe mais totalement fermé en interne, ou inversement. La santé démocratique d’une régulation se mesure à la combinaison des deux.
 
@@ -122,7 +128,7 @@ L’*archicration* ne se limite pas à ce qui autorise la critique ; elle est ce
 
 Enfin, comme pour l’*arcalité* et la *cratialité*, l’*archicration* doit pouvoir être mesurée, qualifiée, falsifiée. Il ne suffit pas d’affirmer qu’une scène existe ; il faut interroger sa qualité : est-elle accessible, proportionnée, pluraliste, transparente, effective ? Est-elle un véritable lieu de remise en cause ou une simple mise en scène ? Ces questions sont au cœur de l’analyse archicratique. Elles seront systématisées dans la section 1.6, où nous formulerons des critères d’opposabilité et d’authentification, et testées empiriquement dans les études de cas du chapitre.
 
-Ainsi, l’*archicration* complète le triptyque fondateur du paradigme archicratique. Sans elle, la régulation n’est qu’un flux technique ; avec elle, elle redevient un ordre politique. Elle n’est pas un supplément éthique, mais une condition de viabilité. Elle n’est pas un idéal abstrait, mais une variable concrète, observable, localisable, qui signe la différence entre un dispositif gouvernant et un dispositif administrant. Et c’est précisément parce qu’elle est aujourd’hui menacée, neutralisée ou mimée que le paradigme archicratique s’impose : pour rendre visible ce qui se perd, pour diagnostiquer ce qui persiste, et pour imaginer ce qui pourrait s’instituer.
+Ainsi, l’*archicration* complète le triptyque fondateur du paradigme archicratique. Privée d’archicration effective, la régulation tend à n’être plus qu’un flux technique ; lorsqu’une scène de reprise demeure praticable, elle redevient un ordre politique. Elle n’est pas un supplément éthique, mais une condition de viabilité. Elle n’est pas un idéal abstrait, mais une variable concrète, observable, localisable, qui signe la différence entre un dispositif gouvernant et un dispositif administrant. Et c’est précisément parce qu’elle est aujourd’hui menacée, neutralisée ou mimée que le paradigme archicratique s’impose : pour rendre visible ce qui se perd, pour diagnostiquer ce qui persiste, et pour imaginer ce qui pourrait s’instituer.
 
 Les trois prises ne se subsument jamais l’une l’autre : l’*arcalité* fonde, la *cratialité* oblige, l’*archicration* met en controverse réglée. Aucune ne vaut sans les deux autres ; toute lecture binaire serait régressive.
 
@@ -214,9 +220,9 @@ Chaque *objet d’archicration* doit donc être interrogé selon ces critères.
 
 Enfin, il convient d’insister sur la topologie des *objets archicratifs*. Ils peuvent être internes : conseils délibératifs, comités d’éthique, médiateurs, dispositifs de saisine interne, commissions de réexamen. Ils peuvent être externes : recours juridictionnels, mobilisation d’instances indépendantes (Défenseur des droits, Conseil d’État, Autorité de régulation), interventions médiatiques documentées, pétitions publiques structurées, tribunaux populaires. Un système politique robuste combine les deux : il s’auto-dispute en interne, mais se rend aussi disputable de l’extérieur.
 
-Dans des configurations archicratiques, les *objets d’archicration* sont souvent mimés en interne — pour donner l’illusion de la scène — tandis que les dispositifs externes d’opposabilité sont rendus inopérants, dilués ou purement formels. Ce n’est pas qu’un régime serait ouvertement archicratique ; c’est que certaines fonctions, certaines séquences ou certains vecteurs de régulation se déploient de manière archicratique : par neutralisation de l’épreuve, occultation des fondements et saturation opératoire. L’*archicratie* ne désigne donc pas une oligarchie instituée, mais une modalité silencieuse de la régulation qui peut traverser tous les régimes, tous les secteurs, et dont certains groupes sociaux ou fonctions deviennent les porteurs structurels — sans en revendiquer pour autant le nom. Nous les appelons ici : les *archicrates*.
+Dans des configurations autarchicratiques, les objets d’archicration sont souvent mimés en interne — pour donner l’illusion de la scène — tandis que les dispositifs externes d’opposabilité sont rendus inopérants, dilués ou purement formels. Ce n’est pas qu’un régime serait ouvertement autarchicratique ; c’est que certaines fonctions, certaines séquences ou certains vecteurs de régulation se déploient selon une logique autarchicratique : par neutralisation de l’épreuve, occultation des fondements et saturation opératoire. L’autarchicratie ne désigne donc pas une oligarchie instituée, mais une dérive silencieuse de la régulation qui peut traverser tous les régimes, tous les secteurs, et dont certains groupes sociaux ou certaines fonctions deviennent les porteurs structurels — sans en revendiquer pour autant le nom. Nous les appellerons ici, si l’on veut les nommer rigoureusement : des porteurs de fermeture autarchique.
 
-Car c’est bien cela qui est en jeu : non pas l’existence théorique d’une contestation, mais sa possibilité instituée, régulée, documentée. Là où l’archicration est absente, le pouvoir devient indiscutable — non par tyrannie explicite, mais par dissolution des conditions de la scène. Là où elle est simulée, le politique devient un théâtre d’ombres. Là où elle est instituée, explicite, traçable, elle redonne au pouvoir sa dimension dialogique, sa dimension temporelle, sa dimension politique.
+Car c’est bien cela qui est en jeu : non pas l’existence théorique d’une contestation, mais sa possibilité instituée, régulée, documentée. Là où l’archicration est neutralisée, mimée, relocalisée hors d’atteinte ou rendue pratiquement inopérante, le pouvoir tend à devenir indiscutable — non par tyrannie explicite, mais par dissolution des conditions effectives de la scène. Là où elle est simulée, le politique devient un théâtre d’ombres. Là où elle est instituée, explicite, traçable et opposable, elle redonne au pouvoir sa dimension dialogique, sa dimension temporelle, sa dimension politique.
 
 Les *objets archicratifs* ne sont donc ni accessoires ni résiduels : ils sont la clef de voûte du politique comme épreuve. Ce sont eux qui assurent qu’une norme n’est pas un destin, qu’une régulation peut être reconfigurée, qu’un ordre n’est pas clos. Ce sont eux qui, au sein de la structure archicratique, permettent que le pouvoir soit tenu pour comptable, et donc transformable.
 
@@ -226,7 +232,7 @@ Il est nécessaire mais non suffisant d’identifier des principes abstraits —
 
 Un badge d’accès, un formulaire de recours, un tableau de bord algorithmique, une charte d’éthique, une convocation à une commission, un registre de délibération, un logiciel de pilotage budgétaire ou un protocole de saisine sont autant d’objets d’apparence neutre — mais qui, situés dans un écosystème de régulation, expriment une position archicratique : ils sont les métonymies de la structure, au sens où chaque objet, bien qu’apparemment partiel, renvoie à l’ensemble du régime dont il procède.
 
-Un badge sans nom, sans fonction lisible, sans statut accessible ne signale pas seulement un problème d’accès : il objective une dissociation entre *cratialité* et *archicration*, en empêchant la formulation de toute contestation localisée. Une charte d’entreprise affichée dans un hall, non opposable juridiquement, manifeste une *arcalité* de façade, sans ancrage normatif. Un algorithme qui produit des décisions sans en publier les règles institue une *cratialité* opaque, sans archicration possible. Ce sont là des objets discrets — mais qui configurent le pouvoir, organisent l’action, orientent la reconnaissance, verrouillent les possibilités de mise en cause.
+Un badge sans nom, sans fonction lisible, sans statut accessible ne signale pas seulement un problème d’accès : il objective une dissociation entre *cratialité* et *archicration*, en empêchant la formulation de toute contestation localisée. Une charte d’entreprise affichée dans un hall, non opposable juridiquement, manifeste une *arcalité* de façade, sans ancrage normatif. Un algorithme qui produit des décisions sans en publier les règles institue une *cratialité* opaque, sans archicration effective possible. Ce sont là des objets discrets — mais qui configurent le pouvoir, organisent l’action, orientent la reconnaissance, verrouillent les possibilités de mise en cause.
 
 Lire une régulation politiquement, c’est donc lire les objets qui la rendent possible, et interroger la grammaire que ces objets rendent visible ou invisible. Or, cette grammaire ne peut être saisie qu’en articulant trois dimensions :
 
@@ -244,11 +250,11 @@ Mais cette lecture métonymique ne s’oppose pas à une lecture systémique : a
 
 Si le paradigme archicratique repose sur cette tripartition fondamentale, il serait erroné d’en faire une grille statique ou une typologie figée. Ce qui fait sa valeur heuristique ne se résume pas en la distinction de ces trois pôles, mais dans la mise en tension dynamique qui les relie, les contraint, les déséquilibre ou les ajuste dans toute situation de régulation. Loin d’être des sphères séparées, ces trois dimensions n’existent que dans leur interaction mutuelle, dans une dialectique structurante où chacune affecte la viabilité des deux autres. C’est cette logique d’interdépendance — parfois harmonieuse, souvent tendue, parfois rompue — qui constitue la véritable mécanique différentielle de l’analyse archicratique.
 
-L’*arcalité* peut exister sans *cratialité* : c’est le cas des idéaux solennels sans effectuation, des textes fondateurs devenus vestiges, des récits politiques non suivis d’action. La *cratialité* peut se déployer sans *arcalité* : c’est le régime du pur instrument, de la machine sans justification, du dispositif opératoire sans horizon. L’*archicration* peut être instituée sans prise réelle : c’est la critique sans effet, le recours sans impact, la procédure désarmée. Chacun de ces désajustements produit des formes pathologiques de régulation, non par la faute d’un défaut total, mais par la déconnexion des pôles entre eux. L’*archicratie* ne devient intelligible qu’en mesurant le degré d’articulation effective — et non déclarative — entre ces trois dimensions.
+L’arcalité peut subsister à l’état de vestige, de référence peu opérante ou de fondement faiblement mobilisé ; la cratialité peut s’autonomiser sur fond d’arcalité peu exposable ou faiblement assumée ; l’archicration peut être formellement instituée tout en restant sans prise réelle sur la trajectoire décisionnelle. Chacun de ces désajustements produit des formes pathologiques de régulation, non par la faute d’un défaut absolu, mais par la déconnexion ou la dégradation des pôles entre eux. L’archicratie ne devient intelligible qu’en mesurant le degré d’articulation effective — et non simplement déclarative — entre ces trois dimensions.
 
-Pour cette raison, il est nécessaire de substituer à la figure du triangle une figure tensorielle, où les forces de chaque pôle exercent une poussée, un rappel ou un affaissement sur les deux autres. Toute régulation produit ainsi un champ de forces, qui peut être tendu, équilibré, instable ou disjoint. L’*arcalité* oriente le sens ; la *cratialité* donne prise au réel ; l’*archicration* introduit le différé, le possible, l’inédit. Leur co-présence est la condition minimale d’un ordre politique habitable. Leur absence ou leur domination univoque constitue, à l’inverse, le signe d’un régime appauvri, voire fermé et autoritaire.
+Pour cette raison, il est nécessaire de substituer à la figure du triangle une figure tensorielle, où les forces de chaque pôle exercent une poussée, un rappel ou un affaissement sur les deux autres. Toute régulation produit ainsi un champ de forces, qui peut être tendu, équilibré, instable ou disjoint. L’*arcalité* oriente le sens ; la *cratialité* donne prise au réel ; l’*archicration* introduit le différé, le possible, l’inédit. Leur co-présence est la condition minimale d’un ordre politique habitable. Leur neutralisation, leur mise en latence ou leur domination univoque constitue, à l’inverse, le signe d’un régime appauvri, voire fermé et autoritaire.
 
-Ce n’est donc pas la présence de chacun des trois pôles, pris isolément, qui garantit la qualité politique d’une régulation, mais la manière dont ils se répondent, se nourrissent, se corrigent ou s’affrontent. Une *arcalité* active, mais non révisable, produit du dogmatisme. Une *cratialité* hyper-efficiente sans fondement engendre de la brutalité technicienne. Une *archicration* procédurale sans fondation partagée tourne à vide sans adhésion dans le pur arbitraire. L’analyse archicratique repose alors sur un principe de consistance dynamique : *toute régulation politiquement viable est un régime où la légitimité fondatrice, la puissance opératoire et la scène contradictoire s’équilibrent par ajustements réciproques.*
+Ce n’est donc pas la présence de chacun des trois pôles, pris isolément, qui garantit la qualité politique d’une régulation, mais la manière dont ils se répondent, se nourrissent, se corrigent ou s’affrontent. Une *arcalité* active, mais non révisable, produit du dogmatisme. Une *cratialité* hyper-efficiente à fondement peu exposable ou désarrimé engendre de la brutalité technicienne. Une *archicration* procédurale sans fondation partagée tourne à vide sans adhésion dans le pur arbitraire. L’analyse archicratique repose alors sur un principe de consistance dynamique : *toute régulation politiquement viable est un régime où la légitimité fondatrice, la puissance opératoire et la scène contradictoire s’équilibrent par ajustements réciproques.*
 
 Cette dynamique se lit dans la manière dont une règle renvoie à une doctrine, dont un instrument laisse place à une critique, dont une norme peut évoluer par révision. Prenons un exemple : un protocole sanitaire. Il peut être fondé (*arcalité* scientifique ou juridique), appliqué (*cratialité* technique et administrative), mais si aucune révision n’est possible en cas de controverse, l’*archicration* fait défaut — et le dispositif devient pure contrainte et imposition. À l’inverse, une procédure ouverte à la contestation qui ne serait pas adossée à un fondement clair produirait du désordre, du flottement ou de l’épuisement normatif.
 
@@ -262,11 +268,11 @@ Ainsi, loin de reposer sur une addition de fonctions ou un empilement de princip
 
 Encore faut-il que notre construction tripartite permette de repérer les régulations qui échouent, non par absence de dispositifs, mais par déséquilibre interne entre les trois pôles constitutifs du paradigme. C’est précisément dans ces cas limites — ces régimes pathologiques où un seul pôle écrase ou court-circuite les autres — que la robustesse analytique du paradigme archicratique peut se vérifier. Ce ne sont pas des anomalies anecdotiques, mais des figures structurantes de la régulation contemporaine, des formes typiques de désarticulation qui signent l’entrée dans une zone grise du politique : ni complètement illégitime, ni ouvertement dictatoriale, mais oblitérant l’opposabilité.
 
-La première configuration critique est celle de la *cratialité* orpheline, où la puissance d’agir est autonome, sans fondement clair, ni scène d’épreuve possible. On y observe des chaînes d’exécution hautement performantes — plateformes logistiques, tableaux de pilotage budgétaire, algorithmes décisionnels, procédures automatisées — qui fonctionnent sans invocation fondatrice (*arcalité*) et sans recours institué (*archicration*). La décision devient impersonnelle, inattaquable, et souvent non négociable. La puissance technique se substitue à la justification et à l’épreuve.
+La première configuration critique est celle de la cratialité orpheline, où la puissance d’agir tend à s’autonomiser sur fond d’arcalité faiblement exposable et d’archicration neutralisée, comprimée ou rendue pratiquement inopérante. On y observe des chaînes d’exécution hautement performantes — plateformes logistiques, tableaux de pilotage budgétaire, algorithmes décisionnels, procédures automatisées — qui fonctionnent avec des fondements peu explicités pour les affectés et avec des voies de reprise, de contestation ou de recours soit relocalisées hors d’atteinte, soit fictives, soit matériellement impraticables. La décision y devient impersonnelle, difficilement attaquable, et souvent non négociable dans les faits. Ce qui caractérise cette configuration n’est donc pas l’absence absolue de fondement ou de scène, mais leur dégradation opératoire : l’arcalité subsiste sous forme implicite, technique ou déléguée ; l’archicration subsiste comme possibilité affaiblie, mimée ou neutralisée ; tandis que la cratialité, elle, concentre l’effectivité.
 
 La seconde figure limite est celle de l’*arcalité* désincarnée, où les récits fondateurs subsistent — parfois en majesté — mais ne produisent plus d’effet régulateur. Constitutions vénérées, serments solennels, principes éthiques, déclarations universelles sont mobilisés dans les discours, affichés dans les chartes, mais ne traversent plus les dispositifs opératoires. Il en résulte un régime de performativité déconnectée : les institutions prétendent être fondées en droit ou en humanisme, mais leur fonctionnement réel s’émancipe totalement de ce socle. L’*arcalité* devient alors décorative, voire cyniquement instrumentalisée : c’est le cas des appels républicains dans des politiques autoritaires, des valeurs affichées dans des dispositifs inaccessibles, ou des codes d’éthique utilisés pour justifier des dispositifs de surveillance. Ce désajustement génère une forme de désorientation politique profonde, où la norme déclarée et la norme opératoire ne se rejoignent plus.
 
-La troisième pathologie est celle de l’*archicration* fictive, où des scènes de dispute sont instaurées, mais sans effectivité réelle. Le dispositif donne l’apparence d’un contradictoire — consultation publique, boîte à idées, forum participatif, convention citoyenne, droit de recours — mais en réalité, aucune des conditions de l’opposabilité n’est remplie : délais trop courts, opacité des motifs, non-publication des réponses, filtrage des revendications, absence de prise sur la décision finale. Cette forme de mise en scène procédurale produit une illusion de démocratie régulée, où la scène d’épreuve est ritualisée sans effet. L’*archicration* existe ici comme spectacle, non comme épreuve, et contribue paradoxalement à renforcer l’irréversibilité des décisions prises. C’est le cas par exemple de certaines concertations environnementales menées en urgence, où les contributions citoyennes sont enregistrées, mais sans être prises en compte ni motivées dans les décisions finales.
+La troisième pathologie est celle de l’*archicration* fictive, où des scènes de dispute sont instaurées, mais sans effectivité palpable. Le dispositif donne l’apparence d’un contradictoire — consultation publique, boîte à idées, forum participatif, convention citoyenne, droit de recours — mais en réalité, aucune des conditions de l’opposabilité n’est remplie : délais trop courts, opacité des motifs, non-publication des réponses, filtrage des revendications, absence de prise sur la décision finale. Cette forme de mise en scène procédurale produit une illusion de démocratie régulée, où la scène d’épreuve est ritualisée sans effet. L’*archicration* existe ici comme spectacle, non comme épreuve, et contribue paradoxalement à renforcer l’irréversibilité des décisions prises. C’est le cas par exemple de certaines concertations environnementales menées en urgence, où les contributions citoyennes sont enregistrées, mais sans être prises en compte ni motivées dans les décisions finales.
 
 Mais il existe aussi des cas où un seul pôle détourne ou capture les deux autres. On parlera alors de court-circuit paradigmatique, ou d’effet de surcodage. Ainsi, une cratialité surpuissante peut simuler un fondement (en produisant des justifications pseudo-techniques ou tautologiques : « c’est la procédure », « l’algorithme l’a déterminé »), tout en neutralisant la scène de l’épreuve (« ce n’est pas contestable, car c’est automatisé »). Nous nommons ce type de dérive : *régime hypercratial*.
 
@@ -274,9 +280,9 @@ Mais il existe aussi des cas où un seul pôle détourne ou capture les deux aut
 
 Enfin, une *archicration* *hypertrophiée* — une société saturée de recours, d’instances, de médiations — peut empêcher toute effectuation : c’est la régulation paralysée par la sur-opposabilité, la scène d’épreuve transformée en labyrinthe.
 
-Ces cas limites ne sont pas simplement pathologiques : ils sont heuristiquement structurants. Ils montrent comment l’équilibre entre les pôles ne relève ni d’une essence ni d’une norme, mais d’un jeu d’ajustement toujours instable, toujours à documenter. C’est dans leur désajustement que se révèlent les conditions minimales de viabilité politique d’un dispositif. Car un ordre peut survivre longtemps sans fondement (arcalité), ou sans épreuve (archicration), ou même sans action (cratialité), mais il cesse alors d’être un ordre politique habitable : il devient un régime bloqué de contrainte, de vacance ou d’impuissance.
+Ces cas limites ne sont pas simplement pathologiques : ils sont heuristiquement structurants. Ils montrent comment l’équilibre entre les pôles ne relève ni d’une essence ni d’une norme, mais d’un jeu d’ajustement toujours instable, toujours à documenter. C’est dans leur désajustement que se révèlent les conditions minimales de viabilité politique d’un dispositif. Car une formation collective peut se maintenir durablement sous déficit d’arcalité, sous atrophie de l’archicration, ou sous affaissement de la cratialité ; mais elle cesse alors d’être un ordre politique pleinement habitable. Elle persiste au prix d’une dégradation de sa co-viabilité, et tend à devenir un régime bloqué de contrainte, de vacance ou d’impuissance.
 
-Enfin, ces déséquilibres ne doivent pas être lus comme des erreurs de conception ou des dysfonctionnements ponctuels. Ils signalent souvent des régimes intentionnels de régulation, où l’absence de fondement, la fermeture de la dispute ou la saturation de l’opération sont stratégiquement construits pour éviter l’épreuve politique. C’est ici que le paradigme archicratique déploie sa force critique : en rendant visibles ces dispositifs qui, tout en étant fonctionnels, se soustraient à la critique, à la scène, à l’épreuve.
+Enfin, ces déséquilibres ne doivent pas être lus comme des erreurs de conception ou des dysfonctionnements ponctuels. Ils signalent souvent des régimes intentionnels de régulation, où le défaut d’exposition du fondement, la neutralisation de la dispute ou la saturation de l’opération sont stratégiquement construits pour éviter l’épreuve politique. C’est ici que le paradigme archicratique déploie sa force critique : en rendant visibles ces dispositifs qui, tout en étant fonctionnels, se soustraient à la critique, à la scène, à l’épreuve.
 
 Mais d’ores et déjà, cette exploration des désajustements initiaux nous permet de poser une hypothèse structurante : une régulation devient politiquement problématique non lorsqu’un pôle manque absolument, mais lorsque ses interactions avec les autres sont rompues, perverties, neutralisées. Ce sont ces configurations, ces bifurcations, ces effets de bascule que l’analyse archicratique doit pouvoir capter, nommer, décrire et critiquer.
 
@@ -302,7 +308,7 @@ La forme, en revanche, relève d’un niveau intermédiaire. Elle désigne les m
 
 Mais en-dessous de ces formes, il y a la structure régulatrice : un plan plus profond, plus transversal, plus déterminant, qui ne désigne ni les institutions ni les pratiques, mais les conditions même de possibilité de la régulation politique. Cette structure est ce qui permet — ou non — qu’un ordre se rende visible, controversable, habitable. Elle ne renvoie pas à une architecture constitutionnelle, mais à une configuration d’agencement entre ce qui fonde, ce qui opère, et ce qui permet d’en discuter. C’est là que se situe l’hypothèse archicratique : non au niveau des régimes ou des formes, mais au niveau de la structure régulatrice profonde, ce que l’on pourrait appeler, en empruntant à Lévi-Strauss ou à Althusser, un *inconscient politique de la régulation*.
 
-L’*archicratie* n’est donc pas un régime de plus. Elle n’est pas la cousine néolibérale de la démocratie, ni une dérive technocratique de l’État-nation. Elle est le nom donné à une structure de régulation sans scène instituée, sans fondement invocable, sans épreuve contradictoire formelle. Et à ce titre, elle peut traverser différents régimes, s’y superposer, y introduire des failles ou des inerties, s’y agglomérer comme un parasitage silencieux. Un régime peut être démocratique en apparence, mais archicratique dans sa structure opératoire réelle. Inversement, certaines formes autoritaires peuvent ménager des archicrations ponctuelles, permettant une conflictualité politique minimale. C’est ce qui rend l’archicratie si difficile à identifier, et si nécessaire à penser : elle ne se lit pas dans les institutions, mais dans la manière dont un ordre rend — ou non — la régulation opposable, différée, arbitrable.
+L’autarchicratie n’est donc pas un régime politique de plus. Elle n’est ni la cousine néolibérale de la démocratie, ni une simple dérive technocratique de l’État-nation. Elle désigne la dérive par laquelle des architectures régulatrices continuent d’opérer tout en se soustrayant progressivement à la scène d’épreuve : les fondements ne disparaissent pas nécessairement, mais deviennent de moins en moins susceptibles d’exposition ; les procédures contradictoires peuvent subsister, mais se vident, se simulent ou deviennent inopérantes ; et la régulation tend à se refermer sur sa propre logique d’exécution. À ce titre, l’autarchicratie peut traverser différents régimes politiques, s’y superposer, y introduire des inerties, des fermetures ou des parasitages silencieux. Un régime peut ainsi être démocratique en apparence, tout en dérivant vers une structure opératoire autarchicratique. Inversement, certaines formes autoritaires peuvent encore ménager des archicrations ponctuelles, permettant le maintien d’une conflictualité politique minimale. C’est ce qui rend l’autarchicratie difficile à identifier, et pourtant nécessaire à penser : elle ne se lit pas seulement dans les institutions, mais dans la manière dont un ordre rend — ou non — sa régulation exposable, opposable, différable et révisable.
 
 Cette distinction entre régime, forme, et structure n’est pas simplement académique. Elle est politiquement décisive. Car c’est elle qui permet d’éviter deux écueils fréquents : le fétichisme institutionnel (croire qu’un régime démocratique suffit à garantir une régulation juste), et le scepticisme cynique (penser que toute régulation est toujours déjà close, dominée, irréformable). L’*archicratie* introduit un plan d’analyse transversal, qui oblige à questionner non ce que les institutions prétendent, mais ce qu’elles permettent réellement en termes de fondement, d’opération, et de dispute. Elle ouvre une lecture différentielle du politique, fondée non sur l’étiquette (démocratie ou non), mais sur la qualité régulatrice de l’ordre.
 
@@ -320,7 +326,7 @@ Dit autrement, un *méta-régime* n’est pas une forme politique particulière,
 
 Cette grille permet par exemple de comparer un dispositif d’allocation d’aides sociales dans une démocratie représentative, un protocole sanitaire dans une dictature *soft*, ou un mécanisme d’ajustement budgétaire dans une structure supra-étatique. Ce qui compte, ce n’est pas l’étiquette politique du régime, mais la qualité de sa régulation au regard des trois critères fondamentaux : le fondement mobilisé (*arcalité*), les moyens d’effectuation (*cratialité*), et les possibilités instituées de contestation (*archicration*). L’*archicratie* devient ainsi un analyseur paradigmatique, c’est-à-dire une manière de lire des dispositifs en détectant ce qui s’y fonde, ce qui y opère, et ce qui s’y dispute — ou non.
 
-Cette approche n’est pas purement descriptive. Elle est diagnostique, critique, opposable. Elle permet de dire : « ici, l’ordre régulateur semble robuste, mais il est archicratique en ce sens qu’il est devenu indisputable » ; ou bien : « ce dispositif mobilise un fondement fort, mais il est cratialisé sans contrôle, et sans scène de recours ». En ce sens, l’*archicratie* n’est pas un concept mollement critique : elle est une épreuve conceptuelle pour les régimes existants, un test de viabilité démocratique ou politique, une mise à nu des écarts entre l’invocation des principes et la structure réelle de la régulation.
+Cette approche n’est pas purement descriptive. Elle est diagnostique, critique, opposable. Elle permet de dire : « ici, l’ordre régulateur semble robuste, mais il fonctionne désormais sur un mode autarchicratique, en ce qu’il devient indisputable » ; ou bien : « ce dispositif mobilise un fondement fort, mais sa cratialité se déploie avec un contrôle affaibli et une scène de recours neutralisée, comprimée ou rendue pratiquement inopérante ». En ce sens, l’archicratie n’est pas un concept mollement critique : elle est une épreuve conceptuelle pour les régimes existants, un test de viabilité politique, une mise à nu des écarts entre l’invocation des principes et la structure réelle de la régulation.
 
 Mais surtout, cette conceptualisation du *méta-régime archicratique* permet de dépasser deux impasses majeures des théories politiques classiques. La première, *normative*, qui suppose qu’un régime est légitime parce qu’il respecte formellement certaines règles (élections, séparation des pouvoirs, État de droit). Or, ces règles peuvent subsister tandis que la régulation réelle devient opaque, automatique ou imperméable à la contestation.
 
@@ -353,7 +359,7 @@ Il devient ainsi possible, grâce à cette grille tripolaire, de qualifier des r
 
 Mais encore faut-il que le paradigme soit explicatif, c’est-à-dire capable de rapprocher des phénomènes épars, de construire des séries intelligibles, de réduire la contingence apparente à des configurations discernables. Là encore, le paradigme archicratique s’impose par sa puissance intégratrice : il permet d’embrasser dans une même grille d’analyse des réalités qui, jusque-là, semblaient hétérogènes — parce que dispersées dans des domaines sectoriels (fiscalité, santé, climat, numérique, sécurité), ou parce qu’enveloppées dans des langages spécialisés (juridique, économique, algorithmique).
 
-C’est précisément cette capacité à unifier sans uniformiser, à articuler sans réduire, qui signe la force d’un paradigme. En *archicratie*, des phénomènes aussi variés que — la gouvernance sanitaire par indicateurs ; la régulation budgétaire par règles automatiques ; la gestion algorithmique des droits sociaux ; l’application de standards techniques globaux sans débat local ; ou encore la prolifération des plateformes numériques de notification unilatérale — peuvent être reliés, compris, comparés à l’aune d’une même question : *cette régulation est-elle fondée, opérante et opposable ?* Si l’un de ces trois pôles fait défaut, la régulation devient fragile, injustifiable ou autoritaire. Ainsi, ce que le paradigme archicratique rend possible, c’est une lecture transversale, critique, intersectorielle du politique contemporain — non plus à partir des formes visibles de pouvoir, mais à partir de ses pratiques effectives de régulation, de ses vecteurs techniques, et de ses seuils de dispute.
+C’est précisément cette capacité à unifier sans uniformiser, à articuler sans réduire, qui signe la force d’un paradigme. En *archicratie*, des phénomènes aussi variés que — la gouvernance sanitaire par indicateurs ; la régulation budgétaire par règles automatiques ; la gestion algorithmique des droits sociaux ; l’application de standards techniques globaux sans discussion locale ; ou encore la prolifération des plateformes numériques de notification unilatérale — peuvent être reliés, compris, comparés à l’aune d’une même question : *cette régulation est-elle fondée, opérante et opposable ?* Si l’un de ces trois pôles fait défaut, la régulation devient fragile, injustifiable ou autoritaire. Ainsi, ce que le paradigme archicratique rend possible, c’est une lecture transversale, critique, intersectorielle du politique contemporain — non plus à partir des formes visibles de pouvoir, mais à partir de ses pratiques effectives de régulation, de ses vecteurs techniques, et de ses seuils de dispute.
 
 #### Une opposabilité empirique : falsifiabilité, indicateurs et critères de lecture
 
@@ -369,13 +375,13 @@ Ces critères sont au nombre de quatre, que nous avons déjà évoqués en filig
 
 - La *possibilité de recours effectif* : une norme est politique si elle peut être contestée dans un délai raisonnable, devant une instance compétente, selon une procédure intelligible et des modalités non excluantes. Le formalisme du recours ne suffit pas ; c’est sa praticabilité qui importe.
 
-Ces quatre indicateurs peuvent être mesurés, étayés et comparés. Ils permettent d’objectiver le diagnostic archicratique, d’en délivrer une cartographie différenciée, et d’en circonscrire les seuils. Ils rendent la critique opératoire et la théorie falsifiable. Car il est tout à fait possible qu’un dispositif tienne sans scène, sans délai, sans recours, sans fondement clair — dans ce cas, notre paradigme devra s’avouer inopérant. C’est précisément cette possibilité qui fonde sa valeur scientifique.
+Ces quatre indicateurs peuvent être mesurés, étayés et comparés. Ils permettent d’objectiver le diagnostic archicratique, d’en délivrer une cartographie différenciée, et d’en circonscrire les seuils. Ils rendent la critique opératoire et la théorie falsifiable. Car il est tout à fait possible qu’un dispositif tienne avec une scène neutralisée ou relocalisée hors d’atteinte, avec des délais fictifs ou comprimés, avec des recours formellement ouverts mais pratiquement impraticables, avec des fondements difficiles à exposer ou à opposer. Dans ce cas, notre paradigme n’a pas à s’avouer inopérant : il doit précisément décrire, qualifier et mesurer cette neutralisation, cette compression, cette inopérance ou cette opacification. C’est précisément cette possibilité qui fonde sa valeur scientifique.
 
 Par ailleurs, ce paradigme pourra être confronté à des contre-exemples méthodiques — ce que nous ferons dans la section 1.10 — afin de tester la puissance de sa réfutabilité. Il ne s’agit pas de tout faire entrer dans le moule archicratique, mais de tester la pertinence du moule face à des réalités rétives, résistantes, voire incompatibles. C’est cela, l’esprit de la critique : ne pas chercher la confirmation, mais la disjonction révélatrice.
 
-En définitive, le paradigme archicratique ne vaut que par sa capacité à rendre visible ce qui opère sans justification, à déplier ce qui agit sans être discuté, à donner langue à ce qui neutralise le contradictoire. Il ne se présente pas comme une nouvelle théorie normative, ni comme un surplomb idéologique, mais comme une grille de détection des régulations silencieuses — celles qui se passent de scène, de délai, de motifs, de recours, et qui, de ce fait, court-circuitent la possibilité même du politique.
+En définitive, le paradigme archicratique ne vaut que par sa capacité à rendre visible ce qui opère à travers des justifications faiblement exposables, à déplier ce qui agit à travers des scènes comprimées, mimées ou relocalisées, à donner langue à ce qui neutralise le contradictoire sans jamais l’abolir purement et simplement. Il ne se présente pas comme une nouvelle théorie normative, ni comme un surplomb idéologique, mais comme une grille de détection des régulations silencieuses — celles où la scène se vide, où les délais deviennent fictifs, où les motifs deviennent inopposables, où les recours cessent d’être pratiquement saisissables, et qui, de ce fait, court-circuitent la possibilité même du politique.
 
-En ce sens, il est un paradigme à la fois critique et méthodique : critique, car il met à nu les absences, les évasions, les courts-circuits ; méthodique, puisqu’il les mesure, les nomme, les cartographie, et les expose à l’épreuve. Ce n’est qu’à cette double condition — fécondité analytique et opposabilité empirique — que le paradigme archicratique pourra prétendre à une légitimité scientifique, académique et politique. Et c’est sur cette base, et cette base seulement, qu’il pourra accompagner l’effort critique contemporain pour penser ce qui régule sans qu’on le voie, ce qui gouverne sans qu’on le dise, ce qui décide sans qu’on puisse le conteste.
+En ce sens, il est un paradigme à la fois critique et méthodique : critique, car il met à nu les neutralisations, les évasions, les courts-circuits ; méthodique, puisqu’il les mesure, les nomme, les cartographie, et les expose à l’épreuve. Ce n’est qu’à cette double condition — fécondité analytique et opposabilité empirique — que le paradigme archicratique pourra prétendre à une légitimité scientifique, académique et politique.
 
 ## **1.3 —** Les axiomes régulateurs du paradigme archicratique
 
@@ -401,7 +407,9 @@ Ce premier axiome constitue le socle ontologique minimal du paradigme archicrati
 
 Poser cet axiome, c’est affirmer que ces trois dimensions — même lorsqu’elles sont invisibles, réduites, capturées ou en dormance — sont toujours présentes, repérables, détectables, au moins de façon latente ou implicite. Autrement dit, on ne peut pas penser une régulation sans ce tripode, même si celui-ci est déséquilibré, distordu ou saboté. Un dispositif qui n’aurait ni *arcalité* (aucun principe fondateur ou récit de justification), ni *cratialité* (aucune opération effective, aucun vecteur d’action), ni *archicration* (aucun lieu ou possibilité de contestation ou de révision), ne serait pas un dispositif régulateur : ce serait un chaos, une contingence brute, un pur hasard ou un agrégat sans structure.
 
-Ce que cet axiome implique immédiatement, c’est un changement de regard épistémique. Il ne suffit pas de repérer les structures visibles du pouvoir (institutions, lois, autorités) : il faut traquer les trois prises constitutives dans tout agencement régulateur — y compris ceux qui prétendent ne pas être politiques, comme par exemple, les régulations algorithmiques, les logiques d’attribution budgétaire, les procédures hospitalières, les normes de conformité technique. Même là, il y a fondement, opération, et possibilité de contestation — et, au pire, leur mise en invisibilité stratégique. De sorte que ce n’est pas parce que l’*arcalité* est devenue silencieuse (par exemple : une légitimation implicite par la science ou par la nécessité technique), ni parce que l’*archicration* est éteinte (absence de scène de recours), que ces dimensions sont absentes : elles sont alors refoulées, verrouillées, court-circuitées — mais leur absence relative est elle-même un indice paradigmatique.
+Ce que cet axiome implique immédiatement, c’est un changement de regard épistémique. Il ne suffit pas de repérer les structures visibles du pouvoir (institutions, lois, autorités) : il faut traquer les trois prises constitutives dans tout agencement régulateur — y compris ceux qui prétendent ne pas être politiques, comme par exemple, les régulations algorithmiques, les logiques d’attribution budgétaire, les procédures hospitalières, les normes de conformité technique. Même là, il y a fondement, opération, et possibilité de contestation — et, au pire, leur mise en invisibilité stratégique. De sorte que ce n’est pas parce que l’*arcalité* est devenue silencieuse (par exemple : une légitimation implicite par la science ou par la nécessité technique), ni parce que l’*archicration* est neutralisée, verrouillée, relocalisée hors d’atteinte ou rendue pratiquement inopérante (absence de scène de recours), que ces dimensions sont absentes : elles sont alors refoulées, verrouillées, court-circuitées — mais leur absence relative est elle-même un indice paradigmatique.
+
+Toute régulation effective comporte, en acte ou en puissance, une arcalité, une cratialité et une archicration ; les pathologies contemporaines n’abolissent pas cette tripolarité, mais en opacifient les fondements, en autonomisent les opérations et en neutralisent, miment ou relocalisent la scène d’épreuve, jusqu’à la dérive autarchicratique.
 
 L’*axiome de coprésence* a donc une valeur heuristique fondamentale. Il permet de penser les situations où une régulation semble purement technique ou exclusivement administrative (*cratialité*) comme étant toujours aussi fondée dans un imaginaire (*arcalité*) et exposée ou soustraite à une épreuve (*archicration*). Il impose ainsi une lecture structurale de tout dispositif, qu’il soit juridique, logistique, algorithmique, sanitaire, éducatif, écologique ou financier. C’est une invitation à lire dans la matière du monde les tripodes de la régulation.
 
@@ -487,9 +495,9 @@ Autre réduction, lorsque tout est renvoyé à la dispute, à la consultation,
 
 L’histoire politique moderne offre de nombreux exemples de ces régimes déséquilibrés : républiques fondées sur des textes constitutionnels irréprochables, mais pratiquement inopérantes ; dictatures fonctionnelles et performantes bien que sans légitimité ni controverse possible ; démocraties dites « délibératives » paralysées par l’inflation des consultations sans pouvoir réel. Chaque fois qu’un pôle tend à se substituer aux deux autres, la régulation se dégrade — soit en simulacre, soit en oppression, soit en chaos.
 
-Ce que l’a*xiome de disjonction fonctionnelle* impose, c’est une lecture différentielle, exigeante, des configurations régulatrices. Il oblige à penser non seulement la présence des trois pôles, mais surtout leur non-confusion. Il n’est pas rare, en effet, que des dispositifs affichent un fondement alors qu’il ne s’agit que d’un effet de langage cratial ; qu’ils prétendent à la dispute alors qu’ils ne permettent aucun recours réel ; qu’ils opèrent à vide sans principe ni scène. L’*archicratie* elle-même, dans ses formes les plus avancées, mime les trois pôles tout en les court-circuitant — comme le montrent certaines plateformes de participation citoyenne entièrement encadrées par des algorithmes de tri et d’euphémisation, dites de modération.
+Ce que l’axiome de disjonction fonctionnelle impose, c’est une lecture différentielle, exigeante, des configurations régulatrices. Il oblige à penser non seulement la présence des trois pôles, mais surtout leur non-confusion. Il n’est pas rare, en effet, que des dispositifs affichent un fondement alors qu’il ne s’agit que d’un effet de langage cratial ; qu’ils prétendent à la dispute alors qu’ils ne permettent aucun recours réel ; qu’ils opèrent à vide sans principe exposable ni scène praticable. Ce ne sont pas là des formes accomplies de l’archicratie, mais des configurations autarchicratiques ou archicratistiques dans lesquelles les trois pôles sont mimés, exhibés ou stylisés tout en étant partiellement court-circuités — comme le montrent certaines plateformes de participation citoyenne entièrement encadrées par des algorithmes de tri, de hiérarchisation ou d’euphémisation.
 
-Autrement dit, ce que l’on croit parfois être une régulation équilibrée peut en réalité relever d’un effondrement fonctionnel déguisé, d’une substitution abusive, d’une délégation simulée. L’*axiome de disjonction fonctionnelle* agit alors comme outil de discernement critique : il permet de tester si un dispositif tient ensemble les trois fonctions, ou s’il glisse vers un monolithe politique — source de désajustement systémique.
+Autrement dit, ce que l’on croit parfois être une régulation équilibrée peut en réalité relever d’un effondrement fonctionnel déguisé, d’une substitution abusive, d’une délégation simulée. L’axiome de disjonction fonctionnelle (1.3.4) vient ensuite avertir que l’effacement, la neutralisation ou l’hypertrophie d’un seul pôle conduit nécessairement à une régulation pathologique. De sorte qu’un ordre privé de fondement exposable, de scène d’épreuve praticable ou de capacité opératoire effective n’est ni pleinement viable, ni légitime, ni habitable.
 
 Mais cet axiome a aussi une portée épistémologique et méthodologique. Il oblige l’analyste à disjoindre ce que la régulation tend à confondre. Il impose de ne pas se satisfaire d’un indicateur unique ou d’une déclaration de principe. Il exige de chercher, pour chaque dispositif : *Quelle est la source réelle de l’arcalité invoquée ? Quelle est la structure effective de la cratialité mobilisée ? Quelle est la scène concrète d’archicration instituée ?*
 
@@ -551,7 +559,7 @@ Cet axiome fonde également la dimension anti-dogmatique du paradigme archicrati
 
 **Tout paradigme qui prétend décrire les régulations politiques doit rendre possible sa propre mise à l’épreuve. Il doit produire des instruments de falsifiabilité, de critique interne et de différenciation analytique. Un paradigme non falsifiable est un dogme ; un cadre non différenciateur est un slogan.**
 
-Une régulation n’est réputée archicratique qu’à la condition d’instituer une scène contradictoire où les prétentions arcale et cratiale peuvent être opposées, arbitrées et révisées selon des procédures publiques et des indicateurs déclarés.
+Une régulation n’est réputée pleinement archicratique qu’à la condition de rendre possible une scène d’épreuve où les prétentions arcale et cratiale puissent être opposées, arbitrées et révisées selon des formes de contestation effectives, lesquelles peuvent être publiques, instituées, rituelles, situées ou faiblement codifiées, pourvu qu’elles soient praticables, opposables et capables d’infléchir la régulation.
 
 Il est une exigence trop oubliée des sciences sociales : un paradigme critique n’est pas une grille qui se plaque partout, mais une matrice qui se teste, qui s’affine, qui peut échouer. Toute proposition théorique sur le pouvoir, la régulation, l’opposabilité doit se soumettre à une exigence que Karl Popper formulait dès 1934 : la condition de scientificité minimale d’un énoncé est sa capacité à être réfuté. Autrement dit, un paradigme qui s’applique partout, tout le temps, sans jamais rencontrer de cas-limite, ne serait pas robuste : il serait vide.
 
@@ -614,7 +622,7 @@ L’*axiome de coprésence* (1.3.1) rappelle que tout dispositif de régulation,
 
 L’*axiome de détectabilité* (1.3.3) pose que chaque pôle laisse des traces situées : visibles ou occultées, explicites ou latentes, mais toujours repérables dans des objets, des pratiques, des structures ou des langages. C’est cet ancrage dans des matérialités documentaires qui permet de différencier l’analyse archicratique de toute spéculation sans prise sur le réel.
 
-L’*axiome de disjonction fonctionnelle* (1.3.4) vient ensuite avertir que l’absence ou l’hypertrophie d’un seul pôle conduit nécessairement à une régulation pathologique. De sorte qu’un ordre sans fondement, sans régulation ou sans opération n’est ni viable, ni légitime, ni habitable.
+L’axiome de disjonction fonctionnelle (1.3.4) vient ensuite avertir que la neutralisation, la mise en latence ou l’hypertrophie d’un seul pôle conduit nécessairement à une régulation pathologique. De sorte qu’un ordre privé de fondement exposable, de scène d’épreuve praticable ou de capacité opératoire effective n’est ni viable, ni légitime, ni habitable.
 
 Les axiomes suivants assurent la robustesse transversale du paradigme. L’*axiome de variabilité différentielle* (1.3.5) affirme que les formes prises par les trois pôles sont historiquement, culturellement, politiquement, technologiquement variables — sans que cela invalide leur structure minimale. L’*axiome d’incomplétude systémique* (1.3.6), quant à lui, soutient qu’aucune régulation n’est jamais entièrement close sur elle-même : il y a toujours un reste, un vide, un point de fuite, une indétermination — condition de la critique comme de l’invention.
 
@@ -642,7 +650,7 @@ Pour comprendre cette architecture mouvante, nous devons prendre appui sur trois
 
 À partir de cette triple assise théorique, nous pouvons affirmer que la grammaire topologique constitue le pivot méthodologique du paradigme archicratique. Elle permet d’analyser chaque pôle de la régulation — *arcalité, cratialité, archicration* — comme une structure positionnelle, où l’interne et l’externe ne sont pas des essences, mais des effets de configuration, des prises, des agencements différenciés. Une *arcalité* peut être interne lorsqu’elle émane du récit propre d’une communauté politique, mais elle peut devenir externe si elle est dictée par des normes globales imposées. Une *cratialité* peut être locale et maîtrisée, mais aussi captée par des infrastructures techniques venues d’ailleurs. Une *archicration* peut se déployer dans une scène instituée par les acteurs concernés, ou leur être imposée depuis une juridiction externe, un tribunal arbitral, une plateforme d’arbitrage privée.
 
-C’est cette plasticité topologique — cette capacité à circuler, à migrer, à se dissimuler — qui fait à la fois la richesse et la dangerosité des régimes archicratiques. Car une régulation peut fonctionner en mimant l’interne tout en étant totalement dépendante d’un externe invisible. Elle peut se présenter comme autonome, participative, située, alors qu’elle est en réalité structurée par des standards qui échappent à toute contestation locale. Le risque est alors celui de la dépolitisation radicale, d’une perte de repères critiques, d’une désorientation normative. Ce que la grammaire topologique rend possible, c’est précisément de restaurer cette lisibilité perdue : de retrouver les fils, de remonter les chaînes, de cartographier les prises.
+C’est cette plasticité topologique — cette capacité à circuler, à migrer, à se dissimuler — qui fait à la fois la richesse analytique du paradigme et la dangerosité de certaines configurations désarchicratiques ou autarchicratiques. Car une régulation peut fonctionner en mimant l’interne tout en étant totalement dépendante d’un externe invisible. Elle peut se présenter comme autonome, participative, située, alors qu’elle est en réalité structurée par des standards qui échappent à toute contestation locale. Le risque est alors celui de la dépolitisation radicale, d’une perte de repères critiques, d’une désorientation normative. Ce que la grammaire topologique rend possible, c’est précisément de restaurer cette lisibilité perdue : retrouver les fils, remonter les chaînes, cartographier les prises.
 
 C’est pourquoi, dans les sections qui suivent, nous déploierons une analyse détaillée de chacun des trois pôles — *arcalité, cratialité, archicration* — en les examinant à travers leurs configurations internes et externes. Nous montrerons comment ces modalités se combinent, se transforment, se superposent. Nous analyserons les effets de ces agencements sur la viabilité, la lisibilité et l’opposabilité des dispositifs. Et nous préparerons ainsi le terrain pour une typologie opératoire des régimes de régulation — une typologie qui ne se contente pas de décrire, mais qui permet de diagnostiquer, de contester, de transformer.
 
@@ -716,15 +724,15 @@ En ce sens, l’analyse archicratique exige une vigilance accrue sur les conditi
 
 Ainsi, l’inertie d’une *arcalité externe* n’est pas seulement un échec technique ou politique : c’est le symptôme d’une absence de portage humain effectif. À l’inverse, sa puissance régulatrice dépend de sa capacité à être habitée, interprétée, mobilisée, par des professionnels, des agents publics, des collectifs intermédiaires ou des figures institutionnelles. Il y a une condition anthropologique de l’*arcalité* : sans corps vivant, pas de fondement durable.
 
-Lorsque ces fondements exogènes sont naturalisés, dépolitisés, non contestables, ils deviennent des vecteurs privilégiés du régime archicratique : leur autorité prétendue neutre masque l’impossibilité de les discuter, de les traduire, de les opposer. Ce n’est pas leur contenu qui pose problème, mais leur mode d’énonciation : sans scène de justification, sans délai, sans dispositif de médiation, ces *arcalités* deviennent des injonctions performatives opaques. Elles gouvernent sans débat, fondent sans s’exposer, et neutralisent la discorde.
+Lorsque ces fondements exogènes sont naturalisés, dépolitisés ou rendus difficilement contestables, ils deviennent des vecteurs privilégiés de dérives autarchicratiques ou archicratistiques : leur autorité prétendue neutre masque l’impossibilité pratique de les discuter, de les traduire ou de les opposer. Ce n’est pas leur contenu qui pose problème, mais leur mode d’énonciation : lorsque la scène de justification est neutralisée, lorsque les délais de médiation sont comprimés ou rendus fictifs, lorsque les dispositifs de traduction deviennent inopérants, ces arcalités tendent à devenir des injonctions performatives opaques.
 
 C’est pourquoi le paradigme archicratique impose une exigence méthodologique claire : documenter le statut, le portage, l’activation et la contestation des *arcalités externes*. *Qui les invoque ? Qui les traduit ? Qui les fait vivre ? Sont-elles révisables ? Opposables ? Intégrées dans une scène ou dissoutes dans le dogme ?* La critique archicratique ne vise pas à disqualifier l’externe, mais à rendre visibles ses conditions d’incarnation.
 
-Une *arcalité externe* bien internalisée, portée par une communauté compétente, disputée dans ses effets, rendue visible dans ses limites, peut renforcer un ordre démocratique. Mais une *arcalité* exogène désincarnée, mimée, figée, peut devenir le vecteur sourd d’un pouvoir sans scène. Le facteur humain, ici encore, est la clef de l’*arcalité vivante*.
+Une *arcalité externe* bien internalisée, portée par une communauté compétente, disputée dans ses effets, rendue visible dans ses limites, peut renforcer un ordre démocratique. Mais une *arcalité* exogène désincarnée, mimée, figée, peut devenir le vecteur sourd d’un pouvoir à scène neutralisée, relocalisée hors d’atteinte ou rendue pratiquement inopérante. Le facteur humain, ici encore, est la clef de l’*arcalité vivante*.
 
 ### 1.4.3 — *Cratialités internes* : opérativité endogène, chaînes d’exécution incarnées et pouvoir discret sans extériorité
 
-La *cratialité interne* constitue l’un des points névralgiques du paradigme archicratique. Elle ne se résume ni à l’action technique, ni à la simple application de normes venues d’ailleurs. Elle désigne la capacité d’un dispositif régulateur à produire lui-même, depuis l’intérieur, sa propre puissance opératoire, sans recourir explicitement à une légitimation transcendante (*arcalité*) ni à une scène d’épreuve (*archicration*). En ce sens, l’interne n’est pas un dedans organique, mais une position topologique de clôture opératoire : là où la régulation se suffit à elle-même, là où l’ordre d’exécution s’impose par la seule inertie du dispositif, là où le pouvoir se fait sans être dit.
+La *cratialité interne* constitue l’un des points névralgiques du paradigme archicratique. Elle ne se résume ni à l’action technique, ni à la simple application de normes venues d’ailleurs. Elle désigne la capacité d’un dispositif régulateur à produire lui-même, depuis l’intérieur, sa propre puissance opératoire, sans mobiliser explicitement une légitimation transcendante, et avec une scène d’épreuve devenue marginale, reléguée à l’arrière-plan ou pratiquement inopérante dans le cours ordinaire de l’exécution. En ce sens, l’interne n’est pas un dedans organique, mais une position topologique de clôture opératoire : là où la régulation tend à se suffire à elle-même, là où l’ordre d’exécution s’impose par l’inertie du dispositif, et là où le pouvoir agit comme s’il n’avait plus à se dire, à se justifier ni à se laisser reprendre.
 
 Ce qui distingue fondamentalement la *cratialité interne*, c’est son auto-suffisance apparente. Elle repose sur la densité cumulative des routines, des instruments, des protocoles, des langages, des procédures et — ce qui est décisif — des humains qui les activent, les maintiennent, les modulent. Car la *cratialité interne* n’est jamais une abstraction systémique désincarnée. Elle est portée par des agents, des métiers, des savoir-faire, qui donnent forme, corps et continuité à l’action régulatrice. Elle est faite de mains, de gestes, de réflexes, de scripts mentaux, de hiérarchies tacites, de cultures professionnelles. Elle n’est pas simplement un logiciel ou un organigramme : elle est le produit vivant de celles et ceux qui opèrent.
 
@@ -744,7 +752,7 @@ Il convient alors de distinguer plusieurs formes typologiques de *cratialité in
 
 - *Langagières et discursives* : ici, le pouvoir tient au langage : aux jargons techniques, aux syntaxes normalisées, aux grilles d’expression. Il est détenu par ceux qui maîtrisent le langage de l’institution — rédacteurs administratifs, formateurs, communicants, traducteurs techniques, qui donnent forme intelligible à la régulation.
 
-Ce qui fait la puissance silencieuse de cette *cratialité interne*, c’est qu’elle ne demande pas à être légitimée. Elle ne requiert ni fondement transcendant (*arcalité*), ni mise en épreuve contradictoire (*archicration*). Elle opère par inertie, par habitude, par flux. Tout y est déjà cadré, validé, formaté. La régulation se fait d’elle-même — non parce qu’elle est juste, mais parce qu’elle est possible, rapide, fluide.
+Ce qui fait la puissance silencieuse de cette cratialité interne, c’est qu’elle peut fonctionner comme si elle n’avait plus à répondre explicitement de ses justifications, et comme si la scène d’épreuve n’avait plus de prise effective sur son cours ordinaire ; c’est le cas des algorithmes non documentés et des procédures automatiques rendues pratiquement inopposables. Tout y est déjà cadré, validé, formaté. La régulation se fait d’elle-même — non parce qu’elle serait absolument sans arcalité ni sans archicration, mais parce que celles-ci deviennent peu exposables, reléguées à l’arrière-plan, ou pratiquement inopérantes dans le cours ordinaire de l’exécution.
 
 Mais c’est précisément cette fluidité sans extériorité qui peut poser problème. Car elle rend toute remise en cause difficile. Il n’y a pas de scène où s’adresser, pas de personne clairement responsable, pas de temporalité pour l’amendement. Ce n’est pas l’illégalité qui menace ici, mais la fermeture autoréférentielle : le dispositif fonctionne, donc il est. Le pouvoir s’exécute, donc il n’a pas besoin de s’expliquer.
 
@@ -836,7 +844,7 @@ C’est ici que le paradigme archicratique prend toute sa valeur : il rend lisib
 
 Autrement dit, l’*archicration interne* est ce qui maintient le pouvoir habitable, parce qu’elle le rend réversible, explicable, explicite et amendable. Elle ne garantit pas la vérité, ni la justice — elle garantit la possibilité d’un autrement.
 
-Mais lorsqu’elle se dissout dans l’inaction, lorsqu’elle est mise en scène sans effets, ou déportée vers des figures incapables d’assumer l’épreuve de la contestation, elle devient un artefact démocratique, un simulacre de dispute, une mise en forme de l’illusion délibérative. C’est là que l’*archicratie* s’installe : non comme domination explicite, mais comme court-circuit silencieux de la possibilité de reprise.
+Mais lorsqu’elle se dissout dans l’inaction, lorsqu’elle est mise en scène sans effets, ou déportée vers des figures incapables d’assumer l’épreuve de la contestation, elle devient un artefact démocratique, un simulacre de dispute, une mise en forme de l’illusion délibérative. C’est là que s’installe non l’archicratie, mais son envers : une désarchicration susceptible de dériver vers l’autarchicratie, c’est-à-dire un court-circuit silencieux de la possibilité de reprise.
 
 ### 1.4.6 — *Archicrations externes* : scènes surplombantes, interpellations dissidentes et figures de contre-institution
 
@@ -898,7 +906,7 @@ C’est aussi, plus tragiquement, le lieu où se manifeste l’effondrement des
 
 Si l’on a distingué, jusqu’ici, les prises internes et externes pour chacun des trois pôles du paradigme archicratique — *arcalité, cratialité, archicration* —, cette cartographie ne saurait être figée. Car les dispositifs régulateurs réels ne sont pas des blocs isolés ; ce sont des ensembles dynamiques, traversés par des circulations, des transferts, des reconfigurations. Autrement dit, l’interne et l’externe sont des positions politiques et stratégiques, dont les objets, les fonctions, les signes et les effets peuvent migrer, se dissimuler ou se renverser.
 
-C’est précisément dans cette dynamique migratoire que se déploie toute la plasticité — mais aussi toute l’ambiguïté — des régulations contemporaines. L’*archicratie* ne se limite pas à une absence de scène ou à une saturation cratiale ; elle procède souvent par reconfiguration des prises : ce qui était externe devient interne (capture), ce qui était interne devient externe (délestage), et ce qui devrait être visible est rendu opaque par changement de topologie. Ainsi, la logique archicratique se manifeste autant par ce qui est dit que par l’endroit d’où cela est dit, tout autant par ce qui est fait que par l’endroit d’où cela est imposé.
+C’est précisément dans cette dynamique migratoire que se déploie toute la plasticité — mais aussi toute l’ambiguïté — des régulations contemporaines. Les dérives autarchicratiques ne se réduisent pas à une simple absence de scène ou à une saturation cratiale ; elles procèdent souvent par reconfiguration des prises : ce qui était externe devient interne (capture), ce qui était interne devient externe (délestage), et ce qui devrait être visible est rendu opaque par changement de topologie. Ainsi, la dérive autarchicratique se manifeste autant par ce qui est dit que par l’endroit d’où cela est dit, tout autant par ce qui est fait que par l’endroit d’où cela est imposé.
 
 #### ***Migrations arcales* : du mythe incorporé au fondement importé**
 
@@ -954,7 +962,7 @@ L’excès d’internalité produit des régulations opaques, fermées, surcodé
 
 Mais c’est précisément entre ces deux pôles extrêmes que se noue la possibilité d’un dispositif politiquement viable : c’est-à-dire ni totalement clos, ni intégralement hétéronome, mais articulé dans une dialectique régulée entre interne et externe. Cette *co-viabilité* repose sur la capacité du dispositif à *maintenir une tension active entre ses composantes*, à autoriser la critique venue de l’extérieur sans se dissoudre dans une dépendance pure, et à mobiliser des justifications internes sans basculer dans l’auto-légitimation close.
 
-Cette tension est particulièrement cruciale dans les formes de régulation dites « silencieuses » — c’est-à-dire sans théâtre, sans acteurs identifiables, sans justification publique explicite. Là où l’interne l’emporte, le risque est celui d’une saturation normative : plus rien ne peut venir troubler le cycle opératoire du dispositif. Là où l’externe l’emporte, c’est l’évaporation du sens qui guette : plus rien ne fonde localement la régulation, plus rien ne la rend habitable.
+Cette tension est particulièrement cruciale dans les formes de régulation dites « silencieuses » — c’est-à-dire à théâtre affaibli ou neutralisé, à acteurs difficilement identifiables, et à justification publique faiblement exposable. Là où l’interne l’emporte, le risque est celui d’une saturation normative : plus rien ne peut venir troubler le cycle opératoire du dispositif. Là où l’externe l’emporte, c’est l’évaporation du sens qui guette : plus rien ne fonde localement la régulation, plus rien ne la rend habitable.
 
 Le paradigme archicratique n’a pas pour vocation de désigner un juste milieu abstrait entre ces deux extrêmes, mais de fournir les instruments critiques pour repérer les points de bascule, les seuils de rupture, les zones où la régulation cesse d’être lieu de confrontation parce que ses prises deviennent illisibles. Ces seuils de *co-viabilité* doivent être pensés à partir de critères politiques précis : *existe-t-il un différé ? Un recours ? Une scène ? Une instance d’interpellation ? Une capacité d’amendement ?* Ces questions ne sont pas secondaires : elles sont les conditions minimales de soutenabilité d’un ordre régulateur dans une société qui se dit démocratique.
 
@@ -1084,15 +1092,15 @@ En cela, les *formes hypertopiques* nous enseignent ce que devient une régulati
 
 Il est des régulations dont la fragilité réside dans le défaut même d’articulation, dans la carence silencieuse d’un ou plusieurs pôles, non pas dominance mais par manquements, effacements, indéterminations. Ces régimes ne sont pas saturés — ils sont désarrimés, désaffiliés, incomplètement ancrés. Ce sont les *formes hypotopiques* : configurations où la triade archicratique ne parvient pas à s’incarner pleinement, soit par inachèvement historique, soit par délitement structurel, soit par marginalisation sociale. Non point des régimes de déséquilibre manifeste — mais de décrochements latents.
 
-Dans ces situations, ce n’est pas la force excessive d’un pôle qui domine, mais l’effacement progressif ou brutal de l’un de ses vecteurs constitutifs. Cela peut être l’arcalité qui fait défaut, lorsqu’une régulation se poursuit sans fondement explicite, sans justification reconnue, sans principe commun. Cela peut être la *cratialité* qui s’effondre, lorsque les moyens d’opération sont absents, disjoints ou dysfonctionnels. Cela peut être l’*archicration* qui se dissout, lorsque plus aucune scène ne permet l’expression du différend, la mise en tension, la confrontation réglée.
+Dans ces situations, ce n’est pas la force excessive d’un pôle qui domine, mais l’effacement progressif ou brutal de l’un de ses vecteurs constitutifs. Cela peut être l’arcalité qui fait défaut, lorsqu’une régulation se poursuit sous des fondements implicites, peu exposables ou dépourvus de justification reconnue. Cela peut être la cratialité qui s’effondre, lorsque les moyens d’opération sont absents, disjoints ou dysfonctionnels. Cela peut être l’archicration qui se dissout, lorsqu’aucune scène effective ne permet plus l’expression du différend, la mise en tension ou la confrontation réglée.
 
-Un exemple manifeste d’*hypoarcalité* se retrouve dans les dispositifs provisoires ou de crise, où l’action publique se déploie sans fondement explicite, dans une zone grise entre droit et exception. L’état d’urgence sanitaire prolongé, la gestion dérogatoire des flux migratoires ou encore les expérimentations territoriales non encadrées sont autant de cas où la *cratialité* et parfois l’*archicration* existent, mais où l’*arcalité* est suspendu, implicite ou réduit à un vague impératif de « nécessité ». Dans ces cas, la légitimité régulatrice s’efface, non pas par volonté autoritaire, mais par inachèvement ou déni de sa propre condition normative. Le pouvoir continue d’agir, mais sans adossement symbolique, éthique ou juridique pleinement assumé.
+Un exemple manifeste d’*hypoarcalité* se retrouve dans les dispositifs provisoires ou de crise, où l’action publique se déploie sur fondement implicite, suspendu ou faiblement exposable, dans une zone grise entre droit et exception. L’état d’urgence sanitaire prolongé, la gestion dérogatoire des flux migratoires ou encore les expérimentations territoriales non encadrées sont autant de cas où la *cratialité* et parfois l’*archicration* existent, mais où l’*arcalité* est suspendu, implicite ou réduit à un vague impératif de « nécessité ». Dans ces cas, la légitimité régulatrice s’efface, non pas par volonté autoritaire, mais par inachèvement ou déni de sa propre condition normative. Le pouvoir continue d’agir, mais sur un adossement symbolique, éthique ou juridique faiblement assumé, peu explicité ou difficilement opposable.
 
 À l’inverse, certaines configurations présentent une *hypocratialité* : les intentions sont fortes, les textes abondants, les dispositifs délibératifs multiples — mais l’opérativité est absente ou déficiente. Ce sont les dispositifs de « papier », sur-institutionnalisés et sous-dotés, où les *arcalités* sont proclamées, les *archicrations* ouvertes, mais rien ne se passe. Les plans de transition écologique sans moyens, les comités citoyens sans budget, les programmes d’inclusion numérique sans matériel sont des formes classiques de cette dérive. Le geste politique est performé, mais peu outillé. L’action régulatrice meurt d’épuisement, faute d’infrastructure ou de continuité d’exécution. Le pôle cratial se délite, et avec lui, la consistance de tout l’édifice.
 
 Il existe enfin des *régimes hypoarchicratifs*, dans lesquels les tensions sont étouffées, non par répression ou simulation, mais par désertion. Les scènes de dispute s’éteignent non faute d’autorisation, mais faute de participants, faute de prise, faute d’appel possible. La démocratie locale peut en être le symptôme : dans certains conseils municipaux ruraux, toutes les délibérations sont publiques, les procès-verbaux accessibles, les voies de recours en théorie ouvertes — mais personne n’y vient, personne ne les utilise. L’espace de la critique devient désert, non pas parce qu’on l’empêche, mais parce qu’il n’a plus d’effet. On ne conteste plus ce que l’on ne croit plus modifiable. L’usure de la dispute devient une forme d’abstention persistante.
 
-Ces *régulations hypotopiques* sont redoutables précisément parce qu’elles ne suscitent pas d’alarme immédiate. Elles n’ont ni l’éclat tyrannique des régimes autoritaires, ni le chaos visible des formes délibératives défaillantes. Elles perdurent, parfois longtemps, dans une grande stabilité apparente, faute de tension, de friction, de dispute. Mais c’est une stabilité vide, une paix sans enjeu, un ordre sans scène.
+Ces *régulations hypotopiques* sont redoutables précisément parce qu’elles ne suscitent pas d’alarme immédiate. Elles n’ont ni l’éclat tyrannique des régimes autoritaires, ni le chaos visible des formes délibératives défaillantes. Elles perdurent, parfois longtemps, dans une grande stabilité apparente, faute de tension, de friction, de dispute. Mais c’est une stabilité vide, une paix sans enjeu, un ordre à scène désertée, neutralisée ou pratiquement inopérante.
 
 Le paradigme archicratique nous invite ici à une vigilance particulière : il ne suffit pas de vérifier la présence formelle des trois pôles. Il faut en interroger l’effectivité, la consistance, la vitalité, dans la durée et dans la conflictualité. Une *arcalité* proclamée mais jamais invoquée est un décor. Une *cratialité* active mais sans prise humaine est un automatisme. Une *archicration* ouverte mais inopérante est une illusion procédurale. Ce qui fait régulation n’est pas l’énumération des fonctions, mais leur co-présence dynamique, différenciée, habitée.
 
@@ -1100,9 +1108,11 @@ Les *formes hypotopiques* sont les signes d’une dérégulation par effacement,
 
 ### 1.5.4 — *Formes atopiques* : déréalisations, vacuités et simulacres
 
-Il est des dispositifs de régulation où les formes sont présentes, les fonctions identifiables, les terminologies stabilisées — mais où la consistance topologique fait défaut. Ni déséquilibre (hypertopie), ni carence (hypotopie), ni tension co-viable (synchrotopie), ces configurations appartiennent à un tout autre régime : celui de l’*irréalité régulatrice*. La structure semble intacte, parfois même sophistiquée, mais aucun des pôles archicratiques n’est substantiellement ancré, ni dans la scène, ni dans les corps, ni dans les pratiques. Ce sont des *formes atopiques* — c’est-à-dire des régulations sans lieu, sans effectivité, sans consistance — qui simulent l’existence d’un ordre tout en ne le rendant ni habitable, ni contestable, ni opératoire.
+Il est des dispositifs de régulation où les formes sont présentes, les fonctions identifiables, les terminologies stabilisées — mais où la consistance topologique fait défaut. Ni déséquilibre (hypertopie), ni carence (hypotopie), ni tension co-viable (synchrotopie), ces configurations appartiennent à un autre régime : celui de l’irréalité régulatrice. La structure semble intacte, parfois même sophistiquée, mais les pôles archicratiques n’y trouvent plus qu’un ancrage vidé, mimé, stylisé ou rendu artefact, sans consistance vivante ni effectivité praticable. L’arcalité y est mimée plutôt qu’exposée, la cratialité y est stylisée plutôt que véritablement rendue opérante, l’archicration y est figurée plutôt qu’instituée comme scène de reprise. Nous n’avons plus affaire à une régulation tenue, mais à une scénographie vide de la régulation.
 
-L’*atopie* n’est pas l’absence pure et simple. Elle est une présence vide, une figuration institutionnelle déconnectée de tout processus régulateur vivant. Elle repose souvent sur des artefacts de légitimation, des outils de pilotage automatisés, des consultations protocolaires — mais dont l’impact sur le réel est nul ou illisible. Tout y est là, en apparence : des fondements (arcalité), des instruments (cratialité), des scènes de discussion (archicration) — mais sans prise, sans contrepartie, sans transformation. L’infrastructure normative est creuse, le pilotage est aveugle, la dispute est factice. On y maintient les gestes, les rites, les discours — mais sans monde.
+L’*atopie* n’est pas l’absence pure et simple. Elle est une présence vide, une figuration institutionnelle déconnectée de tout processus régulateur vivant. Elle repose souvent sur des artefacts de légitimation, des outils de pilotage automatisés, des consultations protocolaires — mais dont l’impact sur le réel est nul ou illisible. Tout y est — en apparence : des fondements, des instruments, des scènes de discussion — mais sous des formes vidées de prise, privées de contrepartie effective et incapables de transformation réelle. L’infrastructure normative est creuse, le pilotage est aveugle, la dispute est factice. On y maintient les gestes, les rites, les discours — mais sans prise vivante sur le monde qu’ils prétendent réguler.
+
+L’atopie ne décrit donc pas une régulation effective amputée de ses pôles, mais un simulacre régulatif dans lequel les prises ne subsistent plus qu’à l’état mimé, vidé ou rendu artefact.
 
 Cette atopie peut se manifester selon plusieurs figures typiques.
 
@@ -1124,7 +1134,7 @@ Enfin, l’atopie peut prendre la forme d’un usage symbolique, rhétorique ou
 
 Ce que révèle l’analyse archicratique, c’est que la vacuité ne s’oppose pas frontalement au pouvoir : elle peut en être la forme la plus stable. Le simulacre est parfois plus durable que l’autoritarisme, car moins repérable, moins conflictuel, plus fluide. Une démocratie peut périr dans l’atopie sans jamais suspendre le droit de vote. Une administration peut devenir autistique sans jamais violer la procédure. Un dispositif de participation peut être déserté par saturation symbolique, non par coercition.
 
-L’*atopie* est donc le point aveugle de la critique classique. Elle ne se manifeste pas par l’excès de pouvoir, ni par son absence, mais par sa *simulation creuse*. Elle est ce moment où les fonctions sont remplies, mais où aucune scène n’est réellement investie, aucun lien n’est réellement actif, aucun différé n’est institué.
+L’*atopie* est donc le point aveugle de la critique classique. Elle ne se manifeste pas par l’excès de pouvoir, ni par son absence, mais par sa *simulation creuse*. Elle est ce moment où les fonctions sont remplies, mais où les scènes ne sont plus réellement investies, où les liens deviennent inactifs ou purement formels, et où le différé n’est plus institué comme prise effective de reprise, mais seulement figuré ou neutralisé.
 
 ### Cartographier la tenue régulatrice : vers une pragmatique des formes archicratiques
 
@@ -1134,9 +1144,9 @@ Nous avons désigné par *forme synchrotopique* la configuration rare bien que d
 
 Les *formes hypertopiques*, quant à elles, rendent visible la plasticité parfois toxique du paradigme : lorsque l’un ou deux des pôles submergent les autres, soit par hégémonie fondatrice (*hyperarcalité*), soit par captation instrumentale (*hypercratialité*), soit par saturation participative (archicration sans opérativité), la régulation se bloque, s’étiole ou se pervertit. Les dérives y sont patentes, mais leur diagnostic exige plus que des jugements de valeur : il réclame une lecture structurelle, patiente, stratifiée.
 
-Avec les *formes hypotopiques*, le paradigme archicratique affronte une tout autre pathologie : celle de l’effacement, du désarrimage, de la déprise. Il ne s’agit plus ici d’excès, mais de manque : manque de justification, d’effectuation, de dispute. Ce n’est plus la sur-présence d’un pôle qui menace, mais l’absence réelle ou feinte de tout principe actif de régulation. Ce sont des régulations en dormance, en rétraction, ou en dissociation.
+Avec les *formes hypotopiques*, le paradigme archicratique affronte une tout autre pathologie : celle de l’effacement, du désarrimage, de la déprise. Il ne s’agit plus ici d’excès, mais de manque : manque de justification, d’effectuation, de dispute. Ce n’est plus la sur-présence d’un pôle qui menace, mais l’effacement, la mise en dormance ou la désactivation apparente des principes actifs de régulation.
 
-Enfin, les *formes atopiques* révèlent la possibilité la plus troublante, et sans doute la plus contemporaine : celle de régulations sans réalité, où les pôles sont mimés, stylisés, formalisés — mais sans consistance, sans scène, sans prise. Ce ne sont plus des déséquilibres, mais des simulacres. Non plus des régimes problématiques, mais des dispositifs qui tiennent sans fonder, sans opérer, sans disputer. Ce sont les formes vides du pouvoir sans régulation véritable — celles qui appellent une reconstitution critique urgente du politique.
+Enfin, les formes atopiques révèlent la possibilité la plus troublante, et sans doute la plus contemporaine : celle de configurations où les pôles sont stylisés et formalisés, mais avec des prises mimées, vidées, à ancrage vivant introuvable, à scène devenue impraticable, et à effectivité régulatrice non soutenable. Ils ne “tiennent” pas au sens fort d’une régulation viable ; ils se maintiennent comme artefacts, comme figures creuses, comme apparences d’ordre. Ce sont les formes vides du pouvoir sans régulation habitable — celles qui appellent une reconstitution critique urgente du politique.
 
 Ce qui se donne à voir, à travers cette cartographie dynamique des tenues régulatrices, c’est donc une topologie active du paradigme archicratique : un modèle théorique qui permet de penser non seulement les composants, mais leur manière d’apparaître, de s’ordonner, de se désordonner, de se figer, de se dissoudre. Il s’agit d’un dispositif critique, qui articule diagnostic, description et problématisation, en donnant au lecteur — et plus encore, au chercheur, au praticien, au citoyen — des outils de repérage, de discernement, d’action.
 
@@ -1148,8 +1158,8 @@ Cette section 1.5 constitue ainsi un tournant dans notre essai-thèse. Car elle
 |:--:|:--:|:--:|:--:|:--:|:--:|:--:|
 | **Synchrotopique** | Trois pôles présents, différenciés, articulés | Équilibre différé et co-tendu | Régulation habitée, amendable, soutenable | — (forme idéale) | Maximal : habitable, critique, stable | Capacité de ralentir, d’ajuster, de contester |
 | **Hypertopique** | Un ou deux pôles hégémoniques (ex. arcalité absolue ou cratialité saturante) | Tension écrasée, figée ou court-circuitée | Régulation asymétrique, autoréférente ou verrouillée | Sur-arcalisation, technogestion, théâtralisation participative | Moyen à faible, selon la plasticité restante | Blocage d’un pôle, exclusion d’un autre, saturation opératoire |
-| **Hypotopique** | Un ou plusieurs pôles effacés, désaffiliés ou en veille | Tension suspendue, inopérante | Régulation dévitalisée, bancale ou inerte | Disparition des fondements, perte d’efficacité, vide contestataire | Faible, sauf réactivation coordonnée | Absence de scènes, silence des agents, désancrage narratif |
-| **Atopique** | Trois pôles présents mais sans ancrage réel | Tension fantomatique ou mimée | Régulation spectrale, simulée ou décorative | Déréalisation, fétichisation, vacuité procédurale | Nul à toxique : simulacre paralysant | Aucun effet de scène, aucune reprise, vacuité masquée par la forme |
+| **Hypotopique** | Un ou plusieurs pôles effacés, désaffiliés ou en veille | Tension suspendue, inopérante | Régulation dévitalisée, bancale ou inerte | Effacement, mise en latence ou faible exposition des fondements ; perte d’efficacité ; dévitalisation contestataire | Faible, sauf réactivation coordonnée | Scènes désertées, neutralisées ou pratiquement inopérantes ; silence des agents ; désancrage narratif |
+| **Atopique** | Trois pôles mimés, stylisés ou artefactuels, sans ancrage vivant soutenable | Tension fantomatique ou mimée | Régulation spectrale, simulée ou décorative | Déréalisation, fétichisation, vacuité procédurale | Nul à toxique : simulacre paralysant | Scène figurée sans prise, reprise neutralisée, vacuité masquée par la forme |
 
 Chaque ligne de ce tableau constitue un cadre analytique complet : il peut être utilisé comme outil de diagnostic dans les chapitres suivants, pour évaluer des dispositifs empiriques sectoriels, repérer des évolutions topologiques, ou cartographier des formes de capture et de libération régulatrice.
 
@@ -1201,7 +1211,7 @@ En somme, la détectabilité est ici un geste critique et herméneutique : recon
 
 L’*archicratie*, destinée à saisir autrement les modalités différenciées, évolutives et souvent opaques de la régulation dans les sociétés humaines, n’entend pas livrer ici un instrument de mesure, mais proposer une grammaire de discernement — ancrée dans la triade *arcalité–cratialité–archicration* — pour éclairer de réelles situations situées. L’ambition est heuristique : offrir des points d’ancrage et de repérage capables de décrire, de discriminer et de problématiser, sans sacrifier la pluralité des expériences ni la conflictualité inhérente à toute *co-viabilité*.
 
-Nous vivons un moment où l’« opérativité » est souvent dévoyée par la prolifération de mesures pseudo-scientifiques érigées en dispositifs de vérité sans scène : tableaux de bord, indicateurs de performance, grilles d’évaluation, algorithmes prédictifs et plateformes de pilotage normant l’action en amont et rétrécissant les marges du possible en aval. Sous prétexte de rationalisation, s’étend une régulation sans scène : sans explicitation des sources, sans exposition des mécanismes, sans différé d’interprétation. La mesure devient sa propre justification, neutralisant le conflit constitutif du social et sapant les conditions d’une *archicration* effective.
+Nous vivons un moment où l’opérativité est fréquemment dévoyée par la prolifération de mesures pseudo-scientifiques élevées au rang de dispositifs de vérité à scène neutralisée, comprimée ou relocalisée hors d’atteinte. Tableaux de bord, indicateurs de performance, grilles d’évaluation, algorithmes prédictifs et plateformes de pilotage étendent ainsi une régulation dont la scène d’épreuve se trouve neutralisée : les sources demeurent insuffisamment explicitées, les mécanismes ne sont pas pratiquement exposables, et le différé interprétatif devient fictif ou inopérant. Sous prétexte de rationalisation, ces dispositifs normaient l’action en amont et resserrent en aval les marges du possible. La mesure tend alors à se faire sa propre justification, neutralisant le conflit constitutif du social et minant les conditions mêmes d’une archicration effective.
 
 Face à cette saturation instrumentale, la tâche du paradigme archicratique est plus modeste et plus exigeante : non pas proposer un outil de pilotage alternatif, ni concurrencer les instruments existants sur leur terrain, mais offrir des repères heuristiques pour identifier des formes différenciées de légitimation, d’opération et de contestation dans des contextes socio-politiques, historiques et institutionnels situés. Ces repères ne visent ni universalité formelle ni exclusivité, mais pertinence contextualisée. Ils se proposent comme scène d’interprétation ouverte, susceptible d’être discutée et ajustée par les acteurs. Ils forment une matrice de discernement, non un schéma d’application.  
 Nota bene : la conversion de ces repères en protocoles d’évaluation relève d’un programme ultérieur, non traité dans l’ouvrage.
@@ -1220,7 +1230,7 @@ Prenons un service public numérisé où les usagers passent par un portail en l
 
 Enfin, l’*archicration* constitue le point névralgique de la lecture archicratique. Elle ne se réduit ni au droit au recours formel ni à une contradiction abstraite : elle désigne la scène instituée, différée, située, où le pouvoir se laisse interroger, où la décision devient amendable, où le fondement redevient discours. Instance juridictionnelle, médiation, espace de débat, conseil pluraliste, rituel, forum numérique, procédure contradictoire, délai suspensif : la forme importe moins que la possibilité effective pour les agents affectés de faire entendre leur voix, demander des comptes, suspendre, raconter une autre version, transformer le dispositif en scène contradictoire.
 
-Une régulation sans *archicration* est une régulation sans visage. Une décision sans différé est une décision sans interlocuteur. Là où le contradictoire disparaît, vacille non seulement la démocratie, mais la capacité d’une société à se représenter comme traversée de conflits et de désaccords potentiellement féconds. La lecture archicratique consiste à repérer, dans chaque dispositif, les conditions minimales d’une telle scène, à diagnostiquer les formes de son effacement et à préfigurer les moyens de sa réapparition. L’*archicration* n’est pas un luxe : c’est la condition de possibilité de toute régulation viable.
+Une régulation privée d’archicration effective est une régulation sans visage. Une décision sans différé praticable est une décision sans interlocuteur. Là où le contradictoire disparaît ou devient inopérant, vacille non seulement la démocratie, mais la capacité d’une société à se représenter comme traversée de conflits et de désaccords potentiellement féconds. La lecture archicratique consiste à repérer, dans chaque dispositif, les conditions minimales d’une telle scène, à diagnostiquer les formes de son effacement et à préfigurer les moyens de sa réapparition. L’archicration n’est pas un luxe : elle est la condition de possibilité de toute régulation viable.
 
 Une telle lecture ne peut être univoque ni standardisée. Elle suppose une approche située, transversale, dialogique, mobilisant des savoirs institutionnels, juridiques, techniques, mais aussi ethnographiques, narratifs, subjectifs. Elle engage des compétences et lectures croisées, et exige que les sujets soient parties prenantes de l’interprétation. C’est dans les récits, résistances, bifurcations, plaintes et silences que la régulation — ou son absence — devient visible. C’est dans les marges, interstices et incidents que l’*archicratie* trouve sa matière vive.
 
@@ -1276,7 +1286,7 @@ Car ce qui fait valeur dans un paradigme critique, ce n’est pas sa seule élé
 
 Ce travail de morphologie opérante repose sur trois exigences conjuguées. D’abord, une *exigence* *référentielle* : comprendre à partir de quels énoncés, objets, récits, modèles, figures ou principes un ordre prétend se légitimer. Ensuite, une *exigence opératoire* : analyser les mécanismes, supports, outils, interfaces, organigrammes, temporalités et frictions par lesquels une règle produit ses effets. Enfin, une *exigence expérientielle* : restituer la manière dont ces formes sont vécues, comprises, redoutées, contournées ou investies par celles et ceux qui y sont exposés. C’est dans cette articulation — du sémantique, du matériel et du sensible — que réside la puissance diagnostique du paradigme.
 
-Mais il nous faut aller plus loin encore, car cette typologie stratifiée ne peut se limiter à un inventaire. Elle constitue davantage le socle critique de l’épreuve archicratique. En effet, une *arcalité* peut exister sans être compréhensible ni contestable ; une *cratialité* peut opérer sans être localisable ni amendable ; une *archicration* peut être instituée sans jamais devenir praticable. Le paradigme archicratique n’exige pas que ces prises soient parfaites — il exige qu’elles soient rendues lisibles dans leur état, qu’elles soient exposées dans leur morphologie effective, et surtout qu’elles soient analysées pour ce qu’elles permettent ou empêchent en termes d’adresse, de comparution et de remédiation.
+Mais il nous faut aller plus loin encore, car cette typologie stratifiée ne peut se limiter à un inventaire. Elle constitue davantage le socle critique de l’épreuve archicratique. En effet, une arcalité peut subsister en demeurant difficilement compréhensible ou contestable ; une cratialité peut opérer tout en restant peu localisable ou faiblement amendable ; une archicration peut être instituée tout en devenant pratiquement impraticable. Le paradigme archicratique n’exige pas que ces prises soient parfaites — il exige qu’elles soient rendues lisibles dans leur état, qu’elles soient exposées dans leur morphologie effective, et surtout qu’elles soient analysées pour ce qu’elles permettent ou empêchent en termes d’adresse, de comparution et de remédiation.
 
 Il s’agit ici d’un pas décisif vers l’observation située, vers la formalisation graduée des régimes, vers une grammaire analytique capable de faire apparaître les formes ténues ou massives, explicites ou latentes, ouvertes ou fermées, des prises archicratiques. C’est un appel à regarder autrement ce qui fait régulation. Et cet appel passe par la reconnaissance des formes — même mutilées, même silencieuses — que prennent nos fondements, nos opérations et nos scènes.
 
@@ -1342,9 +1352,9 @@ Elle peut se déployer dans des *régimes centralisés* — un portail numériqu
 
 Il faut ici récuser toute vision gestionnaire ou techniciste. La *cratialité* ne se résume pas à un processus d’optimisation. Elle n’a pas pour finalité d’assurer l’efficacité d’un dispositif, mais de rendre intelligible les formes d’effectuation concrète d’un ordre. Une chaîne de traitement peut être rapide, fluide, bien documentée — et pourtant rigide, incompréhensible, impitoyable. À l’inverse, une *cratialité* peut être lente, manuelle, fragmentée — mais ménager des seuils d’ajustement, des lieux d’appel, des moments d’interruption qui la rendent habitable. Ce n’est pas le style de l’opération qui compte, mais sa capacité à articuler des effets dans une configuration régulatrice spécifique.
 
-Cette articulation engage la matérialité des infrastructures comme la plasticité des rôles. Un *geste cratial* est conditionné par une forme, un outil, une procédure, un délai, un seuil, un langage. Lorsqu’un distributeur automatique refuse un retrait parce que le compte est bloqué, il ne fait qu’opérer un effet déjà inscrit ailleurs dans une chaîne bancaire : encodage d’un score de risque, clôture discrète d’un accès, préemption sur des soldes en litige. Le geste, ici, est purement machinique, mais sa *cratialité* est pleine : il transforme une trajectoire, conditionne une action, produit un effet de contrainte — sans justification visible et hors de toute scène explicite.
+Cette articulation engage la matérialité des infrastructures comme la plasticité des rôles. Un *geste cratial* est conditionné par une forme, un outil, une procédure, un délai, un seuil, un langage. Lorsqu’un distributeur automatique refuse un retrait parce que le compte est bloqué, il ne fait qu’opérer un effet déjà inscrit ailleurs dans une chaîne bancaire : encodage d’un score de risque, clôture discrète d’un accès, préemption sur des soldes en litige. Le geste, ici, est purement machinique, mais sa *cratialité* est pleine : il transforme une trajectoire, conditionne une action, produit un effet de contrainte — sur une justification faiblement visible et dans une scène d’épreuve neutralisée, reléguée ou pratiquement hors de portée.
 
-C’est précisément cette possibilité d’absence de scène qui rend la *cratialité* décisive dans notre paradigme. Car elle travaille en amont de toute possible contestation et en aval de tout fondement. Elle agit avant la réclamation et après le principe. Elle ne parle pas, mais elle configure les possibilités d’action : ce que l’on peut faire, ce que l’on doit fournir, où l’on peut passer, avec qui l’on peut parler, à quel moment une procédure ou une démarche est susceptible de relance ou s’avère réellement close. En cela, ce sont les chaînes opératoires — non pas les discours — qui rendent compte du régime véritable d’un ordre. En quelque sorte, elle en révèle *sa conduite* et *son conduit*.
+C’est précisément cette possibilité de neutralisation, de relocalisation ou d’inopérance de la scène qui rend la cratialité décisive dans notre paradigme. Car elle travaille en amont de toute possible contestation et en aval de tout fondement. Elle agit avant la réclamation et après le principe. Elle ne parle pas, mais elle configure les possibilités d’action : ce que l’on peut faire, ce que l’on doit fournir, où l’on peut passer, avec qui l’on peut parler, à quel moment une procédure ou une démarche est susceptible de relance ou s’avère réellement close. En cela, ce sont les chaînes opératoires — non pas les discours — qui rendent compte du régime véritable d’un ordre. En quelque sorte, elle en révèle *sa conduite* et *son conduit*.
 
 Dans les pratiques sociales ordinaires, la *cratialité* se manifeste sans protocole formel. Lorsqu’un étudiant s’adresse à un secrétariat, lorsqu’un réfugié tente d’accéder à un guichet saturé, lorsqu’un malade cherche un rendez-vous sur Doctolib, ce ne sont pas les normes écrites qui produisent la régulation, mais les séquences d’opérations réelles : les créneaux disponibles, la tolérance de l’agent, la posture du guichet, l’existence ou non d’un canal alternatif, la résilience du dispositif face à la surcharge. Une *cratialité* se reconnaît au fait que le sujet modifie son agir en fonction de la chaîne d’effectuation perçue ou anticipée — même s’il n’en connaît ni la structure ni les règles exactes.
 
@@ -1352,7 +1362,7 @@ On ne saurait confiner la *cratialité* à l’espace institutionnel. Dans les
 
 Dans les logiques environnementales, la *cratialité* peut prendre la forme de barrières physiques (clôtures, canaux), d’interdictions de prélèvement, de modulations de quota, de déclencheurs de dispositifs d’alerte. De sorte qu’un niveau de pollution franchi peut suspendre le trafic, rediriger des flux, interdire l’usage d’une zone — par l’effet combiné d’instruments de mesure, de seuils préprogrammés et de dispositifs de verrouillage. Cette régulation ne suppose ni acteur visible ni débat public. Elle agit par chaîne. Et c’est cette chaîne — non sa justification — qui par exemple constitue le *régime cratial* de la gestion écologique — dans les faits.
 
-On retrouve ce même mécanisme dans les mécanismes migratoires : un dispositif de visa, un fichier de police, une fermeture administrative, une alerte biométrique, un fichier d’exclusion partagé de ressortissants entre États. Chacun de ces gestes — souvent silencieux, parfois automatisé — transforme l’état d’un sujet sans jamais apparaître comme une décision. Il ne s’agit pas d’arbitraire, mais de *cratialité brute et opaque* : une régulation agissant par action différée, sans scène, sans fondement explicite.
+On retrouve ce même mécanisme dans les mécanismes migratoires : un dispositif de visa, un fichier de police, une fermeture administrative, une alerte biométrique, un fichier d’exclusion partagé de ressortissants entre États. Chacun de ces gestes — souvent silencieux, parfois automatisé — transforme l’état d’un sujet sans jamais apparaître comme une décision. Il ne s’agit pas d’arbitraire, mais de *cratialité brute et opaque* : une régulation agissant par action différée, à scène neutralisée ou relocalisée, et à fondement implicite, euphémisé ou difficilement exposable.
 
 Le problème fondamental n’est donc pas à nos yeux de savoir si une régulation est automatisée ou humaine, numérique ou analogique. Ce qui importe, c’est la morphologie de la chaîne d’effectuation : *peut-on en reconstituer les étapes ? Qui ou qu’est-ce qui a agi durant celles-ci ? Au nom de quoi ? Quelles ont été concrètement les actions conduites ? Quels en ont été leurs effets ? Au profit ou au détriment de qui ? Existe-t-il des seuils de suspension ? des marges de correction ? des points d’interruption ?* Voilà autant de questions qui constituent la tenue d’une enquête sur la *cratialité*. C’est ce à quoi le paradigme archicratique s’attèle, et ce qu’elle entend *in fine* saisir : une topologie factuelle des régimes opératoires prise dans des situations effectives.
 
@@ -1418,11 +1428,11 @@ Il y a ensuite les *scènes retournées*, plus pernicieuses encore. Celles-ci ne
 
 Autre figure : la *scène saturée*. Ici, le dysfonctionnement ne vient pas de l’absence, mais de l’excès non médié. Trop d’accès, pas de filtrage, pas de traduction. Trop de voix, pas d’écoute structurée. Trop d’injonctions, pas de temporalité. La scène devient invivable : le volume d’interpellation y déborde toute capacité de traitement, la comparution s’y dilue dans le chaos, la réversibilité devient illisible. Ce sont les grandes plateformes numériques d’évaluation, les forums de “libre expression”, ou encore certaines réunions communautaires où tout le monde parle sans qu’aucune écoute mutuelle ne tienne. La scène donne lieu au vacarme. Le seuil d’entrée s’avère ouvert, mais l’agencement archicratique se voit détruit. La critique y meurt de sa propre profusion non canalisée.
 
-Plus troublante encore est la *scène spectrale*. Là, il ne s’agit plus d’un simulacre d’écoute ni d’un excès d’expression mais d’un ajournement indéfini. Le sujet n’est pas exclu ; il demeure suspendu. On lui dit : “bientôt”, “encore un peu de patience”, “votre demande est en cours de traitement”. Mais celui-ci ne vient jamais. La scène est invoquée, toujours repoussée, jamais tenue. C’est le règne de la régulation par la latence, où le temps devient instrument d’usure et d’effacement sans brutalité. Dans les politiques d’asile, dans les systèmes de demande de logement, dans les chaînes d’approbation administratives, on trouve ce type de *scènes spectrales* : le dossier est bien présent, mais ne trouve jamais place dans la scène. Ce qui est produit alors est une suspension sans mémoire, une attente sans comparution, une adresse sans réponse. Le différé se mue dès lors en forme de pouvoir.
+Plus troublante encore est la *scène spectrale*. Là, il ne s’agit plus d’un simulacre d’écoute ni d’un excès d’expression mais d’un ajournement indéfini. Le sujet n’est pas exclu ; il demeure suspendu. On lui dit : “bientôt”, “encore un peu de patience”, “votre demande est en cours de traitement”. Mais celui-ci ne vient jamais. La scène est invoquée, toujours repoussée, jamais tenue. C’est le règne de la régulation par la latence, où le temps devient instrument d’usure et d’effacement sans brutalité. Dans les politiques d’asile, dans les systèmes de demande de logement, dans les chaînes d’approbation administratives, on trouve ce type de *scènes spectrales* : le dossier est bien présent, mais ne trouve jamais place dans la scène. Ce qui est produit alors est une suspension sans mémoire, une attente à comparution différée jusqu’à l’inopérance, une adresse privée de réponse effectivement opposable. Le différé se mue dès lors en forme de pouvoir.
 
 Face à cela, il existe des régulations qui s’ajustent sans jamais organiser de nouvelles scènes. Ce sont les *formes post-interpellatives*. L’ordre y intègre la mémoire de scènes passées — plaintes, mobilisations, controverses — pour reconfigurer silencieusement ses opérations. On peut compter dans cette catégorie : un algorithme modifié sans annonce, un seuil déplacé sans justification, une interface ajustée après une vague de critiques. Il n’y a pas de comparution, mais une mémoire agissante. Ce n’est pas une archicration au sens strict, mais une archicratialisation par effet de sédimentation critique. Ce régime peut être fécond, mais aussi inquiétant, car il soustrait à la vue des concernés les litiges et les dérives établis : *qui contrôle que l’ajustement a bien eu lieu ?, qui mémorise la scène absente ?, qui peut rejouer l’interpellation si elle reste sans forme ?* La critique y est intégrée, donne lieu à évolution d’arcalités et de cratialités, mais la polémique est désamorcée.
 
-Par *archicratialisation*, nous désignons ce régime post-interpellatif par lequel une régulation intègre la mémoire d’épreuves passées (plaintes, controverses, mobilisations) sans pour autant rouvrir de scène : les critiques sédimentent et se transmutent silencieusement en ajustements d’*arcalité* (fondements, critères, axiomes) et de *cratialité* (procédures, seuils, algorithmes, interfaces), sans comparution, sans publicité, sans délai contradictoire nouvellement institué. L’*archicratialisation* n’est donc pas l’*archicration* (qui expose et oppose), mais son après-coup opératoire : une auto-réforme qui peut corriger, parfois avec finesse, tout en déplaçant hors scène le litige qui l’a rendue nécessaire ; d’où son ambivalence. Elle peut être féconde si elle demeure traçable et ré-ouvrable, mais devient inquiétante si elle neutralise la polémique en retirant aux concernés la possibilité d’une réinterpellation opposable.
+Par *archicratialisation*, nous désignons ce régime post-interpellatif par lequel une régulation intègre la mémoire d’épreuves passées (plaintes, controverses, mobilisations) sans pour autant rouvrir de scène effective : les critiques sédimentent et se transmutent silencieusement en ajustements d’*arcalité* (fondements, critères, axiomes) et de *cratialité* (procédures, seuils, algorithmes, interfaces), sans comparution véritablement praticable, sans publicité opposable, sans délai contradictoire nouvellement institué et opérant. L’*archicratialisation* n’est donc pas l’*archicration* (qui expose et oppose), mais son après-coup opératoire : une auto-réforme qui peut corriger, parfois avec finesse, tout en déplaçant hors scène le litige qui l’a rendue nécessaire ; d’où son ambivalence. Elle peut être féconde si elle demeure traçable et ré-ouvrable, mais devient inquiétante si elle neutralise la polémique en retirant aux concernés la possibilité d’une réinterpellation opposable.
 
 Enfin, il existe ce que nous nommons les *contre-scènes auto-organisées*, ou *pré-archicrations*. Là, ce n’est plus l’ordre institué qui ouvre une scène, mais les sujets eux-mêmes qui la fabriquent, à même leurs expériences. Ce sont des collectifs d’écoute mutuelle, des cercles d’entraide communautaire, des réunions de colocataires qui instituent des modalités de parole, de suspension, de reconnaissance, de réparation. Ces scènes ne contestent pas toujours l’ordre en bloc : elles déploient un à-côté, un écart, une grammaire marginale de la régulation. Elles tissent leurs propres conditions de comparution, de mémoire, de reprise — et parfois, dans un second temps, elles viennent frapper à la porte de l’institution pour l’obliger à s’ajuster.
 
@@ -1518,8 +1528,8 @@ Dans cette optique, le chapitre 2 constituera l’épreuve originelle. En retra
 
 Ce qui s’ouvre alors est un laboratoire de différenciation régulatrice. Le paradigme archicratique, tel qu’il a été posé ici dans sa topologie formelle, trouvera dans le chapitre 2 les premières scènes d’épreuve de sa pertinence différentielle : il y montrera qu’il est capable de rendre intelligible ce qui varie réellement d’un régime à l’autre — selon la manière dont il fonde, opère, ou se laisse interroger. Loin d’imposer ses catégories, il s’y laissera *moduler* par les formes historiques, dans une dynamique de transduction critique : non pour valider son propre appareil conceptuel, mais pour en éprouver les seuils, les écarts, les tensions fécondes.
 
-Car si l’*arcalité* ne précède pas toujours la *cratialité*, si la scène d’*archicration* n’est pas partout instituée, si certaines *co-viabilités* se tiennent sans fondement explicite, sans suspension déclarée, sans mémoire stabilisée, alors il faut reconnaître que le paradigme ne détermine pas les régimes qu’il analyse : il s’expose à leur complexité. Il n’est pas un moule, mais un geste de lecture — une manière de faire apparaître les points de tension, de redistribution et de transformation. Le chapitre 2 montrera alors comment des configurations archaïques ou proto-politiques, souvent considérées comme « pré-étatiques », témoignent en réalité de formes complexes de régulation différée, de justification rituelle, d’adresse symbolique, de seuils narratifs ou d’épreuves collectives. Il révélera que l’*archicration* ne coïncide pas nécessairement avec la démocratie formelle, pas plus que la *cratialité* avec la souveraineté étatique, ni l’*arcalité* avec la seule Loi écrite : les régimes de viabilité se sont déployés à travers des architectures plus hétérogènes, plus fragiles, plus inventives qu’on ne le suppose.
+Car si l’arcalité ne précède pas toujours la cratialité, si la scène d’archicration n’est pas partout formellement instituée, si certaines co-viabilités se soutiennent à travers des fondements implicites, des suspensions peu codifiées ou des mémoires faiblement stabilisées, alors il faut reconnaître que le paradigme ne détermine pas les régimes qu’il analyse : il s’expose à leur complexité. Il n’est pas un moule, mais un geste de lecture — une manière de faire apparaître les points de tension, de redistribution et de transformation. Le chapitre 2 montrera alors comment des configurations archaïques ou proto-politiques, souvent considérées comme « pré-étatiques », témoignent en réalité de formes complexes de régulation différée, de justification rituelle, d’adresse symbolique, de seuils narratifs ou d’épreuves collectives. Il révélera que l’archicration ne coïncide pas nécessairement avec la démocratie formelle, pas plus que la cratialité avec la souveraineté étatique, ni l’arcalité avec la seule Loi écrite : les régimes de viabilité se sont déployés à travers des architectures plus hétérogènes, plus fragiles, plus inventives qu’on ne le suppose.
 
 C’est donc une archéologie morphologique qui s’ouvrira. Non pas pour remonter à un commencement, mais pour différencier les formes premières de régulation tenue, et ainsi éprouver en retour — par contraste, par confrontation, par amplification — la validité opératoire du paradigme archicratique. Car ce n’est qu’en le confrontant à ces régimes situés qui n’avaient pas encore nos institutions, nos catégories, ni nos grammaires politiques, que nous pourrons établir qu’il s’agit bien d’un paradigme de lecture différenciateur, et non d’un système normatif reconduit à rebours.
 
-Ainsi se clôt ce chapitre 1 : non dans la certitude d’un modèle à dérouler, mais dans l’ouverture d’un champ d’épreuve critique. Car si l’*archicration*, comme nous l’avons montré, constitue bien la condition d’habitabilité d’un ordre, alors c’est aussi elle qui nous oblige à interroger chaque régulation depuis ses effets, ses manques, ses devenirs, et non depuis nos catégories héritées. Ce que le chapitre 2 vient éprouver, c’est donc moins l’origine du paradigme que sa capacité à rendre compte, sans réduction, des formes historiques de la viabilité collective, autrement dit, sa *co-viabilité*.
+Ainsi se clôt ce chapitre 1 : non dans la certitude d’un modèle à dérouler, mais dans l’ouverture d’un champ d’épreuve critique. Car si l’archicration constitue bien la condition d’habitabilité d’un ordre, encore faut-il reconnaître qu’elle ne se donne pas partout sous la forme d’une scène pleinement formalisée, stable ou juridiquement instituée. Elle peut être diffuse, rituelle, intermittente, faiblement codifiée ; mais partout où elle est durablement neutralisée, vidée de sa prise, relocalisée hors d’atteinte ou rendue pratiquement inopérante, la régulation se ferme, devient indisponible à ses affectés et compromet sa propre co-viabilité. C’est pourquoi chaque ordre doit être interrogé depuis les formes concrètes par lesquelles il rend ses décisions, ses justifications et ses tensions exposables, discutables et révisables, plutôt que depuis nos seules catégories héritées. Ce que le chapitre 2 vient alors éprouver, ce n’est pas l’origine pure du paradigme, mais sa capacité à rendre compte, sans réduction, de la diversité historique des formes de viabilité collective — autrement dit, de leur co-viabilité.

src/content/archicrat-ia/chapitre-3.mdx

@@ -14,7 +14,7 @@ source:
 ---
 Ce chapitre se tient à un point nodal de notre essai-thèse : il ouvre un espace d’exploration systématique des formes conceptuelles et philosophiques à travers lesquelles le pouvoir se configure comme régime de régulation. Il ne s’agit pas ici de revenir une nouvelle fois sur les fondements de l’autorité, ni d’interroger la légitimité politique au sens classique du terme, ni même d’enquêter sur la genèse des institutions. L’ambition est autre, structurelle, transversale, morphologique, elle tentera d’arpenter, à même les dispositifs, les pensées, les théorisations et les expériences, les modalités différentiées par lesquelles s’instaurent, s’éprouvent et se disputent les formes de régulation du vivre-ensemble.
 
-Dès lors, ce chapitre ne postule aucun fondement, ne cherche aucun point d’origine, ne prétend restituer aucune ontologie stable du politique. Ce qu’il donne à lire, c’est une cartographie dynamique des régimes de régulation, traversée par des formes irréductibles, non homogènes, souvent conflictuelles, parfois incompatibles, mais toutes pensées comme des configurations singulières.
+Dès lors, ce chapitre ne postule aucun fondement, ne cherche aucun point d’origine, ne prétend restituer aucune ontologie stable du politique. Ce qu’il donne à lire, c’est une cartographie dynamique des régimes de régulation, traversée par des formes irréductibles, non homogènes, souvent conflictuelles, parfois incompatibles, mais toutes pensées comme des configurations singulières, et souvent complémentaires.
 
 Ainsi, loin d’être une galerie illustrative de théories politiques juxtaposées, le chapitre s’agence comme une topologie critique, une plongée stratigraphique dans les scènes où s’articule la régulation — entendue ici non comme stabilisation externe ou ajustement technico-fonctionnel, mais comme dispositif instituant, tension structurante, scène traversée de conflictualité et d’exigence normative. Car à nos yeux, la régulation n’est pas ce qui vient après le pouvoir, elle en est la forme même constitutive — son architecture, son rythme, son épaisseur. Elle est ce par quoi le pouvoir ne se contente pas d’être exercé, mais s’institue, se justifie, se dispute, se recompose.
 

src/content/archicrat-ia/prologue.mdx

@@ -12,7 +12,7 @@ source:
   kind: docx
   path: "sources/docx/archicrat-ia/Prologue—Archicratie-fondation_et_finalite_sociopolitique_et_historique-version_officielle.docx"
 ---
-Nous vivons dans une époque saturée de diagnostics sur les formes de domination, les mutations du pouvoir, les détournements de la souveraineté. Depuis une vingtaine d’années, les appellations s’accumulent : *démocratie illibérale*, *ploutocratie*, *happycratie*, *gouvernement algorithmique*, *démocrature*… À travers ces tentatives de nommer le désordre du présent, un fait se répète, de manière sourde : la scène politique semble désorientée. Les catégories héritées — *État*, *pouvoir*, *représentation*, *volonté générale*, *contrat social* — apparaissent de moins en moins capables de décrire ce qui nous gouverne effectivement.
+Nous vivons une époque saturée de diagnostics sur les formes de domination, les mutations du pouvoir, les détournements de la souveraineté. Depuis une vingtaine d’années, les appellations s’accumulent : démocratie illibérale, ploutocratie, happycratie, gouvernement algorithmique, démocrature… À travers ces tentatives de nommer le désordre du présent, un fait se répète, de manière sourde : la scène politique semble désorientée. Les catégories héritées — État, pouvoir, représentation, volonté générale, contrat social — apparaissent de moins en moins capables de décrire ce qui nous gouverne effectivement.
 
 C’est cette perte de prise sur le réel que ce livre souhaite prendre au sérieux. Non pour lui ajouter un terme de plus au lexique fatigué des contre-pouvoirs ou des impuissances, mais pour repartir d’un point plus fondamental, presque en-deçà de la question politique classique. Ce point, c’est celui de la *tenue d’un monde commun* — c’est-à-dire la possibilité, pour des êtres dissemblables, vulnérables, inégaux, traversés de contradictions et situés dans des temporalités hétérogènes, de coexister sans s’annihiler.
 
@@ -20,14 +20,13 @@ Cette tenue du monde n’équivaut ni à la paix civile, ni à la stabilité des
 
 Le terme n’est pas trivial. Il ne s’agit pas simplement d’une viabilité partagée, ni d’une coexistence pacifique, ni même d’une durabilité écologique élargie. Il s’agit d’un état dynamique, instable, fragile, dans lequel un ensemble — une société, d’un système biologique, d’une formation historique, d’un milieu technique ou d’un monde institué — parvient à maintenir une *existence viable*, *malgré et grâce à ses tensions constitutives*.
 
-La *co-viabilité* ne désigne ni un état d’équilibre, ni une finalité normative. Elle nomme un état dynamique et instable, dans lequel un monde — société, milieu technique, formation historique — tient non pas par homogénéité ou harmonie, mais parce qu’il parvient à réguler ce qui le menace sans se détruire lui-même. Il compose entre des éléments hétérogènes — forces d’inertie et d’innovation, attachements profonds et ruptures nécessaires — sans chercher à les unifier. C’est cette disposition active, faite de compromis fragiles et d’ajustements toujours révisables, que nous tenons pour première, et non dérivée.
+La co-viabilité ne désigne ni un état d’équilibre, ni une finalité normative. Elle nomme un état dynamique et instable, dans lequel un monde — société, milieu technique, formation historique — tient non pas par homogénéité ou harmonie, mais parce qu’il parvient à réguler ce qui le menace sans se détruire lui-même. Il compose entre des éléments hétérogènes — forces d’inertie et d’innovation, attachements profonds et ruptures nécessaires — sans chercher à les unifier. C’est cette disposition active, faite de compromis fragiles et d’ajustements toujours révisables, que nous tenons pour première.
 
-Ce qui revient à dire que la question politique — au sens fort — n’a peut-être jamais été qui commande ? Mais bien plus : *Comment un ordre tient-il malgré ce qui le défait ?* *Quels sont les dispositifs qui permettent à une société de ne pas se désagréger sous l’effet de ses propres contradictions ?* *Comment sont régulées les tensions qui traversent le tissu du monde commun sans le déchirer ?*  
-Cette bascule de perspective prolonge des intuitions anciennes. Max Weber (*Économie et société*, 1922) rappelait que ce qui fait tenir un ordre, ce n’est pas seulement la force ou la loi, mais les « chances de validité » socialement reconnues. Norbert Elias (*La dynamique de l’Occident*, 1939/1975) montrait, quant à lui, que les sociétés se maintiennent par des équilibres toujours précaires entre interdépendances, rivalités et pacifications. Notre démarche s’inscrit dans ce sillage : travailler cette interrogation sur les *conditions de viabilité d’un monde commun*.
+Ce qui revient à dire que la question politique — au sens fort — n’a peut-être jamais été qui commande ? Mais bien plus : Comment un ordre tient-il malgré ce qui le défait ? Quels sont les dispositifs qui permettent à une société de ne pas se désagréger sous l’effet de ses propres contradictions ? Comment sont régulées les tensions qui traversent le tissu du monde commun sans le déchirer ? Cette bascule de perspective prolonge des intuitions anciennes. Max Weber (Économie et société, 1922) rappelait que ce qui fait tenir un ordre, ce n’est pas seulement la force ou la loi, mais les « chances de validité » socialement reconnues. Norbert Elias (La dynamique de l’Occident, 1939/1975) montrait, quant à lui, que les sociétés se maintiennent par des équilibres toujours précaires entre interdépendances, rivalités et pacifications. Notre démarche s’inscrit dans ce sillage : travailler cette interrogation sur les conditions de viabilité d’un monde commun soumis à ses propres tensions constitutives.
 
 Ce changement de perspective implique une rupture profonde dans la manière même de poser la question politique. Pendant des siècles, les sociétés ont pensé le politique à partir de principes transcendants — Dieu, Nature, Volonté générale, Pacte social. Ces principes, supposés extérieurs aux conflits du présent, garantissaient l’ordre en surplomb. Comme le rappelle Michel Foucault, il n’y a pas de principe extérieur au jeu des forces : seulement des rapports de pouvoir situés, modulés, réversibles. C’est précisément cette exigence — trouver dans les relations elles-mêmes les ressources nécessaires pour maintenir des mondes vivables — qui définit notre époque.
 
-Ce qui émerge n’est pas de nouveaux principes, ni une nouvelle idéologie, mais une exigence beaucoup plus modeste, mais aussi beaucoup plus difficile à satisfaire : celle de trouver dans les relations elles-mêmes — entre groupes, entre institutions, entre individus, entre temporalités — les ressources nécessaires pour maintenir leurs mondes viables. Autrement dit : c’est *dans* les tensions, *à même* les conflits, *au sein* des alliances, *au cœur* des désaccords et des polémiques, que semble se construire la régulation. Non plus *au-dessus*, par un décret transcendant, mais *au-dedans*, par un agencement toujours révisable. C’est cela que nous voulons dire — sans technicité inutile — quand nous parlons d’un déplacement vers une *instance de régulation située de co-viabilité* : un espace commun où les forces hétérogènes, souvent antagonistes, peuvent coexister, se contredire, se confronter, s’éprouver, sans se détruire mutuellement.
+Ce qui émerge n’est pas de nouveaux principes, ni une nouvelle idéologie, mais une exigence beaucoup plus modeste, mais aussi beaucoup plus difficile à satisfaire : celle de trouver dans les relations elles-mêmes — entre groupes, entre institutions, entre individus, entre temporalités — les ressources nécessaires pour maintenir leurs mondes viables. Autrement dit : c’est dans les tensions, à même les conflits, au sein des alliances, au cœur des désaccords et des polémiques, que semble se construire la régulation. Non plus au-dessus, par un décret transcendant, mais au-dedans, par un agencement toujours révisable. C’est cela que nous voulons dire — sans technicité inutile — quand nous parlons d’un déplacement vers une instance de régulation située de co-viabilité : un espace commun où les forces hétérogènes, souvent antagonistes, peuvent coexister, se contredire, se confronter, s’éprouver, sans pour autant systématiquement se détruire mutuellement.
 
 Penser le politique depuis cette approche, c’est renoncer à l’idée même qu’un ordre puisse se fonder définitivement, une fois pour toutes. C’est reconnaître que ce qui fait tenir une société n’est jamais un principe unique, un commandement souverain, une légitimité première, mais *un espace d’épreuve toujours rejoué* où se négocient, se recadrent, s’opposent, s’ajustent des forces hétérogènes dont l’accord est constamment partiel, toujours temporaire, perpétuellement instable.
 
@@ -47,7 +46,7 @@ Cela ne veut pas dire que le politique ait disparu, mais plutôt qu’il tend pe
 
 C’est un marché carbone qui, au nom de seuils agrégés à l’échelle continentale, conduit à la fermeture d’un site industriel local, sans qu’aucune figure politique ne puisse rendre visible ni opposable l’arbitrage opéré. C’est un algorithme de régulation hospitalière qui, face à une tension budgétaire ou épidémiologique, déprogramme automatiquement des interventions chirurgicales — sans qu’aucun médecin, aucun patient, aucun responsable politique ne puisse véritablement en discuter les critères. C’est une plateforme numérique de traitement des titres de séjour qui suspend une demande pour “anomalie de saisie”, sans contact humain, sans justification claire, sans voie de recours instituée. C’est un logiciel de pilotage budgétaire, adossé à des indicateurs d’efficience, qui impose la réduction d’une politique sociale sans passage par une arène délibérative. C’est aussi un score algorithmique de risque bancaire qui écarte discrètement une famille d’un prêt, bien avant qu’elle ait pu formuler son projet.
 
-Contrairement aux apparences, ce qui s’offre au regard n’est plus la figure massive du pouvoir trônant dans la clarté de ses apparats, mais la trame patiente d’une régulation en mouvement. Disparues, les instances fixes ; effacée, la demeure solennelle de l’autorité. Le réel geste de gouvernance s’insinue insidieusement dans des protocoles, se glisse sournoisement dans la routine, s’entrelace irrémédiablement dans les habitudes, se ramifie inextricablement dans d’innombrables appareils sans visage. Nul acte inaugural n’en marque ostensiblement la naissance, nulle proclamation n’en scande les rythmes. On constate seulement que la régulation avance sans fracas, tisse patiemment la toile discrète sur laquelle se déplacent nos vies. Ce n’est plus tant le décret ni la loi qui pèsent, bien plus les enchevêtrements de normes, l’imperceptible maillage de procédures et l’ajustement continu de directives flexibles.
+Contrairement aux apparences, ce qui s’offre au regard n’est plus la figure massive du pouvoir trônant dans la clarté de ses apparats, mais la trame patiente d’une régulation en mouvement. Disparues, les instances fixes ; effacée, la demeure solennelle de l’autorité. Le réel geste de gouvernance s’insinue dans des protocoles, se glisse sournoisement dans la routine, s’entrelace irrémédiablement dans les habitudes, se ramifie inextricablement dans d’innombrables appareils sans visage. Nul acte inaugural n’en marque ostensiblement la naissance, nulle proclamation n’en scande les rythmes. On constate seulement que la régulation avance sans fracas, tisse patiemment la toile discrète sur laquelle se déplacent nos vies. Ce n’est plus tant le décret ni la loi qui pèsent, bien plus les enchevêtrements de normes, l’imperceptible maillage de procédures et l’ajustement continu de directives flexibles.
 
 La contrainte n’accable plus par l’ostentation de l’ordre, mais s’inocule par la subtilité des systèmes. Ainsi, il s’agit désormais de façonner, par l’agencement soigné d’équilibres, de données, de flux, où chacun se trouve relié, indexé, impliqué à même cette dentelle administrative, sans jamais croiser le centre, sans jamais savoir nommer celui ou ce qui agit. La régulation moderne tresse ainsi un univers de seuils mobiles et d’agencements souples, où l’on ne peut jamais tout à fait fixer le moment ni le lieu du pouvoir agissant — mais où, à chaque pli de la vie collective, se lit l’empreinte d’une architecture invisible.
 
@@ -57,9 +56,9 @@ Cela signifie que le politique s’est décousu de ses formes historiques. Il co
 
 Autrement dit, nous avons changé d’époque sans encore avoir pu changé de lexique. Nous continuons de penser avec des formes obsolètes ce qui s’active sous nos yeux. Nous employons les mots d’hier pour décrire des processus qui les excèdent de toutes parts. Nous parlons de gouvernements, là où il faudrait parler de structures de régulation composite. Nous discutons de lois, là où il faudrait décrire des protocoles, des seuils, des scénographies d’ajustement, des mécanismes de *feedback* algorithmique, des normes sans normalisateurs.
 
-Cette disjonction entre l’expérience vécue de la contrainte et le vocabulaire disponible pour la dire n’est pas qu’un problème théorique. Elle produit une désorientation profonde. Elle empêche de penser le réel, de localiser les responsabilités et rend inopérantes les critiques. Elle altère la capacité collective à formuler des exigences, jusqu’à dissoudre les repères et les registres d’action.
+Cette disjonction entre l’expérience vécue de la contrainte et le vocabulaire disponible pour l'exprimer n’est pas qu’un problème théorique. Elle produit une désorientation profonde. Elle empêche de penser le réel, de localiser les responsabilités et rend inopérantes les critiques. Elle altère la capacité collective à formuler des exigences, jusqu’à dissoudre les repères et les registres d’action.
 
-Cette impuissance démocratique généralisée à nommer, situer, orienter les formes réelles de la régulation se donne parfois à voir dans des situations d’apparente clarté — et c’est peut-être là le plus troublant. Prenons un exemple rendu brûlant par l’actualité française en 2025 : la proposition de ce que l’on appelle la *taxe Zucman*. Formulée par l’éminent économiste Gabriel Zucman, cette mesure vise à instaurer un impôt minimal annuel sur le patrimoine des ultra-riches — en France et dans le monde — au-delà d’un seuil (autour de 100 millions d’euros). Le taux proposé est d’environ 2 % sur la valeur totale du patrimoine net, qu’il soit liquide ou partiellement non liquide (actions non cotées, participations, biens immobiliers), ce qui pose des défis de paiement et d’évaluation.
+Cette impuissance démocratique à nommer, situer et orienter les formes réelles de la régulation — impuissance qui tend à se généraliser — apparaît parfois au grand jour dans des situations d’apparente clarté, ce qui est peut‑être le plus troublant. En témoigne un exemple rendu brûlant par l’actualité française de 2025 : la proposition de ce qu’on a appelé la taxe Zucman. Formulée par l’économiste Gabriel Zucman, cette mesure prévoit l’instauration d’un impôt minimal annuel sur le patrimoine des ultra-riches, en France comme à l’échelle mondiale, au‑delà d’un seuil d’environ 100 millions d’euros. Le taux proposé, de l’ordre de 2% de la valeur totale du patrimoine net, qu’il soit liquide ou non (actions non cotées, participations, biens immobiliers), soulève toutefois d’importants problèmes de paiement et d’évaluation.
 
 L’idée est de corriger ce que Zucman identifie comme un déséquilibre fiscal majeur : les très grandes fortunes paient aujourd’hui, proportionnellement, beaucoup moins que ce que permettrait une imposition équitable et progressive, notamment en raison de l’évasion fiscale, de la mise sous structures opaques par *holding*, du transfert du patrimoine privée en patrimoine professionnel ou de la dissociation entre richesse effective et revenu imposable.
 

src/content/archicratie/00-demarrage.mdx

@@ -1,42 +0,0 @@
----
-title: "Démarrage — Essai-thèse"
-edition: "archicratie"
-status: "modele_sociopolitique"
-level: 1
-version: "0.0.1"
-concepts: ["archicratie"]
-links:
-  - type: "definition"
-    target: "/glossaire/archicratie/"
-    note: "Terme canonique."
-order: 0
-summary: "Page de test (structure)."
----
-
-import Callout from "../../components/Callout.astro";
-import Term from "../../components/Term.astro";
-
-Ceci est une page de test pour valider la structure de l’**Essai-thèse**.
-
-<Callout kind="definition" title="Entrée minimale">
-  <p>
-    <Term term="Archicratie" slug="archicratie" /> : régime où l’instance régulatrice est tenue d’exposer ses prises,
-    ses critères et ses scènes d’épreuve.
-  </p>
-</Callout>
-
-<Callout kind="these" title="Ce que l’édition web doit rendre possible">
-  <p>Une lecture à plusieurs niveaux, sans confusion entre les productions, et une citabilité stable.</p>
-</Callout>
-
-<div class="level-2">
-  <Callout kind="objection" title="Objection (niveau 2)">
-    <p>Que gagne-t-on par rapport à une simple doctrine ? Réponse : la scène, la contrainte d’exposition, la pluralisation des prises.</p>
-  </Callout>
-</div>
-
-<div class="level-3">
-  <Callout kind="limite" title="Limite (niveau 3)">
-    <p>Tout schéma d’articulation doit préciser ses non-déductions (transpositions), sinon confusion Traité ↔ Archicratie.</p>
-  </Callout>
-</div>

src/content/atlas/00-demarrage.md

@@ -1,13 +0,0 @@
----
-title: "Démarrage — Atlas"
-edition: "atlas"
-status: "cartographie"
-level: 1
-version: "0.0.1"
-concepts: ["archicrates"]
-links: []
-order: 0
-summary: "Page de test (structure)."
----
-
-Ceci est une page de test pour valider la structure de l’**Atlas**.

src/content/cas-ia/annexe-glossaire-audit.mdx

@@ -0,0 +1,141 @@
+---
+title: "Annexe — Glossaire archicratique pour l’audit des systèmes d’IA"
+edition: "cas-ia"
+status: "application"
+level: 1
+version: "0.1.0"
+concepts: []
+links: []
+order: 195
+summary: ""
+source:
+  kind: docx
+  path: "sources/docx/cas-ia/Cas_Pratique-Archicratie_et_gouvernance_des_systemes_IA-Annexe_Glossaire_Archicratique_Cas_IA.docx"
+---
+# Annexe – Glossaire archicratique pour l’audit des systèmes d’IA
+
+Cette annexe propose un bref glossaire des notions archicratiques mobilisées dans l’audit de Système F. Elle n’a pas vocation à réexposer la théorie dans toute son ampleur, mais à fournir au lecteur du cas pratique quelques repères opératoires pour suivre le fil des analyses.
+
+## Arcalité
+
+On appelle *arcalité* la *dimension de tout ordre régulateur qui concerne ses fondements* : *ce qui l’autorise, ce qui le rend légitime, ce qui lui donne droit de décider*. L’*arcalité* est faite de *récits*, de *principes*, de *valeurs*, de *visées explicites ou implicites* : lutter contre la fraude, protéger l’État social, garantir la sécurité, promouvoir la santé, favoriser le “talent”, préserver la liberté d’expression, etc.
+
+Dans Système F, on distingue :
+
+- une *arcalité déclarée* : chartes d’“IA digne de confiance”, discours politiques sur la lutte contre la fraude, documents de marketing qui promettent d’“objectiver” le risque ou d’“optimiser” la sélection ;
+
+- une *arcalité implicite* : choix de variables (coûts de santé comme proxy des besoins, nationalité comme indicateur de risque), arbitrages entre faux positifs et faux négatifs, composition des jeux de données, sélection de critères de “talent” ou de “dangerosité”.
+
+L’enjeu archicratique n’est pas de moraliser *a posteriori* ces choix, mais de les *faire comparer sur scène* : *exposer les axiomes silencieux* (“nous considérons qu’il est plus grave de laisser passer un fraudeur que de punir un innocent”, etc.), *et permettre qu’ils soient discutés, contestés, révisés*.
+
+## Cratialité
+
+La *cratialité* désigne la dimension opératoire du pouvoir régulateur : la manière dont il s’applique concrètement, par quels instruments, quelles chaînes techniques, quelles procédures. C’est le “*par quoi*” et le “*comment*”.
+
+Dans Système F, la *cratialité* se déploie dans :
+
+- les *données mobilisées* (dossiers fiscaux, historiques de soins, casiers judiciaires, CV, contenus de plateformes) ;
+
+- les *pipelines* qui transforment des situations complexes en vecteurs numériques ;
+
+- les *modèles* eux-mêmes (architectures, paramètres, fonctions de coût, seuils de décision) ;
+
+- les *interfaces* (tableaux de bord, scores de risque, codes couleur, messages d’alerte) ;
+
+- les *procédures d’intégration* (règles internes qui imposent de suivre la recommandation ou d’en justifier tout écart).
+
+*Cratialité* n’est pas synonyme de “technique” : elle inclut aussi les *règles organisationnelles*, les *consignes*, les *scripts de travail*. L’audit archicratique ne se contente pas de repérer les algorithmes ; il suit les chaînes cratiales jusqu’aux guichets, aux tribunaux, aux services hospitaliers, aux départements RH, aux plateformes.
+
+## Archicration
+
+L’*archicration* est le troisième terme du triptyque : elle désigne la *scène d’épreuve où arcalité et cratialité sont amenées en visibilité, confrontées, mises à l’épreuve et, si nécessaire, transformées*.
+
+Sans *archicration*, les fondements restent fantômes, et le pouvoir opératoire devient autarcique.
+
+Une *archicration* digne de ce nom réunit quatre conditions minimales :
+
+1.  *Public(s) concerné(s) effectivement représentés* (et pas seulement des experts parlant “en leur nom”) ;
+
+2.  *Accès aux prises* : connaissance minimale des arcalités à l’œuvre (valeurs, finalités, proxies, fonctions de coût) et des cratialités (chaînes techniques, procédures, interfaces) ;
+
+3.  *Capacité de contestation* : possibilité d’interpeller les choix, de demander des modifications, de suspendre un dispositif ;
+
+4.  *Effet réel* : ce qui se dit sur la scène peut produire des transformations sur le système, pas seulement un “avis” consultatif.
+
+Dans Système F, la plupart des dispositifs existants – comités d’éthique, audits de biais, formulaires de recours – n’atteignent pas ce seuil : ce sont des *archicrations fantômes*, qui donnent l’allure de la scène sans en avoir la puissance.
+
+## Hypotopie, hypertopie, atopie
+
+Ces trois termes qualifient la topologie des scènes où la régulation IA apparaît (ou disparaît).
+
+- Une *hypotopie* est une *scène pauvre en prises, faiblement outillée, où les gens peuvent parler mais sans pouvoir effectivement infléchir la régulation*. Par exemple : un usager qui discute avec un agent de caisse sociale d’une décision prise en réalité par Système F, sans accès ni aux paramètres ni aux logs ; un formulaire de recours tellement opaque et lourd qu’il décourage toute contestation.
+
+- Une *hypertopie* est une *scène surdotée à huit-clos* : tout s’y joue – paramètres, seuils, choix de déploiement – mais entre un nombre très limité d’acteurs (directions, ingénieurs, juristes, consultants). *Les comités de pilotage où l’on décide d’intégrer ou non Système F dans la chaîne de décision, les réunions de design des modèles sont souvent des hypertopies*.
+
+- Une *atopie* est une *scène fantomatique* : elle mime le dispositif d’épreuve, sans donner prise réelle. Consultations publiques en ligne sans impact, “boîtes à idées” numériques, mécanismes de *feedback* qui alimentent surtout des métriques internes (satisfaction, engagement) sans reconfigurer la régulation.
+
+L’épreuve topologique, dans le cas IA, consiste à cartographier où se trouvent les *hypotopies, hypertopies, atopies*, et à inventer des scènes nouvelles qui rééquilibrent cette topologie.
+
+## Autarchicratie
+
+L’*autarchicratie* désigne un régime où la régulation devient son propre souverain : les dispositifs de mesure, de modélisation et de contrôle se gouvernent eux-mêmes à partir de leurs propres métriques, et ne reconnaissent plus que très marginalement des scènes externes d’épreuve.
+
+Dans Système F, l’*autarchicratie* prend plusieurs formes :
+
+- *modèles évalués principalement par leurs métriques internes* (perte, précision, indicateurs d’équité) ;
+
+- *dispositifs d’auto-audit et de reporting automatisé* qui servent de preuve de “responsabilité” sans ouvrir réellement le système à la contestation ;
+
+- *boucles de rétroaction fermées* où les décisions passées alimentent les données futures (ceux que le système considère comme “à risque” seront davantage contrôlés, et donc produiront plus de “preuves” de risque).
+
+L’*autarchicratie* est l’exact négatif de l’*archicratie* : *là où l’archicratie multiplie les scènes d’épreuve, l’autarchicratie les marginalise ou les simule*.
+
+## Co-viabilité
+
+Par *co-viabilité*, on entend la *capacité d’un ordre régulateur à rendre simultanément vivables plusieurs dimensions de l’existence* : sociale, écologique, symbolique, parfois économique.
+
+Dans le cas IA :
+
+- la *co-viabilité sociale* renvoie à l’*accès aux droits*, à la *protection contre l’arbitraire*, à la *dignité des personnes* (ne pas être réduit à un profil de risque opaque, pouvoir contester une décision qui affecte des prestations, des peines, des soins, un emploi) ;
+
+- la *co-viabilité écologique* concerne les *coûts matériels de l’infrastructure* (consommation énergétique, pressions sur les ressources, effets territoriaux des centres de données et des centres d’extraction) et la *possibilité de les mettre en scène* ;
+
+- la *co-viabilité symbolique* touche aux *représentations de la justice, du mérite, du risque, de la vérité*, et à la manière dont Système F contribue à les figer ou à les rouvrir.
+
+L’*épreuve de co-viabilité* ne se limite donc pas à mesurer des “impacts” ; elle demande : *quels types de scènes faut-il instituer pour que ces dimensions puissent être mises en balance, arbitrées et révisées ?*
+
+## Politique des épreuves viables
+
+La *politique des épreuves viables* est le nom donné à une *orientation normative minimale* : plutôt que de définir un modèle de justice idéal, elle consiste à organiser les épreuves auxquelles les dispositifs régulateurs doivent se soumettre pour rester archicratiques.
+
+Appliquée à l’IA, elle se traduit par une *série de gestes concrets* :
+
+- *droit au différé contradictoire* pour les décisions appuyées par un système ;
+
+- *journaux de justification* documentant les choix de modèles, de métriques, de proxies, d’usages ;
+
+- *visas d’affectation* qui autorisent ou interdisent certains usages de scores dans des décisions critiques ;
+
+- *coupe-circuits citoyens* permettant de suspendre un système en cas de dégâts massifs ;
+
+- *tribunaux de l’algorithme*, assemblées d’affectation, budgets scéniques pour financer le temps de la délibération et de la traduction ;
+
+- *révisions archicratives périodiques* s’accompagnant d’une *cartographie des scènes manquantes*.
+
+Dans le cas de Système F, ces gestes ne sont pas des ornements : ils définissent le seuil en deçà duquel il n’est plus raisonnable de parler de gouvernance archicratique de l’IA, mais d’*autarchicratie numérique*.
+
+## Système F
+
+Enfin, *Système F* n’est pas le nom d’un produit commercial, mais celui d’une figure composite : un modèle de fondation (LLM / modèle multimodal) accessible par API, intégré dans des flux de travail décisionnels de la protection sociale, de la santé, de la justice, des ressources humaines, des plateformes numériques.
+
+Il condense des caractéristiques empiriquement attestées :
+
+- *usage de systèmes de scoring* pour cibler des contrôles de fraude, évaluer des risques pénaux, gérer des programmes de soins, filtrer des candidatures, modérer des contenus ;
+
+- *insertion de modules d’IA dans des logiciels métier existants* ;
+
+- *dépendance à des fournisseurs privés de services cloud et de modèles* ;
+
+- *adoption de chartes d’“IA responsable” et de procédures d’audit parfois plus symboliques qu’effectives*.
+
+L’intérêt de Système F n’est donc pas de décrire un futur hypothétique, mais de donner un nom commun à une configuration déjà largement engagée, afin de lui appliquer, sans esquive, l’ensemble des épreuves archicratiques.

src/content/cas-ia/chapitre-1.mdx

@@ -0,0 +1,535 @@
+---
+title: "Chapitre I — Épreuve de détectabilité"
+edition: "cas-ia"
+status: "application"
+level: 1
+version: "0.1.0"
+concepts: []
+links: []
+order: 120
+summary: ""
+source:
+  kind: docx
+  path: "sources/docx/cas-ia/Cas_Pratique-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_1_Epreuve_de_detectabilite.docx"
+---
+# I. Épreuve de détectabilité : *arcalité / cratialité / archicration* dans un système d’IA
+
+L’épreuve de détectabilité ne consiste pas à ajouter une couche de vocabulaire au-dessus d’un dispositif déjà saturé de termes techniques. Elle exige, au contraire, un geste presque naïf : *où voit-on quelque chose ? Où peut-on désigner, avec un minimum de précision, ce qui fonde, ce qui opère et ce qui met en épreuve ?* Tant que ces trois prises restent indiscernables ou introuvables, l’*archicratie* n’est pas simplement déficitaire ; elle est empêchée. Appliquée à un grand système d’IA de fondation, l’épreuve de détectabilité commande une micro-cartographie patiente des lieux, des moments et des interfaces où Système F se rend effectivement présent – ou, plus souvent, se déploie sans se déclarer.
+
+## I.1. Scénarisation structurée du système IA
+
+L’enjeu de cette section n’est pas d’inventer un futur hypothétique, mais de composer un cas stylisé à partir d’éléments déjà avérés. Système F sera donc construit comme un agrégat abstrait de dispositifs bien documentés, provenant de plusieurs domaines (protection sociale, justice pénale, santé, recrutement, plateformes numériques). Chaque scène d’usage que nous décrirons ensuite reprend des traits explicitement attestés dans ces cas réels.
+
+### I.1.1. Les briques empiriques de Système F
+
+#### **Protection sociale : SyRI et le scandale des allocations familiales néerlandaises**
+
+Dans le domaine de la protection sociale, deux affaires néerlandaises forment un socle empirique très clair.
+
+Le système SyRI (*Systeem Risico Indicatie*) était un outil de détection de fraude aux prestations sociales, fondé sur le croisement massif de données issues de différentes administrations (assurance sociale, emploi, logement, fiscalité). En février 2020, le tribunal de district de La Haye a jugé que la législation encadrant SyRI violait l’article 8 de la Convention européenne des droits de l’homme (droit au respect de la vie privée), notamment en raison du manque de transparence sur le fonctionnement du système, de la faible proportionnalité et du ciblage de quartiers pauvres. Le tribunal a ordonné l’arrêt immédiat de l’utilisation de SyRI.
+
+Parallèlement, le scandale des allocations pour la garde d’enfants (*toeslagenaffaire*) a mis au jour un modèle de classification du risque utilisé par l’administration fiscale néerlandaise, qui a conduit à accuser à tort environ 26 000 parents de fraude. Ces familles ont été sommées de rembourser des montants importants de prestations, ce qui a provoqué des situations de surendettement massif, de pertes de logement et de détresse psychologique ; une part disproportionnée des victimes avaient un arrière-plan migratoire. Amnesty International a montré que des éléments comme la nationalité ou la double nationalité étaient utilisés comme facteurs de risque, produisant une boucle de discrimination systémique ; l’autorité néerlandaise de protection des données a conclu à un traitement discriminatoire.
+
+Ces deux cas attestent empiriquement que des systèmes de *scoring* algorithmique peuvent être intégrés au travail de guichet, cibler certaines catégories de population, fonctionner de manière opaque et produire des décisions automatiques de suspension ou de recouvrement, avec des voies de recours très limitées.
+
+#### **Justice pénale : l’algorithme COMPAS et l’affaire Loomis**
+
+Dans le champ pénal, l’algorithme COMPAS (Correctional Offender Management Profiling for Alternative Sanctions), développé par Northpointe/Equivant, est utilisé dans plusieurs États américains pour produire des scores de risque de récidive. Ces scores figurent dans des rapports d’aide à la décision destinés aux juges lors des phases de mise en liberté sous caution, de fixation de peine ou de libération conditionnelle.
+
+Dans l’affaire State v. Loomis (Cour suprême du Wisconsin, 2016), le prévenu a contesté l’usage de COMPAS en soutenant que la méthodologie était secrète (secret commercial) et qu’il ne pouvait donc ni en vérifier l’exactitude ni la contester. La Cour a maintenu la possibilité pour le juge d’utiliser COMPAS, mais à condition d’accompagner le score de mises en garde sur ses limites et en rappelant que la décision finale reste humaine, la méthode demeurant néanmoins non accessible à la défense.
+
+On dispose ainsi d’un cas où un score algorithmique chiffré s’inscrit explicitement dans la chaîne de la décision judiciaire, tout en restant largement opaque pour le justiciable et même pour le tribunal.
+
+#### **Santé : l’algorithme de gestion de risques analysé par Obermeyer et al. (Science, 2019)**
+
+Dans le système de santé américain, Ziad Obermeyer et ses co-auteurs ont étudié un algorithme commercial largement utilisé pour la gestion de programmes de “soins intensifs” destinés à des patients à haut risque.
+
+Cet algorithme produit, pour chaque patient, un score de risque ; ceux dont le score dépasse un seuil sont orientés vers des programmes qui mobilisent des ressources supplémentaires (suivi renforcé, coordination des soins, etc.).
+
+L’étude montre que, pour un niveau de risque donné selon l’algorithme, les patients noirs sont en moyenne beaucoup plus malades que les patients blancs (plus de pathologies non contrôlées, marqueurs biologiques plus dégradés).
+
+La raison identifiée est que l’algorithme ne prédit pas directement la morbidité, mais les coûts de santé futurs ; or, dans un système marqué par des inégalités d’accès aux soins, les patients noirs engendrent en moyenne moins de dépenses, à état de santé équivalent. Ce choix de variable (coûts comme proxy des besoins) introduit une biais structurel qui conduit à sous-orienter vers les programmes de soins renforcés des patients noirs qui en auraient le plus besoin.
+
+Ce cas illustre très précisément comment une fonction de coût et un choix de proxy peuvent incorporer une *arcalité implicite* (coûts ≈ besoins) et produire des *effets cratiaux massifs* sur l’accès aux ressources médicales.
+
+#### **Recrutement : l’outil de tri de CV d’Amazon**
+
+En 2018, Reuters a révélé qu’Amazon avait développé, puis abandonné, un outil interne de recrutement automatisé visant à classer des CV de candidat·es à des postes techniques. Entraîné sur une décennie d’historiques de recrutement dans un secteur très masculin, le système a “appris” que les profils masculins étaient plus souhaitables. Il pénalisait les CV comportant le mot “women’s” (comme “women’s chess club captain”) et déclassait les diplômées de certaines universités qualifiées de « féminines ».
+
+Confrontée à ces biais, l’entreprise a renoncé à déployer cet outil en production. Mais l’enquête montre qu’il est techniquement possible – et, en pratique, déjà réalisé – d’intégrer des modèles genrés de scoring dans la chaîne de sélection des candidatures, en laissant leur logique sous-jacente hors de la vue des candidat·es.
+
+#### **Plateformes numériques : modération et curation algorithmique**
+
+Enfin, dans le monde des plateformes, la documentation abondante sur Facebook/Meta, YouTube, TikTok ou X (ex-Twitter) montre que la modération des contenus et la curation algorithmique reposent massivement sur des systèmes automatisés, l’intervention humaine intervenant préférentiellement en seconde ligne ou pour les cas litigieux.
+
+Des guides destinés aux utilisateurs ou aux praticiens décrivent le fonctionnement général de ces dispositifs : chez Facebook, par exemple, l’IA est présentée comme “première ligne de défense”, qui scanne les contenus, détecte les possibles violations et les supprime directement ou les envoie à des modérateurs humains pour revue.
+
+Au niveau réglementaire, le Digital Services Act européen impose désormais aux grandes plateformes de publier des rapports annuels de transparence sur la modération de contenu, en distinguant explicitement les contenus supprimés ou limités suite à des décisions automatisées.  
+Le rapport 2022 de l’Agence des droits fondamentaux de l’UE sur les biais dans les algorithmes mentionne d’ailleurs l’usage croissant de systèmes de détection automatique de discours offensant, avec des risques de discrimination et de sur-modération de certaines communautés ou langues.
+
+En parallèle, la création de l’*Oversight Board* de Meta, doté d’un pouvoir de révision de certaines décisions de modération, confirme l’ampleur des enjeux : une instance quasi-juridictionnelle a été instituée pour examiner des cas emblématiques et problématiques, souvent issus de décisions initiales prises par des systèmes automatisés ou semi-automatisés.
+
+Ces éléments convergent : l’essentiel de ce qui se voit – ou ne se voit pas – sur les grandes plateformes est trié, promu, enfoui, suspendu par des combinaisons d’algorithmes de recommandation, de détection et de filtrage.
+
+### I.1.2. De ces cas à un système composite : définition structurée de “Système F”
+
+À partir de ces pièces empiriques, nous pouvons maintenant définir plus rigoureusement ce que nous appellerons Système F.
+
+#### **Un fournisseur de modèle de fondation accessible par API**
+
+Du côté de l’offre technique, il est désormais établi que des modèles de fondation (grands modèles de langage, modèles multimodaux) sont fournis sous la forme de services cloud accessibles via API. Le Comité européen de la protection des données (EDPB), par exemple, décrit explicitement le modèle “LLM as a Service” : un fournisseur héberge le modèle, en contrôle les poids et la formation, et donne accès aux utilisateurs par une interface de programmation, sans leur donner la main sur l’architecture interne.
+
+Des initiatives comme Azure OpenAI Service pour les administrations publiques américaines ou européennes, et des programmes dédiés comme “OpenAI for Government” ou “ChatGPT Gov”, illustrent l’extension de ce modèle au secteur public : les administrations peuvent appeler des modèles puissants pour traiter des textes, analyser des dossiers, générer des réponses, via des API sécurisées.
+
+L’Ada Lovelace Institute a documenté, dans un rapport dédié, l’usage déjà existant de modèles de fondation dans la sphère publique, intégrés à des outils “grand public” (moteurs de recherche, suites bureautiques, logiciels métiers) que les agents utilisent au quotidien.
+
+Dans notre scénarisation, Système F désigne donc un fournisseur de modèle de fondation (type LLM / modèle multimodal), hébergé dans le cloud, accessible via API, et mis à disposition d’acteurs publics et privés.
+
+#### **Des intégrateurs qui fabriquent des solutions verticales**
+
+Entre le fournisseur de modèle et les administrations, il y a des intégrateurs : grandes entreprises de services numériques, start-ups spécialisées, équipes internes “IA” de ministères ou d’agences. Leur rôle concret, pour l’instant, est bien attesté : adapter des briques de modèles génériques à des cas d’usage sectoriels (chatbots administratifs, aides à la rédaction de courriers, outils d’analyse de documents, systèmes de tri ou de priorisation).
+
+Les dispositifs de détection de fraude sociale, de *scoring* pénal, de gestion de risques en santé et de tri de CV mentionnés plus haut ne reposent pas tous sur des modèles de fondation au sens strict, mais ils incarnent déjà ce rôle d’intégrateur : transformer une capacité de calcul et de classification en un module prêt à l’emploi pour une administration précise. Système F se situe dans cette continuité : un modèle générique, repris et encapsulé par une diversité de prestataires qui construisent des “solutions” pour la protection sociale, la justice, la santé, le recrutement, la modération.
+
+#### **Des organisations utilisatrices : ministères, caisses, hôpitaux, tribunaux, entreprises, plateformes**
+
+Enfin, les utilisateurs institutionnels que nous considérons – caisses de prestations sociales, services fiscaux, tribunaux, hôpitaux, services RH, plateformes de réseaux sociaux – ne sont pas conjecturaux : ce sont précisément ceux qui, dans les affaires documentées, ont déjà recouru à des algorithmes de scoring, de tri ou de filtrage. Les études sur l’IA dans le secteur public montrent que les cas d’usage montent en puissance, notamment dans les fonctions de traitement de dossiers, de tri de demandes, de détection d’anomalies, d’assistance au recrutement et d’information au public.
+
+En agrégeant ces éléments, Système F désigne donc une chaîne socio-technique structurée en trois niveaux :
+
+- un fournisseur de modèle de fondation via API ;
+
+- des intégrateurs qui encapsulent ce modèle dans des solutions sectorielles ;
+
+- des organisations utilisatrices qui insèrent ces solutions dans leurs procédures quotidiennes.
+
+Cette structure n’est pas une vue de l’esprit : elle reflète l’architecture déjà mise en place par les grands fournisseurs d’IA et adoptée, progressivement, par des administrations publiques et des entreprises.
+
+### I.1.3. Quatre scènes typiques d’usage, stylisées mais ancrées
+
+Sur cette base, nous pouvons maintenant détailler quatre scènes d’usage de Système F, en indiquant à chaque fois les cas réels qui nourrissent la description.
+
+#### **L’agent de protection sociale et la liste des dossiers**
+
+Dans de nombreux pays européens, les systèmes de détection de fraude aux prestations prennent la forme de listes de dossiers accompagnées d’un score de risque. Les travaux sur SyRI et sur le scandale des allocations néerlandaises montrent que des fonctionnaires se voient présenter des listes de bénéficiaires classés par “profil de risque”, résultant de modèles qui croisent des données multiples (revenus, composition familiale, historique fiscal, etc.).
+
+Dans notre scène, l’agent·e d’une caisse sociale ouvre une application de gestion des dossiers : une file virtuelle apparaît, avec pour chaque dossier un score numérique et un code couleur. Le tri par défaut ne suit plus l’ordre chronologique de dépôt, mais la priorité calculée par un module issu de Système F, configuré pour combiner “risque de fraude” et “urgence” selon des paramètres fixés en amont. Cette configuration est directement inspirée des systèmes réels de risque de classement (*risk scoring*), même lorsqu’ils ne reposaient pas encore sur des modèles de fondation.
+
+#### **Le juge et le rapport de risque**
+
+L’expérience américaine avec COMPAS montre qu’un rapport de risque algorithmique peut être intégré au dossier judiciaire, sous la forme d’un document qui synthétise un score global et quelques facteurs aggravants ou atténuants. Dans l’affaire Loomis, le prévenu a été évalué comme “à haut risque” par COMPAS, et ce rapport a pesé dans la justification de la peine.
+
+Dans notre scène, le juge ne voit pas directement Système F, mais un rapport standardisé annexé au dossier : un score, une classe de risque, des éléments de langage justifiant ce score, issus d’un module pénal connecté au modèle de fondation. Ce schéma reprend les traits factuels de COMPAS (score, opacité de la méthode, statut “d’aide à la décision”) tout en les transposant dans une architecture de modèle de fondation accessible via API.
+
+#### **La médecin et la priorisation des patients**
+
+L’algorithme étudié par Obermeyer et al. montre comment un outil de gestion des risques en santé peut décider l’éligibilité à un programme de soins renforcés sur la base d’un score calculé à partir des coûts passés.
+
+Dans notre scène, un médecin hospitalier ouvre la liste des patients en attente d’un examen lourd ou d’une consultation spécialisée. L’interface, alimentée par un module de Système F, propose une “vue optimisée” : les patients sont ordonnés selon un indice de priorité calculé, avec un message qui signale lorsqu’elle s’écarte de cette priorisation (“vous vous écartez de la recommandation algorithmique, confirmez-vous ?”). La scène est stylisée, mais elle transpose directement la logique documentée : un score de risque conditionne l’accès à des ressources rares, et le praticien se voit suggérer un ordre “optimal”.
+
+#### **La plateforme et la visibilité des contenus**
+
+Les documents publics de Meta/Facebook reconnaissent que des systèmes automatisés scannent les contenus, les signalent, voire les suppriment directement en première intention. Les obligations de transparence du DSA confirment que les grandes plateformes utilisent des outils automatisés de modération et de recommandation à grande échelle.
+
+Dans notre scène, un utilisateur poste un contenu critique sur une politique publique ou un témoignage lié à des prestations sociales. Un module dérivé de Système F, intégré à la chaîne de modération et de recommandation, évalue ce contenu : il peut le classer comme “à risque” (discours haineux, désinformation présumée, “contenu limite”), réduire sa visibilité ou déclencher une revue humaine. L’utilisateur ne verra, le plus souvent, qu’un message laconique (“votre contenu a enfreint nos standards”) ou une chute d’audience difficilement interprétable.
+
+## I.2. *Arcalité déclarée* du système
+
+Par “*arcalité déclarée*”, nous désignerons l’ensemble des formules par lesquelles les acteurs qui conçoivent, diffusent ou utilisent des dispositifs algorithmiques disent ce qu’ils font et au nom de quoi ils le font. Il ne s’agit pas des détails techniques de l’implémentation, ni des effets réels que nous avons mis au jour dans les affaires de fraude sociale, de justice pénale, de santé, de recrutement ou de plateformes ; il s’agit des *justifications publiques*, telles qu’elles apparaissent dans les textes législatifs, les décisions de justice, les rapports d’autorités administratives, les documents d’entreprises, les chartes de “bonne conduite” et les programmes de régulation internationale. C’est cette couche discursive que l’épreuve archicratique doit d’abord prendre au sérieux, non pour la dénoncer en bloc comme “pure idéologie”, mais pour mesurer ce qu’elle rend visible et ce qu’elle tient pour acquis.
+
+Dans les cinq domaines où nous avons décrit des usages de Système F – protection sociale, justice pénale, santé, recrutement, plateformes numériques –, cette *arcalité déclarée* adopte des formes différentes, liées aux traditions propres de chaque champ, mais elle se rassemble autour d’une grammaire relativement stable : *lutte contre des menaces identifiées* (fraude, récidive, complications coûteuses, “mauvais recrutements”, contenus illégaux ou dangereux), *rationalisation de l’action publique ou privée*, *promesse d’objectivité*, *impératif de sécurité et de confiance*. À ce niveau, Système F apparaît d’abord comme un auxiliaire : l’algorithme n’est pas présenté comme un souverain qui se substituerait aux institutions, mais comme un instrument qui permettrait à celles-ci de mieux remplir leurs missions.
+
+### I.2.1. La fraude comme récit de fondation
+
+Dans le domaine de la protection sociale, l’*arcalité déclarée* est structurée par un récit désormais bien installé : *il s’agit de défendre l’intégrité de l’État social contre la fraude aux prestations, l’abus de droits et les détournements de fonds publics*. Comme l’a montré l’affaire SyRI et, plus encore, le scandale des allocations pour la garde d’enfants, la lutte contre la ‘*fraude*’ devient la matrice discursive qui justifie le recours à des systèmes de classements massifs et opaques.
+
+Dans ce cadre discursif, les termes techniques – *profil de risque*, *croisement de bases de données*, *ciblage des contrôles* – se présentent comme de simples moyens d’atteindre un but qui, lui, est posé comme incontestable : *protéger la “soutenabilité” des régimes de prestations en évitant qu’ils ne soient “vidés de leur substance” par des comportements abusifs*. L’essentiel de l’argument arcal se déploie dans un lexique de la vigilance et de la responsabilité : l’administration se doit, pour protéger les “vrais bénéficiaires”, de traquer les fraudeurs avec des outils modernes, proportionnés et ciblés.
+
+Du point de vue archicratique, on voit se dessiner ici une figure typique : la *fraude* devient le point focal de la justification. La question de savoir ce qu’est, concrètement, une erreur de bonne foi, un litige interprétatif, une situation de vulnérabilité structurelle, est reléguée à l’arrière-plan. La tension entre présomption d’innocence et présomption de suspicion est peu articulée ; le terme de “fraude” fonctionne comme un opérateur de condensation qui autorise des dispositifs de surveillance étendus, pourvu qu’ils soient décrits comme des moyens “nécessaires” à la sauvegarde de l’État social. L’*arcalité déclarée* est donc forte (*défense d’un bien collectif précieux*), mais très générale : elle ne descend guère au niveau des catégories fines qui seront effectivement travaillées par Système F.
+
+### I.2.2. Objectivation du risque et cohérence des peines
+
+Dans le champ de la justice pénale, l’*arcalité déclarée* s’appuie sur un autre récit, lui aussi bien identifié dans la littérature : celui de l’*évaluation actuarielle du risque* et de la “*cohérence*” *des décisions de justice*. Les guides destinés aux praticiens pour l’usage de COMPAS, par exemple, présentent l’outil comme une méthode “objective, standardisée, fondée sur la recherche” pour estimer la probabilité de récidive à partir d’un ensemble de facteurs psychosociaux et historiques.
+
+Dans l’arrêt *State v. Loomis*, la Cour suprême du Wisconsin accepte cette finalité : l’usage d’un instrument actuariel est recevable dès lors qu’il est clairement qualifié d’“aide à la décision” et que le juge conserve, en principe, la maîtrise de la peine. La Cour insiste sur la nécessité de rappeler les limites du système, mais elle ne remet pas en cause la légitimité de l’objectif affiché : rendre les décisions plus cohérentes, plus prévisibles, moins dépendantes des intuitions ou des préjugés des magistrats. L’*arcalité déclarée* articule ici un double horizon : *améliorer la justice distributive* (réduire les disparités de traitement) *et la sécurité publique* (anticiper les comportements futurs “à risque”).
+
+Ce discours s’inscrit dans une histoire plus longue de “gestion du risque” en droit pénal : montée des outils actuariels de probation, intérêt pour les “évaluations fondées sur la preuve”, critiques de l’arbitraire judiciaire. Il emprunte beaucoup au vocabulaire de la statistique, de la psychologie et du management du risque. L’algorithme n’est jamais présenté comme une source de normativité autonome ; il fournit des scores, des ratios, des catégories (“faible”, “moyen”, “élevé”) qui doivent éclairer des décisions qui, elles, demeurent juridiquement encadrées. L’*arcalité déclarée* est donc celle d’une *rationalisation du pouvoir de juger* : mettre la peine sous le signe du calcul et de l’expertise plutôt que du tâtonnement individuel.
+
+### I.2.3. Gestion de population et ciblage de ressources rares
+
+Dans le domaine de la santé, les algorithmes que nous avons retenus comme briques de Système F sont inscrits dans un lexique propre : celui de la “politique santé des populations”, de la “gestion de patients jugés à risque”, de la “prévention des hospitalisations évitables”. L’algorithme analysé par Obermeyer et al. est présenté par ses concepteurs et par les hôpitaux qui l’utilisent comme un outil permettant d’identifier les patients “aux besoins complexes” et de les orienter vers des programmes de gestion de soins intensifs.
+
+Les documents de promotion de ce type de systèmes insistent sur un double objectif : d’une part, “*améliorer la qualité des soins*” en offrant un suivi renforcé aux patients les plus vulnérables ; d’autre part, “*maîtriser les coûts*” en réduisant les complications graves, les ré-hospitalisations et les recours imprévus aux urgences. L’*arcalité déclarée* assume pleinement cette tension : il s’agit de *concilier des impératifs cliniques et budgétaires en allouant des ressources rares* (temps médical, programmes sophistiqués, coordination, technologies coûteuses) *de la “façon la plus efficiente possible*”.
+
+Sur le plan discursif, la notion de “*risque élevé*” est donc chargée d’une valeur positive : loin de stigmatiser les patients, elle leur ouvre l’accès à des dispositifs jugés bénéfiques. Le modèle d’IA est décrit comme un moyen de “repérer ce que l’œil humain ne voit pas facilement”, c’est-à-dire de *détecter en amont des trajectoires de dégradation de la santé*. À nouveau, l’*arcalité déclarée* en appelle à des valeurs fortes : *meilleure prise en charge, prévention, justice dans l’allocation des soins, soutenabilité financière des systèmes de santé*.
+
+### I.2.4. “Talent”, méritocratie et efficacité de la sélection
+
+Dans le secteur du recrutement, les systèmes de tri automatisé empruntent d’autres registres. Les discours qui entourent le projet de classement des CV développé par Amazon, ainsi que la littérature managériale plus large sur les “*talent analytics*”, convergent vers une même promesse : “*mécaniser la recherche des meilleurs talents*”, “*libérer les recruteurs des tâches répétitives*”, “*standardiser la sélection*” et “*réduire les biais individuels*” en confiant la première lecture des dossiers à un modèle.
+
+L’*arcalité déclarée* ici ne renvoie ni à l’État social ni à la justice pénale, mais à une certaine *représentation de la méritocratie en entreprise* : les “bons profils” seraient ceux qui maximisent la performance, la productivité, l’adéquation à la culture de l’organisation. Le système d’IA est présenté comme un “assistant impartial” capable de faire émerger des “signaux faibles” dans les CV, de repérer des trajectoires prometteuses, de réduire le poids des impressions fugitives et des “préjugés inconscients” des recruteurs.
+
+Ce discours est en résonance avec une tradition managériale qui valorise le *data-driven HR*, la capacité à “objectiver” des intuitions en les traduisant en scores, en *rankings*, en probabilités de succès. L’algorithme devient une sorte de miroir supposé neutre des “caractéristiques qui différencient les meilleurs employés des autres”, pour reprendre une formule fréquemment mobilisée dans ce champ. L’*arcalité déclarée* associe donc trois promesses : *gain d’efficacité*, *amélioration de la qualité des recrutements*, *réduction affichée des biais humains*.
+
+### I.2.5. Sécurité, “contenus illégaux” et transparence
+
+Dans l’univers des grandes plateformes, le Digital Services Act européen donne une formulation particulièrement nette de l’*arcalité déclarée*. Le DSA affirme vouloir “*réduire la distribution de contenus illégaux*”, protéger les utilisateurs contre diverses formes de risques en ligne, et instaurer des exigences nouvelles de transparence et de responsabilisation pour les intermédiaires.
+
+Les plateformes, de leur côté, ont développé depuis plusieurs années un lexique de sûreté et de réduction des risques : leurs règles de “standards communautaires” ou de “règles de la communauté” visent à “protéger” les utilisateurs contre les discours haineux, le harcèlement, la propagande terroriste, la désinformation dommageable, les images violentes ou sexualisées non consenties. Elles décrivent leurs systèmes d’IA comme une “*première ligne de défense*” qui filtre les contenus au moment de la mise en ligne, identifie les violations manifestes, et transmet les cas ambigus à des équipes de modération humaines.
+
+L’*arcalité déclarée* se trouve ici à la frontière entre droit et morale : les plateformes affirment respecter les législations nationales et européennes, mais elles revendiquent aussi la mise en œuvre de “standards de communauté” qui excèdent parfois les strictes obligations juridiques. Avec le DSA, une grammaire spécifique se stabilise : celle de la “*sécurité en ligne*” et de la “*transparence des décisions de modération*”, adossée à des *obligations concrètes* (mécanismes de signalement des contenus illégaux, justification des décisions de retrait ou de déréférencement, bases de données publiques d’actions de modération).
+
+Dans ce cadre, l’usage d’outils automatisés est présenté comme un moyen de faire face à des volumes massifs de contenus, de “réagir rapidement” à des menaces, de limiter l’exposition du public à des messages jugés dangereux. L’*arcalité déclarée* articule donc *protection des usagers, respect de la liberté d’expression* (au moins dans l’intention), *et exigence de transparence accrue.*
+
+### I.2.6. Principes transversaux : “*IA responsable*”, “*IA digne de confiance*”
+
+Au-dessus de ces légitimités sectorielles, une couche plus générale s’est constituée autour de l’idée d’“*IA responsable*” ou d’“*IA digne de confiance*”. Les Principes de l’OCDE sur l’intelligence artificielle, adoptés en 2019, affirment que les systèmes d’IA devraient “*bénéficier aux personnes et à la planète en favorisant une croissance inclusive, le développement durable et le bien-être*”, être conçus de manière à “*respecter l’état de droit, les droits de l’homme, les valeurs démocratiques et la diversité*”, et inclure des garanties appropriées (*intervention humaine, traçabilité, sécurité*).
+
+Les Lignes directrices européennes pour une IA digne de confiance, élaborées par le groupe d’experts de haut niveau sur l’IA, déclinent ces ambitions en sept “*exigences*” : agence humaine et contrôle, robustesse et sécurité techniques, gouvernance des données, transparence, diversité et équité, bien-être sociétal et environnemental, responsabilité. Elles sont assorties d’une liste d’auto-évaluation (ALTAI) destinée aux développeurs et aux utilisateurs pour vérifier que leurs systèmes s’y conforment.
+
+Les grands fournisseurs privés de modèles de fondation se sont, pour l’essentiel, alignés sur cette grammaire. Google a publié en 2018 ses “*AI Principles*”, qui insistent sur le fait que les applications d’IA doivent être “*socialement bénéfiques*”, “*éviter de créer ou de renforcer des biais injustes*”, être “*construites et testées pour la sécurité*”, “*être responsables devant les personnes*” et “*incorporer la vie privée dès la conception*”. Microsoft a formulé, quant à lui, un ensemble de principes analogues : *équité, fiabilité et sécurité, confidentialité et sécurité, transparence, responsabilité, inclusivité*, qui servent de base à son “*Responsible AI Standard*” interne.
+
+Cette couche transversale d’énoncés n’est pas anecdotique : elle fournit le vocabulaire dans lequel Système F doit, aujourd’hui, se présenter pour être légitime. Une administration qui lance un appel d’offres pour un module de détection de fraude ou d’aide à la décision judiciaire attend des fournisseurs qu’ils s’inscrivent dans ce registre ; une entreprise qui internalise un système de tri de CV est incitée à le faire sous la bannière de l’“IA responsable” et de la lutte contre la discrimination. L’*arcalité déclarée* de Système F est donc redoublée par ce *halo de principes généraux*, qui se veulent compatibles avec les droits fondamentaux et les valeurs démocratiques.
+
+### I.2.7. Une grammaire commune de légitimation
+
+Si l’on rassemble ces différents registres, une grammaire commune de l’*arcalité déclarée* apparaît assez nettement. Elle articule au moins quatre motifs récurrents.
+
+Le premier est celui de la *protection contre des menaces identifiées*. Dans la protection sociale, c’est la fraude aux prestations qui menace la viabilité du système ; dans la justice pénale, c’est la récidive qui met en danger la sécurité publique ; dans la santé, ce sont les complications évitables et les trajectoires de dégradation qui menacent la stabilité des systèmes de soins ; dans le recrutement, ce sont les “mauvais choix” qui mettent en péril la compétitivité de l’entreprise ; sur les plateformes, ce sont les contenus illégaux ou nocifs qui mettent en péril les usagers et l’espace public. L’algorithme est habilité à partir du moment où il est cadré comme une *barrière* supplémentaire contre ces risques.
+
+Le deuxième motif est celui de la *rationalisation* et de l’*efficience*. L’automatisation est décrite comme un moyen de traiter plus de dossiers, plus rapidement, avec moins de ressources humaines, de rendre les décisions plus cohérentes, de réduire l’arbitraire. Dans le langage des administrations sociales, cela se traduit par la promesse de “*ciblage des contrôles*” et de “*réduction des abus*” ; dans celui des hôpitaux, par la “*priorisation des patients à haut risque*” ; dans celui des services RH, par la “*gestion de volumes massifs de candidatures*” ; dans celui des plateformes, par la possibilité de *modérer des quantités de contenus impossibles à gérer manuellement*. Système F est ici la figure d’un auxiliaire rationnel, intensifiant les capacités habituelles des organisations.
+
+Le troisième motif est celui de l’*objectivité* – ou, à tout le moins, d’une réduction des biais imputés aux évaluations purement humaines. Dans la justice pénale, l’*évaluation actuarielle* se donne comme “*fondée sur la preuve*” plutôt que sur les intuitions ; dans la santé, le score de risque agrège des données cliniques et des historiques de dépenses ; dans le recrutement, l’algorithme promet d’être indifférent au genre, à l’origine, à l’apparence ; dans les plateformes, les modèles de détection de contenus haineux ou terroristes se présentent comme appliquant des critères constants. L’*arcalité déclarée* insiste sur l’idée que ces dispositifs ne font que *mesurer* ou *mettre en forme* *des régularités objectives déjà là*.
+
+Enfin, le quatrième motif est celui de la *sécurité* et de la *confiance*. Les discours sur l’“*IA digne de confiance*” et les documents de régulation européenne convergent : *pour être acceptable, un système doit être robuste, fiable, “sûr”, respecter la vie privée, être transparent et rendre des comptes*. Dans le langage des plateformes, la “*sûreté*” est un *produit que l’on fournit aux utilisateurs* ; dans les textes de l’OCDE et de l’Union européenne, la “*confiance*” est une *condition de possibilité du déploiement de l’IA dans des secteurs sensibles*.
+
+Cette grammaire n’est pas simplement un vernis. Elle structure les termes dans lesquels les acteurs peuvent se justifier devant les tribunaux, les autorités de régulation, les opinions publiques. Elle *détermine ce qui peut être publiquement défendu* et ce qui, au contraire, doit rester dans les coulisses (sélection des variables, choix des proxies, calibrage des seuils). Du point de vue archicratique, elle constitue bien une *arcalité* : *une manière d’exposer – au moins en principe – les finalités et les valeurs censées commander l’usage* de Système F.
+
+### I.2.8. Une *arcalité réelle*, mais *extra-scénique*
+
+Reste à savoir dans quelle mesure cette *arcalité déclarée*, riche et apparemment sophistiquée, remplit les conditions minimales d’une *arcalité* proprement archicratique, c’est-à-dire d’une mise en scène effective des fondements. La réponse, à ce stade de l’audit, est ambivalente.
+
+D’un côté, il serait excessif de considérer que les dispositifs que nous avons examinés seraient dépourvus de toute justification explicite. La lutte contre la fraude sociale, la recherche de cohérence dans les peines, la volonté de mieux prendre en charge des patients vulnérables, l’ambition de limiter les discriminations à l’embauche, la nécessité de réguler les contenus illégaux ou dangereux sur les grandes plateformes, la référence aux droits fondamentaux et aux valeurs démocratiques dans les textes internationaux : tout cela constitue un *socle normatif substantiel*. L’*arcalité déclarée* n’est pas un pur écran de fumée ; elle exprime des préoccupations réelles, souvent largement partagées.
+
+D’un autre côté, cette *arcalité* reste le plus souvent *extra-scénique*. Elle s’exprime dans des préambules de lois, des communiqués, des chartes, des rapports, mais elle n’est guère travaillée dans des scènes où les notions centrales – fraude, risque acceptable, mérite, besoin de soin, dangerosité, contenu nuisible – seraient définies, discutées, révisées en présence de ceux qui en subissent les effets. La définition pratique de la fraude, dans les dispositifs de protection sociale, n’est pas débattue en tant que telle avec les allocataires ; la hiérarchie entre erreurs acceptables et erreurs intolérables dans la justice pénale n’est pas posée frontalement aux justiciables ; le choix de prendre les coûts comme proxy des besoins en santé n’est pas soumis à une délibération spécifique avec les patients et les soignants ; les critères de “talent” dans le recrutement ou de “contenu nuisible” sur les plateformes ne donnent que rarement lieu à des dispositifs de confrontation structurée.
+
+L’effet archicratique de cette situation est double. D’une part, les *valeurs affichées* – protection de l’État social, prévention de la récidive, justice dans l’accès aux soins, égalité des chances, sécurité des espaces numériques, respect des droits fondamentaux – fonctionnent comme des *slogans d’arrière-plan* : elles justifient en bloc l’entrée de Système F dans les chaînes décisionnelles, sans que soient explicitées les manières concrètes dont elles sont traduites en paramètres, en seuils, en arbitrages d’erreurs. D’autre part, cette *faiblesse scénique* ouvre un espace où les véritables fondements opératoires tendent à se déplacer vers d’autres couches du dispositif : fonctions de coût, choix de proxies, sélection de variables, architecture des jeux de données.
+
+Autrement dit, l’*arcalité déclarée* de Système F est à la fois réelle et incomplète : elle pose des finalités, mais elle ne prend pas à bras-le-corps la question de leur implémentation normative fine. Elle ouvre un horizon de légitimation, mais elle laisse largement hors scène les fondements effectifs à partir desquels le système se met à discriminer, prioriser ou classer.
+
+C’est cette dissociation que la section suivante se propose d’examiner. En passant à l’*arcalité implicite*, nous quitterons les formulations officielles pour aller voir où se logent, dans Système F, les axiomes silencieux : ceux qui définissent en pratique ce qui compte comme fraude, comme risque tolérable, comme mérite, comme besoin, comme contenu acceptable. C’est là que se noue l’*oblitération archicratique* caractéristique des dispositifs contemporains : non pas absence de fondement, mais fuite du fondement derrière l’optimisation.
+
+## I.3. *Arcalité implicite*
+
+Avec l’*arcalité déclarée*, nous avons observé ce que les acteurs disent de Système F : protection de l’État social, objectivation du risque pénal, ciblage des soins, rationalisation du recrutement, sécurité des espaces numériques, “IA responsable” et “digne de confiance”. L’*arcalité implicite* se loge ailleurs : dans les *fonctions de coût*, les *proxies choisis*, les *métriques d’évaluation*, la *composition des jeux de données*, les *seuils*, les *arbitrages sur les erreurs*. C’est là que se décide, au sens fort, ce qu’est un “bon” résultat pour le système, ce qu’on est prêt à sacrifier, qui l’on accepte de sur-surveiller, qui l’on accepte de mal desservir.
+
+Du point de vue archicratique, chaque choix de ce type relève d’un acte de fondation silencieux : il fixe une hiérarchie entre injustices acceptables, il distribue les soupçons et les protections, il stabilise une certaine vision de ce qui compte. L’important n’est pas d’opposer un “pôle technique” neutre à un “pôle politique” chargé ; c’est de *reconnaître que le paramétrage lui-même a une portée normative*, et qu’il constitue une *arcalité effective* qui, le plus souvent, ne comparaît jamais en tant que telle. C’est ce régime des fondements non mis en scène que nous appellerons *arcalité implicite* ou *arcalité fantôme*.
+
+### I.3.1. Arbitrages d’erreurs et profilage social
+
+Dans les dispositifs de détection de fraude aux prestations qui composent la brique “protection sociale” de Système F, l’objectif opérationnel est de distinguer des dossiers “à risque” des autres. Techniquement, cela se traduit par une *fonction de coût qui pondère plusieurs objectifs* : *maximiser la détection des fraudes avérées*, *limiter les faux positifs*, *contenir les coûts d’enquête*, *éviter de suspendre abusivement des prestations*. En apparence, il s’agit d’*optimiser une procédure de contrôle* ; en réalité, on décide comment répartir la charge de l’erreur entre l’État et les allocataires.
+
+L’affaire néerlandaise des allocations pour la garde d’enfants, relue par Amnesty International dans son rapport *Xenophobic Machines*, a montré à quel point ces arbitrages implicites pouvaient devenir violents. Des dizaines de milliers de familles, très majoritairement à faibles revenus et souvent issues de l’immigration, ont été accusées à tort de fraude et soumises à des recouvrements massifs sur la base de profils de risque établis par un système automatisé. Amnesty documente l’usage de variables comme la nationalité ou la double nationalité dans la construction des profils, ce qui produisait un ciblage disproportionné de certains groupes ethniques et migratoires.
+
+Du point de vue archicratique, plusieurs axiomes implicites se donnent ici à voir. D’abord, l’idée selon laquelle il serait acceptable de concentrer un volume élevé de faux positifs sur des populations déjà précaires, au nom de la défense du budget public, sans scène où ces personnes puissent contester la hiérarchie ainsi instituée entre la protection des fonds et la protection des droits. Ensuite, l’idée qu’une caractéristique comme la nationalité puisse servir de proxy de suspicion, alors même que le droit non discriminatoire des États européens proscrit précisément ce type d’usage. Le rapport *Xenophobic Machines* parle de discrimination “intégrée” dans la conception même du système, non seulement dans ses usages déviants.
+
+La décision du tribunal de La Haye dans l’affaire SyRI confirme le diagnostic à un autre niveau. SyRI était un dispositif de profilage de risque en matière de sécurité sociale, fondé sur le croisement massif de données issues de multiples administrations et sur la production de “*rapports de risque*” transmis aux services d’inspection. Le tribunal a jugé que la législation encadrant SyRI violait l’article 8 de la Convention européenne des droits de l’homme, en raison notamment d’un déficit de transparence, de l’ampleur du traitement et du ciblage de quartiers défavorisés.
+
+Ce qui est en cause, là encore, n’est pas seulement une erreur de calibrage, mais une *arcalité implicite* : il serait considéré comme *tolérable de soumettre certains territoires à un profilage intensif*, *de croiser leurs données à grande échelle, de déclencher des enquêtes intrusives sur la base de scores opaques, au nom d’un “juste équilibre” entre lutte contre la fraude et respect de la vie privée*. Or ce “*juste équilibre*” n’a pas été déterminé sur une scène où l’on aurait mis en débat les types d’erreurs acceptables, les populations exposées, la nature des données croisées. Il a été fixé dans la fonction de coût globale du système, puis naturalisé sous la forme d’une procédure “moderne” de contrôle.
+
+L’*arcalité implicite* de Système F, dans ce segment social, prend donc la forme d’une *hiérarchisation silencieuse* : mieux vaut tolérer un nombre important de faux positifs concentrés sur des familles vulnérables que d’accepter une fraude résiduelle ; mieux vaut considérer certains profils nationaux ou résidentiels comme intrinsèquement plus suspects que d’ouvrir un débat public sur les causes structurelles des erreurs, des omissions ou des malentendus administratifs.
+
+### I.3.2. Le *proxy* “*coûts*” comme axiome de valeur
+
+L’algorithme de gestion des risques étudié par Ziad Obermeyer et ses co-auteurs offre un exemple paradigmatique d’*arcalité implicite*. Le système, largement utilisé dans les systèmes de santé américains, sert à déterminer quels patients doivent bénéficier de programmes de “*care management*” intensif : ceux dont le score dépasse un certain seuil se voient offrir un suivi renforcé, des ressources supplémentaires et une coordination accrue.
+
+Les auteurs montrent que, pour un même score de risque donné par l’algorithme, les patients noirs sont en moyenne bien plus malades que les patients blancs : davantage de pathologies chroniques non contrôlées, plus de complications, etc. La raison n’est pas une “erreur” de calcul, mais le choix du proxy : l’algorithme prédit les coûts de santé futurs plutôt que la morbidité elle-même. Or, dans un système marqué par des inégalités d’accès aux soins, on dépense historiquement moins pour les patients noirs que pour les patients blancs à état de santé comparable. En prenant les coûts comme substitut des besoins, l’algorithme sous-estime donc systématiquement les besoins des patients noirs, ce qui conduit à les orienter beaucoup plus rarement vers les programmes intensifs.
+
+Du point de vue archicratique, le choix du proxy “coûts” constitue un acte d’*arcalité implicite* majeur : il institue, sans jamais le dire, l’idée que *la meilleure approximation des besoins de santé d’un individu est ce que le système a déjà dépensé pour lui*. Dans un univers égalitaire et sans contraintes budgétaires, ce raccourci pourrait éventuellement se discuter ; dans un univers où l’accès aux soins est profondément inégal, il revient à considérer que les vies pour lesquelles on a historiquement le moins dépensé sont objectivement moins “à risque” et moins prioritaires. L’axiome est extraordinairement chargé sur le plan moral et politique, mais il n’est pas présenté comme un choix de justice : il est codé comme un paramètre d’optimisation raisonnable.
+
+Obermeyer et al. montrent qu’en remplaçant le proxy “coûts” par un proxy plus proche des besoins cliniques (par exemple le nombre de maladies chroniques non contrôlées), on pourrait presque tripler la part des patients noirs orientés vers les programmes intensifs.
+
+Autrement dit, un seul choix de variable suffit à faire basculer la répartition d’un dispositif de soin à grande échelle. Or ce choix n’a donné lieu ni à une controverse publique, ni à une délibération institutionnelle, ni à un dispositif d’*archicration* : il a été décidé en amont, au croisement de considérations pratiques (disponibilité des données, facilité de mesure) et de rationalités gestionnaires (coûts comme indicateur privilégié), puis diffusé comme allant de soi.
+
+Ce cas illustre avec une précision chirurgicale ce que nous nommons *arcalité fantôme* : l’*existence de fondements normatifs réels* – ici, une conception du besoin de santé traduite en coût – *qui pilotent une large distribution de ressources, sans jamais être convoqués sur une scène où ils devraient se justifier devant ceux qu’ils affectent*.
+
+### I.3.3. Hiérarchies des erreurs et justice des risques
+
+L’outil d’évaluation de risque pénal COMPAS, lorsqu’on le regarde à travers les débats suscités par l’enquête de ProPublica et les réponses de ses concepteurs, met en lumière un autre aspect de l’*arcalité implicite* : la gestion différenciée des faux positifs et des faux négatifs selon les groupes. ProPublica a montré en 2016 que, dans le comté de Broward, les accusés noirs étaient beaucoup plus souvent classés à tort comme “à haut risque” que les accusés blancs (faux positifs), tandis que les accusés blancs étaient plus souvent classés à tort comme “faible risque” alors qu’ils récidivaient (faux négatifs).
+
+Des chercheurs et les auteurs de COMPAS ont contesté la méthodologie de ProPublica, en soulignant qu’il est mathématiquement impossible de satisfaire simultanément plusieurs notions de “*justice algorithmique*” (par exemple égalité des taux de faux positifs et égalité de calibration) lorsque les taux de récidive diffèrent entre groupes.
+
+Mais, du point de vue archicratique, cette impossibilité mathématique ne dissout pas le problème : elle le reformule avec plus d’acuité. Si toutes les configurations sont impossibles simultanément, il faut choisir lesquelles on privilégie : *faut-il minimiser les faux négatifs* (ne pas laisser sortir un individu qui récidivera) *au prix d’un grand nombre de faux positifs* (maintenir en détention des personnes qui n’auraient pas récidivé) ? *Ou l’inverse ? Est-il acceptable que ces arbitrages se distribuent différemment selon les groupes racisés ?*
+
+En droit pénal, cette question n’est pas nouvelle : elle recoupe des débats de longue durée sur la *présomption d’innocence*, sur la maxime selon laquelle “*mieux vaut laisser dix coupables en liberté que condamner un innocent*”, sur la hiérarchie entre sécurité collective et protection contre l’erreur judiciaire. Ce que le recours à un outil actuariel comme COMPAS transforme, c’est le lieu où cette hiérarchie est fixée : au lieu d’être l’objet d’une discussion explicite – au Parlement, dans la doctrine, dans la jurisprudence – elle est réglée par la manière dont on écrit la fonction de coût, choisit les métriques d’évaluation, fixe les seuils de risque et paramètre la calibration. Les débats techniques sur les définitions de l’équité deviennent le substitut de débats normatifs sur ce que l’on juge plus grave : enfermer injustement ou libérer à tort.
+
+Là encore, l’*arcalité implicite* n’est pas l’absence de normativité, mais sa *relégation dans des micro-décisions techniques qui n’apparaissent jamais comme telles aux justiciables*. Un prévenu auquel on annonce un score de risque “élevé” ne voit pas la structure normative qui a présidé au calibrage des erreurs ; un juge qui consulte ce score ne voit pas davantage la hiérarchie implicite entre types d’injustice. La scène archicratique – celle où l’on discuterait ouvertement du partage admissible des risques d’erreurs – se trouve remplacée par une scène actuarielle limitée à quelques spécialistes.
+
+### I.3.4. Apprendre des hiérarchies sociales existantes
+
+Le système de tri de CV développé par Amazon, puis abandonné avant son déploiement, met au jour une autre dimension de l’*arcalité implicite* : *l’importation non critique de hiérarchies sociales existantes dans la définition de ce qui compte comme “talent”*. L’enquête de Jeffrey Dastin pour Reuters a montré que l’outil, entraîné sur une dizaine d’années d’historiques de recrutement dans des métiers techniques majoritairement masculins, avait “appris” à désavantager les CV féminins : il pénalisait les dossiers contenant le mot “women’s” et rétrogradait certains établissements fréquentés par des femmes.
+
+L’*arcalité implicite* ne réside pas seulement dans ces effets visibles, mais dans la décision initiale de prendre le passé des recrutements comme référence pour l’avenir. En faisant de la capacité à prédire “qui serait embauché” à partir des données historiques la fonction de coût principale, Amazon a installé comme norme ce que ses pratiques antérieures, déjà marquées par un déséquilibre de genre, considéraient comme un “*bon candidat*”. L’algorithme n’invente pas le biais ; il le systématise et le cristallise.
+
+Du point de vue archicratique, cette configuration revient à traiter les décisions passées – elles-mêmes situées dans des rapports de pouvoir, des routines, des préjugés – comme un “réel” à imiter. La question “qu’est-ce qu’un talent ?” n’est pas abordée comme une question ouverte, susceptible de révision, mais comme un pattern à extraire d’un corpus de CV, de trajectoires et de décisions. L’*arcalité implicite* associe trois éléments : *l’idée que la performance passée est la meilleure mesure du mérite futur* ; *la naturalisation de hiérarchies de genre, de diplôme, de style de CV* ; *la marginalisation de toute scène où ces hiérarchies pourraient être discutées par les personnes qu’elles affectent.*
+
+L’épisode se conclut par l’abandon du projet, une fois les biais mis au jour par les ingénieurs. Mais il illustre bien la logique de Système F : tant que l’algorithme fonctionne dans les coulisses, la question de la normativité de ses critères reste invisible. Ce n’est qu’au moment où l’outil “déraille” visiblement – ici, en supprimant presque mécaniquement les femmes du pool de candidats – que les questions archicratiques surgissent, sur un mode défensif.
+
+### I.3.5. Seuils de tolérance et architectures de la visibilité
+
+Dans le cas des plateformes numériques, l’*arcalité implicite* se manifeste dans un autre registre : celui des seuils de tolérance au contenu et des architectures de visibilité. Les textes de mise en œuvre du Digital Services Act, ainsi que les guides de transparence publiés par la Commission européenne et les analyses doctrinales récentes, montrent que les grandes plateformes sont désormais explicitement tenues de rendre compte de leurs décisions de modération, des outils automatisés qu’elles emploient et des risques systémiques qu’elles identifient.
+
+Les rapports de transparence de Meta, combinés aux travaux de l’*Oversight Board* et aux analyses critiques sur l’évolution des “*Community Standards*”, illustrent concrètement l’ampleur de la délégation faite à des systèmes d’IA pour détecter, classer et retirer des contenus. Meta reconnaît que des systèmes automatisés identifient et agissent sur une grande partie des contenus avant même qu’ils soient signalés, et l’*Oversight Board* rappelle que des millions d’utilisateurs font appel de décisions de retrait initialement prises par ces systèmes, souvent en expliquant que leur contenu relevait de l’information, de la satire ou du témoignage.
+
+Dans ce contexte, l’*arcalité implicite* ne se situe pas seulement dans la définition formelle des “discours haineux”, des “contenus terroristes” ou de la “désinformation”, ni même dans la distinction entre illégalité et simple non-conformité aux standards de communauté. Elle se loge dans la manière dont les systèmes automatisés et leurs opérateurs paramètrent les seuils : *à partir de quel degré d’ambiguïté un contenu est-il retiré préventivement ? jusqu’où privilégie-t-on la réduction du risque d’exposition au détriment de la préservation de la parole minoritaire ? comment traite-t-on les contenus dans des langues peu dotées, pour lesquelles les modèles sont moins précis ?* Les études récentes sur l’impact de ces choix dans le Sud global ou pour certaines communautés minorées montrent que les erreurs de classification et les suppressions abusives se concentrent souvent là où les ressources linguistiques et les contextes locaux sont les moins bien pris en compte.
+
+Le DSA impose aux très grandes plateformes la création de bases de données de décisions de modération et ouvre des accès à la recherche, ce qui, en principe, devrait permettre de rendre visibles ces arbitrages. Mais, tant que le débat reste centré sur la conformité globale aux obligations (rapports de transparence, existence de mécanismes de recours, descriptions qualitatives des systèmes automatisés), la question archicratique de fond – à savoir la hiérarchie implicite entre les types d’erreurs acceptables, les types de contenus sur-modérés ou sous-modérés, les publics plus ou moins protégés – demeure largement encapsulée dans les paramètres des modèles et dans les règles internes.
+
+### I.3.6. L’*arcalité fantôme* comme régime des fondements non mis en scène
+
+Les fragments que nous venons de parcourir permettent de préciser, sans métaphore, ce que nous nommons *arcalité implicite* ou *arcalité fantôme*.
+
+Nous appellerons *arcalité fantôme* l’*opérateur dont les fondements normatifs du dispositif ne disparaissent pas, mais se trouvent encapsulés dans des options de paramétrage* (fonctions de coût, proxies, métriques, seuils) *qui opèrent à l’intérieur de la cratialité, sans jamais être exposées comme telles sur une scène d’épreuve*.
+
+Dans la protection sociale, la *manière de calibrer les modèles de détection de fraude* – *choix des variables, des seuils, des quartiers ciblés, rapport accepté entre faux positifs et faux négatifs* – encode une *hiérarchie entre la lutte contre les abus et la protection des allocataires de bonne foi*, ainsi qu’une *distribution des soupçons selon des lignes de classe et d’origine*. Cette *hiérarchie* n’est en aucune manière discutée publiquement avec les personnes concernées ; elle est incorporée dans la fonction de coût globale du dispositif.
+
+Dans la santé, le *choix d’un proxy* comme les *coûts de santé* pour représenter *les besoins encode une conception implicite de la valeur des vies en fonction des dépenses déjà engagées*, *dans un contexte où ces dépenses sont ethniquement inégales*. Ce choix transforme une inégalité historique d’accès aux soins en différence “objective” de risque, puis en inégalité d’accès à des programmes intensifs supplémentaires.
+
+Dans la justice pénale, la définition d’un profil de risque et la manière de pondérer les erreurs entre différents groupes encode une hiérarchie des injustices supportables : mieux vaut enfermer trop de personnes qui ne récidiveront pas, ou libérer trop de personnes qui récidiveront, et pour quels groupes précisément ? La littérature sur COMPAS montre que, quelles que soient les positions prises dans le débat, un choix normatif irréductible doit être fait, mais qu’il est pris en pratique dans l’écriture de la fonction de coût et des métriques, non dans une scène de délibération pénale explicite.
+
+Dans le recrutement, la décision de prendre les pratiques passées comme guide principal encode une conception du mérite qui sanctuarise des hiérarchies sociales et de genre. L’outil d’Amazon a rendu visible ce mécanisme en produisant des effets suffisamment grossiers pour être politiquement indéfendables ; mais le mécanisme – apprentissage à partir d’historiques de décisions biaisées – demeure au cœur de nombreux systèmes d’“analyse de talents”.
+
+Sur les plateformes, enfin, les seuils de détection, la granularité des catégories de contenu, les modèles de risque assignés aux différentes langues et régions encodent une hiérarchie implicite entre la protection contre certains types de discours et la tolérance à d’autres, entre la visibilité accordée à certains groupes et la sur-modération d’autres. Les obligations du DSA ouvrent des voies de visibilité, mais ne constituent pas en elles-mêmes une scène où ces hiérarchies seraient mises en débat avec les publics concernés.
+
+Dans tous ces cas, on ne peut pas dire qu’il n’y ait pas de fondements : au contraire, ils sont nombreux, puissants, efficaces. Ils prennent la forme de fonctions de coût, de choix de proxies, de distributions de données, de métriques de performance, de seuils de décision. Simplement, ces fondements ne sont pas exposés comme tels ; ils n’apparaissent ni dans les chartes, ni dans les communiqués, ni dans les rapports de principe. Ils agissent dans la *cratialité* du système – dans son code, ses pipelines, ses paramétrages –, mais ils n’accèdent jamais au statut de fondements discutables.
+
+C’est en ce sens que nous parlons d’*arcalité fantôme* : non pas une absence d’*arcalité*, mais une *arcalité exilée hors de la scène*. La modernité algorithmique ne se caractérise pas seulement par une intensification de la capacité à calculer, à corréler, à prédire ; elle se caractérise par une dés-scénarisation des fondements, c’est-à-dire par le transfert des décisions normatives les plus décisives dans des couches techniques où elles ne sont plus identifiées comme telles.
+
+Au regard de l’*archicratie*, cela signifie que la promesse d’une “*IA responsable*” ou “*digne de confiance*” reste structurellement bancale tant que l’on ne ramène pas ces choix à la scène, c’est-à-dire tant qu’on ne crée pas de dispositifs archicratifs pour les rendre visibles, contestables, révisables. L’épreuve de détectabilité, dans sa dimension d’*arcalité implicite*, permet précisément de diagnostiquer ce défaut : là où les axiomes les plus lourds sont dissimulés derrière le langage de l’optimisation, l’*archicratie* n’est pas seulement déficitaire ; elle est *empêchée*. C’est sur cette base que pourra être menée, dans les sections ultérieures, l’analyse des *cratialités* de Système F et des *archicrations* – rares, fragmentaires, parfois fantomatiques – qui tentent déjà, dans certains secteurs, de réintroduire de la scène dans un ordre régulé par les modèles.
+
+## I.4. Cratialité du système IA
+
+Si l’*arcalité* répond à la question “*selon quoi ou qui ?*”, la *cratialité* répond à la question “*par quoi et comment ?*”. Dans Système F, ce “*par quoi et comment*” n’est pas un point, mais une chaîne : *collecte et circulation de données*, *construction d’attributs*, *entraînement du modèle*, *réglages successifs*, *mise en production*, *intégration dans des logiciels très ordinaires* et enfin *procédures d’usage*. Ce que l’*archicratie* appelle *cratialité*, c’est précisément cette chaîne, dès lors qu’elle ne se contente plus d’outiller une activité, mais *distribue de manière répétée des accès, des soupçons, des protections, des sanctions*.
+
+Dans un centre de données où tourne le modèle de fondation, dans le service informatique d’un ministère, dans une direction de l’innovation d’un hôpital, cette chaîne est documentée en détail : *diagrammes d’architecture*, *pipelines de données*, *journaux de traitement*. Mais pour l’agent de guichet qui consulte une file de dossiers triés, pour la médecin confrontée à une liste de patients “priorisés”, pour le juge qui reçoit un rapport chiffré, pour le recruteur ou l’équipe de modération qui voit un indicateur rouge, *cette cratialité est entièrement compacte* : un score, une couleur, un message, parfois une mention vague à un “outil d’analyse avancée”. L’épreuve de détectabilité conduit alors à remonter, autant que possible, cette chaîne invisible, en s’appuyant sur ce que les travaux existants documentent déjà.
+
+### I.4.1. Des archives régulatrices recyclées en carburant statistique
+
+La première strate de la *cratialité* de Système F, ce sont les *données*. Non pas des “matières premières” neutres, mais des *archives de décisions passées*.
+
+Ainsi, avec SyRI, la littérature juridique montre que le système a été conçu comme un *instrument de “couplage” massif entre fichiers administratifs* : *données fiscales, registres de sécurité sociale, informations sur l’emploi, le logement ou la dette, issues d’un ensemble d’organismes publics qui, jusque-là, n’étaient pas nécessairement interconnectés*. L’objet n’était pas simplement de consulter l’un ou l’autre fichier, mais de constituer un “*dépôt de risque*” où les trajectoires de vie des habitants de certains quartiers étaient recomposées en *profils susceptibles de déclencher un contrôle*. Les dossiers saisis par les ONG et la décision de La Haye insistent sur ce point : c’est bien cette concentration, ce couplage étendu et asymétrique des données qui a conduit le tribunal à juger que le dispositif ne respectait pas la vie privée.
+
+Dans le scandale des allocations pour la garde d’enfants, l’algorithme incriminé n’a pas été conçu *ex nihilo* : il reposait sur les dossiers fiscaux et sociaux accumulés par l’administration, sur les anciens contrôles, sur les historiques de remboursement, sur des métadonnées apparemment triviales (nationalité, double nationalité, type de crèche). Les enquêtes parlementaires et les analyses doctrinales montrent que la machine à profiler a, de ce fait, hérité d’une longue histoire de suspicion ciblée, pour la concentrer sur des familles à bas revenus, souvent issues de l’immigration.
+
+Dans ce dispositif précis de santé étudié par Obermeyer et ses co-auteurs, la base d’apprentissage est constituée de données de facturation : coûts passés, diagnostics, passages à l’hôpital, prescriptions, etc. L’algorithme ne “voit” pas les patients, il voit les dépenses que le système de santé a consenties pour eux. Quand le dispositif est ensuite utilisé pour sélectionner les patients éligibles à des programmes de soins intensifs, la *cratialité* de Système F prolonge ainsi une économie historique des soins : ceux dont on a peu dépensé pour eux sont moins visibles pour l’algorithme, même s’ils sont plus malades.
+
+Du côté pénal, les études sur COMPAS rappellent que les scores sont calculés à partir d’une combinaison d’éléments du casier judiciaire et des réponses à un questionnaire de 137 items, portant sur la trajectoire de vie, l’environnement social, l’emploi, la scolarité, le logement. Là encore, Système F ne “crée” pas les variables ; il hérite de la manière dont la police a arrêté, dont les tribunaux ont condamné, dont les services sociaux ont consigné des éléments de biographie, dans un contexte où ces histoires sont déjà fortement structurées par la race, la classe, le territoire.
+
+Dans le recrutement, l’outil d’Amazon décortiqué par Reuters a été entraîné sur une décennie de décisions de recrutement dans des métiers techniques, essentiellement occupés par des hommes. Les CV, lettres, diplômes et trajectoires de carrière qui composent cette base reflètent un champ professionnel déjà fortement genré ; c’est cette archive que le modèle prend pour horizon de référence.
+
+Enfin, sur les plateformes, les systèmes de modération et de recommandation ingèrent des flux continus de contenus, mais aussi des archives de signalements, de suppressions, de “likes”, de signalements de discours haineux ou terroristes. Les rapports de transparence imposés par le Digital Services Act et les documents publiés par Meta insistent sur le *rôle des systèmes automatisés dans la détection initiale des contenus, en se nourrissant précisément de cette mémoire d’interventions passées*.
+
+Dans tous ces cas, la *cratialité* de Système F commence donc par un *geste de reprise* : les *bases de données sur lesquelles repose l’entraînement et le fonctionnement du système sont déjà des condensés d’arbitrages régulateurs, de contrôles et de sélections, parfois de longues routines discriminatoires*. La chaîne cratiale ne se contente pas d’“absorber” la réalité sociale ; elle absorbe des archives de pouvoir.
+
+### I.4.2. Pipelines : transformer des vies en vecteurs
+
+La deuxième strate de la *cratialité* est moins visible encore : ce sont les chaînes de transformation qui convertissent ces données hétérogènes en représentations exploitables par le modèle. Les manuels de science des données et les guides sur l’usage de l’IA dans les administrations décrivent des étapes désormais classiques : nettoyage, normalisation, sélection ou construction de variables, agrégation, puis vectorisation.
+
+Dans le cas d’un dispositif de détection de fraude sociale, une succession de décisions apparemment techniques se met en place : faut-il coder la “nationalité” comme une variable binaire, ou comme une liste fine de pays ? Faut-il comptabiliser le nombre de déménagements sur cinq ans, ou sur dix ? Comment transformer des remarques écrites par des agents en indicateurs numériques ? Le rapport de la Commission d’enquête parlementaire néerlandaise sur le scandale des allocations montre que, dans la pratique, ces choix ont conduit à donner un poids particulier à certains marqueurs (double nationalité, erreurs mineures dans les formulaires), qui faisaient passer des familles entières du côté du “risque élevé”.
+
+Pour l’*algorithme de santé* analysé par Obermeyer et al., cette chaîne consiste à *agréger des années de dépenses en santé, de diagnostics et d’hospitalisations en un score unidimensionnel de “risque”, censé représenter les “besoins futurs” du patient*. Le fait d’opter pour les coûts plutôt que pour des indicateurs cliniques, puis de compresser ces informations en un score continu, est un *geste cratial* autant que statistique : il *rend possible l’intégration du système dans les tableaux de bord des gestionnaires*, et *autorise un tri automatique des patients à échelle industrielle*.
+
+Dans COMPAS, transformer 137 réponses et un casier judiciaire en un score de 1 à 10 suppose plusieurs *couches de prétraitement* : *recodage des réponses en catégories numériques*, *pondération de facteurs*, *combinaison en indices partiels*, puis en *score global*. Les études qui ont reconstruit partiellement la méthode à partir de données ouvertes montrent à quel point *cette chaîne incorpore des éléments contextuels* (code postal, stabilité résidentielle, entourage, historique de consommation de drogues) qui, une fois vectorisés, deviennent des *attributs apparemment neutres, mais fortement corrélés à des trajectoires socio-raciales différenciées*.
+
+L’*outil de tri de CV* d’Amazon, pour sa part, devait convertir des documents richement formatés en vecteurs de caractéristiques : *universités*, *mots-clés*, *expériences*, *engagements*, parfois même *tournures de phrases*. C’est dans cette phase que le système a “*appris*” à pénaliser des expressions comme “*women’s chess club*” ou des références à des universités connotées féminines, parce que ces traits coïncidaient, dans les données d’entraînement, avec des candidatures historiquement moins retenues.
+
+Enfin, les *pipelines de modération* et de *recommandation* transforment chaque message, image ou vidéo en une série de marqueurs : *langue, thème, tonalité, degré présumé de violence ou de haine, signaux de “fiabilité” de la source, etc.* Les documents de Meta et les analyses indépendantes montrent que ces *pipelines* combinent *détection automatisée*, *listes de mots*, *signaux issus de comportements passés*, avant de produire des étiquettes (“contenu à risque”, “contenu limite”) qui orientent la visibilité des publications bien en amont de toute décision humaine.
+
+Ce que la lecture archicratique met ici en avant, ce n’est pas seulement la technicité de ces *pipelines*, mais leur *effet de réduction* : *des vies, des trajectoires, des plaintes, des prises de parole sont ramenées à des vecteurs, des classes, des scores*. Cette réduction est nécessaire pour que Système F fonctionne ; elle n’est pas en soi illégitime. Mais elle constitue l’un des lieux où la *cratialité* fait passer un seuil : *ce qui devient calculable devient gouvernable*.
+
+### I.4.3. Modèles, paramètres, seuils : la mécanique fine des décisions
+
+La troisième strate de la *cratialité* de Système F est celle des *modèles* et de leurs *réglages*. Les manuels de *machine learning* parlent *d’architectures, de fonctions de perte, d’optimisation, d’hyperparamètres*. Pour l’*archicratie*, ces notions deviennent intéressantes lorsqu’elles cristallisent des *choix régulateurs*.
+
+Ainsi, *santé* étudié par Obermeyer et al., le modèle est paramétré pour *minimiser l’erreur globale de prédiction des coûts futurs*. Ce choix – minimiser une somme d’erreurs plutôt que de garantir un niveau de traitement minimal pour certains groupes – a pour effet d’optimiser la performance moyenne au prix d’une sous-protection systématique des patients noirs. Les auteurs montrent qu’en modifiant la fonction de coût pour intégrer explicitement des mesures de morbidité, le classement des patients noirs change radicalement.
+
+Dans COMPAS, les paramètres du modèle et la manière dont les scores sont répartis en catégories (“faible”, “moyen”, “élevé”) déterminent la proportion de personnes qui basculent dans chaque classe de risque. Les études empiriques indiquent que, pour un même score, la probabilité de récidive est similaire entre accusés noirs et blancs, mais que la distribution des erreurs (faux positifs, faux négatifs) diffère fortement selon les groupes. L’architecture et les réglages du modèle correspondent donc à un compromis implicite : il est jugé acceptable de produire davantage de faux positifs pour certains groupes, afin de maintenir une calibration globale satisfaisante.
+
+Les *systèmes de scoring* de fraude sociale fonctionnent de la même manière : la décision de fixer un seuil de déclenchement de contrôle à tel niveau plutôt qu’à tel autre se traduit immédiatement en nombre de dossiers réexaminés, en proportion de familles frappées par des procédures, en intensité de la surveillance sur certains quartiers. Les travaux juridiques sur SyRI insistent sur le fait que ce seuil, et les indicateurs qui y conduisent, n’étaient pas seulement inconnus du public, mais inaccessibles même aux personnes contrôlées.
+
+Dans le cas d’Amazon, l’architecture exacte du modèle n’a pas été publiée, mais les sources indiquent qu’il s’agissait d’un système d’apprentissage supervisé qui attribuait une note d’une à cinq étoiles aux CV, en imitant les décisions de recrutement passées. La simple existence d’une échelle discrète de 1 à 5, avec un tri automatique des dossiers en fonction de cette note, traduit un choix cratial : il n’y a plus de lecture directe de chaque CV, mais un filtrage basé sur un signal synthétique, qui décide de ce qui est vu ou non par les recruteurs.
+
+Dans tous ces cas, les modèles, les paramètres et les seuils ne sont pas seulement des composantes techniques ; ils sont les points précis où la chaîne cratiale se décide : *combien de personnes seront contrôlées, qui sera inclus dans un programme de soins, qui portera le stigmate d’un “haut risque”, qui sera vu par un recruteur ou par le public d’une plateforme*. La *cratialité* de Système F, c’est cette capacité à faire varier, par ajustement de quelques coefficients, la forme concrète de l’accès aux droits, aux ressources, à la visibilité.
+
+### I.4.4. Interfaces : là où la *cratialité IA* rencontre la *cratialité humaine*
+
+Pour les agents, juges, médecins, recruteurs, modérateurs, la *cratialité* n’apparaît cependant qu’à l’autre bout de la chaîne : dans les *interfaces*. C’est là que Système F devient visible – sous la forme d’une colonne de scores, d’un code couleur, d’un message d’alerte, d’une suggestion “recommandée par le système”.
+
+Les études sur les systèmes d’aide à la décision clinique montrent que la manière dont une recommandation est affichée (alerte intrusive, message discret, couleur, possibilité de justification) influence fortement la propension des praticiens à la suivre ou à la contourner. Les travaux sur les biais d’automation confirment que, lorsque l’interface présente une proposition algorithmique avec un fort statut d’autorité (icône de validation, texte en vert, mention “recommandé”), les opérateurs ont tendance à lui accorder plus de crédit qu’à leur propre jugement, surtout dans des contextes de charge de travail élevée.
+
+Transposé à Système F, cela signifie qu’un agent de caisse sociale, confronté à une liste de dossiers triés par un score rouge–orange–vert, sera incité à traiter en priorité les dossiers rouges, même si rien ne l’oblige formellement à suivre l’ordre proposé. Une médecin, devant une liste de patients ordonnés par un indice de “priorité” accompagné d’un avertissement lorsqu’elle s’en écarte, devra assumer de “désobéir” au système pour reclasser un patient. Un juge, lisant un rapport de risque pénal avec un score mis en avant et une série de formulations standardisées, sait que toute divergence devra être explicitée dans son jugement.
+
+Les interfaces de plateformes, elles, ne montrent souvent rien du tout : l’utilisateur voit que sa publication “marche moins bien”, ou bien reçoit un message standardisé lui indiquant que son contenu a “enfreint les standards”, sans que la contribution exact de Système F soit explicitée. Les rapports de transparence exigés par le DSA commencent à donner des indicateurs agrégés sur la proportion de décisions automatisées, mais ils ne modifient pas cette expérience élémentaire : pour l’usager, la *cratialité* se résume à un refus, une baisse de portée, un retrait.
+
+Du point de vue archicratique, ces interfaces sont des lieux décisifs : elles articulent la *cratialité IA* et la *cratialité humaine.* Selon la manière dont elles sont conçues – plus ou moins explicites, plus ou moins contraignantes, plus ou moins configurables – elles peuvent soit renforcer l’autorité de Système F au point d’en faire un quasi-oracle, soit ménager des marges de requalification, de contestation, de suspension. La matérialité du bouton, de la couleur, de l’alerte est ici pleinement politique.
+
+### I.4.5. Procédures d’intégration : scripts d’usage et effets disciplinaires
+
+Enfin, la *cratialité* de Système F se fixe dans les règles internes qui déterminent sa place dans les procédures de décision. Les études de cas sur l’IA dans les administrations et le droit de l’UE sur les décisions automatisées insistent sur ce point : la différence entre un système de “recommandation” et un système de “décision automatisée” tient souvent moins à la technique qu’aux scripts organisationnels qui encadrent son usage.
+
+Dans un service de protection sociale, il peut être écrit que “les dossiers marqués à haut risque doivent être examinés en priorité” ; dans un tribunal, que “le score de risque ne peut être le seul fondement d’une décision, mais que toute divergence substantielle doit être motivée”. Dans un hôpital, qu’“un patient proposé par l’algorithme pour un programme de soins intensifs ne peut être exclu qu’après justification”; dans un service de recrutement, que “seuls les CV classés au-dessus d’un certain seuil seront examinés humainement”.
+
+Chacune de ces règles transforme un score en quasi-obligation : l’agent, la médecin, le juge, le recruteur ne se contentent plus de consulter Système F ; ils doivent se positionner par rapport à lui, éventuellement s’en justifier. C’est là que se loge, souvent, l’“*humain dans la boucle*” invoqué par les chartes d’IA responsable : un humain reste dans la boucle, mais placé en position d’avoir à expliquer pourquoi il ne suit pas la recommandation, plutôt que de décider de manière primaire.
+
+Les travaux sur SyRI et sur le scandale des allocations montrent en outre que ces scripts ne sont pas toujours explicités, ni même stabilisés : certains agents témoignent d’une pression implicite à suivre les signaux produits par le système, sous peine d’être jugés “laxistes” ou “inefficaces”. Dans le cas de COMPAS, la décision Loomis autorise l’usage de l’outil comme aide à la décision, mais sans offrir de critères clairs sur la manière dont les juges devraient articuler le score avec leur appréciation propre : la *cratialité* *se faufile ainsi entre prescription et simple “support”, en laissant la responsabilité dernière porter par les individus*.
+
+Du point de vue de l’*archicratie*, cette couche procédurale est cruciale parce qu’elle fixe, en pratique, ce que “vaut” Système F : s’il doit être suivi par défaut, s’il peut être contredit, s’il déclenche automatiquement des contrôles ou des sanctions, s’il ouvre ou non un droit à un examen contradictoire. Dans de nombreuses configurations actuelles, cette valeur est déterminée par des circulaires internes, des guides utilisateurs, des formations *ad hoc*, rarement débattus sur une scène publique.
+
+### I.4.6. Une *cratialité hypertopique*
+
+*Reprise des archives régulatrices, pipelines de transformation, modèles et paramètres, interfaces, scripts d’usage* : si l’on assemble ces strates, la *cratialité* de Système F apparaît comme une *chaîne dense, continue, extraordinairement efficace*. Elle fait circuler des signaux depuis les bases de données jusqu’aux décisions prises au guichet, au tribunal, à l’hôpital, dans l’entreprise, sur la plateforme. Elle est fortement topologisée – située dans des centres de données, des services informatiques, des consoles administratives –, mais elle ne dispose pas, dans la plupart des cas, de lieux où elle se montre comme telle.
+
+Pour les personnes affectées – bénéficiaires, patients, justiciables, candidat·es, usagers – la *cratialité* de Système F se présente avant tout comme une force “*hypertopique*” : un *vecteur d’effets sans visibilité de sa propre structure*. On peut ressentir ses conséquences (un contrôle inattendu, une radiation, un refus de prestation, une incarcération prolongée, une non-sélection, un contenu invisibilisé), sans jamais pouvoir désigner précisément le “*par quoi et comment*” qui a conduit à la situation.
+
+L’*enjeu de l’épreuve de détectabilité*, appliquée à la *cratialité*, est dès lors double. D’une part, *rendre descriptible cette chaîne, en montrant qu’elle n’est ni magique ni diffuse, mais composée de décisions localisées, techniquement et institutionnellement situées*. D’autre part, *ouvrir la possibilité d’un déplacement : faire exister des scènes où cette cratialité peut être exposée, discutée, reconfigurée, et ne plus opérer de manière invisible*.
+
+C’est à cette condition seulement que la puissance calculatoire de Système F peut être insérée dans un ordre archicratique — c’est-à-dire dans un ordre où la manière dont le pouvoir prend forme dans les dispositifs reste, elle aussi, amenée à l’épreuve.
+
+## I.5. Archicration existante mais lacunaire
+
+Après l’*arcalité déclarée et implicite*, après la *cratialité* de Système F, reste à interroger ce qui tient lieu, aujourd’hui, d’*archicration* : des *scènes d’épreuve où l’on pourrait amener la régulation algorithmique en visibilité, la contester, la transformer*. Dans la grammaire de la thèse, une archicration n’est pas un simple “dispositif de contrôle” : c’est un *lieu institué où les fondements (arcalité) et les instruments (cratialité) peuvent être mis en discussion par des acteurs concernés, dans des formes réglées, avec des effets possibles sur l’architecture du système*.
+
+À première vue, l’écosystème de Système F semble en être riche : *comités d’éthique de l’IA*, *conseils de gouvernance des données*, *audits de biais*, *autorités de protection des données*, *agences sectorielles*, *juges*, *mécanismes de recours*, désormais complétés par les *obligations de transparence et de plainte du Digital Services Act*, par des lois sectorielles comme le *Local Law 144* de New York sur les outils automatisés de recrutement, ou par des dispositifs singuliers comme le *Meta Oversight Board*.
+
+Mais, dès qu’on reformule les questions dans les termes archicratiques — *qui peut voir quoi ? qui peut contester quoi ? avec quels effets sur le système lui-même ?* — le paysage se transforme. Beaucoup de ces dispositifs produisent des avis, des rapports, des sanctions ponctuelles, des formulaires de recours ; très peu organisent une véritable comparution de Système F devant ceux qu’il affecte.
+
+### I.5.1. Cartographie rapide des prétendants à la scène
+
+On peut, pour commencer, distinguer quatre grandes familles de dispositifs qui, chacune à leur manière, prétendent jouer un rôle d’instance d’épreuve pour l’IA :
+
+1.  *Comités, chartes, conseils d’experts*
+
+    Comités internes d’éthique de l’IA dans les grandes entreprises technologiques, commissions *ad hoc* dans les administrations, groupes d’experts de haut niveau comme celui qui a élaboré les Lignes directrices pour une IA digne de confiance au niveau européen. Ils produisent des principes, des recommandations, des “bonnes pratiques”.
+
+2.  *Audits et évaluations techniques*
+
+    Audits de biais sur les outils de recrutement imposés par le Local Law 144 à New York (obligation de réaliser un audit annuel, de publier un résumé, d’informer les candidats).
+
+    Évaluations d’impact sur les droits fondamentaux ou sur les risques, demandées par certains régulateurs et expérimentées dans le cadre de l’AI Act européen et de rapports comme *Algorithmic Rule* ou le *Handbook: AI and Public Administration*.
+
+3.  *Autorités de régulation et juridictions*
+
+    Autorités de protection des données, conseils pour l’égalité et organismes antidiscrimination, autorités sectorielles, institutions européennes (Commission, FRA, etc.) qui ont enquêté sur les systèmes de profilage dans le social, la police ou la fiscalité.
+
+    Cours nationales et européennes, comme le tribunal de La Haye dans SyRI, ou la chaîne de procédures qui a suivi le scandale des allocations familiales aux Pays-Bas.
+
+4.  *Voies de recours et mécanismes de réclamation*
+
+    Droit au recours des allocataires, des justiciables, des patients, des candidats à l’emploi, des utilisateurs de plateformes.
+
+    Mécanismes internes de plainte et de contestation imposés par le Digital Services Act (obligation pour les grandes plateformes de prévoir des procédures de traitement des signalements et des recours, de publier des rapports annuels sur la modération, en précisant notamment la part de décisions automatisées et les taux d’erreurs).
+
+    Dispositifs spécifiques comme le *Meta Oversight Board*, qui réexamine un nombre limité de décisions de modération emblématiques et publie des décisions motivées et des recommandations.
+
+Dans ce maillage, les éléments d’une *archicration authentique* sont présents : *lieux de délibération, expertises, procédures contradictoires, sanctions possibles*. Mais leur articulation et leur accessibilité restent profondément inégales. Surtout, la plupart de ces dispositifs s’adressent avant tout aux organisations et aux concepteurs, beaucoup moins aux personnes directement affectées par Système F.
+
+### I.5.2. Comités et chartes : scènes sans publics
+
+Les comités d’éthique de l’IA et les groupes d’experts ont joué un rôle central dans la formulation des grands principes qui structurent l’*arcalité déclarée des systèmes* — équité, transparence, robustesse, responsabilité, etc. Les AI Principles de Google et Microsoft, les Lignes directrices européennes pour une IA digne de confiance, ou encore les rapports nationaux sur “l’IA et les libertés” en sont des exemples typiques.
+
+Ces instances ont bien une dimension quasi archicratique : elles mettent en scène, dans un cercle de spécialistes, des questions de fond (“qu’est-ce qu’une IA digne de confiance ?”, “quels sont les risques majeurs pour les droits fondamentaux ?”). Elles produisent des textes publics, organisent des consultations, parfois invitent la société civile à réagir. Mais, du point de vue de Système F, elles restent à un niveau très général :
+
+- elles ne se prononcent que rarement sur un système concret inséré dans des chaînes cratiales spécifiques (fraude sociale, tri de CV, gestion des risques de santé, etc.) ;
+
+- elles ne réunissent qu’à la marge les personnes directement affectées par ces dispositifs (allocataires, patients, justiciables, candidats, usagers) ;
+
+- elles n’ont pas, sauf exception, de pouvoir d’injonction ou de suspension sur les systèmes en question.
+
+Autrement dit, ces comités produisent des scènes de discours normatif situées très en amont, mais ils n’organisent pas l’épreuve d’un Système F déterminé. Ils contribuent à la fondation discursive de l’“IA responsable”, sans pour autant mettre en visibilité la *cratialité effective* des dispositifs déjà déployés.
+
+### I.5.3. Audits de biais et évaluations d’impact : scènes confinées, biaisées par les conflits d’intérêts
+
+Une deuxième famille de dispositifs, plus proche des chaînes réelles de Système F, est celle des *audits de biais* et des *évaluations d’impact algorithmiques*. Dans de nombreux pays, cette famille est en plein essor : New York, avec le *Local Law 144*, impose des audits de biais pour les outils automatisés de recrutement ; le Canada a généralisé l’“*Algorithmic Impact Assessment*” pour les systèmes de décision automatisée dans l’administration ; des guides de bonnes pratiques, produits par des organisations internationales, des agences publiques et des *think tanks*, enjoignent désormais administrations et entreprises à “évaluer” leurs systèmes de profilage avant ou pendant leur déploiement.
+
+Dans l’esprit, on pourrait croire tenir enfin une *archicration* structurée : un tiers examine un système, mesure ses effets, formule des recommandations, éventuellement sous le regard de l’autorité ou du public. Un rapport est produit, parfois publié ; des chiffres sont discutés ; des engagements d’amélioration sont pris. Mais dès qu’on regarde de près *qui audite, sur quoi, avec quelles marges de manœuvre*, apparaissent des tensions lourdes, qui tiennent moins de la sophistication statistique que de la *configuration des intérêts en présence*.
+
+Premièrement, la plupart des régimes d’audit existants reposent sur un modèle classique de *relation client–prestataire*. C’est l’organisation qui déploie Système F – employeur, administration, plateforme – qui commande, finance et choisit son auditeur. Le *Local Law 144* de New York illustre bien cette logique : les employeurs doivent faire réaliser un audit annuel par un tiers “indépendant” de leurs outils de décision automatisée en matière d’emploi, et publier un résumé des résultats. Sur le papier, l’exigence d’indépendance est posée ; dans la pratique, rien n’empêche la constitution d’un marché de cabinets spécialisés dont la survie dépend de la capacité à produire des audits compatibles avec les attentes de leurs clients. Les premières analyses de ce régime soulignent un nombre limité d’audits effectivement réalisés, une tentation d’interpréter les exigences de manière minimaliste, et un *risque de* “*vice de conformité*” : *l’audit devient un examen du respect formel des prescriptions, non une épreuve substantielle du dispositif et de ses usages*.
+
+Deuxièmement, la montée en puissance d’une véritable “industrie de l’audit de l’IA” introduit un *conflit d’intérêts structurel*. De *grandes firmes de conseil* – parfois les mêmes qui développent, vendent ou intègrent des solutions d’IA – *se positionnent comme auditeurs des systèmes qu’elles contribuent par ailleurs à diffuser*. Des organismes de normalisation, comme le British Standards Institution, ont explicitement mis en garde contre cette situation : un nombre significatif d’acteurs qui commercialisent des audits d’IA sont aussi producteurs de technologies, ce qui alimente des doutes sur leur indépendance et sur la rigueur des évaluations ; des initiatives de standardisation cherchent désormais à encadrer ces pratiques. Dans le même sens, les appels à des audits “holistiques” – qui évalueraient non seulement les performances techniques, mais aussi les présupposés normatifs, les effets sociaux et les mécanismes de gouvernance – insistent sur la *nécessité d’auditeurs* “*libres de tout conflit d’intérêts*”, *sans quoi la procédure se réduit à une validation de façade*.
+
+Troisièmement, les *évaluations d’impact algorithmiques* mises en place dans le secteur public prolongent souvent, sous une forme plus sophistiquée, la *logique de l’auto-évaluation*. Lorsqu’un ministère ou une agence réalise lui-même “son” évaluation d’impact avant de déployer un système de profilage ou de tri, il se trouve en position de juger la pertinence d’un dispositif qu’il a conçu, financé, promu et qu’il espère présenter comme vecteur de modernisation. Les travaux pionniers sur les *Algorithmic Impact Assessments* insistent, à l’inverse, sur la nécessité de dispositifs véritablement contradictoires : participation forte des publics concernés, consultations publiques substantielles, possibilité pour des acteurs externes (ONG, chercheurs, journalistes) de demander des compléments ou de contester des évaluations jugées insuffisantes. Certaines analyses des cadres européens vont dans le même sens, en plaidant pour des droits d’accès aux données, aux modèles et aux documents de conception, faute de quoi aucun écosystème d’audit réellement indépendant ne peut émerger.
+
+Si l’on recompose ces éléments dans notre langue archicratique, on voit se dessiner une *typologie de conflits d’intérêts qui affectent directement la scène d’épreuve*. Les conflits sont *financiers*, lorsque l’auditeur dépend économiquement, de manière répétée, du client qu’il est censé contrôler ; *organisationnels*, lorsque l’audit est confié à des structures internes, à des filiales ou à des partenaires stratégiques qui partagent les mêmes objectifs de déploiement ; *cognitifs*, enfin, lorsque audités et auditeurs appartiennent au même petit milieu technico-juridique, avec des catégories de pensée, des indicateurs et des horizons de pertinence largement communs. Dans ces trois cas, *l’instance censée jouer le rôle de tiers contradicteur se trouve, à divers degrés, alignée avec les intérêts et les cadrages de ceux qui conçoivent et exploitent Système F*.
+
+Le cadrage même des audits accentue cette dérive. Les textes juridiques et les guides méthodologiques encouragent parfois une vision très étroite de l’objet audité. Le *Local Law 144*, par exemple, impose de mesurer des écarts de taux de sélection selon le genre et la “race/ethnicité” dans les outils de recrutement, mais ne couvre pas d’autres dimensions pourtant protégées par le droit (âge, handicap) ou manifestement pertinentes (origine sociale, statut migratoire, langue). Dans ce contexte, l’organisation a tout intérêt à limiter l’exercice à ce qui est strictement requis, à traiter l’audit comme une *check-list* de ratios, et à laisser hors champ les questions plus profondes de fonction de coût, de proxy ou de composition des jeux de données – c’est-à-dire précisément l’*arcalité implicite* que notre cas cherche à mettre au jour.
+
+Au terme de cette séquence, les *audits de biais* et *évaluations d’impact* apparaissent comme des *archicrations tronquées*. Il y a bien, formellement, une scène : un rapport est rédigé, parfois rendu public ; des chiffres sont produits ; des recommandations sont formulées. Mais les personnes directement affectées par Système F – allocataires, justiciables, patients, candidat·es, utilisateurs de plateformes – en sont largement absentes, ou réduites au statut de “parties prenantes” abstraites ; les choix les plus déterminants (fonctions de coût, proxies, seuils, composition des jeux de données) restent souvent hors du périmètre audité, au profit d’indicateurs aisément mesurables ; les *conflits d’intérêts structurels*, enfin, minent la capacité de l’auditeur à assumer le rôle de *tiers contradicteur* que l’*archicration* exigerait.
+
+Dans notre grammaire archicratique, ces dispositifs constituent donc des épreuves techniques sans scène véritable : l’algorithme est certes testé, mais la collectivité ne dispose pas d’un lieu institué où confronter les résultats, interroger les axiomes, contester les compromis retenus, exiger des transformations. L’audit remplit principalement une fonction de légitimation – “le système a été évalué” – plus qu’une fonction de mise en débat. Autrement dit : la *cratialité* de Système F est brièvement éclairée par quelques faisceaux d’expertise, mais l’*arcalité implicite* reste soustraite à la comparution, et la scène demeure largement capturée par ceux qui ont intérêt à maintenir le dispositif intact.
+
+### I.5.4. Autorités et tribunaux : scènes fortes, mais rares et *ex post*
+
+Les autorités de régulation et les juridictions offrent, à première vue, les formes les plus accomplies d’*archicration* : procédures contradictoires, auditions, décisions motivées, sanctions, parfois réparation.
+
+L’arrêt SyRI du tribunal de La Haye est emblématique : le dispositif de profilage de fraude aux prestations y est décrit, mis en rapport avec l’article 8 de la CEDH, et finalement jugé disproportionné, en raison notamment du manque de transparence, du ciblage de quartiers défavorisés et de la difficulté pour les personnes profilées de contester le système.  
+Dans le scandale des allocations pour la garde d’enfants, les enquêtes de l’Autorité de protection des données (AP), les rapports parlementaires et, finalement, la crise politique qui a conduit à la démission du gouvernement Rutte illustrent ce que peut être une scène d’épreuve à grande échelle : les pratiques de profilage, les critères utilisés (dont la double nationalité), les effets sur des milliers de familles sont mis au jour, décrits, condamnés, et donnent lieu à un vaste plan de compensation.
+
+Au niveau européen, le DSA commence à être appliqué comme base juridique pour sanctionner des plateformes qui manquent à leurs obligations de transparence, comme dans le cas récent de l’amende infligée à X (anciennement Twitter) pour violation de ses devoirs de transparence et de lutte contre les “*dark patterns*”.
+
+Ces scènes ont un effet archicratique réel : elles forcent les systèmes à comparaître, révèlent des pratiques jusque-là invisibles, imposent des réformes. Mais elles ont aussi des limites structurelles :
+
+- Elles interviennent tard, après des années d’usage, lorsque les dommages sont déjà massifs, comme dans le *toeslagenaffaire* (surendettement, perte de logement, placement d’enfants).
+
+- Elles restent focalisées sur certains aspects juridiques (vie privée, discrimination, transparence) sans pouvoir, à elles seules, reconfigurer l’ensemble de la chaîne cratiale de Système F.
+
+- Elles donnent une place indirecte aux personnes affectées (plaignants, associations, ONG), mais ces dernières n’ont ni la maîtrise de l’agenda, ni la garantie que la logique même du modèle sera transformée.
+
+On pourrait dire, en termes archicratiques, que ces procédures sont des *scènes de rattrapage* : elles produisent des effets puissants, mais elles ne transforment pas encore la régulation algorithmique en régime ordinaire de comparution. Système F n’y vient qu’en cas de crise, non comme un acteur continuellement justiciable.
+
+### I.5.5. Recours individuels et plaintes : scènes fermées, réponses standardisées
+
+Reste la question des recours : que peut faire, dans l’état actuel des choses, un individu ciblé par Système F ?
+
+Dans les politiques sociales, un allocataire qui voit sa prestation suspendue ou refusée peut en principe exercer un recours administratif ou contentieux. Pourtant, comme l’ont montré les enquêtes sur le scandale néerlandais, ces voies ont été largement inopérantes face à des décisions massives et standardisées, fondées sur des profils de risque opaques. Des parents ont multiplié les recours individuels sans succès, jusqu’à ce que des journalistes, des parlementaires et des autorités de contrôle parviennent à ouvrir le scandale au niveau systémique.  
+Le recours reste structuré comme si la décision avait été prise par un agent individuel, dans un dossier singulier ; il n’offre aucune prise pour contester la logique même du système de profilage.
+
+Dans le recrutement, des candidats peuvent saisir les autorités anti-discrimination ou engager des actions en justice, comme dans les affaires récentes où des candidats ont attaqué des fournisseurs d’outils de tri automatisé pour discrimination raciale ou fondée sur le handicap.
+
+Mais même les dispositifs les plus avancés, comme le *Local Law 144*, se concentrent sur le respect d’obligations de procédure (audit, transparence minimale), non sur l’ouverture d’une scène où les candidats pourraient discuter des critères incorporés dans l’outil. Une fois que l’employeur peut montrer qu’un audit a été réalisé et qu’un résumé est en ligne, la possibilité de contester la structure même de l’outil reste très limitée.
+
+Pour les plateformes, le DSA impose l’existence de *mécanismes internes de réclamation* et, pour les très grandes plateformes, la *mise en place de systèmes de traitement des notifications de contenus illégaux et de plaintes contre les décisions de modération*, ainsi que des *mécanismes de règlement extrajudiciaire des litiges*.
+
+En pratique, ces dispositifs prennent la forme de formulaires en ligne, de délais de réponse, de messages standardisés. Ils permettent parfois de corriger des erreurs manifestes (restauration d’un contenu, réouverture d’un compte), mais ils n’ouvrent presque jamais une discussion sur les critères de modération eux-mêmes. L’utilisateur reste face à une interface laconique ; le rôle de Système F dans la décision (score de toxicité, détection de désinformation, etc.) est rarement explicité.
+
+Le *Meta Oversight Board* constitue une exception partielle : il *publie des décisions motivées*, *analyse la conformité des politiques de Meta aux droits humains*, *formule des recommandations publiques*, parfois très critiques, sur certains *aspects de la modération* et de la *hiérarchisation des contenus*.
+
+Mais il ne traite qu’un nombre infime de cas, sélectionnés parce qu’ils soulèvent des questions emblématiques ; il n’a pas de pouvoir direct sur la conception des systèmes de recommandation ou sur l’ensemble des algorithmes qui régulent la visibilité. Sa scène est réelle, mais fortement débitée : quelques affaires par an, dans un océan de décisions automatisées quotidiennes.
+
+Dans la santé, enfin, les patients disposent de droits d’accès à leur dossier et, dans certains pays, peuvent saisir des médiateurs ou des commissions d’éthique clinique. Les travaux sur l’algorithme d’Obermeyer et al. montrent que la prise de conscience de ses effets discriminatoires est venue de chercheurs en épidémiologie et en médecine, non de recours individuels de patients.  
+Là encore, la scène d’épreuve reste centrée sur la relation médecin–patient ; Système F y apparaît, au mieux, comme un outil contextuel, rarement comme objet principal de la contestation.
+
+On voit se dessiner un trait commun : les mécanismes de recours existants permettent de contester les effets (une suspension de prestation, une peine, un refus d’embauche, un retrait de contenu), beaucoup plus difficilement le dispositif qui les produit. Ils ouvrent surtout des scènes de réclamation, non des scènes d’*archicration*.
+
+### I.5.6. *Archicrations fantômes* et *oblitération de la scène*
+
+Si l’on rassemble ces éléments, le diagnostic archicratique sur l’“*archicration existante*” de Système F devient plus précis.
+
+- Oui, il existe des *instances qui ressemblent à des scènes* : *comités d’experts, audits, autorités de régulation, tribunaux, mécanismes de plainte, organes comme l’Oversight Board*.
+
+- Oui, certaines de ces *instances produisent des effets tangibles* : *arrêt de SyRI, révélation et compensation dans le scandale des allocations, sanctions financières sous le DSA, ajustements ou abandons de certains outils* (comme le système de recrutement d’Amazon).
+
+- Mais, pour l’essentiel, ces *instances restent partielles, sectorisées, tardives et pauvres en participation directe des personnes affectées*.
+
+Du point de vue de l’*archicratie*, cela signifie que :
+
+- L’*arcalité* de Système F existe, mais elle demeure largement *fantomatique* : les fondements implicites (proxies, fonctions de coût, hiérarchies des erreurs) ne sont presque jamais mis en scène comme tels. Les grands principes d’“IA digne de confiance” ou de “lutte contre la fraude” sont proclamés, mais leurs traductions opératoires ne sont pas exposées devant ceux qu’elles engagent.
+
+- La *cratialité* est puissante, finement articulée, mais *hypertopique* : elle concentre ses opérations dans des architectures techniques et organisationnelles peu visibles, qui produisent des effets massifs sans qu’il soit possible, pour un individu, de remonter aisément la chaîne du “*par quoi et comment*”.
+
+- L’*archicration*, enfin, est *lacunaire* : elle se manifeste soit sous forme de procédures internes, d’audits, de comités qui ne sont pas de vraies scènes publiques ; soit sous forme de grandes affaires contentieuses ou de scandales médiatiques, qui jouent le rôle de scènes d’exception plutôt que d’instances ordinaires de mise à l’épreuve.
+
+On peut, avec la thèse, parler ici d’*archicrations fantômes* : des dispositifs qui empruntent l’allure des scènes (commissions, formulaires, recours), mais qui ne disposent ni de la consistance, ni de l’ouverture, ni de la réflexivité nécessaires pour faire effectivement comparaître Système F. Ils maintiennent l’impression d’une possibilité de recours, sans organiser véritablement la confrontation des fondements, des instruments et des effets.
+
+La première conclusion de l’épreuve de détectabilité est ainsi nette : dans l’état actuel des usages de Système F, la régulation algorithmique est, pour une large part, hors scène. Les scènes qui existent sont soit trop en amont (principes généraux), soit trop en aval (scandales, contentieux), soit trop étroites (audits techniques fermés, formulaires de plainte standardisés). La suite du cas d’étude consistera à replacer cette *oblitération archicratique* dans la longue histoire des régimes régulateurs, puis à examiner ce que pourrait signifier, pour un système d’IA de ce type, une véritable réouverture de la scène : non plus des reculs ponctuels, mais une politique explicite des épreuves, où Système F serait tenu de rendre des comptes, non seulement sur ses performances, mais sur les fondements et les formes de pouvoir qu’il met en œuvre.
+
+##

src/content/cas-ia/chapitre-2.mdx

@@ -0,0 +1,273 @@
+---
+title: "Chapitre II — Épreuve topologique"
+edition: "cas-ia"
+status: "application"
+level: 1
+version: "0.1.0"
+concepts: []
+links: []
+order: 130
+summary: ""
+source:
+  kind: docx
+  path: "sources/docx/cas-ia/Cas_Pratique-Archicratie_et_gouvernance_des_systemes_IA-Chapitre_2_Epreuve_Topologique.docx"
+---
+# II. Épreuve topologique : hypotopies, hypertopies, atopies des scènes IA
+
+L’épreuve de détectabilité nous a permis de reconstituer, pour Système F, la distribution des trois prises archicratiques : *arcalités déclarées et implicites, cratialités en chaîne, archicrations rares et fragmentaires*. L’épreuve topologique déplace maintenant la focale : il ne s’agit plus seulement de savoir où se trouvent *arcalité, cratialité* et *archicration*, mais dans quels types de scènes elles se laissent – ou non – approcher. Elle interroge la configuration concrète des lieux où la régulation algorithmique apparaît, se dit, se discute, se justifie, se conteste. Autrement dit : non seulement *quoi* et *comment*, mais *où* et *avec qui*.
+
+Dans la thèse, la topologie archicratique désigne cette manière de lire un ordre régulateur à partir de la forme de ses scènes : *synchrotopies*, quand l’*archicration tient ensemble, de façon relativement stable, des prises arcalitaires et cratiales en présence de publics divers* ; *hypotopies*, quand la *scène existe, mais sous une forme tellement appauvrie qu’elle n’offre presque aucune prise réelle* ; *hypertopies*, lorsque la *scène est concentrée dans quelques lieux fermés où se décident l’essentiel des orientations, loin des personnes affectées* ; *atopies*, enfin, lorsque des *dispositifs jouent théâtralement la scène* (consultations, boîtes à idées, *feedbacks* symboliques), *sans connexion effective avec les lieux de décision*. La topologie n’est donc pas un simple “plan” des espaces physiques ou numériques : c’est une cartographie des situations scéniques où le pouvoir régulateur accepte – ou refuse – de se rendre visible.
+
+Or l’écosystème de Système F est typiquement un espace topologiquement différencié. D’un côté, des *scènes locales d’usage* : guichets transformés en interfaces, portails en ligne, tableaux de bord, applications mobiles, formulaires de recours, boutons “signaler” ou “noter”. *Ces scènes sont souvent les seuls lieux où les personnes affectées par Système F peuvent ressentir quelque chose de sa présence* : un score, un code couleur, un refus, une chute de visibilité, un message standardisé. Du point de vue archicratique, elles ressemblent à des *hypotopies* : ce sont bien des scènes – il y a une interface, parfois un droit de réclamation, un espace minimal d’adresse –, mais elles sont *pauvres en prises, déconnectées des lieux où se décident l’architecture du système, les choix de proxies, les fonctions de coût, les seuils*. Par endroits, elles basculent même dans l’*atopie* : *faux dialogues, consultations sans effet, boîtes à idées numériques dont les contributions ne remontent jamais vers les lieux de conception*.
+
+À l’autre extrémité, Système F se cristallise dans des *scènes institutionnelles* où se jouent les décisions structurantes : *comités de pilotage, boards techniques, réunions de design, arbitrages budgétaires, cellules “d’innovation” au sein des ministères ou des grandes entreprises, cabinets de conseil et de prestataires*. Ce sont des scènes très denses en prises cratiales : on y discute des architectures, des choix de déploiement, des objectifs d’optimisation, des métriques de performance, de la conformité juridique, parfois même des enjeux d’acceptabilité sociale. Mais ces *scènes* sont *fermées* : la plupart du temps, n’y participent que des *experts techniques, des responsables hiérarchiques, des juristes et quelques représentants institutionnels*. Les personnes directement affectées par Système F – allocataires, patients, justiciables, candidats, usagers – n’y apparaissent que sous la forme d’“utilisateurs finaux”, de “profils de risque” ou de “cas d’usage”. Ces lieux relèvent de l’*hypertopie cratiale* : ce sont des s*cènes effectives, mais concentrées, saturées de pouvoir, inaccessibles pour ceux qui subissent les décisions qui y sont prises*.
+
+Entre ces deux polarités, une troisième famille de scènes se dessine : les *scènes judiciaires et quasi-judiciaires*. Cours et tribunaux, autorités de protection des données, régulateurs sectoriels, instances comme l’*Oversight Board*, mécanismes de règlement extrajudiciaire des litiges instaurés par le Digital Services Act. Ce sont des lieux où Système F, ou certains de ses avatars, peuvent être introduits comme objet de litige : *refus de prestation sociale, décision automatisée contestée, modération de contenu jugée abusive, sélection algorithmique à l’embauche, pratiques discriminatoires en santé*. On y trouve des éléments majeurs d’*archicration* : *procédure contradictoire, possibilité de produire des preuves, décisions motivées, sanctions*. Mais ces scènes sont souvent tronquées du point de vue archicratique : le juge ou l’instance n’ont pas toujours accès aux paramètres, aux données, aux logs ; ils se heurtent au *secret commercial*, à l’*opacité technique*, à l’*indisponibilité de certaines informations*. L’algorithme apparaît alors dans la scène, mais partiellement : la chaîne cratiale reste, en grande partie, hors champ. La scène d’épreuve est réelle, mais incomplète.
+
+L’épreuve topologique appliquée à Système F va consister à organiser ce paysage, non pas en ajoutant un vocabulaire supplémentaire, mais en qualifiant les formes scéniques où la régulation algorithmique se manifeste. Dans un premier temps (II.1), nous prendrons au sérieux les scènes locales d’usage : guichets, interfaces, formulaires, dispositifs de “feedback”. Nous montrerons comment elles combinent, le plus souvent, *hypotopies* (scènes pauvres en prises) et *archicrations fantômes* (recours et consultations sans prise sur la structure du système). Dans un second temps (II.2), nous déplacerons le regard vers les *scènes institutionnelles de conception et de pilotage*, pour caractériser ce que l’on peut appeler une *hypertopie cratiale* : une *concentration scénique du pouvoir de configuration, sous forme de réunions, de comités et de boards largement fermés aux publics concernés*. Dans un troisième temps (II.3), nous interrogerons les *scènes judiciaires et quasi-judiciaires* où l’IA apparaît dans les contentieux, en demandant jusqu’où ces scènes parviennent – ou non – à recomposer une *archicration* complète incluant l’accès aux données, aux modèles et aux traces d’exécution.
+
+Au terme de cette épreuve, une synthèse topologique (II.4) permettra de rendre visible, sous une forme compacte, la manière dont Système F distribue ses scènes : lignes de guichet, interfaces numériques, comités techniques, tribunaux, chacune étant lue à travers les trois prises archicratique (*arcalité* / *cratialité* / *archicration*), le type topologique (*hypotopie, hypertopie, atopie*) et son *degré d’ouverture ou de fermeture*. L’objectif n’est pas de plaquer un schéma préexistant sur l’IA, mais de montrer, très concrètement, que ce type de dispositif tend à dégrader la scène : en multipliant les *pseudo-espaces d’expression sans effet, en concentrant la décision dans des hypertopies techniques, en laissant les arènes judiciaires lutter avec des objets partiellement invisibles*. C’est cette dégradation topologique que la suite du cas d’étude cherchera à caractériser et, surtout, à retourner : *que faudrait-il, pour que Système F soit inséré dans une topologie réellement archicratique des scènes ?*
+
+## II.1. Scènes locales d’usage : *hypotopies* et *archicrations fantômes*
+
+Là où Système F devient perceptible pour la plupart des personnes, ce n’est ni dans les *data centers*, ni dans les comités de pilotage, ni dans les rapports d’audit, mais dans des scènes beaucoup plus modestes : un écran de guichet, un portail en ligne, un SMS automatique, un formulaire de recours, un bouton “signaler”, une boîte de dialogue “évaluez votre expérience”. Ce sont des scènes, au sens strict : il y a une interface, une adresse possible, parfois un droit minimal de réponse. Mais ce sont des scènes pauvres, prises dans un rapport extrêmement dissymétrique avec les lieux où Système F est conçu, paramétré, déployé. Topologiquement, elles relèvent de l’*hypotopie* et, lorsqu’elles se contentent de simuler un dialogue sans prise réelle, de l’*atopie*.
+
+### II.1.1. Guichets devenus interfaces : la scène réduite au formulaire
+
+Dans les régimes de protection sociale que nous avons évoqués dans la Partie I, l’introduction de Système F ne supprime pas le guichet ; elle le transforme. Là où se trouvaient autrefois des bureaux, des agents, des piles de dossiers papier, on rencontre de plus en plus souvent des *interfaces* : *écran partagé entre l’agent et l’allocataire, portail sur lequel ce dernier doit déposer ses justificatifs, suivre l’avancement de son dossier, répondre à des notifications*.
+
+Du point de vue de l’allocataire, la scène se réduit à une *série d’actions codifiées* : *remplir des champs, téléverser des documents, cliquer sur “valider”, consulter un statut* (“en cours d’instruction”, “refusé”, “suspendu”), *parfois recevoir un message standardisé*. Système F est présent, mais en creux : il se manifeste par l’*ordre d’apparition des dossiers*, la *vitesse de traitement*, un *score de risque invisible*, un *basculement automatique d’un statut à un autre*.
+
+Du point de vue de l’agent de guichet, la scène a aussi changé : là où l’on triait les dossiers “à vue” ou selon des procédures explicites, l’écran présente désormais une *file de cas pré-classés*, souvent accompagnés de *codes couleur*, *de priorités*, *d’alertes*. L’agent peut parfois *ajouter une note*, *corriger un champ*, *signaler une anomalie* ; mais l’*architecture globale de la décision* (quels dossiers arrivent, dans quel ordre, avec quel niveau d’urgence) *lui échappe en grande partie*. La *cratialité* de Système F traverse la scène, sans y apparaître vraiment.
+
+Topologiquement, cette situation correspond à une *hypotopie* : il y a bien une scène – des personnes présentes, des échanges, une interface, des décisions qui se prennent – mais elle est pauvre en prises sur la régulation algorithmique. L’allocataire ne voit ni les variables qui le caractérisent dans Système F, ni le score qui a déclenché un contrôle ; l’agent lui-même n’a souvent qu’un accès très partiel aux raisons techniques du classement. La scène sert à exécuter des décisions déjà pré-structurées ailleurs, non à interroger la logique qui les organise.
+
+On pourrait imaginer, en théorie, un guichet où l’allocataire pourrait demander : “*quel rôle précis a joué le système automatique dans ma suspension ? quels critères ont été appliqués ? quels sont les taux d’erreur habituels ?*” En pratique, ces questions n’ont souvent pas de place dans la scène : ni l’interface, ni la formation des agents, ni les procédures n’ont prévu qu’on puisse les poser – et encore moins y répondre. L’*archicration reste hors champ*.
+
+### II.1.2. Recours numériques : de la réclamation au simulacre d’*archicration*
+
+Lorsque la décision est défavorable – une prestation suspendue, un dossier classé sans suite, un refus d’allocation, une radiation –, la scène se déplace vers les *procédures de recours*. Elles sont, de plus en plus, numérisées : *formulaires en ligne, espaces personnels où l’on peut “contester” une décision, champs de texte libre limité en nombre de caractères, cases à cocher pour indiquer un motif* (“erreur de calcul”, “changement de situation”, “décision injustifiée”, etc.).
+
+Sur le papier, ces dispositifs matérialisent une forme d’*archicration* : ils offrent à la personne concernée une *possibilité de s’adresser à l’institution*, de *présenter ses arguments*, d’*obtenir une révision*. Mais, lorsqu’on les lit à travers la grille archicratique, beaucoup apparaissent comme des *archicrations fantômes*.
+
+D’abord, parce qu’ils sont structurés pour traiter des réclamations individuelles sur le résultat, non pour ouvrir une discussion sur le dispositif. Le formulaire invite à dire “je n’aurais pas dû être suspendu”, “mes revenus ont été mal pris en compte”, “vous n’avez pas considéré tel document”, mais il n’offre aucune case, aucune catégorie, aucun canal pour dire : “l’algorithme qui m’a classé comme fraudeur repose sur des hypothèses inacceptables”, “la nationalité ne devrait pas être utilisée comme facteur de risque”, “les erreurs du système sont concentrées sur des personnes dans ma situation”. La scène est calibrée pour corriger des erreurs perçues comme accidentelles, non pour instruire des critiques sur la structure même de Système F.
+
+Ensuite, parce que la trajectoire de ces recours est souvent opaque. Une fois le formulaire envoyé, l’allocataire reçoit un accusé de réception automatique, puis une réponse laconique confirmant ou non la décision initiale. *Le recours a-t-il été lu par un humain ? Par un second modèle ? Par un agent qui ne fait que vérifier la présence de certains justificatifs ? Les éléments soumis ont-ils une chance de remonter vers les équipes qui conçoivent et paramètrent Système F ?* La scène existe, mais elle est décrochée de la chaîne cratiale.
+
+Enfin, parce qu’il n’y a pas, dans la plupart des cas, de *mise en publicité des recours* : ni statistiques agrégées sur le nombre de contestations liées aux décisions co-produites par Système F, ni analyses régulières des motifs de mécontentement, ni articulation explicite entre ces données et la reconfiguration des modèles. La *scène de recours reste cloisonnée*, sans devenir une scène où l’*arcalité implicite* et la *cratialité* pourraient être rejouées.
+
+Du point de vue topologique, ces dispositifs relèvent d’une forme mixte : *hypotopiques, parce qu’ils offrent très peu de prises réelles sur la régulation algorithmique* ; et déjà partiellement *atopiques*, dès lors qu’ils se contentent de *jouer le rôle de “voix des usagers” sans que cette voix rencontre des lieux de décision*. La scène est là, mais comme *décor procédural*, non comme espace d’épreuve.
+
+La scène de recours est donc globalement hypotopique : elle existe bien, mais avec une densité de prises tellement faible qu’elle ne peut presque jamais infléchir la régulation algorithmique. Il s’agit bien souvent au mieux d’une correction ponctuelle et discrète.
+
+### II.1.3. Feedbacks, étoiles, likes, boutons “signaler” : l’atopie comme style
+
+Un troisième type de scènes locales d’usage est celui des *dispositifs de feedback continu* : étoiles attribuées à un service, notation d’une interaction, boutons “j’aime” / “je n’aime pas”, icônes “signaler ce contenu”, “ce résultat est utile / ne l’est pas”, “résultats inappropriés”. Ils sont omniprésents dans les plateformes numériques, mais aussi de plus en plus dans les services publics et les applications professionnelles.
+
+À première vue, ces dispositifs prolongent une ambition archicratique : *rendre les systèmes sensibles à l’expérience des usagers, intégrer en continu des retours, corriger les dérives*. L’utilisateur de Système F – bénéficiaire, patient, conducteur ou passager d’une plateforme de mobilité, client d’un service, internaute exposé à des contenus – se voit offrir un petit geste : cliquer sur une étoile, cocher une case, rédiger un bref commentaire, signaler un abus. *Autant de micro-prises qui donnent l’impression d’une scène toujours disponible*.
+
+Mais là encore, la lecture topologique révèle souvent une *atopie* : *un usage du langage de la scène sans articulation réelle avec les lieux où la régulation se décide.* Dans les *systèmes de notation réciproque* (chauffeurs / passagers, vendeurs / acheteurs, travailleurs de plateforme / clients), l’étoile donnée par un individu est très rarement pensée comme un *acte de mise à l’épreuve d’une norme*. Elle est conçue comme un *signal quantifiable*, immédiatement intégré à un *score global* qui servira ensuite à ordonner des files d’attente, à attribuer des courses, à exclure des travailleurs jugés “peu fiables”. La *scène de feedback* n’est pas l’endroit où les critères de qualité de service se discutent ; elle est un *mécanisme de discipline diffuse* : chacun sait qu’il peut être “noté”, mais ne sait pas vraiment comment les notes sont agrégées, interprétées et utilisées.
+
+Sur les plateformes de contenus, le bouton “signaler” promet au contraire une *capacité à faire remonter des problèmes* : contenu haineux, illégal, trompeur, dangereux. En pratique, l’utilisateur ne voit presque jamais ce qu’il advient de son signalement : celui-ci part dans une chaîne cratiale obscure – combinaison de filtres automatisés, de priorisations, de requalifications humaines – pour revenir, parfois, sous la forme d’un message standard (“nous avons examiné votre signalement et décidé de…”), sans explication sur les critères appliqués, sur la place exacte de Système F dans la décision, ni sur la manière dont ce signalement contribue à reconfigurer les modèles.
+
+Sur les interfaces de certains outils d’IA, les boutons “pouce en haut / pouce en bas”, “utile / non utile”, “trop sévère / trop permissif” jouent un rôle similaire : ils promettent une *co-construction des comportements du modèle*, mais ne donnent ni visibilité sur la manière dont ces retours sont utilisés, ni possibilité d’élargir la scène à d’autres acteurs que l’utilisateur individuel. Là encore, nous sommes devant une scène minimale – un geste, un symbole, un canal – mais qui ne s’adosse à aucune *archicration* identifiable.
+
+Ce qui caractérise ces dispositifs, du point de vue archicratique, c’est donc leur ambiguïté : ils sont présentés comme des instruments de participation, alors qu’ils fonctionnent surtout comme des capteurs supplémentaires dans la chaîne cratiale de Système F. Ils peuvent améliorer certains paramètres (réduire des erreurs manifestes, affiner des modèles de recommandation), mais ils ne créent pas de scène où les fondements et les effets du système seraient mis à l’épreuve avec les publics concernés. *Ce sont des scènes sans monde : des atopies*.
+
+Lorsque le *feedback* se réduit à un geste symbolique sans trajectoire identifiable vers les lieux de décision, on ne se trouve alors plus seulement dans une *hypotopie*, mais dans une *atopie* : *une scène jouée pour elle-même, déconnectée des décisions effectives et des répercussions affectives*.
+
+### II.1.4. *Hypotopies* et *archicrations fantômes* : première coupe topologique
+
+Si l’on rassemble ces trois familles de scènes locales – *guichets devenus interfaces, recours numériques, dispositifs de feedback* –, un motif commun se dessine.
+
+1.  Elles sont *proches des personnes affectées* : c’est là que Système F est ressenti, au moment où un dossier bascule, où un contenu disparaît, où une notation tombe, où une décision est confirmée ou refusée.
+
+2.  Elles *offrent bien des formes de scène* : présence d’un agent, d’une interface, d’un canal de parole, d’un geste de notation ou de signalement.
+
+3.  Mais elles sont *décrochées des lieux où se configurent la cratialité et l’arcalité implicite du système* : les choix de proxies, de fonctions de coût, de seuils, de stratégies de déploiement, de politiques de modération ne sont presque jamais discutés ni requalifiés à partir de ce qui s’y joue.
+
+Topologiquement, ces scènes sont donc *hypotopiques* : elles existent, mais avec un *très faible nombre de prises effectives sur la régulation*. Et lorsqu’elles promettent une participation forte (*feedback* continu, consultations en ligne, enquêtes de satisfaction, boîtes à idées numériques) sans offrir de trajectoire identifiable des contributions vers les lieux de décision, elles basculent dans l’*atopie* : il y a bien un théâtre, des gestes, un vocabulaire de la co-construction, mais pas de connexion stable avec la chaîne cratiale qui la rend effective.
+
+C’est ce déficit topologique – cette combinaison de scènes pauvres en prises et de pseudo-scènes sans pouvoir réel – qui explique, pour une part, la persistance d’*archicrations fantômes* autour de Système F. La suite de la Partie II montrera que cette pauvreté n’est pas un simple problème “local” à corriger par quelques améliorations d’interface : elle est le reflet d’une configuration d’ensemble où la scène, au sens archicratique, est structurellement reléguée.
+
+## II.2. *Scènes institutionnelles* : *hypertopie cratiale*
+
+Les *scènes locales d’usage* donnent à voir Système F sous forme de *reflets* : un écran de guichet, un portail de recours, un bouton “signaler”. La véritable scène, celle où se combinent les choix de fondement et les décisions opératoires, se déplace ailleurs : dans des *salles de réunion*, des *comités de pilotage,* des *“boards” responsables de l’IA,* des *cellules de conformité ou d’innovation*. C’est là que se décide le *design du modèle*, le *périmètre des données*, les *fonctions de coût*, les *seuils*, les *conditions de déploiement*, les *mécanismes de supervision humaine*. Du point de vue topologique, ces lieux concentrent une *densité exceptionnelle de prises cratiales* et, de plus en plus, d’*énoncés arcaux explicites* – *principes, standards, matrices de risques*. Mais ils sont *fermés* : les publics affectés n’y sont presque jamais présents, ni même représentés autrement que sous la forme de “*personae*”. Ce sont des *hypertopies cratiales*.
+
+### II.2.1. Là où Système F se décide : comités, *workshops*, “*steering boards*”
+
+Dans une caisse sociale qui envisage d’intégrer un module de Système F pour prioriser les contrôles, la scène institutionnelle typique prend la forme d’un *comité projet* : autour de la table, des responsables métiers (fraude, prestation, contrôle), des informaticiens, un juriste spécialisé en protection des données, parfois un représentant de la direction de la stratégie ou de l’inspection interne. C’est dans cette configuration que l’on discute des “*cas d’usage*” envisagés, des *sources de données* que l’on estime mobilisables, des *critères de risque* jugés pertinents, des *modalités de “pilotage”* (périodes de test, indicateurs de performance, seuils de déclenchement des contrôles).
+
+Un schéma comparable se retrouve dans un hôpital qui veut déployer un outil de tri des patients à haut risque, dans un ministère de la justice qui envisage un système d’aide à la décision pénale, ou dans une grande entreprise qui souhaite industrialiser l’utilisation de Système F pour le tri des candidatures. Dans tous ces cas, *le cœur de la décision se situe dans des réunions internes* où l’on *arbitre entre plusieurs architectures possibles*, où l’on *discute des proxies envisageables* (historique de coûts, variables socio-démographiques, signaux comportementaux), où l’on *fixe des seuils de déclenchement et des règles d’escalade*. Les personnes dont les trajectoires seront directement affectées – allocataires, patients, justiciables, candidats – sont absentes ; au mieux, elles sont présentes sous forme de *catégories* (“usagers vulnérables”, “publics à risque”, “talents”) ou de *statistiques*.
+
+Cette structure se retrouve, à un autre niveau, chez les fournisseurs de Système F. Les grands acteurs du *cloud* et des modèles de fondation ont mis en place des comités internes de gouvernance de l’IA : chez Microsoft, le comité *Aether* (*AI, Ethics, and Effects in Engineering and Research*) conseille la direction sur les risques éthiques, juridiques et sociétaux, appuyé par un standard interne de “*Responsible AI*” que les équipes produits doivent respecter. Google décrit un processus de gouvernance couvrant le développement du modèle, le déploiement des applications et la surveillance post-lancement, avec des comités formels qui examinent les nouveaux projets au regard de ses *AI Principles*, complétés par des exercices de *red teaming* et des *revues croisées*.
+
+Dans ces scènes, les décisions structurantes sur Système F sont prises : *quel type de modèle sera proposé par API, avec quels garde-fous, quelles limitations de cas d’usage ; quels critères de “sensibilité” imposent une revue approfondie* ; *quelles demandes de clients (ministères, banques, hôpitaux) doivent être acceptées, négociées, refusées*. Là encore, les experts présents sont nombreux – ingénieurs, juristes, spécialistes de la conformité, parfois chercheurs en sciences sociales – mais les publics concernés sont absents en tant que tels.
+
+Topologiquement, on voit apparaître un *déplacement de la scène* : ce n’est plus au guichet, dans la salle d’audience, au bureau de recrutement que Système F se décide, mais dans ces *arènes internes où se tissent ensemble la stratégie, le droit, la technique, le marketing*.
+
+### II.2.2. Une gouvernance annoncée “*responsable*” comme *scène saturée* de *cratialité*
+
+Pour comprendre le caractère *hypertopique* de ces scènes institutionnelles, il faut prendre au sérieux la montée en puissance de la *gouvernance “responsable” de l’IA*. Au cours des dernières années, une littérature abondante a proposé des cadres de gouvernance articulant *principes éthiques*, *structures d’organisation* (comités, responsables IA, cellules d’accompagnement) *et procédures* (revues de risques, audits internes, évaluations d’impact).
+
+Les grands fournisseurs de Système F ont intégré ces cadres en interne. Microsoft insiste sur le fait que son *Responsible AI Standard* s’applique à toutes les équipes produits, que les cas d’usage “sensibles” doivent être portés devant des groupes de travail spécialisés, et que le comité *Aether* peut, en dernière instance, se prononcer sur des projets à haut risque, en lien direct avec la direction. Google met en avant des comités formels chargés de vérifier que les projets respectent ses *AI Principles*, qui couvrent notamment les questions de bénéfice social, d’évitement des biais injustes, de sécurité et de responsabilité.
+
+Dans le secteur public, des dispositifs analogues apparaissent : le gouvernement canadien a rendu obligatoire un *Algorithmic Impact Assessment* pour tout système de décision automatisée, sous la forme d’un questionnaire structuré qui détermine un niveau de risque et déclenche des exigences de gouvernance (revue par des comités, publication de résumés, documentation renforcée). Des organisations internationales et des ONG ont proposé des typologies de mécanismes d’“*algorithmic accountability*” — *responsabilité algorithmique* — dans le secteur public (audit, évaluations d’impact, transparence, consultations), qui se traduisent souvent par la *création de cellules transversales et de comités d’examen des projets*.
+
+Ces structures incarnent une *cratialité scénique* : elles sont des lieux où des personnes se réunissent, où des dossiers sont présentés, où des avis sont rendus, où certains projets sont acceptés, d’autres renvoyés, parfois abandonnés. Elles ne sont pas de simples scripts : ce sont des scènes où la trajectoire de Système F est effectivement infléchie. Mais elles fonctionnent selon une logique d’*hypertopie* :
+
+- elles *concentrent un grand nombre de prises* – définition des cas d’usage autorisés, choix des métriques de risque, arbitrages entre principes, décisions de go/no-go – dans un petit nombre de lieux fermés ;
+
+- elles *organisent l’accès à ces scènes selon des critères internes* (appartenance à l’entreprise, à l’administration, à une communauté de pratique) ;
+
+- les publics affectés ne sont présents qu’à travers des proxies (études d’impact, “voix de l’utilisateur” reportée par des intermédiaires), rarement comme participants directs ;
+
+- elles se *situent à l’interface entre la stratégie* (marchés, opportunités, cas d’usage), le *droit* (conformité au RGPD, à l’AI Act, aux directives sectorielles), et la *technique* (choix de modèles, d’architectures, de paramètres), de sorte que c’est là que s’articulent désormais *arcalité déclarée* (principes, chartes) *et cratialité* (instruments, procédures).
+
+Autrement dit, la gouvernance “responsable” de Système F n’est pas extérieure à la *cratialité* : elle en est une couche supplémentaire, qui déplace vers ces comités le pouvoir de décider ce qui est “acceptable”, “conforme”, “aligné avec les principes”. *La scène existe, mais elle est réservée aux experts.*
+
+### II.2.3. *Hypertopie régulatoire* : AI Act, autorités, AI Office
+
+À cette gouvernance interne s’ajoute une couche régulatoire qui, elle aussi, se concrétise dans des scènes institutionnelles fermées ou semi-fermées. L’AI Act européen organise un dispositif de gouvernance articulant un AI Office au sein de la Commission, des autorités nationales de surveillance du marché, des comités consultatifs d’experts et des mécanismes de coordination entre États membres.
+
+Pour les systèmes d’IA considérés comme “à haut risque”, les fournisseurs doivent mettre en place un système de gestion des risques couvrant tout le cycle de vie, documenter leurs modèles, assurer une gouvernance des données (représentativité, qualité, absence d’erreurs dans la mesure du possible), garantir des mécanismes de supervision humaine efficaces, tenir des journaux d’événements, et coopérer avec les autorités.
+
+Concrètement, ces obligations donnent lieu, dans les entreprises et les administrations, à la constitution de structures dédiées : responsables produit pour l’IA, unités de conformité, “*AI governance boards*” qui suivent l’état d’avancement des projets, examinent les dossiers techniques, préparent les échanges avec les régulateurs. Des guides récents pour la gouvernance de l’IA recommandent de définir des principes internes, de documenter l’ensemble des politiques relatives au design, au déploiement et à l’exploitation des modèles, et de coordonner ces efforts sous une instance de supervision dédiée.
+
+Là encore, la scène est réelle : des équipes se réunissent pour remplir des questionnaires d’évaluation d’impact, préparer des audits, décider si un cas d’usage tombe ou non dans une catégorie de risque, définir le périmètre des journaux à conserver, négocier avec les autorités sur la qualification d’un système ou la proportionnalité des obligations. Ce sont des lieux où l’architecture de Système F est littéralement “*mise en forme*” *pour répondre aux cadres juridiques*.
+
+Mais cette *hypertopie régulatoire* ne corrige pas spontanément le déficit archicratique des scènes locales. Elle peut renforcer, dans certains cas, l’exigence de documentation et de supervision humaine ; elle peut créer de nouveaux motifs de contentieux, comme on le voit déjà avec les premiers litiges autour de l’AI Act ou des obligations de transparence pour les plateformes.  
+Ce qu’elle ne fait pas, par elle-même, c’est ouvrir ces scènes aux publics affectés : les *procédures restent principalement l’affaire des fournisseurs, des intégrateurs, des régulateurs, éventuellement de quelques représentants de la société civile intégrés à des groupes d’experts*. Les allocataires, les patients, les justiciables, les candidats n’apparaissent qu’indirectement, via des évaluations d’impact ou des consultations ponctuelles.
+
+### II.2.4. Lecture topologique : la scène archicratique capturée par l’*hypertopie*
+
+Du point de vue de l’épreuve topologique, ces *scènes institutionnelles* présentent une configuration paradoxale.
+
+D’un côté, elles *rassemblent ce qui manque aux scènes locales* : ici, les fondements sont explicitement discutés (au moins sous la forme de principes et de matrices de risques), les instruments sont détaillés (modèles, données, paramètres), des arbitrages sont opérés, des décisions sont prises qui engagent la trajectoire de Système F. Ce sont, au sens archicratique, des scènes potentielles : on y parle de ce qui fonde, de ce qui opère, de ce qui est acceptable.
+
+De l’autre, elles sont fermées : la liste des participants est limitée, les publics concernés ne sont présents que sous forme d’abstractions, les conflits de normativité (par exemple entre les intérêts économiques du fournisseur, les objectifs politiques de l’administration et les droits des personnes affectées) sont réglés dans un cercle restreint. L’information circule de manière asymétrique : les expériences des scènes locales (erreurs, injustices, effets pervers) remontent peu, sauf lorsqu’elles éclatent en scandales ou en contentieux ; les décisions prises dans ces hypertopies redescendent sous la forme de modèles “prêts à l’emploi”, de paramètres par défaut, de seuils automatisés, de formulaires de recours formatés.
+
+On peut dire, en reprenant la terminologie de la thèse, que la scène archicratique a été capturée par l’hypertopie cratiale. Au lieu de s’organiser autour d’espaces où les différents mondes concernés par Système F se rencontreraient (bénéficiaires, praticiens, concepteurs, régulateurs, chercheurs, associations), la mise en forme du pouvoir algorithmique se joue dans des cénacles d’experts spécialisés, au croisement de la technique, du droit et de la gestion. La densité de prises y est maximale ; la pluralité des publics y est minimale.
+
+Ce constat ne signifie pas que ces scènes seraient inutiles ou purement cyniques : elles sont indispensables à la mise en conformité, à la réduction de certains risques, à la prise de conscience interne des enjeux. Mais, tant qu’elles restent organisées comme des hypertopies fermées, elles ne constituent pas des archicrations au sens plein : elles ne rendent pas Système F justiciable devant ceux qu’il affecte, elles ne transforment pas la gouvernance de l’IA en scène de confrontation des arcalités et des cratialités.
+
+La Partie II montrera que c’est précisément dans la tension entre ces hypertopies cratiales et les hypotopies/atopies des scènes locales que se dessine le paysage topologique propre aux systèmes d’IA contemporains : un paysage où la scène existe, mais où elle est à la fois concentrée (dans quelques arènes expertes) et dégradée (dans les lieux ordinaires où se jouent les vies).
+
+## II.3. Scènes judiciaires et quasi-judiciaires
+
+Les *scènes judiciaires et quasi-judiciaires* sont, en principe, les lieux par excellence de l’*archicration* : *espaces réglés où une décision peut être contestée, où des preuves sont produites, où des arguments s’affrontent, où une instance tranche en motivant son jugement*. Si Système F devait être mis en cause quelque part, ce serait ici : lorsqu’un refus de prestation sociale est contesté, lorsqu’une décision automatisée est attaquée, lorsqu’une suspension de compte ou un retrait de contenu est porté en justice ou devant une autorité indépendante.
+
+De fait, les systèmes d’IA et, plus largement, les dispositifs algorithmiques, apparaissent de plus en plus souvent dans ces scènes : dans les litiges autour des dispositifs de profilage social néerlandais, dans les recours contre des décisions automatisées au titre du RGPD, dans les affaires de modération de contenus tranchées par des tribunaux nationaux ou par l’*Oversight Board* de Meta, dans les procédures ouvertes par des autorités contre des plateformes qui manquent à leurs obligations de transparence ou de diligence. Mais, lorsque l’on regarde ces scènes à travers la grille archicratique, une question revient avec insistance : *le juge, ou l’instance quasi-judiciaire, voit-il vraiment Système F ? A-t-il accès aux paramètres, aux données, aux logs, aux arbitrages d’erreurs ?* Si la réponse est non ou partielle, la scène reste incomplète : l’*archicration est tronquée*.
+
+### II.3.1. Contentieux sociaux : le système est jugé… tard, et par morceaux
+
+Les affaires néerlandaises liées au profilage social sont exemplaires. Dans le’exemple de SyRI, le tribunal de district de La Haye a été saisi par une coalition d’ONG et de syndicats qui contestaient la conformité du système au droit au respect de la vie privée garanti par l’article 8 de la CEDH. Le jugement de 2020 décrit SyRI comme un *dispositif de croisement massif de données issues de multiples administrations, produisant des “rapports de risque” sur certaines zones ou populations, sans transparence suffisante ni garanties contre les discriminations*. Le tribunal conclut que la législation encadrant SyRI ne respecte pas le “*juste équilibre*” entre la lutte contre la fraude et la protection des droits, et en interdit l’usage.
+
+Dans le scandale des allocations pour la garde d’enfants, ce sont des années de litiges individuels, de plaintes, de rapports de l’Autorité de protection des données, d’enquêtes parlementaires qui ont fini par mettre au jour l’ampleur des *pratiques de profilage* : utilisation de la double nationalité comme facteur de risque, concentration des contrôles sur certaines familles, impossibilité pour les parents de comprendre pourquoi ils étaient ciblés et sommés de rembourser. Les contentieux ont fini par prendre une dimension quasi-systémique, conduisant à la démission du gouvernement et à un vaste plan de compensation.
+
+Ces *scènes judiciaires* ont un effet archicratique réel : elles *obligent l’administration à exposer, au moins partiellement, le fonctionnement de ses dispositifs* ; elles *rendent publics certains critères* ; elles *prononcent des condamnations* ; elles *engagent des réformes*. Mais elles interviennent tard, après la production de dommages parfois considérables, et elles restent souvent focalisées sur un segment de Système F (un système particulier de *scoring*, une catégorie de données, une base légale), sans reconstituer la chaîne cratiale entière.
+
+Du point de vue topologique, ces scènes sont donc fortes, mais intermittentes : ce sont des moments où Système F est forcé d’apparaître, mais seulement lorsqu’un scandale ou un contentieux de grande ampleur éclate. L’*archicration reste événementielle, non structurelle*.
+
+### II.3.2. Décisions automatisées et RGPD : une visibilité juridique sans visibilité technique
+
+Le RGPD et les droits qu’il consacre – *droit d’accès, droit à l’explication, droit d’opposition, droit de ne pas faire l’objet d’une décision exclusivement automatisée produisant des effets juridiques significatifs* – fournissent un autre cadre d’apparition des systèmes d’IA sur la scène judiciaire. Des individus contestent des décisions en invoquant le caractère automatisé du traitement, l’absence d’information claire sur la logique des algorithmes, la difficulté d’exercer effectivement leurs droits.
+
+Les autorités de protection des données ont commencé à instruire des dossiers où des systèmes de *scoring* ou de *profilage* sont au cœur du litige : *applications de notation sociale, systèmes de tri de candidatures, outils de ciblage publicitaire, plateformes de livraison ou de mobilité utilisant des algorithmes pour évaluer les performances et attribuer des tâches*. Dans certains cas, la justice est saisie après une décision de l’autorité, soit par les entreprises qui la contestent, soit par les plaignants qui estiment les mesures insuffisantes.
+
+Mais, dans la pratique, ces scènes se heurtent à un obstacle récurrent : le *fossé entre la visibilité juridique du traitement et la visibilité technique* de Système F. Le RGPD permet à la personne concernée d’obtenir des “*informations utiles quant à la logique*” d’un traitement automatisé ; les autorités peuvent *exiger des explications détaillées* ; les juges peuvent *ordonner la communication de documents techniques*. Cependant :
+
+- Les *informations fournies restent souvent très générales* (description de la finalité, liste de catégories de données, mention d’une utilisation de profilage), *sans entrer dans le détail des modèles, des proxies, des seuils, des arbitrages de coût*.
+
+- Les *entreprises invoquent fréquemment le secret des affaires pour limiter la divulgation de certains éléments* (architecture exacte du modèle, paramètres, méthodes de calibration), *ce qui restreint les capacités d’expertise contradictoire*.
+
+- Les *juges*, sauf à s’entourer d’experts techniques, *ne disposent pas toujours des outils pour interpréter les logs, les matrices de confusion, les rapports de validation qui leur seraient éventuellement communiqués.*
+
+La scène judiciaire existe, mais Système F n’y est présent qu’en silhouette : on connaît sa finalité, on sait qu’il y a un algorithme, on discute de sa base légale et de ses effets, mais on ne reconstitue pas intégralement la *cratialité*. L’*archicration* est, là encore, tronquée : c’est moins l’architecture du système qui comparaît que ses conséquences et son habillage juridique.
+
+### II.3.3. Modération de contenus, *Oversight Board* et DSA : scènes emblématiques mais parcellaires
+
+Dans le domaine de la modération et de la curation de contenus, les *scènes quasi-judiciaires* se multiplient : *recours d’utilisateurs contre des suspensions de compte*, *actions en justice contre des plateformes pour sur-modération ou sous-modération*, *recours devant les autorités au titre du droit à la liberté d’expression* ou de la *protection contre les contenus haineux*, *procédures instruits dans le cadre du Digital Services Act*.
+
+Le *Meta Oversight Board* occupe une position singulière : instance indépendante financée par un trust, composée d’experts et de personnalités diverses, chargée de réexaminer un petit nombre de décisions de modération de Facebook et Instagram, à la demande d’utilisateurs ou de la plateforme elle-même. Dans ces procédures, l’algorithme de recommandation ou les systèmes de détection automatique sont parfois explicitement mentionnés : ils ont pu déclencher une première étape de retrait, ou influencer la visibilité d’un contenu. Les décisions du Board analysent alors la conformité de la décision globale aux règles de la plateforme et aux standards internationaux des droits humains, et formulent des recommandations sur les politiques de modération et leur mise en œuvre.
+
+Le DSA, de son côté, crée des *obligations de transparence et de diligence pour les très grandes plateformes* : publication de rapports sur les contenus retirés ou limités, description des systèmes de recommandation, mise en place de mécanismes internes de plainte et de règlements extrajudiciaires des litiges, audits indépendants. Les premières affaires instruites au titre du DSA montrent que la Commission et les autorités nationales entendent examiner la manière dont les mesures automatisées sont utilisées pour détecter, hiérarchiser ou supprimer des contenus, notamment lorsqu’il s’agit de discours politique, de désinformation ou de contenus ciblant des groupes vulnérables.
+
+Ces dispositifs produisent des *scènes quasi-judiciaires* où les plateformes doivent expliquer – au moins partiellement – *comment leurs systèmes fonctionnent, pourquoi un contenu a été retiré ou maintenu, comment les utilisateurs peuvent contester ces décisions*. Mais ici aussi, la visibilité reste partielle :
+
+- Les *décisions de l’Oversight Board* portent sur un très petit nombre de cas, choisis en fonction de leur importance symbolique ; elles n’offrent qu’un éclairage ponctuel sur la manière dont les algorithmes de Meta structurent l’exposition aux contenus.
+
+- Les *rapports de transparence exigés* par le DSA agrègent des chiffres (nombre de contenus modérés, proportion de décisions automatisées vs humaines, volumes de recours) et décrivent les systèmes de manière très synthétique, sans exposer les paramètres concrets de Système F.
+
+- Les *mécanismes de plainte et de règlement extrajudiciaire* permettent de corriger des décisions individuelles, mais ils ne s’accompagnent pas automatiquement d’une capacité pour les plaignants à déclencher une révision profonde des modèles.
+
+L’impression, du point de vue archicratique, est celle de scènes emblématiques mais parcellaires : elles jouent un rôle de vitrine et peuvent générer des inflexions importantes, mais elles ne suffisent pas à constituer un régime ordinaire de comparution pour Système F.
+
+### II.3.4. Un accès incomplet à la *cratialité* : logs, données, paramètres en pointillés
+
+Ce qui traverse toutes ces scènes, c’est la question des conditions d’accès à la *cratialité*. Pour qu’une *archicration* soit complète, il ne suffit pas que la décision soit contestable en droit ; il faut que les instruments qui la produisent puissent être amenés sur scène dans leur *structure opérationnelle* : *données d’entraînement, variables choisies, fonctions de coût, seuils, logs d’exécution, métriques d’erreurs, modifications successives*.
+
+Or la plupart des contentieux impliquant Système F se heurtent à des barrières récurrentes :
+
+- *Secret des affaires et propriété intellectuelle* : les entreprises invoquent la protection de leurs secrets industriels pour refuser de divulguer certains éléments ; les juges doivent arbitrer entre cette protection et le droit à un procès équitable, sans toujours disposer de mécanismes robustes (experts tiers, accès limité mais réel, obligations de documentation approfondie).
+
+- *Fragmentation de l’information* : même lorsque des éléments sont communiqués, ils le sont souvent par fragments – un descriptif de la finalité, une liste de variables, des extraits de code, un rapport d’audit interne – sans qu’un travail de reconstitution complète de la chaîne cratiale soit réalisé dans la procédure.
+
+- *Capacités d’expertise* : juges, avocats, autorités, associations disposent de ressources inégales pour analyser les modèles, comprendre les rapports techniques, interpréter les logs ; les plaignants individuels, eux, n’ont généralement accès qu’à des informations très abstraites sur la “logique” du traitement.
+
+- *Temporalité* : les systèmes évoluent rapidement ; au moment où un contentieux est arrivé à maturité, le modèle a parfois été modifié, remplacé, recalibré, ce qui complique la tâche de statuer sur un état donné de Système F.
+
+Le résultat, du point de vue topologique, est que la *scène judiciaire* ou *quasi-judiciaire* voit Système F, mais comme à travers une vitre dépolie : on devine une architecture, on identifie certaines variables, on mesure des effets discriminatoires ou disproportionnés, mais la mécanique fine reste hors de portée. L’*archicration est ouverte en droit, mais entravée en fait.*
+
+### II.3.5. Topologie d’une *archicration tronquée*
+
+Si l’on replace ces *scènes judiciaires et quasi-judiciaires* dans la carte tracée par la Partie II, on obtient une image contrastée :
+
+- Par rapport aux *hypotopies* des guichets et des interfaces, les tribunaux, autorités et instances quasi-judiciaires constituent un gain net : ils *offrent des procédures, des droits, des possibilités de mise en publicité, des décisions motivées, parfois des sanctions et des réparations*.
+
+- Par rapport aux *hypertopies cratiales* des comités de gouvernance interne, ils *introduisent un élément extérieur, une mise en cause par des acteurs qui ne participent pas à la conception de Système F et peuvent, au moins en partie, l’obliger à se justifier*.
+
+Mais ces scènes portent les marques d’une *archicration tronquée* :
+
+- tronquée vers l’amont, faute d’un accès systématique aux choix de design, aux fonctions de coût et aux jeux de données qui structurent Système F ;
+
+- tronquée vers l’aval, car les décisions de justice ou les recommandations quasi-judiciaires n’entraînent pas toujours une transformation profonde et durable des systèmes, mais plutôt des ajustements circonscrits, des promesses de réforme, des mesures de compensation.
+
+Topologiquement, elles occupent une position intermédiaire entre l’*hypotopie* et la *synchrotopie* : des scènes fortes, mais fragmentaires ; des moments d’*archicration*, mais sans la continuité ni la profondeur nécessaires pour transformer l’ensemble de la configuration archicratique de Système F.
+
+C’est sur cette base que la synthèse topologique (II.4) pourra être conduite : en montrant comment, entre les *hypotopies locales*, les *hypertopies cratiales* et ces *archicrations partielles*, se dessine un paysage où la scène n’est ni absente ni pleinement instituée, mais morcelée, déphasée, décalée par rapport aux lieux où la régulation algorithmique déploie effectivement ses effets.
+
+## II.4. Synthèse topologique
+
+L’épreuve de détectabilité avait permis de montrer comment Système F distribue, dans ses différents segments, *arcalités déclarées et implicites*, *cratialités en chaîne* et *archicrations lacunaires*. L’épreuve topologique révèle maintenant que cette distribution n’est pas homogène : elle prend la forme d’une dégradation structurée de la scène. Si l’on reprend les catégories introduites au chapitre 1 – synchrotopies, hypotopies, hypertopies, atopies – on constate que Système F se déploie dans un espace où la synchrotopie archicratique (scènes tenues, denses en prises, ouvertes à des publics pluriels) est quasiment absente, tandis que trois configurations dominent :
+
+- *aux points de contact avec les personnes affectées* (guichets, interfaces, formulaires de recours, feedbacks), des *hypotopies* et des *atopies* : scènes pauvres en prises sur la régulation algorithmique, ou pseudo-scènes où l’on joue la participation sans prise réelle sur Système F ;
+
+- *au centre de gravité organisationnel* (comités de pilotage, boards techniques, cellules de gouvernance de l’IA, unités de conformité), des *hypertopies cratiales* : scènes très denses en prises, mais fermées, réservées à des cercles d’experts et de décideurs ;
+
+- dans les *arènes de mise en cause* (tribunaux, autorités, instances quasi-judiciaires), des *archicrations partielles* : scènes fortes mais fragmentaires, où Système F apparaît souvent en silhouette, faute d’accès complet à sa *cratialité*.
+
+Autrement dit, le système IA typifié par Système F est bien un dispositif scénique, mais topologiquement dégradé. La scène n’a pas disparu ; elle a été déplacée, concentrée, morcelée. Les *hypotopies locales* rendent la présence de Système F sensible (un refus, un classement, un retrait, une notation), sans offrir de prise pour contester la manière dont ces effets sont produits. Les *hypertopies institutionnelles* prennent en charge la “*mise en forme*” du pouvoir algorithmique (design, paramétrage, gestion des risques), mais en maintenant les publics affectés à distance. Les *scènes judiciaires et quasi-judiciaires* rouvrent ponctuellement l’espace de contestation, sans parvenir à transformer cette intermittence en régime ordinaire de comparution.
+
+Ce paysage répond exactement au diagnostic posé dans l’essai-thèse, concernant l’*autarchicratie* : un *méta-régime où la régulation tend à devenir son propre juge, où les appareils de calcul, de standardisation et de pilotage se ferment sur eux-mêmes, en reléguant la scène – au sens démocratique – à des marges appauvries (recours individuels, formulaires, feedbacks) ou à des épisodes de crise (scandales, contentieux emblématiques).* L’IA de fondation intégrée à des chaînes de décision publiques et privées ne crée pas *ex nihilo* cette configuration ; elle intensifie des tendances déjà à l’œuvre dans les méta-régimes techno-logistique, scripturo-bureaucratique et marchand : *externalisation des arbitrages dans des infrastructures techniques*, *multiplication de points de contact sans véritable scène*, *concentration des décisions structurantes dans des cénacles spécialisés*.
+
+Du point de vue archicratique, cette topologie a deux conséquences majeures. Premièrement, elle explique pourquoi la critique de Système F oscille souvent entre deux registres incomplets : une *dénonciation des effets* (biais, injustices, opacités) *qui reste prisonnière des hypotopies locales*, et une *focalisation sur les normes juridiques et les principes éthiques dans les hypertopies de gouvernance*, sans que les deux niveaux se rencontrent vraiment dans une scène commune.
+
+Deuxièmement, elle montre que la question d’une *politique des épreuves viables*, telle que proposée dans la conclusion de la thèse, ne peut pas se réduire à ajouter des procédures ou des principes ; elle suppose un *reprofilage topologique* : épaissir certaines scènes, en ouvrir d’autres, *désaturer les hypertopies*, *relier les archicrations judiciaires aux expériences des guichets et des interfaces*.
+
+On peut résumer cette configuration sous la forme d’un tableau, qui n’est pas une grille normative, mais une carte de travail pour la suite du cas pratique :
+
+| Type de scène | Rôle pour les personnes concernées | Prise arcalité (A) | Prise cratialité (C) | Prise archicration (A’) | Type topo | Ouverture / fermeture |
+|:--:|:--:|:--:|:--:|:--:|:--:|:--:|
+| Guichet / interface de service (social, santé, justice, RH, plateformes) | Lieu où l’on dépose un dossier, consulte un statut, reçoit une réponse, subit un classement, voit un contenu disparaître ou être promu | A déclarée minimale (formules de mission, messages standard) ; A implicite invisible pour l’usager | C présente par ses effets (scores, priorités, codes couleur), mais non explicitable depuis la scène | A’ quasi absente : pas de mise en épreuve du dispositif, seulement des marges de contournement informelles | Hypotopie | Ouverte aux usagers, mais pauvre en prises sur Système F |
+| Recours numériques / feedbacks (formulaires, étoiles, “signaler”) | Lieu où l’on conteste une décision, où l’on exprime une insatisfaction, où l’on “note” un service ou un contenu | A réduite à des catégories pré-codées (“motifs de recours”, items de satisfaction) | C sollicitée comme capteur (les *feedbacks* alimentent Système F), mais non exposée comme telle | A’ fantomatique : l’idée de scène est mise en forme, sans garantie de remontée vers les lieux de décision | Hypotopie / Atopie | Ouverte, mais trajectoires des contributions opaques, pouvoir réel incertain |
+| Comités de projet, boards techniques, gouvernance “IA responsable”, conformité AI Act | Lieux où se décident les cas d’usage, les architectures, les proxies, les seuils, les stratégies de déploiement, la gestion des risques | A explicite (principes internes, matrices de risques, traductions locales de normes éthiques et juridiques) | C centrale : design du modèle, choix des données, paramétrage, intégration dans les procédures | A’ potentielle mais capturée : débats et arbitrages internes, sans présence directe des publics affectés | Hypertopie cratiale | Fermée, réservée à des experts et décideurs, forte capacité de décision |
+| Scènes judiciaires et quasi-judiciaires (tribunaux, autorités, régulateurs, Oversight Board) | Lieux où l’on conteste des effets de Système F (refus, discriminations, censures), où des obligations sont interprétées et imposées | A reconstituée a posteriori : qualification juridique, examen des finalités, rappel des droits fondamentaux | C partiellement accessible : éléments techniques communiqués par fragments, sous contraintes de secret et de compétence | A’ réelle mais tronquée : procédure contradictoire, décisions motivées, sans accès systématique à l’ensemble de la chaîne cratiale | Entre hypotopie et synchrotopie | Semi-ouverte : accès conditionné, forte institutionnalisation, capacité d’inflexion mais intermittente |
+
+Ce tableau ne remplace pas l’analyse, il la condense. Il fait apparaître, d’un seul coup d’œil, le motif central : Système F s’inscrit dans un régime où les *scènes ouvertes aux personnes concernées sont topologiquement appauvries* (*hypotopies* et *atopies*), tandis que les *scènes riches en prises se trouvent concentrées dans des hypertopies cratiales et régulatoires qui restent largement hors de leur portée*. Les *scènes judiciaires et quasi-judiciaires* jouent un rôle d’*intermédiation*, mais sans parvenir, dans l’état actuel des choses, à recomposer une *synchrotopie archicratique co-viable*.
+
+Cette carte topologique ne surgit pas de nulle part : elle condense des motifs déjà repérés dans les méta-régimes techno-logistique, scripturo-bureaucratique et marchand. La Partie III se donnera précisément pour tâche de replacer Système F dans cette archéogénèse, afin de montrer que l’IA n’inaugure pas un monde entièrement nouveau, mais recombine des puissances régulatrices déjà à l’œuvre – en les poussant vers un méta-régime *autarchicratique numérique*.
+
+La suite du cas pratique pourra s’appuyer sur cette synthèse topologique pour deux mouvements complémentaires : replacer ce paysage dans l’*archéogénèse des méta-régimes régulateurs* (Partie III), puis explorer ce que signifierait, concrètement, une réouverture archicratique de Système F, c’est-à-dire une transformation simultanée des prises (A/C/A’) et des lieux (topologie scénique) dans lesquels se joue sa puissance régulatrice.
+
+##