Sécuriser une application métier ou un SaaS : les bases, sans jargon ni alarmisme

Que veut dire sécuriser une application métier ?

Sécuriser une application métier, c'est garantir que seules les bonnes personnes accèdent aux bonnes données, que ces données ne sont ni altérées ni perdues, et que l'outil reste disponible. Ce n'est pas une affaire de produits miracles : beaucoup d'incidents exploitent des bases mal appliquées.

L'article 32 du RGPD fixe l'obligation pour toute application qui traite des données personnelles : le responsable du traitement et le sous-traitant mettent en œuvre des mesures adaptées au risque, y compris, selon les besoins, la pseudonymisation et le chiffrement, des moyens de garantir la confidentialité, l'intégrité, la disponibilité et la résilience des systèmes, la capacité de rétablir l'accès aux données après un incident, et une procédure pour tester régulièrement l'efficacité de ces mesures. Le volet données personnelles est développé dans le guide RGPD et logiciel métier.

Les dix mesures de base, en un tableau

Dix mesures forment le socle de sécurité d'une application métier ou d'un SaaS de PME. Chacune s'appuie sur une recommandation publique.

Authentification et droits : là où se jouent beaucoup de failles

Dans une application métier, un risque fréquent n'est pas un pirate génial mais un utilisateur qui voit ce qu'il ne devrait pas voir. L'OWASP place d'ailleurs les contrôles d'accès défaillants (Broken Access Control) en tête de son Top 10 2025.

Exemple typique : un technicien modifie le numéro de dossier dans l'adresse de la page et affiche l'intervention d'un autre client. L'écran ne proposait pas ce lien, mais le serveur ne vérifiait pas le droit. La CNIL le rappelle dans sa fiche sur les développements : les mesures prises dans l'interface peuvent être contournées et devraient être renforcées par des mesures côté serveur.

• Authentification : la CNIL qualifie une authentification de multifacteur lorsqu'elle combine au moins deux catégories de facteurs : ce que l'on sait, ce que l'on a, ce que l'on est. L'ANSSI recommande de la privilégier et de préférer un facteur de possession. Pour les mots de passe, la CNIL recommande de ne conserver que leur empreinte et de ne plus imposer de renouvellement périodique aux simples utilisateurs, à la différence des administrateurs.
• Comptes : un identifiant par personne, pas de compte partagé « atelier », désactivation le jour du départ.
• Droits : des profils définis par métier, le moindre privilège, et une revue au moins annuelle des habilitations avec les responsables métier, comme le recommande la CNIL.

Sur la plateforme Klass., qui compte douze rôles et cloisonne strictement les établissements, YMHB Web a écrit des contrôles automatiques des accès et du cloisonnement, rejoués à chaque mise à jour.

Le Top 10 de l'OWASP 2025, traduit pour un dirigeant

L'OWASP Top 10 est un document de sensibilisation, publié par la fondation OWASP, qui liste les dix catégories de risques les plus critiques pour les applications web ; sa version la plus récente est celle de 2025. Voici chaque catégorie, avec la question à poser à votre prestataire.

Sauvegardes et journaux : ce qui sauve le jour de l'incident

Le jour d'un incident, deux choses font la différence : une sauvegarde que l'on sait restaurer et des journaux qui disent ce qui s'est passé. Un rançongiciel qui chiffre le serveur chiffre aussi les sauvegardes stockées sur ce même serveur.

Dans sa fiche de 2024 sur les sauvegardes, la CNIL recommande :

• des sauvegardes fréquentes, avec par exemple des incrémentales quotidiennes et des complètes à intervalles réguliers ;
• au moins une sauvegarde sur un site géographiquement distinct et au moins une sauvegarde hors ligne ;
• des sauvegardes protégées au même niveau que les données d'origine, chiffrées notamment ;
• des tests réguliers d'intégrité et de restauration ;
• la règle dite 3-2-1 : trois copies, sur deux supports différents, dont une hors ligne.

