--- title: "Sécurité Applicative & Conformité - José DA COSTA" description: "La sécurité applicative et la conformité, c'est pour moi **concevoir un logiciel qui ne fuit pas, ne permet pas d'accès latéral, et ne brise pas les attentes d'un régulateur**. Ça couvre OWASP Top 10 " locale: "fr" canonical: "https://portfolio.josedacosta.info/fr/competences/securite-applicative-conformite" source: "https://portfolio.josedacosta.info/fr/competences/securite-applicative-conformite.md" html_source: "https://portfolio.josedacosta.info/fr/competences/securite-applicative-conformite" author: "José DA COSTA" type: "skill" slug: "application-security-compliance" generated_at: "2026-05-26T15:39:07.804Z" --- # Sécurité Applicative & Conformité Icône: 🔐 ## Ma définition La sécurité applicative et la conformité, c'est pour moi **concevoir un logiciel qui ne fuit pas, ne permet pas d'accès latéral, et ne brise pas les attentes d'un régulateur**. Ça couvre OWASP Top 10 ([**Open Worldwide Application Security Project**](https://owasp.org/) - la liste de référence des 10 risques de sécurité applicative les plus critiques, mise à jour par la communauté), sécurité réseau, droit des contrats IT, RGPD. Ce n'est pas un add-on qu'on branche en fin de projet, c'est une discipline qu'on installe dès la phase wireframe - sinon la dette de sécurité devient existentielle au premier audit externe sérieux. ### Contexte Voilà mes **3 couches** tenues en parallèle : - **Code** : [OWASP (Open Worldwide Application Security)](https://owasp.org/) Top 10 internalisé sur les principales bases (PSR, SaaS comptable, Magento, ESB), **audit dépendances**, **secret scanning**, **threat-modeling** sur chaque feature qui touche credentials, paiement ou KYC. - **Système** : **segmentation réseau**, IAM délimité par rôle, **vault credentials**, isolation par partenaire via APIM. - **Conformité** : RGPD, **négociation contractuelle directe** (DPA, SCCs, SLA, réversibilité) que je mène avec un **juriste externe en appui** sur les négociations courantes. Baseline réseau posée par le **BTS Informatique de Gestion** (TCP/IP, sous-réseaux, segmentation, hardening kernel, fail2ban) puis affinée par **11 ans de production** entre Zend Framework chez European Sourcing, Magento Enterprise PCI chez Smile, ESB et PSR chez Pichet, et SaaS comptable régulé chez ACCENSEO. La discipline [OWASP (Open Worldwide Application Security)](https://owasp.org/) s'aiguise par les **incidents réels et les audits externes**, jamais par la simple lecture du Top 10. ### Pertinence En 2026, le paysage réglementaire européen impose un saut de maturité : la [**transposition NIS2 en France**](https://monespacenis2.cyber.gouv.fr/) est en phase finale d'adoption (loi attendue mi-2026, **15 000 entités** concernées, audits réguliers à partir du Q4 2026), avec une fenêtre de reporting d'incident de **24 heures** strictement applicable. Les détails sont disponibles sur [le suivi officiel de la Commission européenne](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive-france) et, côté français, sur [la page officielle de l'ANSSI sur la directive NIS 2](https://cyber.gouv.fr/reglementation/cybersecurite-systemes-dinformation/directives-nis-nis2-et-dispositif-saiv/directive-nis-2/) qui détaille le périmètre, les obligations et le calendrier d'accompagnement. En parallèle, l'[**AI Act**](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) entre en pleine applicabilité, et le [**mandat français e-facturation 2026-2027**](https://www.impots.gouv.fr/professionnel/facturation-electronique) ajoute une couche de conformité fiscale aux SaaS comptables. Le CTO CSSLP/CISSP-ready devient un profil recruté en priorité sur les industries régulées (santé, finance, immobilier institutionnel). ## Mes éléments de preuve ### Sécuriser la plateforme PSR de bout en bout **Contexte:** 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. **Mise en œuvre:** À 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**](https://www.cnil.fr/fr/referentiel-pour-la-gestion-des-activites-commerciales) : 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. **Résultat:** **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. **Valeur ajoutée:** 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. ### Concevoir la sécurité du SaaS comptable autour de données régulées **Contexte:** 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. **Mise en œuvre:** 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. **Résultat:** **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. **Valeur ajoutée:** 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. ### Sécuriser le SaaS courtier crédit immobilier d'ACCENSEO **Contexte:** 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. **Mise en œuvre:** 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. **Résultat:** **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. **Valeur ajoutée:** 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. ## Mon autocritique ### Degré de maîtrise Niveau **Senior** sur [OWASP (Open Worldwide Application Security)](https://owasp.org/) applicatif et droit IT (lecture et négociation contractuelle), **Confirmé** sur sécurité réseau et RGPD. OWASP Top 10 internalisé sur les principales bases du parcours, baseline réseau posée par le BTS Informatique de Gestion et entretenue par 11 ans de production. Pratique forgée sur 11 ans : coordination contractuelle avec **Akeneo, Bynder**, et les portails partenaires chez **Pichet**, puis négociation directe de DPA, SCCs, SLA et clauses de réversibilité comme **CTO ACCENSEO et Celiane** - je lis et challenge moi-même les clauses, avec un **juriste externe en appui** sur les négociations courantes. Ce qui reste à muscler : [**threat modeling formel (STRIDE)**](https://owasp.org/www-community/Threat_Modeling_Process) et préparation industries hautement régulées comme la santé ou la finance critique. ### Importance dans mon profil **Indispensable pour un rôle CTO** et différenciant explicite sur les industries régulées. C'est ce qui me permet de sécuriser une plateforme produit sans dépendre d'un consultant externe et de défendre les clauses contractuelles côté sales sans escalade juridique. Pour le SaaS comptable régulé (e-facturation 2026-2027) et le SaaS courtiers (DSP2, KYC), c'est la condition de mise en marché. ### Conseils (pour moi-même et pour les autres) ### Mes règles d'or *Traiter la sécurité comme un livrable continu, pas un événement.* **Mes 4 règles d'or :** - Rafraîchir le [**Top 10 OWASP (Open Worldwide Application Security)**](https://owasp.org/) chaque année sur les stacks actives - Faire passer un **audit externe** au moins une fois par an - **Threat-modeler** chaque feature qui touche credentials, paiement ou KYC **dès la phase wireframe**, pas après - Documenter les choix sécurité dans des **ADR** pour qu'ils survivent au turn-over ## Mon évolution dans cette compétence ### Rôle dans mon projet professionnel La sécurité applicative et la conformité sont **ce qui rend mes décisions CTO acceptables côté board, juridique et clients**. Dans mon plan de carrière 2026-2028, elles me permettent d'attaquer un marché régulé (santé, finance, immobilier institutionnel) sans surcoût juridique externalisé et de passer un audit ISO / SOC2 light sans réécriture massive. Sans elles, le rôle se restreint aux secteurs non régulés et perd la moitié du marché adressable français. ### Niveau souhaité à moyen terme L'objectif observable est de **faire passer un audit externe** (ISO 27001 light, SOC2 type 1 ou pentest tier 2) sans non-conformité majeure et de **défendre la stratégie sécurité devant un comité d'audit en 60 minutes**. Maintien Senior par défaut, ouverture vers Expert si l'industrie cible le justifie (santé, finance critique). ### Formations en cours Revue annuelle systématique du [**Top 10 OWASP (Open Worldwide Application Security)**](https://owasp.org/) appliqué aux stacks ACCENSEO, suivi continu des [bulletins ANSSI](https://www.cert.ssi.gouv.fr/) et de [Cloudflare Radar](https://radar.cloudflare.com/), threat-modeling appliqué aux features récentes du SaaS comptable. Master Expert en Ingénierie du Logiciel actif. ### Formations à venir **Certifications visées 2026-2027** : - [**CSSLP** (Certified Secure Software Lifecycle Professional)](https://www.isc2.org/certifications/csslp) ou [**CISSP** (Certified Information Systems Security Professional)](https://www.isc2.org/certifications/cissp) selon la maturité du rôle CTO cible - [**CIPP/E** (Certified Information Privacy Professional / Europe)](https://iapp.org/certify/cippe/) de l'**IAPP** pour le pilotage RGPD côté SaaS B2B régulés (santé, finance, immobilier institutionnel) - [**ISO 27001 Lead Implementer**](https://pecb.com/en/education-and-certification-for-individuals/iso-iec-27001/iso-iec-27001-lead-implementer) du PECB pour la posture audit-ready **Formations pratiques 2026** : - Threat-modeling avancé ([**STRIDE**](https://owasp.org/www-community/Threat_Modeling_Process) / [**LINDDUN**](https://linddun.org/)) sur le SaaS comptable et le SaaS courtiers - [**MOOC SecNumacadémie**](https://secnumacademie.gouv.fr/) de l'ANSSI en intake continu (gratuit) pour rester aligné sur les fondamentaux français de cybersécurité ## Progression à travers les parcours Cette compétence a été développée dans 9 parcours différents. - **1999** - [CTO · Founder · directeur technique](https://portfolio.josedacosta.info/fr/parcours/celiane-founder.md) (entrepreneurship) - Confidence: 1/5 - **2001** - [BTS IG (Informatique de Gestion)](https://portfolio.josedacosta.info/fr/parcours/bts-computer-science.md) (education) - Confidence: 1/5 - **2008** - [Junior Software Engineer · webmaster développeur PHP Joomla](https://portfolio.josedacosta.info/fr/parcours/ministere-sante-webmaster.md) (experience) - Confidence: 2/5 - **2009** - [Software Engineer · développeur PHP Zend Framework](https://portfolio.josedacosta.info/fr/parcours/european-sourcing-engineer.md) (experience) - Confidence: 4/5 - **2013** - [Senior Software Engineer · lead développeur PHP Symfony](https://portfolio.josedacosta.info/fr/parcours/medialeads-senior-engineer.md) (experience) - Confidence: 3/5 - **2017** - [Senior Software Engineer · lead développeur PHP Magento](https://portfolio.josedacosta.info/fr/parcours/smile-senior-engineer.md) (experience) - Confidence: 3/5 - **2019** - [Engineering Manager · Project Manager / Product Owner · Technical Lead](https://portfolio.josedacosta.info/fr/parcours/pichet-group.md) (experience) - Confidence: 4/5 - **2019** - [Technical Lead · Flux et Produits : contenus et intégration d'entreprise](https://portfolio.josedacosta.info/fr/parcours/pichet-technical-lead.md) (experience) - Confidence: 3/5 - **2023** - [Master Expert en Ingénierie du Logiciel](https://portfolio.josedacosta.info/fr/parcours/master-software-engineering.md) (education) - Confidence: 4/5 ## Réalisations associées - [Intelligent Accounting SaaS Platform](https://portfolio.josedacosta.info/fr/realisations/plateforme-comptabilite-saas.md) - Competitor security audit (IDOR, KYC) feeding the platform's secure-by-design conception - [Partner Lead Reception API Platform (alias PSR)](https://portfolio.josedacosta.info/fr/realisations/plateforme-api-reception-leads-partenaires.md) - APIM credential isolation, GDPR compliance and 2023 security audit Version interactive avec navigation : https://portfolio.josedacosta.info/fr/competences/securite-applicative-conformite