La sécurité logiciel métier ne peut pas se limiter aux applications jugées stratégiques. En 2026, un service de commande de repas de l’AP-HP a exposé les données d’identité de 1 015 patients. La leçon est nette : une application périphérique peut créer un risque majeur dès qu’elle traite des données personnelles, communique avec d’autres systèmes ou reste accessible en ligne.
Que s’est-il passé avec le logiciel de repas de l’AP-HP ?
L’AP-HP a appris le 24 septembre 2026 que des données provenant de son logiciel de gestion des repas étaient proposées sur un forum cybercriminel. Le 7 octobre 2026, l’établissement a confirmé la publication de données d’identité concernant 1 015 patients, tout en précisant que l’enquête se poursuivait.
Le service concerné permettait aux patients de sélectionner leurs repas pendant une hospitalisation. Il appartenait à SRD Restauration, une suite de Dedalus utilisée par 23 hôpitaux de l’AP-HP pour gérer la nutrition, la production et la distribution des repas.
Selon le communiqué de l’AP-HP du 7 octobre 2026, les éléments alors publiés comprenaient le nom, le prénom, des informations de naissance et un identifiant patient interne. Aucune donnée médicale, administrative, bancaire ou de contact ne semblait concernée à cette date, sous réserve des résultats de l’enquête.
Des affirmations diffusées sur le forum évoquaient davantage de patients et certains comptes professionnels. L’AP-HP indiquait le 7 octobre 2026 ne pas avoir vérifié ces allégations. En l’absence de rapport technique public ou de déclaration détaillée de Dedalus sur cet incident au 10 octobre 2026, attribuer l’intrusion à une faille précise ou à un acteur serait prématuré.
L’AP-HP a désactivé le module en ligne, réinitialisé les mots de passe et déclaré avoir corrigé les vulnérabilités suspectées. L’établissement avait aussi déposé plainte le 25 septembre 2026, puis signalé l’incident à la Commission nationale de l’informatique et des libertés et à la cellule d’assistance cyber du secteur de la santé.
Pourquoi une application périphérique peut-elle exposer l’entreprise ?
Une application métier périphérique reste sensible lorsqu’elle contient des identifiants, échange des données par API ou ouvre un accès depuis Internet. La sécurité logiciel métier dépend donc des données et des connexions réelles, pas de l’étiquette « secondaire » attribuée au service dans l’organisation.
Un logiciel métier est une application conçue pour exécuter un processus propre à une organisation : commandes, stocks, maintenance, ressources humaines, production ou restauration. Il n’a pas besoin de contenir un dossier médical complet ou les coordonnées bancaires d’un client pour permettre une usurpation, un ciblage frauduleux ou un rebond vers d’autres systèmes.
Le piège le plus fréquent est organisationnel. Une application modeste échappe parfois aux audits réservés au site principal, à l’ERP ou au logiciel de relation client. Pourtant, elle conserve des comptes anciens, des secrets d’API, des interfaces d’administration et des dépendances techniques qui vieillissent.
Sur les projets que nous menons, nous voyons souvent une différence entre le périmètre décrit dans le cahier des charges et les échanges de données réellement ajoutés au fil des années. Une spécification précise de l’application métier doit donc répertorier les flux, les utilisateurs, les sous-traitants et les durées de conservation, pas seulement les écrans attendus.
Quels contrôles protègent réellement un logiciel métier ?
La sécurité d’un logiciel métier repose d’abord sur dix contrôles : cartographier les données, réduire leur collecte, individualiser les comptes, limiter les droits, vérifier les accès, protéger les API, journaliser les opérations, tester les risques, cloisonner l’application et préparer la réponse à incident. Aucun outil unique ne remplace cet ensemble.
La Commission nationale de l’informatique et des libertés recommande, dans son guide de sécurité de 2024, d’inventorier les traitements, d’attribuer des comptes individuels et d’appliquer le moindre privilège. Le moindre privilège consiste à donner à chaque personne ou programme uniquement les droits nécessaires à sa mission.
Une revue des habilitations doit être réalisée au moins une fois par an selon le guide 2024 de la CNIL. Pour une application exposée, des départs fréquents ou des données sensibles justifient souvent une fréquence plus courte. Un contrôle annuel ne doit pas devenir un délai d’attente avant de supprimer le compte d’un salarié parti.
Voici la checklist à intégrer à la conception, à la maintenance et aux audits :
- cartographier les données, les serveurs, les prestataires et les dépendances ;
- supprimer les champs collectés sans finalité démontrable ;
- utiliser des comptes individuels et retirer les droits inutiles ;
- contrôler les comptes dormants, partagés et techniques ;
- activer l’authentification multifacteur lorsque le risque le justifie ;
- examiner les API et protéger leurs clés, jetons et mots de passe ;
- enregistrer les accès et surveiller les comportements anormaux ;
- réaliser des tests de sécurité proportionnés aux risques ;
- cloisonner l’application pour limiter les déplacements d’un attaquant ;
- documenter la gestion, la notification et la communication des incidents.
L’authentification multifacteur, ou MFA, exige au moins deux preuves distinctes pour se connecter, par exemple un mot de passe et une validation sur un appareil. Les recommandations 2024-2025 de la CNIL la considèrent nécessaire dans son principe pour les bases sensibles ou susceptibles d’avoir un impact élevé.
Honnêtement, ajouter la MFA à l’interface visible tout en laissant une API ancienne protégée par un secret partagé crée surtout un sentiment de sécurité. Les interfaces techniques doivent être incluses dans l’audit, tout comme les comptes de service utilisés automatiquement par les logiciels.
Comment prioriser la sécurité logiciel métier ?
La sécurité logiciel métier doit être priorisée selon l’exposition à Internet, la sensibilité des données, le nombre d’utilisateurs et les connexions au système d’information. Une application périphérique accessible en ligne et reliée à un référentiel d’identités mérite davantage de contrôles qu’un outil isolé sans donnée personnelle.
| Situation | Risque principal | Contrôles prioritaires | Décision recommandée |
|---|---|---|---|
| Application accessible sur Internet | Accès non autorisé | MFA, tests de sécurité, journaux surveillés | Traiter avant une mise en production |
| API connectée à plusieurs systèmes | Propagation et extraction de données | Secrets protégés, droits minimaux, cloisonnement | Cartographier chaque flux |
| Comptes partagés ou dormants | Action impossible à attribuer | Comptes individuels, suppression, revue des droits | Corriger sans attendre l’audit annuel |
| Données personnelles sensibles ou à fort impact | Atteinte aux personnes | MFA, chiffrement adapté, journalisation protégée | Réaliser une analyse de risques |
| Application ancienne et isolée | Composants obsolètes | Correctifs, inventaire des versions, segmentation | Arbitrer maintien, refonte ou retrait |
Le cloisonnement consiste à séparer les réseaux ou systèmes afin qu’une compromission ne donne pas accès à tout le système d’information. Les guides de l’Agence nationale de la sécurité des systèmes d’information publiés depuis 2017 et les recommandations de la CNIL soutiennent ce principe pour limiter les déplacements latéraux d’un attaquant.
La maintenance compte autant que la conception. Une politique de gestion automatisée des correctifs sans casser la production réduit le temps d’exposition, à condition de prévoir un environnement de test et un retour arrière. À budget contraint, mieux vaut corriger d’abord les accès externes, les comptes excessifs et les composants exposés que financer un tableau de bord sophistiqué peu surveillé.
Côté agence, le réflexe est de demander la preuve de fonctionnement de chaque contrôle : extrait anonymisé d’une revue de droits, alerte issue des journaux, restauration testée ou compte effectivement bloqué. Une politique écrite ne protège rien si personne ne vérifie son application.
Que faire après une fuite de données d’une application métier ?
Après une fuite issue d’une application métier, l’entreprise doit contenir l’accès, préserver les traces, mesurer les données touchées et documenter l’incident. Une violation présentant un risque doit être notifiée à la CNIL dès que possible et, lorsque cela est réalisable, dans un délai de 72 heures au titre du RGPD.
Toutes les violations de données doivent être consignées, même lorsqu’aucune notification externe n’est requise. Lorsque le risque pour les personnes est élevé, le règlement général sur la protection des données impose aussi de les informer rapidement avec des explications compréhensibles.
Couper immédiatement tout le système est-il toujours la bonne décision ? Pas nécessairement. La désactivation peut limiter l’exposition, mais elle risque aussi d’effacer des éléments volatils ou d’interrompre un service essentiel. La décision doit associer responsables métier, équipe technique, délégué à la protection des données et personnes chargées de la sécurité.
Les journaux, c’est-à -dire l’historique des accès et actions, doivent être protégés contre la modification et conservés selon le niveau de risque. Ils servent à déterminer quels comptes ont été utilisés, quelles données ont été consultées et pendant combien de temps l’exposition a pu durer.
Une procédure de réponse à incident adaptée aux PME évite d’improviser les responsabilités sous pression. Elle doit préciser les contacts, les critères de gravité, les modalités de conservation des preuves, les décisions de coupure et le circuit de notification.
Cadrer la sécurité logiciel métier avant le développement ou la reprise d’une application évite une grande partie des angles morts. Un regard extérieur peut surtout aider à relier les exigences métier, les flux techniques et les obligations du RGPD sans multiplier les contrôles inutiles.
FAQ sur la protection des applications métier
Une application sans données bancaires est-elle sensible ?
Une application sans données bancaires peut rester sensible si elle contient des identités, des habitudes, des données de santé ou des accès à d’autres systèmes. Le risque dépend des conséquences pour les personnes et l’entreprise, pas d’une seule catégorie de données.
À quelle fréquence faut-il revoir les droits des utilisateurs ?
La CNIL recommande en 2024 une revue des habilitations au moins annuelle. Les droits doivent toutefois être retirés dès un départ ou un changement de fonction, et une application à risque peut justifier des contrôles plus fréquents.
La double authentification suffit-elle à sécuriser une application ?
L’authentification multifacteur réduit le risque lié au vol d’un mot de passe, mais ne corrige ni une API vulnérable, ni des droits excessifs, ni un composant obsolète. La sécurité exige plusieurs barrières complémentaires.
Faut-il faire un test d’intrusion avant chaque mise en ligne ?
Un test d’intrusion doit être décidé selon les risques, l’exposition et l’ampleur des changements. Une application accessible sur Internet, traitant des données à fort impact ou modifiant son authentification justifie une vérification approfondie avant sa mise en production.