fix

.gitea/actionlint.yaml

@@ -1,3 +1,2 @@
-self-hosted-runner:
-  labels:
-    - xpeditis-deploy
+# All jobs use the existing ubuntu-latest runner label.
+{}

.gitea/workflows/cd-main.yml

@@ -248,9 +248,8 @@ jobs:
   # ═══ 4. Déploiement ══════════════════════════════════════════════════════
   deploy:
     name: Déployer en production
-    runs-on: xpeditis-deploy
+    runs-on: ubuntu-latest
     needs: [verify-image, build-frontend, image-security]
-    # Gitea 1.22 ignores environments: serialize on the dedicated deployment runner.
     steps:
       - uses: https://github.com/actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4
         with:

.gitea/workflows/cd-preprod.yml

@@ -329,7 +329,7 @@ jobs:
   # ── 5. Deploy via Portainer ──────────────────────────────────────────
   deploy:
     name: Deploy to Preprod
-    runs-on: xpeditis-deploy
+    runs-on: ubuntu-latest
     needs: [build-backend, build-frontend, build-log-exporter, image-security]
     steps:
       - uses: https://github.com/actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4

docs/CI-CD-SECURITY.md

@@ -80,12 +80,14 @@ comme des protections effectives dans les workflows adaptés.
    Docker. Les builds multiarchitecture ont besoin du support QEMU/binfmt.
    Les services d'intégration sont joints via `postgres` et `redis`, sans ports
    hôte fixes ; un runner en mode host n'est pas la cible de ces workflows.
-2. Enregistrer **un seul runner** avec le label **`xpeditis-deploy`**, une capacité
-   **1**, et une limite d'exécution adaptée (par exemple 1 h). Les deux jobs de
-   déploiement utilisent ce label : publication des alias, déploiement, santé et
-   fermeture du firewall restent dans le même job. Ne pas donner ce label à
-   plusieurs runners. Le runner doit être isolé des jobs de PR et disposer de
-   Docker, Git, curl, SSH et rsync. Sans ce runner, les déploiements restent en attente.
+2. Les déploiements préprod et production utilisent le runner existant avec le
+   label **`ubuntu-latest`**, comme les builds et les audits. Aucun runner dédié
+   `xpeditis-deploy` n'est nécessaire. Ce runner doit aussi disposer de SSH et
+   rsync pour le déploiement de production. Gitea 1.22 ne prenant pas en charge
+   `concurrency`, les workflows ne garantissent pas la sérialisation des
+   déploiements si les runners autorisent plusieurs jobs simultanés.
+   Pour éviter les chevauchements, attendre la fin d'un déploiement avant de
+   déclencher le suivant sur le même environnement.
 3. Protéger `dev`, `preprod`, `main` dans les réglages de branches Gitea : interdire
    les push directs/force-push et exiger **Security gate**, les deux contrôles
    qualité et les deux tests unitaires ; ajouter l'intégration pour preprod/main.