Sécuriser le site d’un professionnel de la finance, c’est d’abord chiffrer les échanges avec HTTPS, puis protéger tout ce que le HTTPS ne couvre pas : le CMS, les comptes administrateurs, les formulaires, l’espace client et la capacité à réagir en cas d’incident. Ces mesures sont documentées par l’ANSSI et la CNIL, et elles s’appliquent aussi bien à un cabinet de gestion de patrimoine qu’à une fintech.
Ce guide vous donne la liste de ces mesures, dans l’ordre où il est raisonnable de les traiter, avec les textes officiels sur lesquels elles s’appuient.
HTTPS repose sur le protocole TLS. Selon la CNIL, TLS sécurise les échanges de données en garantissant leur confidentialité et l’identité du site consulté. Pour cela, le site doit utiliser des certificats délivrés par une autorité de certification et les gérer correctement, y compris leur renouvellement.
Pour un visiteur, le cadenas dans la barre d’adresse signifie que la connexion est chiffrée. Il ne dit rien de la qualité du site, ni de l’honnêteté de son éditeur. Les navigateurs jugent d’ailleurs les données transmises en HTTP peu sûres et facilement interceptées.
Côté configuration, l’ANSSI indique que les versions préconisées pour HTTPS sont TLS 1.2 et TLS 1.3. Les anciennes versions, SSL compris, n’ont plus leur place sur un site qui recueille des données patrimoniales.
Le chiffrement protège le trajet entre le navigateur et le serveur. Il ne protège pas contre les failles applicatives comme les injections SQL ou les failles XSS, ni contre les logiciels malveillants. L’ANSSI rappelle aussi les risques de déclassement vers HTTP, de compromission des certificats et de vulnérabilités côté serveur ou poste client.
Une parade citée par l’ANSSI est le mécanisme HSTS, et en particulier l’inscription à une liste préchargée. Elle force le navigateur à utiliser HTTPS dès la première visite, ce qui ferme la fenêtre d’attaque de la toute première requête.
| Risque | Ce que HTTPS change | Mesure complémentaire |
|---|---|---|
| Interception des échanges | Protège contre l’écoute | TLS 1.2 ou 1.3, HSTS |
| Retour forcé vers HTTP | Ne protège pas seul | HSTS, HSTS preload |
| Faille du code (SQLi, XSS) | Aucun effet | Audits de code, mises à jour |
| Compte administrateur volé | Aucun effet | Authentification multifacteur |
| Logiciel malveillant sur un poste | Aucun effet | Poste protégé, droits limités |
Une précision utile si vous ajoutez un CDN, un pare-feu applicatif ou une protection anti-DDoS. La CNIL note que ces outils peuvent exposer des données en clair lors du déchiffrement TLS et entraîner des transferts hors de l’Union européenne. Vérifiez donc où le prestataire traite les données avant de l’activer.
Le site d’un CGP, d’un courtier ou d’une société de gestion collecte des données personnelles : coordonnées, situation patrimoniale, projets d’investissement. Le RGPD impose d’en assurer la sécurité. Nous détaillons les autres points dans notre guide sur le RGPD d’un site web financier.
Le Code pénal est explicite sur un point précis : l’article 226-17-1 punit de cinq ans d’emprisonnement et de 300 000 € d’amende le responsable de traitement qui ne notifie pas une violation de données personnelles. Savoir détecter un incident est donc une obligation, pas un confort.
Les acteurs régulés ont en plus un cadre sectoriel. Le règlement européen DORA sur la résilience opérationnelle numérique s’applique depuis le 17 janvier 2025 et concerne, sauf exceptions, l’ensemble des entités du secteur financier. Il couvre la gestion du risque informatique, le reporting des incidents, les tests de résilience et la gestion des prestataires informatiques. Selon votre statut, vérifiez avec votre conformité ce qui vous est applicable.
L’ANSSI publie des guides précis pour les sites web et les CMS. Leurs recommandations tiennent en une liste de contrôle que votre prestataire ou votre équipe peut dérouler.
Le CMS est souvent le maillon faible, parce qu’un site financier évolue vite : nouvelles pages, nouveaux formulaires, nouveaux outils de suivi. Chaque extension ajoutée élargit la surface d’attaque. Un plugin abandonné par son éditeur est une porte laissée ouverte, même si le site paraît sain.
Le sujet est aussi pédagogique : vos équipes doivent comprendre pourquoi on refuse un mot de passe partagé ou une extension de confort. Des contenus vidéo et motion design peuvent aider à expliquer ces règles de façon claire aux collaborateurs qui ont un accès au back office.
Limitez les comptes au nombre de personnes qui en ont réellement besoin. La CNIL déconseille dans son guide de sécurité les comptes génériques partagés entre plusieurs utilisateurs, car ils empêchent de savoir qui a fait quoi. Chaque intervenant externe, y compris une agence ou un freelance, doit avoir son propre compte, retiré à la fin de la mission.
Un formulaire de contact ou de prise de rendez-vous transporte des informations sensibles. Il doit transiter en HTTPS, ne collecter que ce qui est utile et envoyer les données vers un espace de stockage protégé, jamais vers une simple boîte mail partagée sans contrôle d’accès.
Un espace client demande davantage : authentification solide, droits par profil et protection de chaque document. Le cas sanctionné par la CNIL est parlant. Dans une délibération de décembre 2018, elle a sanctionné une entreprise dont une faille permettait d’accéder à des documents de clients sans authentification. Une erreur humaine avait laissé désactivé le code d’authentification, et des tests et audits inadaptés n’avaient pas détecté la vulnérabilité.
La leçon est pratique : ce n’est pas l’outil qui a failli, c’est l’absence de contrôle. Chaque mise en production d’un module qui touche à des données clients mérite un test d’accès explicite, par exemple vérifier qu’une URL de document ne s’ouvre pas sans connexion.
| Élément du site | Point de contrôle |
|---|---|
| Formulaire de contact | HTTPS, champs limités, stockage protégé |
| Prise de rendez-vous | Données minimales, durée de conservation définie |
| Espace client | Authentification forte, droits par profil, accès aux documents testé |
| Back office du CMS | Authentification multifacteur, comptes nominatifs |
| Pages légales | Mentions et politique de confidentialité à jour |
La liste des pages que doit comporter un site de conseiller est détaillée dans notre article sur les pages obligatoires d’un site CGP.
La sécurité n’est pas un état, c’est un cycle. L’ANSSI recommande de planifier des audits de sécurité et de qualité du code pendant toute la vie du système, et de mettre en place des mécanismes de détection, de journalisation et d’alerte. Pour le secteur financier, le cadre international du G7 insiste aussi sur une surveillance périodique incluant tests et audits.
Un rythme simple à adopter :
Prévoyez aussi, avant d’en avoir besoin, une fiche réflexe d’incident : qui coupe l’accès, qui contacte l’hébergeur, qui informe le délégué à la protection des données ou le référent, et qui décide de la notification. Une refonte est un moment à risque : notre méthode de refonte de site fintech intègre ces contrôles.
Dans la finance, un site est souvent le premier point de contact avant un rendez-vous. Le prospect ne juge pas seulement votre discours : il remarque un certificat expiré, un formulaire bancal ou une page qui s’affiche mal. Pour un métier qui repose sur la confiance, ces détails comptent.
Nous accompagnons des conseillers en gestion de patrimoine, des courtiers, des fintechs et des sociétés de gestion. Notre connaissance de l’écosystème financier, de ses enjeux réglementaires et de ses cycles de vente longs nous amène à traiter le site comme un outil commercial, dont la fiabilité technique est une composante du positionnement.
Notre approche consiste à cadrer ces exigences dès la conception ou la refonte, avec les bons prestataires techniques, plutôt que de les découvrir après un incident. Cela évite de recruter une équipe marketing interne tout en gardant un site cohérent avec votre image.
Digital Dandy
Un site sécurisé, rapide et conforme renforce votre crédibilité auprès de prospects exigeants. Chez Digital Dandy, nous aidons les acteurs de la finance à structurer leur positionnement de marque, leur site et leur communication, par exemple à travers notre offre Marque et positionnement ou un atelier sur-mesure.
Si vous préparez une refonte ou souhaitez cadrer votre présence en ligne, échangeons sur votre projet. Pour aller plus loin sur les autres exigences d’un site financier, consultez aussi notre guide sur l’accessibilité d’un site financier et celui sur les Core Web Vitals en finance.
Non. HTTPS chiffre les échanges entre le visiteur et le serveur, mais il ne protège pas contre les failles du code, les logiciels malveillants ou un compte administrateur compromis. Il se complète par HSTS, l’authentification multifacteur, des mises à jour régulières et des audits.
L’ANSSI préconise TLS 1.2 et TLS 1.3 pour HTTPS. Désactivez les versions plus anciennes sur votre serveur. Votre hébergeur ou votre prestataire technique peut vérifier cette configuration et vous la documenter.
Isolez l’accès concerné, conservez les journaux et prévenez immédiatement votre référent protection des données. Le responsable de traitement doit notifier la violation, et le Code pénal sanctionne l’absence de notification. Pour la procédure exacte, rapprochez-vous de la CNIL et de votre conseil juridique.
Oui. L’ANSSI recommande de ne garder que les plugins et thèmes strictement nécessaires, activement maintenus et validés par leur éditeur. Chaque extension supprimée réduit la surface d’attaque et le travail de mise à jour.
L’ANSSI demande des audits planifiés pendant toute la vie du système. En pratique, prévoyez des contrôles mensuels et trimestriels en interne, et un audit externe au moins après chaque refonte ou ajout important, comme un espace client.
