Formulaire d'ouverture de compte
src/views/public/OpenAccountView.vue (frontend) — page publique.
Vérifié le 2026-08-13.
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 — pas un vrai OTP
L'étape Identité a un bouton "Vérifier" sur le téléphone, avec un modal de saisie de code. Entièrement simulé côté client, sans aucun appel réseau : sendOTP() attend 1 seconde (setTimeout) puis ouvre le modal, verifyOtp() attend 1,5 seconde puis force phoneVerified = true — aucune vérification réelle du code saisi, aucun SMS envoyé.
Le formulaire de prêt scolaire a le même défaut de fond (aucune intégration SMS réelle), mais lui bloque tout l'accès au formulaire derrière l'OTP et le signale explicitement par un commentaire dans le code. Ici, l'OTP ne bloque que la progression de l'étape — et rien dans le code de cette page ne signale qu'il s'agit d'une simulation, contrairement au prêt scolaire. Un futur développeur lisant seulement ce fichier peut légitimement croire qu'une vérification réelle a lieu.
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.