Accueil

DeVs

Liste des choses à faire — qualité, tests, perf, maintenabilité

Vue dev / test

Objectifs de test (métier, API, flux, perf, sécurité) — statut couvert / non couvert

Structure type d’une agence de logement social

Référence métier pour les rôles et périmètres. Le Copilot CRC est le point d’entrée du Pôle 1 (Relation Client) ; il s’interface avec le Pôle 3 (Technique & Patrimoine) via les affaires et prestataires.

  • 1. Relation Client (Front Office) — CRC, accueil physique ; qualification, diagnostic, historisation. → Couvert par l’app.
  • 2. Gestion Locative & Sociale — CALEOL, baux, avenants, SLS, CESF. → Hors périmètre actuel.
  • 3. Technique & Patrimoine — Gardiens, maintenance, prestataires, GER. → Affaires / prestataires dans l’app.
  • 4. Gestion Financière & Prévention — Impayés, contentieux, charges. → Hors périmètre actuel.

Détail : STRUCTURE_AGENCE_LOGGEMENT_SOCIAL.md à la racine du projet.

Sécurité & accès (RBAC)

Auth (qui es-tu) : Clerk / Auth0 / Supabase + SSO. Autorisation (qu’as-tu le droit de faire) : rôles (Conseiller CRC, Gestionnaire Technique, Contentieux, Gardien, Admin) avec accès et actions définis. Multi-tenancy : cloisonnement par agency_id (et sector_id pour les gardiens). Middleware : Token → Périmètre → Droit.

Documentation complète : SECURITE_RBAC.md à la racine. Schéma SQL et types TS : docs/schema-securite.sql, frontend/app/types/user-rbac.ts.

Workflow CI/CD (norme industrielle)

On ne touche jamais au serveur de prod directement. Pipeline en place :

  1. Local — Vous codez sur votre PC (ou sur une branche de test).
  2. GitHub — Vous pushez votre code (git push).
  3. Automation (GitHub Actions) — Le code est testé automatiquement (lint, tests Vitest, build). S'il n'y a pas d'erreur, le build est prêt pour déploiement ; l'étape de déploiement vers le serveur est à activer dans .github/workflows/ci.yml.

Fichier : .github/workflows/ci.yml. Déclenché sur push/PR vers main ou master.

Configuration serveur & capacité données

Configuration optimale

  • Node.js 18+ (LTS recommandé)
  • RAM 512 Mo min. (1 Go conseillé pour build + runtime)
  • CPU 1 vCPU min. (2 pour build plus rapide)
  • Next.js 14.x — build : npm run build, démarrage : npm run start
  • API données (json-server ou BDD) : CORS activé, même domaine ou env NEXT_PUBLIC_JSON_SERVER_URL
  • Niveau log WARN ou ERROR en prod (éviter DEBUG)

Données que le code peut encaisser

  • Locataires : testé jusqu’à ~50k en objectif (checklist) ; avec json-server, rester raisonnable (quelques milliers) ; en prod avec BDD + pagination/index : bien plus.
  • Patrimoine : agences → résidences → bâtiments → entrées → logements chargés à la demande (pas de chargement global) ; pas de limite stricte côté front.
  • Affaires : liste en mémoire (state) ; recommandation : pagination côté API au-delà de quelques milliers.
  • Conseil : indexer les champs de recherche (nom, prénom, tél.), utiliser ?limit= sur les listes pour garder de bonnes perfs.

15 conseillers en flux d’appel continu — ça tient la route ?

Oui. Chaque conseiller = une session navigateur indépendante (state local, CTI/Kiamo par poste). L’app ne gère pas d’état serveur partagé entre conseillers : pas de file d’attente côté app, pas de limite logicielle au nombre de connexions simultanées.

  • Serveur : prévoir ~15 connexions HTTP simultanées (pages + appels API). RAM 1 Go peut suffire ; 2 Go conseillé pour confort (build + 15× runtime). Pas de WebSocket côté app (CTI = Kiamo côté client).
  • API données : 15 requêtes parallèles possibles (recherche locataire, GET affaires, patrimoine). Avec json-server : surveiller la charge ; avec BDD (PostgreSQL, etc.) : pool de connexions ≥ 20 recommandé.
  • Kiamo / CTI : une session par agent (gérée par la plateforme Kiamo), pas de limite côté CRC. Le flux d’appel continu est géré par le central téléphonique et Kiamo, pas par cette app.
  • À valider : test en charge avec 15 onglets ou 15 postes (recherche + fiche + création affaire en parallèle) pour ajuster RAM/CPU et paramètres API si besoin.

400 collaborateurs, accès à des données différentes

