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.

J'ai imposé une isolation des credentials par partenaire via Microsoft 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, et rejet immédiat des requêtes malformées. J'ai mené un audit de sécurité formel en 2023 qui a abouti à un renforcement des contrôles d'accès et à la mise à jour des règles pare-feu. En parallèle, j'ai outillé une isolation par rôle sur les credentials internes pour que chaque opérateur n'ait accès qu'aux portails dont il était responsable.

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.

À la refonte de Fleurance Nature en 2017, Magento Enterprise Edition 1.10 portait la responsabilité PCI-DSS du e-commerce de l'entreprise (paiement en ligne sur 3 storefronts, 4 groupes clients, 12 matrices tarifaires). Avec 60 modules custom et 1 040 fichiers PHP modifiés, le risque d'introduire une régression sécurité à chaque release était permanent - et toute fuite carte aurait coûté la conformité PCI au groupe.

J'ai imposé sur chaque module custom le respect strict des patterns PCI-aware : aucun stockage de données carte côté Magento (délégation totale au prestataire de paiement certifié), passage systématique par les patterns Observer / Strategy pour ne jamais toucher au cœur Magento - ce qui empêche l'introduction inattendue d'un point de capture - et suite de régression sécurité complète avant chaque release. Côté OWASP Top 10, j'ai cadré la prévention des XSS sur les contributions UGC, l'isolation des sessions multi-store, et la validation stricte des entrées sur tous les formulaires custom.

Zéro incident sécurité production sur la migration et sur les 5 années d'exploitation qui ont suivi, conformité PCI maintenue tout au long du process, et le cache Varnish est resté opérationnel sans introduire de bypass d'authentification.

Sur ce projet, j'ai installé chez moi la sécurité comme revue quotidienne plutôt que comme audit annuel. C'est ce réflexe-là qui me permet aujourd'hui de négocier les clauses contractuelles IT (DPA, SCCs, SLA, réversibilité) en direct chez ACCENSEO sans passer par un juriste externe sur les négociations courantes - parce que je sais ce que je signe.