auto_clea

tests

@@ -0,0 +1 @@
+/home/debian/4NK_env/tests/lecoffre-front

tests/analyse.md

@@ -1,27 +0,0 @@
-### Objet
-Axes de tests pour `lecoffre-front` (sans exemples d’implémentation).
-
-### Couverture prioritaire
-- **Routage**: accessibilité des pages clés sous `basePath` `/lecoffre`
-- **Auth**: parcours login client et callbacks (Id360/IdNot)
-- **Tableau client**: chargement données, états vides, erreurs
-- **Dossiers/Documents**: création/affichage, téléchargements, filigrane
-- **Souscription**: parcours complet (erreur/succès/gestion)
-- **Notifications/Toasts**: affichage cohérent des erreurs
-
-### Données et intégrations
-- **API Back**: validation des URL via `NEXT_PUBLIC_BACK_API_*` et `NEXT_PUBLIC_API_URL`
-- **IdNot Auth**: vérifier que l’appel se fait en POST `/api/v1/idnot/auth` avec `{ code }` dans le corps, et qu’aucune URL longue n’est utilisée.
-- **Idnot/Docaposte**: vérification des redirections et scopes
-
-### Non-régressions UI/UX
-- **DesignSystem**: composants critiques (boutons, tabs, formulaires)
-- **Accessibilité**: focus, contrastes, navigation clavier
-
-### Performance
-- **Chargement initial**: taille bundle avec `React.lazy`/`Suspense` si applicable
-- **Rendu**: éviter re-renders via stores et mémoïsations locales
-
-### Sécurité
-- **Données sensibles**: absence de secrets dans `NEXT_PUBLIC_*`
-- **JWT**: décodage côté client limité aux besoins

tests/ci.md

@@ -1,32 +0,0 @@
-### Plan de tests CI/CD
-
-Ce document liste les scénarios de test pour valider la chaîne CI/CD décrite dans `docs/ci.md`.
-
-### Pré-requis
-
-- Accès au registre Scaleway avec droits de push/pull.
-- Accès au cluster Kubernetes `lecoffre` et à Vault (lecture des chemins référencés).
-- BuildKit activé et agent SSH opérationnel pour l’accès `git.4nkweb.com`.
-
-### Tests de build
-
-- Vérifier l’installation des dépendances avec accès SSH aux ressources privées.
-- Exécuter `npm run build` et confirmer la génération sans erreurs.
-
-### Tests d’image Docker
-
-- Construire l’image avec le forward SSH.
-- Valider la taille, les couches, l’utilisateur non-root, et l’exécution `npm run start`.
-- Pousser l’image taguée (ex. `ext`) vers le registry `git.4nkweb.com` et vérifier la présence.
-
-### Tests Kubernetes
-
-- Appliquer les manifests/Helm sur un environnement de test.
-- Valider la création de l’`ExternalSecret` et du `imagePullSecret`.
-- Vérifier que le `Deployment` démarre, que Vault injecte les variables, et que le `Service` et `Ingress` sont fonctionnels.
-- Vérifier que `NEXT_PUBLIC_4NK_URL` (origin) et `NEXT_PUBLIC_4NK_IFRAME_URL` (URL complète) sont bien injectées au build (présentes dans `/lecoffre-front/.next/standalone/.env` ou via `next.config.js`) et cohérentes avec l’iframe réellement servie.
-
-### Observabilité et rollback
-
-- Vérifier les logs d’injection Vault et de l’application.
-- Tester un rollback d’image (retag vers version précédente) et vérifier la restauration.

tests/ext.md

@@ -1,28 +0,0 @@
-### Tests image "ext"
-
-Objectif: vérifier que l'image démarre et que les URLs d'API proviennent des variables d'environnement.
-
-Plan de test manuel:
-
-1. Vérifier l'injection des variables NEXT_PUBLIC_*
-
-```
-docker pull git.4nkweb.com/4nk/lecoffre-front:ext
-docker run --rm git.4nkweb.com/4nk/lecoffre-front:ext sh -lc "env | grep '^NEXT_PUBLIC_' | sort"
-```
-
-Attendus (exemples):
-- `NEXT_PUBLIC_4NK_URL`, `NEXT_PUBLIC_4NK_IFRAME_URL` définies
-- `NEXT_PUBLIC_API_URL` et `NEXT_PUBLIC_BACK_API_*` cohérentes
-
-2. Vérifier que l'app démarre
-
-```
-docker run --rm -p 3001:3000 git.4nkweb.com/4nk/lecoffre-front:ext
-# Ouvrir http://localhost:3001/lecoffre
-```
-
-Critères de réussite:
-
-- Le conteneur écoute sur 3000 et répond.
-- Les URLs d'API proviennent des variables d'environnement.