Aller au contenu

Module Creation de compte

Objectif

Le module Creation de compte est un parcours d'inscription artisan separe de l'application PHP historique.

Il couvre :

  • une interface React/Vite en deux etapes ;
  • une API Node/Express dediee a l'inscription ;
  • la creation d'un membre Solutravo ;
  • la creation de la presociete artisan rattachee au membre ;
  • la notification email administrateur ;
  • la trace et le retry des notifications admin ;
  • la generation d'un jeton d'autologin ;
  • la redirection vers l'application Solutravo apres inscription ;
  • les workflows de deploiement du frontend et du backend d'inscription.

Emplacement du code

Le module a ete identifie sur les branches register/prod et register/staging.

Arborescence principale :

backend/
  app.ts
  server.ts
  src/controllers/RegisterController.ts
  src/services/RegisterService.ts
  src/services/AutoLoginTokenService.ts
  src/services/RegistrationRedirect.ts
  src/jobs/retryAdminRegistrationNotifications.ts
  src/config/env.ts
  src/config/db.ts
  src/routes/router.ts
frontend/
  src/pages/Inscription.tsx
  src/pages/Inscription.css
  src/helpers/fetchData.ts
.github/workflows/deploy-backend.yml
.github/workflows/deploy-frontend.yml

Point important : ce module n'est pas une page ajoutee dans app/views de l'application PHP. C'est une petite application autonome qui ecrit dans la meme base metier Solutravo.

Vue d'ensemble architecture

Navigateur
  |
  | POST /api/register
  v
Backend inscription Node/Express
  |
  | transaction SQL
  v
Base Solutravo
  - membres
  - presocietes
  - registration_admin_notifications
  |
  | SMTP
  v
Email administrateur

Backend inscription
  |
  | redirectUrl + token JWT court
  v
Application Solutravo
  - /connexion-microservice?token=...

Frontend

Fichier principal :

  • frontend/src/pages/Inscription.tsx

Le formulaire est decoupe en deux etapes :

  1. Connexion : email et mot de passe.
  2. Societe : nom, prenom, entreprise, taille d'entreprise, telephone.

Validation visible cote frontend :

  • telephone francais au format 0612345678, +33612345678 ou 0033612345678 ;
  • champs requis par etape ;
  • affichage d'une erreur API sous le formulaire ;
  • modal de succes apres reponse positive.

Le frontend appelle :

POST {VITE_API_BASE_URL}/register

via frontend/src/helpers/fetchData.ts.

La variable VITE_API_BASE_URL est obligatoire au demarrage du frontend. Le helper leve une erreur si elle est absente, ce qui evite de construire une URL silencieusement invalide.

Redirection apres inscription

Le frontend privilegie le redirectUrl retourne par le backend. Si un autoLoginToken est present, il force la route d'autologin :

/connexion-microservice?token=...

Sinon, il retombe sur :

/connexion?email=...

La normalisation d'origin remplace notamment :

  • auth.staging.solutravo-compta.fr par staging.solutravo-compta.fr ;
  • frontend.staging.solutravo-compta.fr par staging.solutravo-compta.fr ;
  • auth.solutravo-app.fr par app.solutravo-app.fr.

Cette logique existe aussi cote backend. En cas de reprise, maintenir les deux implementations coherentes, ou centraliser le contrat pour eviter une divergence.

Backend

Point d'entree HTTP :

  • backend/src/routes/router.ts
  • backend/src/controllers/RegisterController.ts

Route exposee :

POST /api/register

Payload attendu :

{
  "nom": "Durand",
  "prenom": "Alice",
  "email": "alice@example.com",
  "phonenumber": "0612345678",
  "name": "Entreprise Durand",
  "size": "2 a 5 personnes",
  "passe": "Motdepasse1"
}

Reponse de succes :

{
  "success": true,
  "message": "Inscription réussie, notification administrateur envoyée",
  "data": {
    "email": "alice@example.com",
    "adminNotificationSent": true,
    "adminNotificationId": 1,
    "autoLoginTokenCreated": true,
    "autoLoginToken": "...",
    "redirectUrl": "https://.../connexion-microservice?token=..."
  }
}

