Refactor: Backend Frontend-Centric Auth - Suppression OIDC, validation JWT

Architecture modifiée pour Frontend-Centric Authentication:

1. **Suppression des dépendances OIDC**
   - quarkus-oidc → quarkus-smallrye-jwt
   - quarkus-keycloak-authorization → quarkus-smallrye-jwt-build
   - Le backend ne gère plus l'authentification OAuth

2. **Configuration JWT simple**
   - Validation des tokens JWT envoyés par le frontend
   - mp.jwt.verify.publickey.location (JWKS de Keycloak)
   - mp.jwt.verify.issuer (Keycloak realm)
   - Authentification via Authorization: Bearer header

3. **Suppression configurations OIDC**
   - application.properties: Suppression %dev.quarkus.oidc.*
   - application.properties: Suppression %prod.quarkus.oidc.*
   - application-prod.properties: Remplacement par mp.jwt.*
   - Logging: io.quarkus.oidc → io.quarkus.smallrye.jwt

4. **Sécurité simplifiée**
   - quarkus.security.auth.proactive=false
   - @Authenticated sur les endpoints
   - CORS configuré pour le frontend
   - Endpoints publics: /q/*, /openapi, /swagger-ui/*

Flux d'authentification:
1️⃣ Frontend → Keycloak (OAuth login)
2️⃣ Frontend ← Keycloak (access_token)
3️⃣ Frontend → Backend (Authorization: Bearer token)
4️⃣ Backend valide le token JWT (signature + issuer)
5️⃣ Backend → Frontend (données API)

Avantages:
✅ Pas de secret backend à gérer
✅ Pas de client btpxpress-backend dans Keycloak
✅ Séparation claire frontend/backend
✅ Backend devient une API REST stateless
✅ Tokens gérés par le frontend (localStorage/sessionStorage)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

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

ANALYSE_CONTROLLERS.md

@@ -0,0 +1,60 @@
+# 📋 ANALYSE DES CONTROLLERS DANS presentation/controller
+
+**Date** : 2025-10-29  
+**Status** : Analyse en cours
+
+---
+
+## 🎯 RÉSUMÉ
+
+Les controllers dans `presentation/controller/` utilisent les mêmes patterns que les Resources dans `adapter/http/`, mais semblent être des doublons ou des versions anciennes.
+
+### Controllers identifiés :
+1. `StockController.java` - `/api/v1/stocks` ❌ Pas de StockResource dans adapter/http
+2. `BonCommandeController.java` - `/api/v1/bons-commande` ❌ Pas de BonCommandeResource dans adapter/http
+3. `ChantierController.java` - `/api/v1/chantiers` ⚠️ **DOUBLON** : ChantierResource existe déjà dans adapter/http
+4. `MaterielController.java` - `/api/v1/materiels` ⚠️ **DOUBLON** : MaterielResource existe déjà dans adapter/http
+5. `EmployeController.java` - `/api/v1/employes` ⚠️ À vérifier si EmployeResource existe
+6. `EquipeController.java` - `/api/v1/equipes` ❌ À vérifier
+7. `PhaseChantierController.java` - `/api/v1/phases-chantier` ❌ À vérifier
+
+---
+
+## 🔍 PLAN D'ACTION RECOMMANDÉ
+
+### Option 1 : Migration vers adapter/http (RECOMMANDÉ)
+- **StockController** → Créer `StockResource.java` dans `adapter/http/`
+- **BonCommandeController** → Créer `BonCommandeResource.java` dans `adapter/http/`
+- **EmployeController** → Vérifier si doublon ou migrer
+- **EquipeController** → Vérifier si doublon ou migrer
+- **PhaseChantierController** → Vérifier si doublon ou migrer
+
+### Option 2 : Supprimer les doublons
+- **ChantierController** → ❌ SUPPRIMER (ChantierResource existe)
+- **MaterielController** → ❌ SUPPRIMER (MaterielResource existe)
+
+---
+
+## ⚠️ RISQUES
+
+1. **Endpoints en double** : Si on garde les deux, Quarkus peut lever des erreurs de routes dupliquées
+2. **Incohérences** : Les controllers peuvent avoir une logique différente des Resources
+3. **Maintenance** : Avoir deux implémentations est source de confusion
+
+---
+
+## 📝 ACTION IMMÉDIATE
+
+**PRIORITÉ P0** : 
+- ✅ Analyser les différences entre ChantierController et ChantierResource
+- ✅ Analyser les différences entre MaterielController et MaterielResource
+- ✅ Décider : migrer ou supprimer
+
+**PRIORITÉ P1** :
+- Créer StockResource dans adapter/http (si StockController a une logique utile)
+- Créer BonCommandeResource dans adapter/http (si BonCommandeController a une logique utile)
+
+---
+
+**Status** : ⏸️ En attente de décision
+