Quel socle de sécurité exiger pour une application métier ?

Avant de charger de vraies données, posez une question plus utile que « l’application est-elle sécurisée ? » : qui pourrait voir, modifier, bloquer ou perdre quoi, et quel serait l’effet sur l’activité ?

Attribuez un responsable à chaque mesure et demandez des traces observables sur quatre capacités : prévenir, détecter, reprendre et répondre. Une procédure écrite compte, mais un contrôle critique doit aussi être exercé.

Restaurez l’application dans un environnement isolé. Déclenchez un événement autorisé et vérifiez que l’alerte arrive à la bonne personne. Rejouez la première heure d’un incident.

Si l’impact, la preuve ou le responsable d’un point décisif reste inconnu, limitez le pilote ou reportez la mise en service avec de vraies données.

« Cyberattaque » est trop large pour décider. Décrivez plutôt ce qu’une personne, une erreur, un composant ou une panne pourrait provoquer. Cette formulation aide le métier à fixer les priorités et l’équipe technique à proposer des contrôles vérifiables.

Pour rendre la ligne « contrôle d’accès » testable, définissez qui peut voir et modifier quoi objet par objet, puis associez à chaque autorisation critique un cas autorisé et un cas refusé.

Pour un traitement de données personnelles, l’article 32 du règlement général sur la protection des données (RGPD) demande au responsable du traitement et au sous-traitant des mesures techniques et organisationnelles appropriées au risque pour les droits et libertés des personnes. Il cite, selon le cas, confidentialité, intégrité, disponibilité, résilience, restauration et évaluation régulière. Il ne fournit pas une fréquence de sauvegarde ou une architecture universelle.

Une fois ces conséquences décrites, reliez chaque mesure à ce qu’elle doit empêcher, révéler ou permettre de reprendre. Vous pourrez alors demander l’élément précis qui l’étaye.

Une mesure isolée déplace parfois le problème. Un accès bloqué aide peu si les secrets fuient ailleurs. Des journaux sans alerte laissent l’événement dormir. Et restaurer uniquement la base échoue dès que l’identité, les fichiers ou la configuration manquent. Les quatre capacités doivent donc fonctionner ensemble.

Le NIST Cybersecurity Framework 2.0 présente six fonctions — Govern (gouverner), Identify (identifier), Protect (protéger), Detect (détecter), Respond (répondre) et Recover (rétablir) — comme un cadre flexible et non prescriptif. Pour la revue de mise en service, ces questions sont regroupées en quatre capacités. Ce raccourci n’attribue aucun niveau et ne reproduit pas le cadre.

Une exigence technique doit citer sa version et son test

Pour une application web, le référentiel ASVS 5.0.0 de l’OWASP — Application Security Verification Standard — peut servir de base versionnée pour sélectionner des exigences et des tests. Référencez la version et les exigences retenues, leur périmètre, leur résultat et leurs exceptions. « Nous suivons OWASP » ou « le Top 10 est couvert » ne constitue pas une certification.

Contrôle :
Conséquence métier réduite :
Exigence versionnée :
Périmètre et environnement :
Responsable :
Test autorisé :
Résultat observé :
Écart, limite ou exception :
Action et date de prochaine revue :

Le métier doit d’abord préciser la perte de données et l’interruption qu’il peut accepter.

L’ANSSI-BP-100 version 1.1 du 27 novembre 2025 relie la stratégie de sauvegarde à ces besoins. La perte de données maximale admissible est appelée PDMA, ou RPO en anglais. La durée maximale d’interruption admissible est appelée DMIA, ou RTO en anglais. Aucune valeur par défaut ne convient automatiquement à votre activité.

La reprise répond à la perte ou à l’arrêt. Il faut encore savoir assez tôt qu’un événement anormal se produit : c’est le rôle de la chaîne de détection.

L’ANSSI, dans son guide de journalisation version 2.0 du 28 janvier 2022, recommande de prévoir la journalisation des applications métier dès les spécifications. Les événements servent à détecter pendant l’activité ou à reconstituer le chemin et l’impact après un incident. Cela suppose des formats exploitables, une protection, une horloge cohérente et une analyse.

La fiche CNIL « Tracer les opérations » du 14 mars 2024 demande notamment de ne pas enregistrer les mots de passe ou leurs empreintes et de protéger les traces. Sa recommandation usuelle de six mois à un an concerne les données de journalisation destinées à sécuriser un traitement de données personnelles, avec des adaptations à justifier. Elle ne crée pas une durée universelle pour tous les journaux.

