ci: correction syntaxe Woodpecker (.woodpecker.yml)

- Suppression des headers Drone CI (kind/type/name)
- Déplacement du trigger when: au niveau global
- Volumes inline (host:container) au lieu des named volumes
- Suppression de la section volumes: Drone en bas de fichier
- Correction $$ → $ pour les variables dans les commandes
- Chaînage des cd avec && pour les commandes radar-app
- Image docker:27-cli cohérente avec le modèle de référence

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

.woodpecker.yml

@@ -1,207 +1,66 @@
----
-kind: pipeline
-type: docker
-name: build-and-deploy
-
-# Ce pipeline Woodpecker CI automatise le build et le déploiement de l'application statique
-# Il se déclenche automatiquement sur chaque push vers les branches main ou stand-alone
+when:
+  - branch:
+      - main
+      - stand-alone
+    event: push
 
 steps:
-  # ============================================
-  # ÉTAPE 1: BUILD DE L'APPLICATION STATIQUE
-  # ============================================
-  # Cette étape construit l'application Next.js et génère les fichiers statiques HTML/CSS/JS
-  - name: build
-    # Image Docker utilisée : Node.js 20 sur Alpine Linux (légère et rapide)
-    image: node:20-alpine
-    
-    # Variables d'environnement nécessaires pour le build
-    environment:
-      NODE_ENV: production        # Mode production (optimisations activées)
-      HUSKY: 0                    # Désactive Husky (git hooks) pour éviter les erreurs
-      HUSKY_SKIP_INSTALL: 1       # Skip l'installation de Husky
-    
-    # Commandes exécutées dans l'ordre
-    commands:
-      # Installation des dépendances système nécessaires
-      # - git : pour cloner/récupérer des dépendances si nécessaire
-      # - python3 : requis pour les scripts de patch (patch_document.py, add_team_link.py)
-      - apk add --no-cache git python3
-      
-      # Installation des dépendances Node.js de la racine du projet
-      # npm ci : Clean Install (supprime node_modules et réinstalle depuis package-lock.json)
-      # --legacy-peer-deps : Ignore les conflits de dépendances peer (compatibilité)
-      - npm ci --legacy-peer-deps
-      
-      # Installation des dépendances de radar-app/ (le framework Next.js vendu)
-      # On se déplace dans le dossier radar-app pour installer ses dépendances
-      - cd radar-app
-      
-      # Installation des dépendances de radar-app (y compris devDependencies)
-      # --include=dev : Inclut les dépendances de développement (tsx, eslint, etc.)
-      - npm ci --legacy-peer-deps --include=dev
-      
-      # Build des icônes SVG en composants React TypeScript
-      # Ce script génère les composants Icons depuis les fichiers SVG dans src/icons/
-      - npm run build:icons
-      
-      # Retour à la racine du projet
-      - cd ..
-      
-      # Génération des données de visualisation équipe
-      # Ce script lit les profils dans docs/data/team/*.md et les technologies
-      # Il génère public/team-visualization-data.json utilisé par la page /team
-      - node scripts/generate-team-visualization-data.js
-      
-      # Build de l'application complète
-      # Ce script (build-radar.js) :
-      # 1. Copie config-business.json vers radar-app/data/config.json
-      # 2. Copie radar-business/2025-01-15/ vers radar-app/data/radar/2025-01-15/
-      # 3. Copie public/* vers radar-app/public/
-      # 4. Applique les patches (team page, _document, Navigation)
-      # 5. Lance npm run build:data puis npm run build dans radar-app/
-      # 6. Copie radar-app/out/ vers build/ à la racine
-      - npm run build
-      
-      # Vérification que le build a réussi
-      # Affiche les 10 premiers fichiers du dossier build/ pour vérifier la génération
-      - ls -la build/ | head -10
-    
-    # Volumes temporaires pour accélérer les builds suivants
-    # Ces volumes persistent les node_modules entre les étapes pour éviter de réinstaller
-    volumes:
-      - name: node_modules_root
-        path: /app/node_modules
-      - name: node_modules_radar_app
-        path: /app/radar-app/node_modules
 