Regles metier d'inscription

Fichier :

  • backend/src/services/RegisterService.ts

Validations backend :

  • email obligatoire et valide ;
  • prenom obligatoire ;
  • nom obligatoire ;
  • nom d'entreprise obligatoire ;
  • telephone obligatoire ;
  • mot de passe obligatoire ;
  • mot de passe fort : au moins 8 caracteres, 1 majuscule, 1 chiffre ;
  • telephone francais normalise avant validation ;
  • email unique dans membres.

Ecritures SQL dans une transaction :

  1. verification d'absence de membre existant avec le meme email ;
  2. hash du mot de passe avec bcrypt.hash(passe, 10) ;
  3. insertion dans membres avec :
  4. type = 'membre' ;
  5. statut = 'actif' ;
  6. isVerified = 0 ;
  7. email_verification_required_at renseigne a l'heure courante UTC ;
  8. ref = UUID() ;
  9. insertion dans presocietes avec :
  10. role = 'artisan' ;
  11. membre_id rattache au membre cree ;
  12. nom, taille et telephone de l'entreprise.

La transaction est committee apres les deux insertions. En cas d'erreur, elle est rollbackee.

Codes d'erreur metier utilises :

  • 400 pour email ou champs obligatoires invalides ;
  • 409 quand l'email existe deja ;
  • 422 pour mot de passe trop faible ou telephone invalide.

Notification administrateur

Le module envoie un email admin apres creation du compte.

Variables impliquees :

SMTP_HOST
SMTP_PORT
SMTP_USER
SMTP_PASSWORD
SMTP_SECURE
REGISTER_EMAIL_SENDER
REGISTER_EMAIL_SENDER_NAME
REGISTER_EMAIL_REPLY_TO
REGISTER_EMAIL_LOGO_URL
REGISTER_ADMIN_NOTIFICATION_EMAIL
REGISTER_ADMIN_NOTIFICATION_SUBJECT
REGISTER_ADMIN_NOTIFICATION_MAX_ATTEMPTS
REGISTER_ADMIN_NOTIFICATION_RETRY_DELAY_MINUTES
REGISTER_ADMIN_NOTIFICATION_RETRY_LIMIT

Avant l'envoi, le service cree une trace en base dans registration_admin_notifications.

Table creee automatiquement par le service si elle n'existe pas :

registration_admin_notifications
  id
  membre_id
  email
  recipient_email
  status
  attempt_count
  payload_json
  last_error
  next_retry_at
  sent_at
  created_at
  updated_at

Statuts :

  • pending
  • sent
  • failed

Si l'email admin echoue, l'inscription reste valide. La reponse API indique adminNotificationSent: false et garde l'identifiant de notification quand il existe.

Retry des notifications admin

Fichier :

  • backend/src/jobs/retryAdminRegistrationNotifications.ts

Le job :

  1. charge l'environnement ;
  2. lit REGISTER_ADMIN_NOTIFICATION_RETRY_LIMIT, avec 20 par defaut ;
  3. selectionne les notifications pending ou failed dont next_retry_at est vide ou depasse ;
  4. ignore les lignes ayant atteint REGISTER_ADMIN_NOTIFICATION_MAX_ATTEMPTS, avec 5 par defaut ;
  5. renvoie l'email ;
  6. marque la trace en sent ou failed.

Le delai de retry est exponentiel a partir de REGISTER_ADMIN_NOTIFICATION_RETRY_DELAY_MINUTES, avec 15 minutes par defaut et un multiplicateur plafonne.

Autologin

Fichier :

  • backend/src/services/AutoLoginTokenService.ts

Le backend genere un JWT HS256 avec :

{
  "userId": 123,
  "email": "alice@example.com"
}

TTL par defaut :

REGISTER_AUTOLOGIN_TOKEN_TTL_SECONDS=600

Secret utilise par ordre de priorite :

  1. REGISTER_AUTOLOGIN_JWT_SECRET
  2. API_SECRET_KEY
  3. secret de secours code dans la branche