Oui, à condition de filtrer les données côté API selon le collaborateur (agence, rôle, périmètre). L’app ne gère pas encore l’authentification ni les droits par utilisateur ; la structure des données (agences, résidences par agence) permet d’alimenter des vues différentes selon qui se connecte.

  • Données différentes : patrimoine déjà structuré par agence (agenceId sur les résidences). L’API (ou BDD) doit exposer des endpoints ou des filtres par agence/rôle (ex. /residences?agenceId=X) et n’envoyer que les données autorisées pour l’utilisateur connecté.
  • Auth / droits : à mettre en place côté serveur (auth + règles métier : quel collaborateur voit quelles agences, quels locataires). Le front consomme des données déjà filtrées ; pas de liste globale « 400 utilisateurs » côté app.
  • Charge : 400 comptes ≠ 400 connexions simultanées. Dimensionner pour des pics réalistes (ex. 50–100 connexions en parallèle). Serveur : 4 Go RAM, 2 vCPU recommandés pour ce volume ; BDD avec pool de connexions adapté (ex. 50–100).
  • Résumé : l’architecture (Next + API filtrée par périmètre) supporte 400 collaborateurs avec des données différentes, dès lors que l’API applique les règles d’accès et que l’infra est dimensionnée pour les pics de connexion.

Authentification en local ou externe ? — 50 collaborateurs (15 conseillers, 2 managers, 1 support, personnel agence)

En local, ça ne sera pas « lourd » côté technique (50 comptes, quelques rôles) : une table utilisateurs + sessions en BDD, un cookie JWT ou session ID, ça tient très bien. Ce qui devient lourd, c’est la gestion opérationnelle : mots de passe oubliés, MFA, audit des accès, montée en charge des rôles (conseiller / manager / support / agence) et des périmètres (agences différentes).

  • Démarrer en local : possible pour 50 utilisateurs. Backend (ou Next API routes) : table users (id, email, role, agenceId, hash mot de passe), table sessions ou JWT. Règles d’accès (qui voit quelles agences) dans l’API. Charge serveur négligeable pour 50 comptes.
  • À partir de 50 + plusieurs rôles : un IdP externe (SSO) est souvent plus rentable : Keycloak, Auth0, Azure AD, Google Workspace… Gestion des comptes, MFA, révoquation et audit centralisés. L’app reçoit un token (JWT) ou une session après redirection ; elle n’a plus à gérer les mots de passe. Moins de code, moins de risque, moins de « lourd » en local.
  • Recommandation : pour 50 collaborateurs (15 conseillers flux continu, 2 managers, 1 support, personnel agence), on peut commencer en local (auth simple + rôles) pour valider le métier, puis migrer vers un SSO quand la structure (rôles, agences, périmètres) est stabilisée. Si vous avez déjà un annuaire (AD, Google, etc.), partir sur SSO dès le début évite la double gestion.

Tests & couverture

  • Écrire les tests avant le code (TDD) sur les flux critiques

    Ex. régularisation, trop-perçu 0,01€

    fait

  • Cas limites métier (solde à zéro, doublons, champs manquants)

    à faire

  • Vérifier que la couverture teste du comportement, pas du remplissage

    à faire

Qualité & cohérence

  • Rédiger / renforcer le fichier .cursorrules (métier, conventions)

    à faire

  • Utiliser les abstractions maison (API, BDD) — pas de réinvention par fichier

    à faire

  • ESLint, Prettier (ou équivalent) configurés et appliqués en CI

    à faire

  • Suivre la complexité cyclomatique (ex. CodeClimate)

    à faire

Performance & sécurité

  • Éviter le N+1 (requêtes en boucle) — pagination, batch

    à faire

  • Tester à l’échelle (ex. 50k locataires) avant prod

    à faire

  • Analyse statique sécurité (SAST) en pipeline

    à faire

  • Paramètres préparés / ORM pour toute requête SQL

    à faire

  • Sécurité importante — jetons et credentials : ne jamais partager un token (GitHub, API) en chat ni dans un fichier versionné ; révoquer immédiatement un jeton exposé ; utiliser les tokens uniquement sur le serveur ou dans des variables d'env non committées.

    à faire

    Dans le code

    Rappel : token GitHub = clone sur le VPS uniquement ; si exposé en chat → révoquer sur GitHub et en créer un nouveau. .env et secrets hors dépôt.

Maintenabilité

  • Code lisible en 30 secondes par un dev senior

    à faire

  • Fonctions courtes, nommage métier explicite

    à faire

  • Suivre le taux de rejet en code review et le MTTR sur le code IA

    à faire

Métier & fonctionnel

  • Structurer le patrimoine par agence (niveau au-dessus des sites)

    à faire

  • Remplacer json-server par une vraie BDD (PostgreSQL) en prod

    à faire

  • Typage fin des réponses Intent (proxy connexions-tiers)

    à faire

  • Synchro affaires / prestataires avec les APIs Intent si besoin

    à faire

Cette liste est indicative. À mettre à jour au fil des sprints et des revues.