-  # ============================================
-  # ÉTAPE 2: DÉPLOIEMENT VIA RSYNC (OPTIONNEL)
-  # ============================================
-  # Cette étape synchronise les fichiers statiques vers un serveur web distant
-  # Utile si vous avez un serveur Nginx/Apache qui sert des fichiers statiques
+  # Etape 1 : Build de l'application statique
+  - name: build
+    image: node:20-alpine
+    environment:
+      NODE_ENV: production
+      HUSKY: 0
+      HUSKY_SKIP_INSTALL: 1
+    commands:
+      - apk add --no-cache git python3
+      - npm ci --legacy-peer-deps
+      - cd radar-app && npm ci --legacy-peer-deps --include=dev && npm run build:icons && cd ..
+      - node scripts/generate-team-visualization-data.js
+      - npm run build
+      - ls -la build/ | head -10
+
+  # Etape 2a : Deploiement via rsync (optionnel — choisir rsync OU docker, pas les deux)
   - name: deploy-rsync
-    # Image Alpine (légère) avec rsync et SSH
     image: alpine:latest
-    
-    # Variables d'environnement récupérées depuis les secrets Woodpecker
     environment:
       DEPLOY_HOST:
-        from_secret: deploy_host      # Exemple: techradar.example.com
+        from_secret: deploy_host
       DEPLOY_USER:
-        from_secret: deploy_user      # Exemple: deploy
+        from_secret: deploy_user
       DEPLOY_PATH:
-        from_secret: deploy_path      # Exemple: /var/www/techradar
+        from_secret: deploy_path
       DEPLOY_KEY:
-        from_secret: deploy_key       # Clé privée SSH complète
-    
+        from_secret: deploy_key
     commands:
-      # Installation des outils nécessaires
       - apk add --no-cache openssh-client rsync
-      
-      # Création du dossier .ssh pour les clés SSH
       - mkdir -p ~/.ssh
-      
-      # Écriture de la clé privée SSH dans le fichier id_rsa
-      # $$ est échappé pour éviter l'interpolation par le shell
-      - echo "$$DEPLOY_KEY" > ~/.ssh/id_rsa
-      
-      # Protection de la clé privée (lecture/écriture uniquement pour le propriétaire)
+      - echo "$DEPLOY_KEY" > ~/.ssh/id_rsa
       - chmod 600 ~/.ssh/id_rsa
-      
-      # Ajout de la clé publique du serveur dans known_hosts
-      # Évite la vérification manuelle lors de la première connexion
-      - ssh-keyscan -H $$DEPLOY_HOST >> ~/.ssh/known_hosts || true
-      
-      # Synchronisation des fichiers
-      # rsync -avz : Archive mode, Verbose, Compression
-      # --delete : Supprime les fichiers sur le serveur qui n'existent plus localement
-      # build/ : Source (dossier build généré à l'étape précédente)
-      # $$DEPLOY_USER@$$DEPLOY_HOST:$$DEPLOY_PATH/ : Destination (serveur distant)
-      - rsync -avz --delete build/ $$DEPLOY_USER@$$DEPLOY_HOST:$$DEPLOY_PATH/
-      
-      # Message de confirmation
-      - echo "✅ Déploiement terminé sur $$DEPLOY_HOST:$$DEPLOY_PATH"
-    
-    # Conditions de déclenchement
-    # Cette étape ne s'exécute que si :
-    when:
-      branch:
-        - main        # Sur la branche main
-        - stand-alone # Ou sur la branche stand-alone
-      event:
-        - push        # Et uniquement sur un événement push (pas sur les PR)
+      - ssh-keyscan -H $DEPLOY_HOST >> ~/.ssh/known_hosts || true
+      - rsync -avz --delete build/ $DEPLOY_USER@$DEPLOY_HOST:$DEPLOY_PATH/
+      - echo "Deploiement termine sur $DEPLOY_HOST:$DEPLOY_PATH"
 
-  # ============================================
-  # ÉTAPE 3: DÉPLOIEMENT DOCKER (RECOMMANDÉ)
-  # ============================================
-  # Cette étape build et déploie l'application via Docker
-  # Plus simple et reproductible que rsync
+  # Etape 2b : Deploiement via Docker Compose (recommande)
   - name: deploy-docker
