Un logiciel métier peut parfaitement répondre aux besoins de ses utilisateurs tout en présentant des faiblesses de sécurité.
Ces faiblesses ne proviennent pas toujours d'une erreur de développement. Elles peuvent aussi résulter de décisions prises dès la conception, lorsque les exigences de sécurité n'ont pas été suffisamment anticipées.
Une fois le développement engagé, revoir les règles d'accès, réorganiser les données ou remplacer un composant technique peut nécessiter des modifications importantes de l'architecture.
Certaines décisions méritent donc une attention particulière dès le cadrage du projet, avant qu'elles ne deviennent difficiles à corriger. Voici trois d'entre elles.
1. Définir où vont les données et comment elles sont protégées
Avant de choisir un hébergeur ou une solution technique, il faut comprendre quelles données le logiciel va traiter, où elles seront stockées et avec quels services elles seront échangées.
Cette réflexion concerne les données utilisées au quotidien, mais aussi leurs copies : sauvegardes, exports, environnements de test ou transferts vers des prestataires externes.
Un logiciel peut ainsi être hébergé dans un environnement sécurisé tout en transmettant certaines informations à des services tiers dont les conditions d'accès ou de conservation n'ont pas été suffisamment étudiées.
Anticiper les exigences réglementaires
Le RGPD impose d'intégrer la protection des données personnelles dès la conception du logiciel. Cela implique notamment de limiter la collecte aux informations nécessaires, de définir leur durée de conservation et de prévoir des mesures de protection adaptées.
Certains secteurs sont également soumis à des exigences particulières.
Dans le domaine de la santé, par exemple, le recours à un hébergeur certifié HDS peut être obligatoire selon la nature des données, le contexte dans lequel elles ont été recueillies et les prestations d'hébergement réalisées.
Il faut également vérifier le périmètre de la certification : un hébergeur certifié ne garantit pas, à lui seul, la conformité de l'ensemble du logiciel.
Pourquoi ces décisions doivent être prises tôt
Lorsque les flux de données n'ont pas été identifiés dès le départ, les conséquences peuvent être importantes : revoir l'organisation des bases de données, modifier certaines intégrations, changer d'hébergeur ou adapter les contrats avec les prestataires.
Ces changements sont généralement plus complexes une fois le logiciel développé et les données déjà en circulation.
Dès le cadrage, l'objectif est donc de disposer d'une vision claire des données collectées, de leur circulation et des responsabilités de chaque acteur.
2. Définir qui peut accéder à quoi, et dans quelles conditions
Dans un logiciel métier, tous les utilisateurs n'ont pas besoin d'accéder aux mêmes informations ni de disposer des mêmes droits.
Un commercial peut consulter les dossiers de ses clients, tandis qu'un responsable peut avoir accès à ceux de toute son équipe. Un administrateur peut, quant à lui, gérer les comptes utilisateurs sans nécessairement consulter les données métier.
Ces règles doivent être définies dès la conception du logiciel.
Authentifier un utilisateur ne suffit pas
Deux notions sont à distinguer :
- L'authentification permet de vérifier l'identité d'un utilisateur.
- L'autorisation détermine les informations auxquelles il peut accéder et les actions qu'il peut effectuer.
Un utilisateur peut donc se connecter avec des identifiants valides tout en disposant de droits beaucoup trop étendus.
En septembre 2026, la CNIL a annoncé une sanction de 500 000 euros à l'encontre de l'Hôpital privé de la Loire, à la suite d'une violation de données survenue en 2025.
Un attaquant avait réussi à accéder aux données de plus de 524 000 patients en utilisant les identifiants d'un seul compte. L'enquête a notamment révélé une authentification insuffisamment sécurisée et des droits d'accès trop étendus, qui ne tenaient pas compte de l'appartenance des professionnels aux équipes de soins.
L'établissement ne disposait pas non plus de mesures permettant de détecter rapidement les activités suspectes.
Cette affaire illustre les conséquences possibles d'une gestion des accès insuffisamment encadrée.
Prévoir des droits adaptés aux responsabilités de chacun
Dès le cadrage, il est utile de déterminer les différents profils d'utilisateurs et leurs permissions.
Pour chaque profil, il faut préciser les données accessibles, les actions autorisées et les éventuelles conditions d'accès.
Ces règles doivent également s'appliquer aux API et aux services connectés au logiciel. Masquer une fonctionnalité dans l'interface ne suffit pas à empêcher un accès non autorisé : les contrôles doivent être effectués côté serveur.
Lorsque cette organisation est définie trop tard, sa mise en place peut nécessiter de revoir plusieurs fonctionnalités, les échanges entre services et parfois la structure même des données.
Définir les droits dès la conception permet de limiter les accès au strict nécessaire et d'éviter des modifications complexes une fois le logiciel développé.
3. Choisir des composants que l'entreprise saura sécuriser et maintenir
Lorsqu'une entreprise développe un logiciel métier, elle doit choisir les composants techniques sur lesquels reposera son application : authentification, gestion des identités, échanges de données ou encore chiffrement.
Ces choix ont des conséquences sur la sécurité du logiciel, mais aussi sur sa capacité à évoluer et à être maintenu dans le temps.
S'appuyer sur des composants éprouvés
Développer soi-même chaque fonctionnalité de sécurité n'est pas toujours pertinent. Certains mécanismes, notamment l'authentification et la gestion des identités, sont complexes et nécessitent une expertise spécifique.
Des solutions existantes permettent de s'appuyer sur des composants déjà largement utilisés et régulièrement maintenus.
C'est notamment le cas de Keycloak, une solution open source de gestion des identités et des accès. Elle permet de centraliser l'authentification des utilisateurs, de gérer les sessions et d'intégrer des mécanismes comme l'authentification multifacteur.
Son utilisation évite de devoir développer ces fonctionnalités dans chaque application.
Toutefois, choisir un composant reconnu ne garantit pas automatiquement sa sécurité. Sa configuration, son intégration au logiciel et ses mises à jour restent déterminantes.
Par exemple, Keycloak peut gérer l'authentification d'un utilisateur, mais les règles d'accès propres au métier doivent toujours être définies et appliquées dans l'application.
Anticiper la maintenance et les mises à jour
Un composant fiable aujourd'hui peut présenter une vulnérabilité demain. Certaines bibliothèques peuvent également ne plus être maintenues par leurs éditeurs ou leurs communautés.
Dès la conception, il est donc important de s'interroger sur la pérennité des solutions retenues.
Qui sera responsable des mises à jour ? Comment les vulnérabilités seront-elles identifiées ? Le composant pourra-t-il être remplacé si nécessaire ?
Ces questions permettent d'anticiper les contraintes de maintenance et d'éviter qu'une dépendance technique ne devienne une faiblesse durable du logiciel.
Prévoir la surveillance du logiciel
La sécurité repose également sur la capacité à identifier les comportements inhabituels et à comprendre ce qui s'est passé lorsqu'un incident survient.
Pour cela, le logiciel doit conserver des traces pertinentes de certaines opérations : tentatives de connexion, modifications des droits d'accès, actions administratives ou accès à des informations sensibles.
Ces journaux doivent être protégés et exploités. Leur simple existence ne permet pas de détecter une activité suspecte.
Prévoir cette surveillance dès la conception facilite l'identification des incidents et leur analyse, sans devoir ajouter tardivement des mécanismes de traçabilité à l'ensemble de l'application.
Comment vérifier que ces choix ont été pris en compte ?
Anticiper la sécurité ne nécessite pas de multiplier les documents. L'important est de s'assurer que les décisions prises lors du cadrage se traduisent par des mesures concrètes.
Plusieurs éléments permettent de le vérifier :
- Une cartographie des données et des flux pour identifier les informations traitées, leur circulation et les acteurs qui y ont accès.
- Une matrice des autorisations pour préciser les actions permises à chaque profil d'utilisateur et les données concernées.
- Un inventaire des composants techniques pour connaître les solutions utilisées, leurs versions et les responsabilités liées à leur maintenance.
- Une stratégie de journalisation et de supervision pour définir les événements à surveiller, les anomalies à détecter et les personnes chargées d'intervenir.
Ces vérifications doivent être adaptées à la nature du logiciel, à la sensibilité des données et aux risques identifiés.
Des référentiels comme l'OWASP ASVS peuvent également aider les équipes techniques à définir des exigences de sécurité précises et à vérifier leur mise en œuvre.
Maintenir la sécurité tout au long de la vie du logiciel
Les mesures prévues lors de la conception doivent évoluer avec le logiciel.
L'ajout de fonctionnalités, l'arrivée de nouveaux utilisateurs ou la connexion à des services externes peuvent modifier les risques initialement identifiés. Les droits d'accès, les composants techniques et les dispositifs de surveillance doivent alors être réévalués.
La maintenance et les mises à jour régulières permettent également de corriger les vulnérabilités découvertes après la mise en production.
Les décisions prises dès le cadrage posent les bases de la sécurité du logiciel. Leur suivi dans le temps permet de préserver cette sécurité à mesure que le produit évolue.
Vous préparez un projet de logiciel métier ?
Un cadrage en amont permet de clarifier les besoins, les contraintes techniques et les points de vigilance avant de lancer le développement.