Ce guide s'adresse aux dirigeants, DSI et entrepreneurs qui veulent comprendre les enjeux de la sécurité mobile, éviter les erreurs coûteuses, et savoir comment choisir un prestataire qui prend la sécurité au sérieux.
---
Table des matières
---
1. Pourquoi la sécurité mobile est une priorité stratégique en 2026 {#pourquoi}
Le smartphone est devenu le terminal de travail principal pour des millions de collaborateurs français. Applications métier, CRM mobile, outils de gestion terrain, tableaux de bord dirigeants — nos données les plus sensibles transitent quotidiennement par des applications mobiles.
Cette centralisation des données crée des surfaces d'attaque inédites. En 2025, selon le rapport Verizon Data Breach Investigations, les attaques exploitant des vulnérabilités dans les applications mobiles ont augmenté de 34% par rapport à l'année précédente. Les PME françaises, souvent moins bien protégées que les grands groupes, représentent une cible de choix.
Les conséquences concrètes d'une faille de sécurité
Quand une application mobile est compromise, les conséquences sont multiples et graves :
Financières : Coût moyen d'une violation de données en France : 4,05 millions d'euros (source : IBM Cost of a Data Breach Report 2025). Ce montant inclut la détection, la notification des victimes, les pertes business, les frais juridiques et les amendes réglementaires. Réglementaires : La CNIL a infligé plus de 50 millions d'euros d'amendes à des entreprises françaises en 2025 pour des manquements au RGPD liés à des applications mobiles. Les amendes peuvent atteindre 20 millions d'euros ou 4% du CA mondial annuel. Réputationnelles : 65% des utilisateurs français déclarent qu'ils cesseraient d'utiliser une application après une violation de leurs données personnelles, selon une étude Ipsos 2025. Opérationnelles : Une application compromise peut être neutralisée par des pirates (ransomware mobile), paralysant l'activité pendant des jours ou des semaines.Les secteurs les plus exposés
Certains secteurs sont particulièrement ciblés car leurs applications mobiles manipulent des données à haute valeur :
- Fintech et paiement : données bancaires, transactions financières
- Santé : données médicales (parmi les plus sensibles sous le RGPD)
- RH et paie : données personnelles, salaires, contrats
- Commerce : coordonnées clients, historiques d'achats
- Industrie et BTP : plans, données de production, propriété intellectuelle
---
2. Les principales menaces qui ciblent vos applications mobiles {#menaces}
Comprendre les menaces est la première étape pour s'en protéger. Voici les attaques les plus fréquentes en 2026 :
Les injections (SQLi, XSS, etc.)
Les injections restent l'attaque n°1 contre les applications mobiles. Un attaquant exploite un champ de saisie mal sécurisé pour injecter du code malveillant et accéder à la base de données. En 2025, 30% des violations de données dans les applications mobiles impliquaient ce type d'attaque.
Exemple concret : Un formulaire de connexion qui n'est pas correctement sécurisé permet à un attaquant de bypasser l'authentification et d'accéder à tous les comptes utilisateurs.Le Man-in-the-Middle (MITM)
Quand une application envoie des données sans chiffrement robuste (ou avec un chiffrement mal configuré), un attaquant positionné entre l'app et le serveur peut intercepter et lire toutes les communications : mots de passe, tokens d'authentification, données personnelles.
Les réseaux WiFi publics (hôtels, aéroports, cafés) sont le terrain de jeu favori des attaques MITM. Si vos collaborateurs utilisent votre application depuis ces réseaux sans protection adéquate, ils sont exposés.Le vol de tokens et sessions
Les applications mobiles utilisent des tokens (jetons d'authentification) pour maintenir les utilisateurs connectés. Si ces tokens sont mal stockés (dans le stockage non sécurisé du device, dans les logs, dans des variables non chiffrées), ils peuvent être volés par un malware ou lors d'un accès physique au téléphone.
Les applications clones et fausses mises à jour
Des pirates créent des copies quasi-identiques de votre application et les distribuent via des canaux non officiels. Les utilisateurs qui les téléchargent divulguent leurs credentials à des imposteurs.
En 2025, des milliers d'applications mobiles françaises ont été clonées. Les cibles favorites : applications de paiement, applications RH (pour voler les credentials des employés), applications e-commerce.
Les vulnérabilités dans les librairies tierces
Une application mobile moderne utilise des dizaines de librairies open-source. Si l'une d'elles contient une faille de sécurité non patchée, toute votre application est exposée. En 2025, l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) a recensé 47 vulnérabilités critiques dans des librairies très utilisées dans les apps mobiles.
Le reverse engineering
Des concurrents malveillants ou des pirates peuvent "décompiler" votre application pour analyser son code, découvrir des secrets (clés API, algorithmes propriétaires), et trouver des failles à exploiter. Sans obfuscation du code, votre application est un livre ouvert.
Les attaques sur les APIs
L'application mobile n'est que la face visible de l'iceberg. Derrière, des APIs (interfaces de programmation) connectent votre app à vos bases de données et services. Des APIs mal sécurisées sont souvent le vrai point d'entrée des attaques sophistiquées.
---
3. Les 10 exigences de sécurité incontournables {#exigences}
Le standard de référence mondial en sécurité des applications mobiles est l'OWASP Mobile Application Security Verification Standard (MASVS). Voici les 10 exigences fondamentales que toute application mobile professionnelle doit respecter :
1. Chiffrement des données au repos
Toutes les données sensibles stockées sur le device doivent être chiffrées. Cela inclut les bases de données locales (SQLite), les fichiers de configuration, les tokens d'authentification et les données mises en cache.
Standard technique : AES-256 minimum, utilisation du Keystore Android et du Secure Enclave iOS pour les clés cryptographiques.2. Chiffrement des données en transit
Toutes les communications entre l'application et le serveur doivent être chiffrées via TLS 1.3 (le standard 2026). Le Certificate Pinning est recommandé pour les applications manipulant des données très sensibles : il lie l'application à un certificat SSL spécifique, rendant les attaques MITM impossibles même sur des réseaux compromis.
3. Authentification robuste
En 2026, les mots de passe seuls ne suffisent plus. Les bonnes pratiques incluent :
- Authentification à deux facteurs (2FA) obligatoire pour les actions sensibles
- Biométrie (Face ID, Touch ID) pour une expérience fluide et sécurisée
- FIDO2/Passkeys comme alternative aux mots de passe traditionnels
- Délai d'expiration des sessions configurable selon le niveau de sensibilité
4. Gestion sécurisée des mots de passe
- Jamais de mots de passe en clair dans le code (hard-coded credentials)
- Politique de mots de passe forts imposée
- Hachage avec algorithme moderne (Argon2, bcrypt) côté serveur
- Blocage des comptes après N tentatives échouées
5. Validation des entrées côté serveur
Toujours. La validation côté client (dans l'application) peut être contournée. Seule la validation côté serveur est fiable. Cela inclut la protection contre les injections SQL, les injections de commandes, et les attaques XSS.6. Obfuscation et anti-tampering
Le code de l'application doit être obfusqué pour rendre le reverse engineering difficile. Les mécanismes anti-tampering détectent si l'application a été modifiée ou si elle tourne dans un environnement de débogage suspect.
7. Gestion sécurisée des secrets
Clés API, tokens d'accès, secrets de configuration — ils ne doivent jamais se trouver dans le code source. Ils doivent être stockés dans des vaults sécurisés (HashiCorp Vault, AWS Secrets Manager) et injectés au runtime de façon sécurisée.
8. Journalisation et monitoring
Toute action sensible doit être loggée avec horodatage, identifiant utilisateur et données de contexte. Un système de détection d'anomalies (SIEM) doit alerter en temps réel sur les comportements suspects (tentatives de connexion multiples, accès depuis des géolocalisations inhabituelles, etc.).
9. Mises à jour de sécurité
L'application doit avoir un mécanisme de mise à jour forcée pour permettre de déployer rapidement des correctifs de sécurité critiques. Les librairies tierces doivent être auditées régulièrement et mises à jour.
10. Tests de pénétration réguliers
Une application n'est jamais "définitivement sécurisée". Les menaces évoluent, le code change, de nouvelles vulnérabilités apparaissent. Des pentests réguliers (au moins annuels pour les applications B2B, semestriels pour le fintech/santé) sont indispensables.
---
4. Conformité RGPD et applications mobiles {#rgpd}
Le RGPD (Règlement Général sur la Protection des Données) impose des obligations précises aux applications mobiles qui collectent des données personnelles d'utilisateurs européens. Et en 2026, la CNIL est de plus en plus active dans l'audit des applications mobiles.
Ce que le RGPD impose pour les applications mobiles
1. Consentement explicite et granulaireL'application doit obtenir un consentement clair et explicite pour chaque type de traitement de données. Les cases pré-cochées, les consentements globaux, et les interfaces trompeuses ("dark patterns") sont interdits et sanctionnés.
Depuis l'arrêté de la CNIL de 2024, les bannières de consentement dans les applications mobiles doivent proposer un refus aussi facilement qu'une acceptation — fini le bouton "Accepter" gros et vert face à un lien "Paramétrer" quasi-invisible.
2. Minimisation des donnéesL'application ne peut collecter que les données strictement nécessaires à sa fonction. Collecter la géolocalisation en continu d'un utilisateur quand votre application n'en a besoin qu'une fois par semaine, c'est une violation du principe de minimisation.
3. Droit à l'effacement ("droit à l'oubli")Les utilisateurs ont le droit de demander la suppression de toutes leurs données. L'application doit implémenter un mécanisme de suppression complet : profil, historique, données analytiques, sauvegardes. Et cette suppression doit être réelle, pas juste un marquage "inactif" dans la base de données.
4. Portabilité des donnéesLes utilisateurs peuvent demander l'export de leurs données dans un format lisible et interopérable (JSON, CSV). Cette fonctionnalité doit être intégrée dans l'application.
5. Transparence sur les traitementsLa politique de confidentialité doit être claire, accessible depuis l'application, et expliquer en langage simple : quelles données sont collectées, pourquoi, combien de temps elles sont conservées, et avec qui elles sont partagées.
6. Hébergement des donnéesPour les données sensibles (santé, finances), le RGPD recommande fortement — et certaines réglementations sectorielles imposent — un hébergement sur des serveurs physiquement localisés dans l'UE. Exit les serveurs en Chine ou dans certains contextes aux États-Unis, qui posent des problèmes légaux de transfert de données.
7. Analyse d'impact (DPIA)Pour les traitements à risque élevé (profilage, données de santé, surveillance de collaborateurs), une Analyse d'Impact relative à la Protection des Données (DPIA) est obligatoire avant le lancement de l'application.
Les sanctions de la CNIL en 2025 : les cas emblématiques
- 5,3 millions d'euros pour une application de mobilité qui collectait la géolocalisation en continu sans consentement valide
- 3,8 millions d'euros pour une application e-commerce dont le SDK analytique transmettait des données à des tiers sans information des utilisateurs
- 1,9 million d'euros pour une application RH qui ne respectait pas le droit d'accès des employés à leurs données
---
5. La directive NIS2 et ses implications pour le mobile {#nis2}
La directive NIS2, transposée en droit français en 2024, étend significativement le périmètre des entreprises soumises à des obligations de cybersécurité. Si votre entreprise opère dans un secteur "essentiel" ou "important", vous êtes désormais soumis à des exigences renforcées qui incluent la sécurité de vos applications mobiles.
Secteurs concernés par NIS2
Secteurs essentiels : Énergie, transports, banque, infrastructures des marchés financiers, santé, eau potable, eaux usées, infrastructures numériques, administration publique, espace. Secteurs importants : Services postaux, gestion des déchets, fabrication, production et distribution de produits chimiques, production, transformation et distribution de denrées alimentaires, fabrication (médical, électronique, mécanique, automobile), fournisseurs de services numériques.Obligations NIS2 pour les applications mobiles
- Évaluation des risques et politiques de sécurité documentées pour toutes les applications
- Plan de continuité et procédures de gestion des incidents de sécurité
- Sécurité de la chaîne d'approvisionnement : audit des prestataires et partenaires (incluant vos développeurs d'applications)
- Notification obligatoire des incidents dans les 24h pour les incidents significatifs, 72h pour le rapport complet
- Tests et audits réguliers des systèmes d'information, incluant les applications mobiles
Les sanctions en cas de non-conformité NIS2 peuvent atteindre 10 millions d'euros ou 2% du chiffre d'affaires mondial pour les entités essentielles.
---
6. Sécurité by Design : comment construire une app sécurisée dès le départ {#security-by-design}
La sécurité intégrée dès la conception (Security by Design) est l'approche préconisée par l'ANSSI et l'OWASP. Elle coûte 3 à 5 fois moins cher que corriger les failles de sécurité après le développement.
L'approche DevSecOps
Le DevSecOps intègre la sécurité à chaque étape du cycle de développement :
Phase de conception :- Threat modeling : identifier les menaces potentielles avant de coder
- Privacy Impact Assessment : cartographier les données personnelles traitées
- Architecture Zero Trust : chaque composant valide l'identité de chaque autre
- Revues de code avec focus sécurité (pair review systématique)
- Linting sécuritaire : outils d'analyse statique (SAST) intégrés dans l'IDE
- Bibliothèque de patterns sécurisés pour les fonctions critiques
- Tests de sécurité automatisés dans la CI/CD
- Scan des dépendances (OWASP Dependency Check)
- Tests d'intrusion sur les versions pre-prod
- Secrets management (pas de credentials en dur)
- Hardening de l'infrastructure
- Monitoring et alerting en temps réel
Le coût comparé de la sécurité
| Moment d'intégration de la sécurité | Coût relatif |
|-------------------------------------|-------------|
| Conception (Security by Design) | 1x |
| Pendant le développement | 6x |
| Après les tests | 15x |
| Après le déploiement | 64x |
| Après une violation | 100x+ |
Source : IBM Systems Sciences Institute
---
7. Combien coûte la sécurité d'une application mobile ? {#couts}
La sécurité a un coût. Mais ce coût est toujours inférieur au coût d'une violation de données. Voici les budgets réalistes pour le marché français 2026 :
Budget de sécurité intégré au développement
Pour une application standard (e-commerce, application métier, SaaS) :
- Sécurité de base (chiffrement, authentification, validation des entrées) : inclus dans le développement standard chez un bon prestataire
- Sécurité intermédiaire (2FA, Certificate Pinning, obfuscation, conformité RGPD) : +15 à 25% du budget de développement
- Sécurité avancée (pentest, audit OWASP MASVS, conformité NIS2) : +25 à 40% du budget de développement
Coût d'un audit de sécurité (pentest)
- Application standard (20-50 écrans) : 5 000€ à 15 000€
- Application complexe (50-100 écrans, APIs multiples) : 15 000€ à 35 000€
- Application critique (fintech, santé, infrastructure) : 35 000€ à 100 000€+
Coût de la conformité RGPD
- Mise en conformité initiale d'une application existante : 3 000€ à 15 000€ selon la complexité
- Intégration native RGPD lors du développement : 2 000€ à 8 000€
- DPO externalisé (si obligation) : 800€ à 3 000€ par mois
Comparaison avec le coût d'une faille
| Scénario | Coût estimé |
|----------|------------|
| Fuite de 1 000 données clients | 50 000€ à 500 000€ (sanctions + notification + gestion crise) |
| Application compromis par ransomware | 100 000€ à 2 000 000€ (arrêt activité + rançon + récupération) |
| Amende CNIL | 10 000€ à 50 000 000€ selon la violation |
| Atteinte à la réputation | Incalculable, mais 65% de perte clients après une violation |
---
8. Questions essentielles à poser à votre développeur {#questions}
Quand vous évaluez un prestataire de développement mobile, voici les questions qui révèlent leur niveau de maturité en sécurité :
Questions techniques
Questions process et organisation
Questions RGPD
---
9. Pourquoi choisir RapidCraft pour une application sécurisée {#rapidcraft}
Chez RapidCraft, la sécurité n'est pas une option ou un module ajouté en fin de projet — c'est un principe fondamental intégré dans notre processus depuis la première ligne de code.
Notre approche Security by Design :- Threat modeling systématique en phase de conception pour chaque projet
- Code review avec checklist de sécurité OWASP sur chaque Pull Request
- Pipeline CI/CD avec scan automatique des vulnérabilités (SonarQube + OWASP Dependency Check)
- Secrets management via vault sécurisé — jamais de credentials dans le code
- Chiffrement natif : AES-256 au repos, TLS 1.3 en transit, Keychain/Keystore pour les tokens
- Mise en conformité RGPD documentée sur tous nos projets
- Hébergement en France ou dans l'UE systématiquement proposé
- Implémentation des 8 droits RGPD (accès, rectification, effacement, portabilité...)
- Templates de politique de confidentialité conformes aux dernières directives CNIL
Nous livrons, avec chaque application, un rapport de sécurité documentant les mesures implémentées, les choix architecturaux, et les recommandations pour les évolutions futures. Vous ne signez pas un chèque en blanc — vous savez précisément ce qui protège votre application.
Notre réseau de partenaires sécurité :Pour les applications critiques (fintech, santé, infrastructure), nous travaillons avec des auditeurs de sécurité indépendants certifiés OSCP/CREST pour les pentests. Vous bénéficiez d'un regard externe impartial sur la sécurité de votre application.
---
Conclusion : La sécurité est un investissement, pas un coût
En 2026, négliger la sécurité de son application mobile, c'est prendre un risque financier, juridique et réputationnel considérable. Les amendes RGPD, les coûts d'une violation de données, et la perte de confiance des utilisateurs coûtent systématiquement bien plus cher que d'avoir bien fait les choses dès le départ.
La bonne nouvelle : une application mobile sécurisée est aussi une application de qualité. Les pratiques de sécurité (validation des entrées, gestion robuste des erreurs, code bien structuré) améliorent aussi la stabilité et les performances.
Choisir un prestataire qui prend la sécurité au sérieux, c'est choisir un partenaire qui pense à long terme.
---
Sécurisez votre application avec RapidCraft
Vous avez un projet d'application mobile ou vous voulez auditer la sécurité d'une application existante ? RapidCraft propose un audit de sécurité gratuit de vos spécifications ou de votre application existante.
En 60 minutes d'échange, nous identifions les risques majeurs et vous proposons un plan d'action concret.
Contactez-nous : Parce qu'une application non sécurisée n'est pas seulement un risque technique — c'est un risque pour votre business.---
Sources
- IBM Security — Cost of a Data Breach Report 2025 (ibm.com/security)
- Verizon — 2025 Data Breach Investigations Report (verizon.com/business/resources/reports/dbir)
- ANSSI — Guide de sécurité des applications mobiles (ssi.gouv.fr)
- CNIL — Rapports d'activité et sanctions 2025 (cnil.fr)
- OWASP — Mobile Application Security Verification Standard (MASVS) (owasp.org)
- Appinventiv — Why Enterprise Application Security Matters (appinventiv.com/blog/enterprise-application-security)
- Directive NIS2 — Journal Officiel de l'Union Européenne 2022/2555 et transposition française 2024
- IBM Systems Sciences Institute — Coût relatif de la correction des bugs selon leur phase de découverte
---
10. Les outils et frameworks de sécurité à connaître {#outils}
Pour les décideurs qui veulent comprendre ce que leur prestataire devrait utiliser, voici les principaux standards et outils de sécurité mobile en 2026 :
Les standards de référence
OWASP Mobile Top 10 (2025) : La liste des 10 vulnérabilités les plus critiques dans les applications mobiles, mise à jour annuellement par l'Open Web Application Security Project. Tout développeur mobile sérieux connaît cette liste par cœur. OWASP MASVS (Mobile Application Security Verification Standard) : Un framework de vérification de la sécurité en 3 niveaux selon la sensibilité des données :- Niveau 1 (L1) : Sécurité de base, toutes les applications
- Niveau 2 (L2) : Défense en profondeur, applications manipulant des données sensibles
- Niveau R (Résistance) : Contre-mesures contre le reverse engineering, applications très critiques
Les outils d'analyse de code
SonarQube : Analyse statique du code (SAST) qui détecte les vulnérabilités dans le code source. S'intègre dans la pipeline CI/CD pour bloquer automatiquement les développements contenant des failles. Checkmarx : Outil d'analyse de sécurité des applications mobiles iOS et Android, très utilisé en entreprise. OWASP Dependency Check : Scan automatique des librairies tierces pour détecter les CVE (Common Vulnerabilities and Exposures) connues. Snyk : Analyse en temps réel des dépendances open-source avec alertes automatiques quand une nouvelle vulnérabilité est découverte.Les outils de test dynamique
OWASP ZAP (Zed Attack Proxy) : Outil de test dynamique (DAST) qui simule des attaques sur une application en fonctionnement. Burp Suite : L'outil de référence des pentesters professionnels pour analyser les communications entre une application mobile et son backend. Frida : Framework d'instrumentation dynamique qui permet d'analyser le comportement d'une application en temps réel — utilisé par les auditeurs de sécurité et les développeurs pour tester la résistance au reverse engineering. MobSF (Mobile Security Framework) : Plateforme d'analyse de sécurité mobile open-source qui combine analyse statique et dynamique.---
11. Sécurité des APIs : le maillon faible souvent négligé {#api-security}
Les applications mobiles ne sont que la partie visible. Derrière, les APIs (interfaces de programmation) qui connectent l'app à vos bases de données et services sont souvent le point d'entrée privilégié des attaquants. L'OWASP maintient une liste spécifique des 10 vulnérabilités les plus critiques des APIs (OWASP API Top 10).
Les vulnérabilités API les plus exploitées
Broken Object Level Authorization (BOLA) : L'API ne vérifie pas que l'utilisateur est bien autorisé à accéder à la ressource demandée. Exemple : l'URL/api/factures/12345 renvoie la facture d'un autre client si l'utilisateur change simplement l'ID.
Excessive Data Exposure : L'API renvoie plus de données que nécessaire, laissant au client le soin de filtrer. Un attaquant qui intercepte la réponse accède à toutes les données, pas seulement celles affichées.
Broken Authentication : Tokens mal signés, sessions non expirées, lack of rate limiting sur les endpoints d'authentification — des failles qui permettent aux attaquants de s'emparer de comptes.
Injection : Les requêtes SQL, NoSQL, et de commandes construites à partir d'entrées utilisateur non sanitisées restent très répandues malgré leur ancienneté.
Les bonnes pratiques pour sécuriser vos APIs
---
12. Plan de réponse aux incidents : que faire quand ça arrive ? {#incident-response}
Même avec les meilleures mesures de sécurité, un incident peut survenir. La différence entre une entreprise résiliente et une entreprise dévastée, c'est la qualité de sa réponse.
Les 6 phases de gestion d'un incident de sécurité
Phase 1 — Préparation (avant l'incident)- Constitution d'une équipe de réponse aux incidents (interne ou via un prestataire)
- Documentation des procédures d'escalade
- Mise en place du monitoring et des alertes
- Formation des équipes aux procédures à suivre
- Identification de l'indicateur d'attaque (IOA) ou de compromission (IOC)
- Analyse des logs pour comprendre l'étendue de l'incident
- Évaluation de la criticité et priorisation de la réponse
- Isolation des systèmes compromis pour stopper la propagation
- Révocation des tokens et sessions compromis
- Blocage des vecteurs d'attaque identifiés
- Suppression du malware ou du backdoor
- Correction de la vulnérabilité exploitée
- Nettoyage des systèmes affectés
- Restauration depuis des sauvegardes saines
- Retour progressif en production
- Monitoring renforcé post-incident
- Post-mortem sans jugement pour comprendre ce qui s'est passé
- Amélioration des processus et contrôles
- Documentation pour éviter la répétition
Les obligations de notification RGPD et NIS2
En cas de violation de données personnelles, vous avez l'obligation légale de :
- Notifier la CNIL dans les 72 heures suivant la découverte de l'incident
- Notifier les personnes concernées sans délai indu si l'incident est susceptible d'engendrer un risque élevé pour leurs droits
- Documenter tous les incidents, même mineurs, dans un registre interne
Le non-respect de ces obligations aggrave considérablement les sanctions.
---
13. Checklist sécurité avant le lancement de votre application {#checklist}
Avant de lancer votre application mobile en production, voici la checklist de sécurité minimale à valider avec votre développeur :
Authentification et sessions
- [ ] Politique de mots de passe robuste implémentée et documentée
- [ ] Authentification à deux facteurs disponible et configurée
- [ ] Tokens JWT correctement signés et à durée de vie limitée
- [ ] Mécanisme de déconnexion totale (révocation de tous les tokens actifs)
- [ ] Verrouillage de compte après N tentatives échouées
- [ ] Sessions côté serveur, pas uniquement côté client
Chiffrement et stockage
- [ ] Toutes les communications en HTTPS/TLS 1.3
- [ ] Certificats SSL valides et Certificate Pinning si applicable
- [ ] Données sensibles chiffrées sur le device (Keychain iOS / Keystore Android)
- [ ] Aucune donnée sensible dans les logs ou les fichiers temporaires
- [ ] Secrets et clés API absents du code source
Validation et traitement des données
- [ ] Validation des entrées côté serveur (pas seulement côté client)
- [ ] Protection contre les injections SQL, NoSQL, LDAP
- [ ] Protection contre les attaques XSS et CSRF
- [ ] Taille maximale des fichiers uploadés limitée et validée
- [ ] Types de fichiers acceptés filtrés et vérifiés
Configuration et infrastructure
- [ ] Mode debug désactivé en production
- [ ] Messages d'erreur génériques (pas de stack traces exposées)
- [ ] Headers de sécurité HTTP configurés (HSTS, CSP, X-Frame-Options...)
- [ ] Firewall et WAF (Web Application Firewall) en place
- [ ] Monitoring et alertes configurés
RGPD et conformité
- [ ] Politique de confidentialité à jour et accessible
- [ ] Mécanisme de consentement conforme CNIL 2024
- [ ] Implémentation du droit à l'effacement
- [ ] Implémentation de la portabilité des données
- [ ] DPA (Data Processing Agreement) signé avec tous les sous-traitants
---
14. Sécurité mobile par secteur : les spécificités à connaître {#par-secteur}
La sécurité d'une application de livraison de repas n'a pas les mêmes exigences qu'une application de gestion de santé. Voici les spécificités sectorielles les plus importantes.
Fintech et paiement mobile
C'est le secteur soumis aux exigences les plus strictes. En plus du RGPD, les applications de paiement doivent se conformer à :
PCI-DSS (Payment Card Industry Data Security Standard) : Le standard de sécurité des données de paiement. Si votre application traite des données de cartes bancaires, la conformité PCI-DSS est obligatoire et nécessite un audit annuel par un auditeur certifié QSA. DSP2 (Directive sur les Services de Paiement 2) : Impose l'authentification forte du client (SCA — Strong Customer Authentication) pour toutes les transactions en ligne. Concrètement : l'utilisation d'au moins deux facteurs d'authentification parmi quelque chose que l'utilisateur connaît (PIN), possède (smartphone) et est (biométrie). Exigences spécifiques pour les fintech :- Chiffrement de bout en bout des données de paiement
- Tokenisation des numéros de carte (jamais stockés en clair)
- Surveillance des transactions en temps réel (détection de fraude)
- Tests de pénétration semestriels minimum
- Journalisation immuable de toutes les transactions
Santé numérique (e-Santé)
Les données de santé sont qualifiées de "données sensibles" par le RGPD (article 9) et bénéficient d'une protection renforcée. En France, s'y ajoutent des réglementations spécifiques :
HDS (Hébergement de Données de Santé) : Tout hébergement de données de santé à caractère personnel doit être réalisé par un hébergeur certifié HDS par l'ANS (Agence du Numérique en Santé). Les grandes plateformes cloud (AWS, Azure, GCP) ont des offres HDS certifiées en France. Le Référentiel de Sécurité de l'ANS : Les applications de santé numériques référencées au remboursement (label "Mon Espace Santé") doivent respecter un référentiel de sécurité publié par l'ANS. Règlement européen IVDR/MDR : Les applications mobiles qui constituent des dispositifs médicaux (diagnostic, traitement) sont soumises à des certifications CE et des contrôles de qualité spécifiques.Applications RH et paie
Les applications RH traitent des données parmi les plus sensibles au sens du RGPD : données personnelles des salariés, salaires, données de santé (arrêts maladie), données syndicales, évaluations professionnelles...
Exigences spécifiques :- Droits d'accès très granulaires (un manager ne voit que ses équipes, pas toute l'entreprise)
- Historisation immuable de toutes les modifications
- Durées de conservation strictement définies et automatisées
- Anonymisation/pseudonymisation pour les usages analytiques
- Information préalable des salariés sur les traitements (obligation légale)
Applications e-commerce et retail
Conformité RGPD pour la publicité ciblée : Depuis 2024, les applications qui pratiquent le ciblage publicitaire doivent obtenir un consentement explicite pour chaque finalité (profilage, publicité, partage avec partenaires). Les pratiques de "fingerprinting" et de suivi cross-device sont encadrées strictement. Sécurité des données de paiement : Même sans traiter directement des données de carte (via Stripe, PayPal...), vous restez responsable de la sécurité du flux de paiement de bout en bout. Protection contre les bots et la fraude : Les applications e-commerce sont ciblées par des attaques automatisées (credential stuffing, card testing, scalping). Des protections anti-bot et des systèmes de détection de fraude sont indispensables.---
15. Préparer le budget sécurité de votre roadmap produit {#budget-roadmap}
La sécurité n'est pas un projet ponctuel mais un processus continu. Voici comment intégrer les dépenses de sécurité dans votre planification produit.
Année 1 : Poser les fondations
Au lancement (budgétisez 15-25% du budget de développement) :- Architecture sécurisée dès la conception
- Implémentation RGPD native
- Configuration infrastructure sécurisée (WAF, monitoring)
- Pentest de lancement (5 000 à 15 000€)
Année 2-3 : Renforcer et certifier
Evolution et certification :- Pentest annuel (5 000 à 20 000€)
- Mise en conformité NIS2 si applicable
- Intégration d'outils de monitoring avancés (SIEM)
- Formation continue de l'équipe développement
En continu
Charges récurrentes annuelles :- Abonnements outils de sécurité (scanning, monitoring) : 2 000 à 10 000€/an
- DPO externalisé si requis : 10 000 à 30 000€/an
- Veille sécurité et mises à jour : inclus dans contrat de maintenance
- Assurance cyber : 3 000 à 30 000€/an selon la taille et le secteur
L'assurance cyber : une protection complémentaire indispensable
En 2026, l'assurance cyber est devenue aussi indispensable que l'assurance RC Pro pour les entreprises numériques. Elle couvre :
- Les coûts de réponse à incident (investigation forensique, notification CNIL, gestion de crise)
- Les pertes d'exploitation pendant l'indisponibilité
- Les rançons en cas de ransomware (sous conditions)
- La responsabilité civile en cas de préjudice causé à des tiers
