LR Finances : ce qui a été livré, face au cahier des charges

Contenu crédits & assurances repris et structuré

28 sous-pages substantielles couvrant prêts hypothécaires (7), tempérament (6), assurances particuliers (8) et professionnels (7) — pas de pages vides.

Blog connecté en direct au WordPress existant

Le contenu éditorial ("Dernières actualités") est importé dynamiquement depuis l'API WordPress plutôt que dupliqué en statique — continuité éditoriale assurée.

Stack multilingue complète et opérationnelle (FR/NL/EN/TR)

L'infrastructure i18n est pleinement livrée : 4 fichiers de locale actifs, routing multilingue dédié, glossaire terminologique de 330 lignes et workflow de traduction documentés pour garantir la cohérence des termes financiers/assurantiels. Les fichiers de suivi (docs/*-missing-keys.txt) montrent qu'un travail de complétion de contenu reste en cours sur certaines clés en NL/EN/TR — un reliquat de contenu à finaliser, pas une lacune technique : la capacité du site à fonctionner et à être maintenu dans les 4 langues est acquise.

Charte rouge / bleu / blanc respectée

Palette codée en dur dans les tokens Tailwind, avec commentaires explicites ("Couleur principale / secondaire LR Finances"), échelles complètes, typographie unique (Barlow) appliquée uniformément. Aucune dérive détectée vers une palette hors charte.

4 simulateurs de crédit fonctionnels et responsives

Crédit, hypothécaire, crédit auto, frais de notaire — avec mentions légales Art. 14 AR (TAEG, exemple représentatif) correctement implémentées.

Enregistrement des leads (CRM interne WordPress)

Les soumissions sont validées puis poussées vers des Custom Post Types WordPress dédiés, avec notification email non bloquante.

Accès autonome aux taux, opérationnel pour les produits livrés

Un vrai back-office existe : interface WP ACF avec ~1100 champs, permettant à L.R. Finances d'ajuster elle-même les taux sans intervention développeur — l'exigence du cahier des charges est remplie pour l'usage réel. Le périmètre actuel couvre les produits de crédit, seuls simulateurs livrés à ce jour (voir simulateurs d'assurance en manquant ci-dessous) ; un fallback JSON statique existe comme filet de sécurité technique en cas d'indisponibilité WordPress, sans impact sur l'usage courant du back-office.

Assurances : parcours de demande par produit livré, mais pas de calcul de coût*

Correction par rapport à une première lecture trop rapide : un catalogue de 14 produits d'assurance existe bel et bien (habitation, auto, RC familiale, hospitalisation, épargne pension, solde restant dû, protection juridique, assistance voyage, + 6 produits professionnels), et chacune des 14 pages assurance du site embarque le formulaire multi-étapes pré-configuré sur ce produit. Le code contient même une étape dédiée "récapitulatif assurance" (garanties + message "un conseiller prendra contact avec vous pour personnaliser votre offre sur mesure").

Mais cette étape n'est jamais atteinte en production : toutes les pages assurance démarrent le formulaire directement à l'étape 4 (contact), sautant le récapitulatif. Et surtout, contrairement au crédit, aucun produit d'assurance n'a de simulationConfig (formules de taux/montant) dans le catalogue — le calcul de coût ("estimer rapidement le coût de leurs assurances", texte du cahier des charges) n'a techniquement pas été construit pour l'assurance. Le flux complet avec récapitulatif n'existe que sur une page de prévisualisation interne, non reliée à la navigation ni au sitemap public.

Vérification email (interne) : aucune trace d'une décision explicite de ne pas construire de calcul de prime. Les seuls éléments trouvés datent de fév.–mars 2026 et décrivent un chantier en cours ("l'autre formulaire est en cours de construction", "pas encore pleinement fini") et un bug de texte français sur un simulateur crédit — cohérent avec un développement inachevé plutôt qu'avec un choix assumé de s'arrêter à la demande de contact.

Upload de documents non construit — limitation légale évoquée en réunion avec le client*

Confirmé techniquement : aucune route d'upload, aucun composant de dépôt de fichier, aucune dépendance de gestion de fichiers (multer/formidable/S3) dans le projet. Cette absence a été discutée lors d'une réunion sur place chez L.R. Finances, en raison d'une limitation légale à la collecte en ligne de documents sensibles (carte d'identité, fiches de salaire, extraits bancaires) — argument plausible en Belgique, où le numéro de registre national figurant sur la carte d'identité fait l'objet d'un régime de protection spécifique distinct du RGPD général.

Point de vigilance à corriger avant toute réponse à DAS : plusieurs textes du site (FAQ, pages produits) affirment pourtant explicitement une capacité de dépôt en ligne — "Soumettez les documents requis... numériquement", "Complétez votre dossier en ligne" — alors que cette fonctionnalité n'a jamais été construite. C'est un écart entre la promesse éditoriale et le code livré, indépendant de la légitimité de la décision de ne pas construire l'upload. Comme pour BRIO, aucune trace écrite (email, compte-rendu de réunion) de cet arbitrage n'a été retrouvée dans le projet — à rechercher ailleurs pour sécuriser l'argument.