Une alerte n’a de valeur que si quelqu’un peut la qualifier et agir. La section suivante attribue cette décision, son remplacement en cas d’absence et les autres responsabilités de reprise.

« Le prestataire gère » ne suffit pas. Un contrat peut confier l’hébergement, les alertes ou la maintenance ; l’organisation doit encore fixer les conséquences acceptables, autoriser les actions, qualifier les obligations et vérifier les preuves.

Une même personne peut cumuler plusieurs rôles. Chacun doit néanmoins être accepté, compris et confié à un remplaçant en cas d’absence. Selon le contexte, associez le délégué à la protection des données (DPD, aussi appelé DPO), le responsable de la sécurité des systèmes d’information (RSSI), un juriste ou un autre spécialiste.

L’absence d’une personne clé met déjà l’organisation à l’épreuve

Un exercice sur table — une simulation discutée sans provoquer d’incident réel — peut rester court : une alerte arrive, la personne principale est absente, un compte doit être suspendu, une sauvegarde doit rester isolée et un décideur doit accepter le mode dégradé. Observez les appels, les accès manquants, les ambiguïtés et les décisions. Conservez les limites ; ne transformez pas l’exercice en attestation.

Événement fictif autorisé :
Personne alertée :
Suppléant :
Première décision :
Action d’isolement :
Responsable de la restauration :
Éléments utiles à conserver :
Information métier / données / juridique :
Écart observé et action :

L’outil ci-dessous relit huit contrôles en traitant d’abord le plus urgent. Il garde les inconnues, donne la priorité aux incidents et aux blocages, puis demande les écrits, les responsables, la restauration, la détection et les autres exercices. Il ne mesure ni probabilité, ni impact, ni conformité.

Une fois les exigences minimales documentées ou exercées, le contexte reste décisionnel. Un impact matériel ou critique, des données personnelles ou une exposition Internet conduisent à une revue qui tient compte du contexte. Elle mobilise, selon les raisons signalées, les compétences en métier et continuité, en protection des données ou en sécurité applicative et exploitation. Ces compétences peuvent être internes ; aucun intervenant extérieur n’est imposé par défaut. Seul le contexte déclaré limité, sans données personnelles et sans exposition Internet, aboutit à la revue métier limitée.

Utilisez-le une première fois avec le propriétaire métier, puis avec le responsable technique. Un désaccord est une information utile : recherchez la preuve au lieu de choisir la réponse la plus rassurante. Quand l’outil affiche « dossier présentable », il indique seulement qu’une revue humaine peut commencer.

La décision dépend des conséquences, du résultat des contrôles, des écarts et des personnes autorisées. Aucun seuil de réussite ne se déduit de cette revue. Écrivez la décision, les limites, les mesures temporaires, les risques qui restent, le propriétaire et la prochaine échéance.

Pour faire examiner l’architecture, les preuves et les inconnues, consultez le service d’audit technique. Si vous avez déjà réuni le contexte et souhaitez le transmettre sans secret ni détail d’incident, vous pouvez ensuite décrire le projet.

L’hébergement annonce des sauvegardes quotidiennes, sans exercice de restauration. Les modifications administrateur produisent des journaux, mais aucune alerte n’est adressée et personne n’est responsable de leur lecture. En cas d’incident, la consigne est seulement « appeler le développeur », sans suppléant ni accès vérifié.

Un pilote peut continuer avec des données fictives, des accès limités et une sortie simple si cet environnement ne devient pas implicitement la production. Après la restauration, l’alerte et l’exercice de responsabilité, les résultats reviennent devant une personne autorisée. Ils ne produisent toujours pas une déclaration automatique de sécurité.

Ces contrôles ne vivent pas isolément. Ils commencent par les droits d’accès, se rédigent comme exigences dans le cahier des charges et se prouvent par le plan de recette, restauration et journalisation comprises. Un prestataire se juge aussi là-dessus, comme le détaille le choix d’un prestataire sur preuves.

Deux situations imposent une vigilance supplémentaire. Reprendre un logiciel métier existant oblige à inventorier des accès dont plus personne ne connaît le périmètre, et une migration sans interruption de service multiplie temporairement les copies de données. Sur une plateforme partagée, enfin, les guides Airtable ou Notion face à une application métier et Power Apps face à une application sur mesure précisent ce que le plan souscrit couvre réellement.