Pour les journaux, la recommandation de la CNIL de novembre 2021 préconise de tracer les accès, créations, modifications et suppressions, de conserver ces traces entre six mois et un an dans le cas général, et de les analyser automatiquement pour détecter rapidement les usages anormaux. Un journal que personne ne lit ne sert qu'après coup.

Dépendances et mises à jour : la chaîne d'approvisionnement

Une application moderne repose sur des dizaines, voire des centaines, de bibliothèques écrites par d'autres : une faille dans l'une d'elles devient une faille de votre outil. L'OWASP classe cette famille de risques au troisième rang de son Top 10 2025, sous le nom de Software Supply Chain Failures.

• Versions figées et connues pour chaque bibliothèque, avec un fichier de verrouillage dans le dépôt.
• Alertes automatiques de vulnérabilité, lues et traitées selon leur gravité.
• Un rythme régulier de mise à jour, plutôt qu'un grand saut tous les trois ans.
• Suppression des bibliothèques inutilisées : chacune est une surface d'attaque.
• Pour le mobile, prise en compte des nouvelles versions d'iOS et d'Android.

Ce travail continu relève de la maintenance, dont l'organisation est décrite dans le guide de la TMA.

Qui est responsable de quoi : client, prestataire, hébergeur ?

La sécurité d'une application se partage entre trois acteurs, et chaque sujet doit avoir un responsable nommé dans le contrat.

Selon l'article 33 du RGPD, le responsable du traitement notifie une violation de données à la CNIL dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si elle n'est pas susceptible d'engendrer un risque pour les personnes ; le sous-traitant doit l'en informer dans les meilleurs délais. L'hébergement ne règle pas tout : l'ANSSI précise que la qualification d'une offre cloud ne préjuge pas de la sécurité des applications des clients, comme l'explique le guide sur l'hébergement souverain.

Faut-il un audit ou un test d'intrusion ?

Un test d'intrusion se justifie avant d'ouvrir une application à des clients ou au public, après une refonte importante, et dès que les données sont sensibles. C'est une photographie à une date donnée, pas un certificat de sécurité.

L'ANSSI qualifie des prestataires d'audit de la sécurité des systèmes d'information (PASSI) pour cinq activités : audit organisationnel et physique, audit d'architecture, audit de configuration, audit de code source et tests d'intrusion. La liste figure dans son catalogue des services qualifiés. Pour une application métier, l'audit de code et le test d'intrusion sont les plus utiles ; un bon rapport classe les failles par gravité et propose une correction pour chacune.

Entre deux audits, des contrôles automatiques à chaque mise à jour (analyse des dépendances, tests des droits) évitent de réintroduire une faille corrigée. Les ordres de grandeur sur les attaques subies par les entreprises sont réunis dans la page chiffres clés de la cybersécurité.

Checklist avant la mise en production

1. L'authentification multifacteur est active, au minimum pour les comptes administrateurs.
2. Chaque profil n'accède qu'à ses données, et les droits sont vérifiés côté serveur.
3. Les mots de passe sont stockés sous forme d'empreinte, selon une politique conforme à la recommandation de la CNIL.
4. Tout le trafic passe en HTTPS ; les sauvegardes et données sensibles sont chiffrées.
5. Une sauvegarde hors ligne et une sauvegarde sur un autre site existent, et une restauration a été testée.
6. Les accès et actions sont journalisés, avec une alerte sur les comportements anormaux.
7. Les dépendances sont à jour et surveillées.
8. Aucun secret ne figure dans le dépôt de code, et ceux du développement ont été changés.
9. Les comptes de test et pages de débogage sont supprimés de la production.
10. La procédure en cas de violation de données est écrite : qui prévient qui, et sous quel délai.

YMHB Web intègre ces points au cadrage et à la construction, puis les suit dans le cadre de la maintenance et sécurité des applications en production.