Point de reprise important : en production, ne jamais dependre du secret de secours. Definir explicitement REGISTER_AUTOLOGIN_JWT_SECRET et verifier que l'application Solutravo qui consomme /connexion-microservice utilise le meme secret et le meme algorithme.

CORS et exposition HTTP

Fichier :

  • backend/app.ts

Le backend expose :

  • GET / pour une reponse de statut API ;
  • GET /health ;
  • POST /api/register.

Origins autorisees par defaut :

http://localhost:5173
http://127.0.0.1:5173
https://auth.staging.solutravo-compta.fr
https://auth.solutravo-app.fr

La variable CORS_ALLOWED_ORIGINS remplace cette liste si elle est renseignee.

Headers autorises :

  • Content-Type
  • Authorization
  • Origin
  • Accept
  • X-Requested-With

Chargement d'environnement

Fichier :

  • backend/src/config/env.ts

Le backend cherche un .env dans cet ordre :

  1. repertoire courant du process ;
  2. deux niveaux au-dessus du repertoire de base ;
  3. trois niveaux au-dessus du repertoire de base.

Si aucun fichier n'est trouve, dotenv.config() est appele sans chemin explicite.

Cette logique existe pour supporter a la fois le dev local, le build dist/ et le deploiement ou le .env est ecrit dans le dossier deploye.

Deploiement

Workflows :

  • .github/workflows/deploy-backend.yml
  • .github/workflows/deploy-frontend.yml

Branches declencheuses :

  • register/staging
  • register/prod

Backend :

  • Node 20.19.4 ;
  • pnpm 10.33.0 ;
  • build dans backend/ ;
  • copie de package.json dans backend/dist/ ;
  • creation du .env depuis les variables GitHub ;
  • deploiement SSH vers un VPS ;
  • restart PM2 avec --update-env.

Frontend :

  • Node 20.19.4 ;
  • pnpm 10.33.0 ;
  • build dans frontend/ ;
  • injection de VITE_API_BASE_URL selon la branche ;
  • deploiement FTP du dossier frontend/dist/.

URLs API configurees dans le workflow frontend :

register/prod    -> https://backend.auth.solutravo-app.fr/api
register/staging -> https://backend.auth.solutravo-compta.fr/api

Tests identifies

Fichiers :

  • backend/tests/registrationRedirect.test.ts
  • backend/tests/env.test.ts

La couverture existante verifie surtout :

  • la construction de l'URL de redirection ;
  • la priorite du token d'autologin sur l'email ;
  • le fallback si REGISTER_SUCCESS_REDIRECT_URL est absent ou invalide ;
  • la resolution des chemins .env.

Il n'y a pas, dans les fichiers identifies, de test d'integration couvrant une inscription complete avec base MySQL, insertion membres, insertion presocietes et creation de la trace de notification.

Points d'attention pour reprise

  • Le module ecrit directement dans les tables metier Solutravo. Toute evolution du schema membres ou presocietes doit etre repercutee ici.
  • La table registration_admin_notifications est creee au runtime par le service. Pour une exploitation stricte, prevoir une migration SQL versionnee plutot que de laisser la creation implicite au premier envoi.
  • L'inscription est consideree reussie meme si la notification admin echoue. C'est volontaire dans le code actuel, mais le monitoring du job de retry devient indispensable.
  • Le secret d'autologin doit etre gere par variable d'environnement et partage avec l'application qui valide le token.
  • La logique de normalisation des URLs existe cote frontend et cote backend. Toute modification de domaine doit etre faite aux deux endroits ou factorisee.
  • Le backend retourne actuellement le token au frontend dans la reponse JSON. Il faut conserver un TTL court et servir uniquement en HTTPS.
  • Le helper frontend reconstruit les erreurs et ne conserve pas le status HTTP d'origine dans l'erreur relancee. Pour du debug support, il peut etre utile de preserver ce status.
  • Les commentaires et libelles du helper frontend ne sont pas totalement homogenes. Ne pas les prendre comme documentation contractuelle ; le contrat fiable est le couple POST /api/register et la reponse du controleur.