-    # Image Docker officielle avec docker-compose
-    image: docker:latest
-    
-    # Configuration Docker
-    environment:
-      DOCKER_HOST: unix:///var/run/docker.sock  # Socket Docker du serveur Woodpecker
-    
-    commands:
-      # Installation de docker-compose
-      - apk add --no-cache docker-compose
-      
-      # Build de l'image Docker sans cache
-      # --no-cache : Force un rebuild complet (garantit que tout est à jour)
-      # docker-compose.business.yml : Fichier de configuration Docker Compose
-      - docker compose -f docker-compose.business.yml build --no-cache
-      
-      # Démarrage du conteneur en mode détaché
-      # -d : Détaché (en arrière-plan)
-      # up : Crée et démarre les conteneurs
-      - docker compose -f docker-compose.business.yml up -d
-      
-      # Vérification que le conteneur tourne
-      # Affiche les conteneurs contenant "laplank-radar" ou un message si non trouvé
-      - docker ps | grep laplank-radar || echo "Conteneur non trouvé"
-    
-    # Volume pour accéder au socket Docker du serveur
-    # Nécessaire pour que le conteneur puisse utiliser Docker
+    image: docker:27-cli
     volumes:
-      - name: dockersock
-        path: /var/run/docker.sock
-    
-    # Conditions de déclenchement (identique à deploy-rsync)
-    when:
-      branch:
-        - main
-        - stand-alone
-      event:
-        - push
+      - /var/run/docker.sock:/var/run/docker.sock
+    commands:
+      - docker compose -f docker-compose.business.yml build --no-cache
+      - docker compose -f docker-compose.business.yml up -d --remove-orphans
+      - docker compose -f docker-compose.business.yml ps | grep laplank-radar || echo "Conteneur non trouve"
 
-  # ============================================
-  # ÉTAPE 4: NOTIFICATION TELEGRAM
-  # ============================================
-  # Cette étape envoie une notification Telegram à la fin du pipeline
-  # Utile pour être informé immédiatement du résultat du build
+  # Etape 3 : Notification Telegram
   - name: notify
-    # Plugin Drone/Woodpecker pour Telegram
-    # Compatible avec Woodpecker (fork de Drone)
     image: appleboy/drone-telegram
-    
-    # Configuration du plugin Telegram
     settings:
       token:
-        from_secret: telegram_token      # Token du bot Telegram
+        from_secret: telegram_token
       to:
-        from_secret: telegram_chat_id_ajr # ID du chat Telegram (destinataire)
-      format: markdown                    # Format du message (Markdown supporté)
-      
-      # Message personnalisé avec template Woodpecker
-      # {{#success build.status}} : Condition si le build a réussi
-      # {{repo.name}} : Nom du dépôt Git
-      # {{commit.branch}} : Branche du commit
-      # {{commit.message}} : Message du commit
-      # {{commit.author}} : Auteur du commit
-      # {{build.link}} : Lien vers le build dans Woodpecker
+        from_secret: telegram_chat_id_ajr
+      format: markdown
       message: >
         {{#success build.status}}
         ✅ Build réussi pour `{{repo.name}}` sur la branche `{{commit.branch}}`
@@ -214,32 +73,7 @@ steps:
         👤 Auteur: {{commit.author}}
         🔗 {{ build.link }}
         {{/success}}
-    
-    # Conditions de déclenchement
-    # S'exécute toujours, que le build réussisse ou échoue
     when:
-      status:
-        - success  # Si le build réussit
-        - failure  # Si le build échoue
-
-# ============================================
-# VOLUMES TEMPORAIRES
-# ============================================
-# Ces volumes sont créés temporairement pour chaque pipeline
-# Ils permettent de partager des données entre les étapes
-volumes:
-  # Volume pour les node_modules de la racine
-  # Persiste entre les étapes pour éviter de réinstaller
-  - name: node_modules_root
-    temp: {}  # Volume temporaire (supprimé à la fin du pipeline)
-  
-  # Volume pour les node_modules de radar-app
-  # Persiste entre les étapes pour éviter de réinstaller
-  - name: node_modules_radar_app
-    temp: {}
-  
-  # Volume pour accéder au socket Docker du serveur
-  # Nécessaire pour que les conteneurs puissent utiliser Docker
-  - name: dockersock
-    host:
-      path: /var/run/docker.sock  # Chemin du socket Docker sur le serveur
+      - status:
+          - success
+          - failure