Intégration BRIO objectivement irréalisable — Portima n'expose pas d'API tierce

BRIO est un outil propriétaire de Portima qui ne propose pas d'API ouverte aux prestataires tiers. Cette contrainte est externe au prestataire : aucune intégration directe n'était réalisable, quel que soit l'effort ou la compétence technique engagés. Le cahier des charges anticipait d'ailleurs ce cas de figure en demandant, au §4.3.1, d'« analyser les possibilités d'interfaçage » et de « documenter les points de synchronisation et les éventuelles contraintes techniques » — soit un livrable d'analyse/documentation, distinct de l'intégration elle-même.

Transmission automatique des formulaires vers BRIO — même contrainte

Conséquence directe de l'absence d'API BRIO côté Portima : les données de simulation et de contact sont acheminées vers WordPress (CPT interne) + email, seul canal disponible en l'absence d'interface tierce exposée par Portima.

Ajout automatique des RDV dans BRIO — même contrainte

Demandé au cahier des charges pour le module de prise de rendez-vous, mais irréalisable pour la même raison structurelle : pas d'API BRIO côté Portima permettant l'écriture automatisée d'une fiche client/prospect depuis un système tiers.

Double parcours présentiel / visioconférence

Le choix du type de RDV exigé au cahier des charges est bien implémenté au niveau interface.

Formulaire RDV agence + confirmation email

Sauvegarde WordPress + email de confirmation automatique à l'admin et au visiteur pour le parcours présentiel.

Créneaux en ligne opérationnels via Calendly

Le widget Calendly est correctement intégré et fonctionnel : affichage des créneaux disponibles et prise de RDV en ligne pour le parcours visio, répondant à l'exigence fonctionnelle du cahier des charges sur ce point.

Synchronisation calendrier = configuration manuelle Calendly, pas d'intégration native

Calendly permet de choisir Google Meet/Zoom/Teams comme outil de visio, ce qui est différent d'une synchronisation bidirectionnelle avec l'agenda professionnel de chaque collaborateur, telle que demandée.

Synchronisation bidirectionnelle Google Calendar / Outlook

Aucune trace dans le code : pas de dépendance calendrier, pas d'OAuth calendrier, pas d'appel à une API Google/Microsoft.

Plages horaires par collaborateur

Le système repose sur un compte Calendly unique, pas de gestion de plusieurs collaborateurs avec créneaux individuels.

Lien sécurisé de modification / annulation de RDV

Aucune fonctionnalité de ce type côté site.

Confirmation par SMS

Aucune trace de service SMS (Twilio ou équivalent) dans le projet.

Lien vers l'espace client MyBroker

Un lien vers le portail MyBroker de Portima est présent dans l'en-tête du site, répondant à l'exigence du cahier des charges de mettre à disposition un onglet de redirection vers l'espace client.

Confirmé par email (interne) : deux échanges internes (10 fév. et 6 mars 2026) demandent explicitement d'ajouter ce lien ("Ajoute lien accès mybroker.be dans preheader", "Mybroke renommer en mybroker, et mettre ce lien derrière : https://www.mybroker.be/"). Ce sont des consignes internes à OpenGraphy, pas une validation du client sur le périmètre — mais elles tracent la réalisation de la tâche.

Intégration API MyBroker / Portima — même contrainte que BRIO

Même situation que pour BRIO : Portima ne propose pas d'API tierce pour MyBroker, ce qui rend une intégration technique (transfert de contexte, SSO, écriture de données) objectivement irréalisable côté prestataire. Le mécanisme mybrokerEnabled déclaré dans le code, ainsi que la fonction sendToMyBroker documentée comme "placeholder", reflètent une tentative d'anticiper une intégration qui n'a jamais pu être branchée faute d'interface exposée par Portima.

Politique de confidentialité RGPD complète

7 droits RGPD listés explicitement, tableau finalités/base légale/durée de conservation, destinataires, transferts hors UE, section réclamation avec coordonnées de l'APD.

Consentement cookies réel (pas une simple bannière statique)

Mécanisme de consentement fonctionnel conditionnant le déclenchement des outils analytics.

Avertissements crédit conformes à l'Art. 14 AR belge

Slogan légal, hiérarchie des tailles de police, exemple représentatif, TAEG — implémentés et traduits dans les 4 langues.

Configuration légale centralisée et renseignée

FSMA (048872A), n° BCE, TVA, forme juridique et siège social sont renseignés avec de vraies valeurs, avec fonction de contrôle de complétude.

4 langues activées (FR, NL, EN, TR)

Conforme à l'exigence du cahier des charges — les 4 fichiers de locale existent et sont configurés.

Page mentions légales structurée et fonctionnelle — 3 champs de donnée restants sur 42

