Formulaire d'ouverture de compte
src/views/public/OpenAccountView.vue (frontend) — page publique.
Vérifié le 2026-08-13, section 2 re-vérifiée le 2026-08-24.
GET /api/account-requests n'exigeait aucune authentification — toute donnée soumise via ce formulaire (identité, téléphone, email, adresse, FATCA/TIN) était listable par n'importe qui. verifyToken + filtrage par agence/zone ajoutés, voir Bugs & failles actives connues.
1. Vue d'ensemble
Contrairement au prêt scolaire, ce formulaire n'a pas de portail d'authentification bloquant avant l'accès. Le nombre d'étapes dépend du type de compte choisi à l'étape 0 (stepConfigs) :
| Type de compte | Étapes après le choix du type |
|---|---|
| Particulier | 6 (Identité, Filiation & Adresse, Situation Pro, FATCA, Agence, Documents) |
| Société | 5 |
| Association | 4 |
| Entreprise Individuelle | 4 |
Un brouillon est sauvegardé automatiquement dans localStorage (utb_open_account_draft, restauré au montage) et effacé après soumission réussie — filet de sécurité en cas de fermeture accidentelle de l'onglet, absent du formulaire de prêt scolaire.
2. Vérification téléphone — OTP réel depuis le 2026-08-24, mais sans auto-remplissage
L'étape Identité a un bouton "Vérifier" sur le téléphone, avec un modal de saisie de code. Ce n'est plus une simulation : sendOTP()/verifyOtp() appellent désormais réellement le backend (api.post('/otp/send', { phoneNumber }) puis api.post('/otp/verify', { phoneNumber, code }), voir OTP, SMS & vérification SBA) — code à 6 chiffres généré aléatoirement, envoyé par SMS réel (passerelle Kannel), vérifié côté serveur.
accountNumber, donc pas d'auto-remplissageContrairement au formulaire de prêt scolaire, l'appel /otp/send de cette page n'envoie que phoneNumber, jamais de numéro de compte. Le backend ne consulte donc jamais le service SBA (mock) pour cette page — pas de risque d'un 404 Numéro de compte introuvable bloquant, mais aussi aucune donnée d'identité auto-remplie en retour : cette étape ne fait que prouver la possession du numéro de téléphone, rien de plus. Avant le 2026-08-24, le contraste entre les deux formulaires était que celui-ci était fake sans le signaler ; aujourd'hui les deux utilisent la même infrastructure OTP réelle, la différence porte uniquement sur ce paramètre optionnel.
3. Déclaration FATCA (particuliers uniquement)
6 questions à l'étape FATCA, avec un champ TIN (Tax Identification Number) qui devient obligatoire dès qu'une réponse "Oui" est cochée. Propre aux comptes de type Particulier — les autres types de compte n'ont pas cette étape.
4. Consentement — un seul champ, pas trois
formData.consentement : une case unique ("j'accepte les conditions générales"), répétée à chaque étape Documents. Aucun équivalent aux trois champs consent_data_processing / consent_electronic_signature / consent_date horodatés du prêt scolaire (voir Consentements légaux) — pas de preuve de consentement structurée de la même façon pour l'ouverture de compte.
5. Documents — système différent de celui du prêt
Contrairement au prêt scolaire (clés dynamiques, attribution incertaine a_classer_N), la liste de documents est fixe et prédéfinie par catégorie (documentByType), avec des clés stables connues à l'avance (lettre_demande, cni, justificatif_fonds, photo, plan_localisation, facture...). Pas de mécanisme d'attribution incertaine — chaque document a un identifiant métier fixe dès l'upload.
Les pièces d'identité jointes en dehors de documentByType — CNI des signataires (comptes Société), CNI des membres du bureau (Association), CNI du promoteur (Entreprise Individuelle) — restaient imbriquées en base64 dans le JSON additional_data, sans jamais passer par le service de documents ni apparaître dans l'onglet "Documents" de la fiche backoffice. buildAdditionalData() les inclut désormais dans additional_data.documents avec une clé descriptive (signataire_1_cni, bureau_president_cni, promoteur_cni...), retirée des objets signataires/bureau/promoteur pour éviter de dupliquer le blob base64. Aucun changement backend nécessaire — account_requests.controller.js traitait déjà additional_data.documents de façon générique (voir section 6).
6. Soumission
buildAdditionalData() place tous les documents (génériques documentByType + CNI signataires/bureau/promoteur depuis le 2026-08-13) sous additional_data.documents. Côté backend (account_requests.controller.js), chaque entrée de ce sous-objet est créée dans la table documents avec entity_type: 'account_request' — même mécanisme physique que le prêt (Documents, tickets & archivage), mais sans le système d'attribution incertaine.
7. Doc backoffice associée
Voir Fiche détail d'une demande de compte — beaucoup plus pauvre que son équivalent côté prêt, à lire avant de supposer que les deux fonctionnent pareil.