La plateforme PSR du Groupe Pichet était une API publique recevant des leads partenaires depuis une dizaine de portails immobiliers externes - chaque lead contenait des données personnelles (nom, email, téléphone, projet immobilier) soumises au RGPD, et chaque credential mal géré ouvrait potentiellement la porte à un détournement de leads vers la concurrence. La protection ne pouvait pas être un add-on, elle devait être dans le design initial.

À mon arrivée, le périmètre n'avait pas la maturité sécurité qu'il aurait dû avoir - credentials peu segmentés, gouvernance d'accès laxiste, données réelles parfois manipulées hors prod. Honnêtement, on aurait dû le faire dès le départ. Le RSSI, le DPO et le chef de projet RSSI du Groupe Pichet ont posé le cadre attendu, et avec Thomas R. on l'a appliqué proprement. Mise en place d'une isolation des credentials par partenaire via APIM (clés API uniques par portail, permissions délimitées par scope, rotation systématique via le cycle de vie APIM). Pour les flux RGPD : HTTPS exclusif, pas de stockage persistant intermédiaire des leads (le CRM commercial reste le seul référentiel), validation au gateway sur le format et la taille des payloads, rejet immédiat des requêtes malformées. Anonymisation systématique des données dans les environnements hors production (dev, recette, staging) avec génération de jeux de tests synthétiques. Politique de purge alignée sur le référentiel CNIL : suppression automatique des leads non convertis 3 ans après le dernier contact (recommandation CNIL pour la prospection commerciale), avec archivage minimal des oppositions à la prospection. Côté CRM, gouvernance d'accès par rôle et par périmètre : chaque opérateur n'avait accès qu'aux portails et programmes dont il était responsable, avec logs d'accès auditables et revue trimestrielle des droits. Audit de sécurité formel en 2023 qui a validé l'ensemble et abouti à un dernier renforcement des contrôles d'accès et à la mise à jour des règles pare-feu.

Audit 2023 validé sans non-conformité majeure, confiance partenaire maintenue sur 3 ans, et zéro incident sécurité sur l'ensemble de l'exploitation - ce qui a permis d'élargir progressivement le périmètre partenaire sans repasser par une nouvelle phase d'évangélisation interne.

Ce projet a installé chez moi une revue sécurité comme cycle récurrent plutôt que comme événement ponctuel. Aujourd'hui, sur chaque mission ACCENSEO qui touche à des données régulées, je rejoue le même pattern : threat-modeler dès la phase wireframe, isolation par rôle dès le design, audit externe au moins une fois par an. C'est ce qui permet de défendre des contrats SLA en face d'un client critique sans avoir à tout justifier à chaque vague.

Le SaaS comptable d'ACCENSEO traite ce qu'il y a de plus sensible : données bancaires Open Banking DSP2 (3 providers connectés en parallèle), KYC client, écritures comptables soumises à audit, e-facturation 2026-2027 réglementée par la DGFiP. Avant même de développer une feature, j'ai lancé un audit de sécurité des plateformes concurrentes : il a révélé plusieurs failles critiques chez les acteurs établis (IDOR permettant de voir les données d'un autre client, failles KYC sur la vérification d'identité). Je ne pouvais pas reproduire ces erreurs.

J'ai construit la sécurité avant le code applicatif. Threat model IDOR + KYC posé sur chaque feature qui touche à des données client, contrôle d'accès par 6 rôles différenciés (Admin, Collaborateur, Consultant, Comptable, Comptabilité, Banque) câblé via Better Auth avec MFA complet (email, TOTP, SMS) et jetons de connexion comptable dédiés. Côté flux régulés, j'ai branché l'EDI Teledec (partenaire agréé DGFiP) pour les téléclarations TVA / IS / CFE / DAS2 / PAS, intégré l'Open Banking DSP2 sur 3 providers (GoCardless/Nordigen, Bridge, Qonto) avec respect strict des consentements. Pour la facturation électronique, j'ai construit le pipeline DGFiP v3.1 dès 2025 avant le mandat 2026-2027. J'ai aussi documenté chaque choix sécurité dans des ADR versionnés pour qu'ils survivent à la croissance de l'équipe.

Baseline de conformité atteinte avant l'échéance réglementaire 2026-2027, prêt pour rollout sans réécriture sécuritaire en urgence, et plateforme commercialisable auprès des cabinets comptables et des PME françaises sans dépendre d'un audit externe à chaque cycle.

Sur ce projet, j'ai compris que la conformité régulatoire bien faite devient un moat produit : les concurrents qui ont des failles IDOR ou KYC ne peuvent pas attaquer mon segment sans réécrire des pans entiers. C'est exactement la posture que je veux pousser sur le prochain rôle CTO scale-up en industrie régulée - transformer la régulation en barrière à l'entrée plutôt qu'en boulet.

Le SaaS courtier crédit immobilier d'ACCENSEO opère sur un marché ultra-régulé : ORIAS (Registre des intermédiaires d'assurance et de courtage), HCSF (Haut Conseil de Stabilité Financière qui fixe les contraintes d'octroi), taux d'usure encadré par la Banque de France, et DSP2 pour l'agrégation bancaire. Chaque dossier de prêt contient des données KYC très sensibles (revenus, dettes, projet immobilier, situation familiale) et doit pouvoir traverser un audit ORIAS sans surprise. Sur ce périmètre, j'ai cadré la sécurité avant de poser la première feature produit - reproduire les failles classiques du marché (IDOR cross-courtier, KYC bancale) aurait condamné la commercialisation.

J'ai mis en place une auth post-mot-de-passe avec WebAuthn / passkeys (FIDO2) pour réduire la surface d'attaque phishing dès le sign-in, avec Better Auth câblé MFA (TOTP, SMS, email) sur les comptes legacy non-passkeys. Threat-modeling KYC sur la collecte de pièces justificatives (RIB, bulletins de salaire, avis d'imposition) avec hashing serveur des documents et accès limité dans le temps par token signé. Côté DSP2, agrégation bancaire via 3 providers (GoCardless/Nordigen, Bridge, Qonto) avec respect strict du flux consentement OAuth + révocation utilisateur. Hub SSO centralisé entre l'espace courtier, co-courtier, client final et banque, avec session courte (15 min idle) et rotation de tokens. Le schéma de rôles sépare strictement courtier / co-courtier / client / banque pour bloquer tout IDOR cross-rôle. Documentation contractuelle ORIAS / HCSF / RGPD versionnée en ADR pour passer les audits sans réécriture.

Auth WebAuthn déployée dès le rollout, DSP2 multi-provider opérationnel sur 3 agrégateurs, périmètre ORIAS-ready documenté et défendable, zéro incident sécurité sur l'exploitation à date. Les contrôles ORIAS / HCSF passent sans non-conformité majeure parce que la conformité est embedded dans le code, pas ajoutée en post-prod.

Sur ce projet, j'ai compris que le mortgage broking est un terrain de jeu sécurité distinct de la comptabilité : KYC plus dense, traçabilité ORIAS exigée, sensibilité DSP2 plus aiguë sur l'agrégation bancaire. C'est cette spécialisation par vertical régulé qui me permet d'arbitrer build vs buy devant un board sans naïveté - chaque domaine a sa réglementation propre, et copier-coller une stack sécurité d'une vertical à l'autre est exactement comment on perd un audit.