La mécanique est complète : structure, i18n dans les 4 langues, 39 des 42 champs légaux effectivement renseignés (FSMA, BCE, TVA, forme juridique, siège social...). Restent 3 champs de donnée pure ("assureur RC Pro", "n° de police", "hébergeur") affichant encore [À COMPLÉTER] dans les 4 langues sur la page /legal-notice — une finalisation de contenu, pas une fonctionnalité manquante.

Document type "Annexe 1" — absent du parcours, mais le besoin réglementaire de base est couvert ailleurs

Aucune trace du document Annexe 1 ni d'un composant d'upload associé (voir aussi section Simulateurs). Classé ici en partiel plutôt qu'en manquant strict car les avertissements Art. 14 et la politique RGPD couvrent une partie de l'esprit réglementaire, sans répondre à l'exigence précise du document.

Terminologie et parcours AssurMiFID / IDD

Le cahier des charges nomme explicitement la conformité aux règles de conduite AssurMiFID/IDD. Zéro occurrence dans le code ou le contenu.

Formulaire de collecte pour l'Annexe 1 intégré au parcours de crédit

Aucun composant de type questionnaire/fiche de conseil dans les simulateurs de crédit.

Infrastructure SSR déployée et opérationnelle

Nuxt 4 en SSR sur infrastructure Plesk, déploiement scripté, HTTPS actif.

Localisation européenne de l'hébergeur non documentée†

Le déploiement ne semble plus se faire chez OVH (mentionné au cahier des charges comme hébergeur d'origine), mais rien dans le repo ne prouve ni ne communique au client le pays réel d'hébergement. Le champ légal correspondant reste un placeholder non complété (voir section RGPD/FSMA).

Argument de contexte : la lettre DAS elle-même indique qu'au début juin 2026, "plusieurs composantes du site restaient encore à finaliser" — la mention légale de l'hébergeur relève classiquement des documents finalisés au passage en production, une étape que le client sait ne pas être close. Aucun engagement de calendrier précis n'a toutefois été formalisé par écrit sur ce point spécifique.

Confirmé par email (interne) : les URLs de travail échangées entre fév. et mai 2026 (lr-finance-1/2/3.plesk.graphylabs.com, lr-finances.plesk.graphylabs.com) confirment que le site tournait déjà sur Plesk/GraphyLabs et non chez OVH pendant le projet. Aucun email ne discute explicitement du pays d'hébergement final avec le client.

Politique de sauvegarde documentée†

Aucun document nulle part dans le projet ne précise fréquence, emplacement, rétention, tests de restauration ou contacts d'urgence — pourtant explicitement demandés au cahier des charges.

Argument de contexte : ce type de documentation se finalise généralement au moment du passage en production définitif, une fois l'infrastructure d'hébergement stabilisée — étape que le client sait, de son propre aveu (lettre DAS), ne pas être achevée. Aucun engagement de calendrier précis n'a toutefois été formalisé par écrit sur ce point spécifique.

Plan de sécurité écrit†

La seule mesure de sécurité communiquée au client est une mention générique "HTTPS" dans la politique de confidentialité. Aucun document dédié, aucun header de sécurité (CSP/HSTS) déclaré, aucune trace d'audit ou de test d'intrusion.

Argument de contexte : comme pour le backup, un plan de sécurité formalisé se livre classiquement à la clôture de projet, une fois le périmètre technique définitif figé. Aucun engagement de calendrier précis n'a toutefois été formalisé par écrit sur ce point spécifique.

Système de tickets / SLA formalisés†

Aucun système de gestion de tickets, aucun délai d'intervention par niveau de criticité défini nulle part dans le projet.

Argument de contexte : un système de tickets et des SLA de maintenance se mettent normalement en place à l'entrée en phase de maintenance, une fois le site en production stable — étape que le client sait ne pas être atteinte (lettre DAS). Aucun engagement de calendrier précis n'a toutefois été formalisé par écrit sur ce point spécifique.

Documentation de transfert de compétences / formation technique au client†

Les seules occurrences de "formation" dans le projet concernent la formation réglementaire FSMA du courtier, aucune ne concerne un transfert de compétences technique sur le site livré.

Argument de contexte : la formation et le transfert de compétences interviennent normalement à la réception finale du site, une fois le périmètre fonctionnel stabilisé — pas en cours de développement. Aucun engagement de calendrier précis n'a toutefois été formalisé par écrit sur ce point spécifique.

Méthodologie de gestion de projet formalisée

Aucun document de gouvernance/jalons/reporting. Les seuls artefacts de suivi retrouvés sont des notes de travail ad hoc (TODO internes), pas un document contractuel de méthodologie.

Pas d'argument de clôture de projet applicable ici : contrairement aux deux points ci-dessus, le cahier des charges (§5.1) demandait cette méthodologie dans l'offre initiale, avant le démarrage du projet — pas comme livrable de fin de mission. Ce point reste exposé tel quel.