Le durcissement du serveur n'est que la première couche. Les risques propres à l'ERP qui font vraiment perdre des données sont le contrôle d'accès, les privilèges de base de données, les journaux d'audit et les sauvegardes non testées — voici une checklist qui fonctionne.
Un ERP en production est le seul système qui rassemble tout — votre finance, votre paie, vos stocks et vos clients dans une seule base de données — donc une faille de sécurité n'est pas un problème informatique, c'est un problème business. Le durcissement du serveur en dessous est nécessaire, mais ce n'est que la première couche, car la plupart des incidents ERP réels ne viennent pas d'un serveur compromis. Ils viennent d'une personne ayant accès à un module qui ne la concerne pas, d'une application qui se connecte à la base de données avec des privilèges d'administrateur, d'un changement que personne ne peut retracer, ou d'une sauvegarde qui se révèle irrécupérable le jour où on en a besoin. La checklist ci-dessous couvre les couches propres à l'ERP que le durcissement du serveur n'atteint pas.
Un site web compromis peut être restauré depuis une sauvegarde et reconstruit en une journée. Un ERP ne le peut pas, car la valeur réside dans les données vivantes accumulées — chaque facture, chaque paie, chaque mouvement de stock — et parce que les gens qui l'utilisent au quotidien ne sont pas des techniciens. Trois conséquences en découlent. Premièrement, les données sont l'actif : le chiffrement, le contrôle d'accès et les restaurations testées importent plus que n'importe quelle règle de pare-feu. Deuxièmement, la menace est souvent interne : un employé ayant des permissions plus larges que son rôle n'en exige, un prestataire jamais décompté, ou une erreur honnête dans un écran financier qu'aucun journal d'audit ne peut expliquer. Troisièmement, l'indisponibilité se mesure en retards de paie et d'expédition, pas en pages vues, donc chaque contrôle ici est choisi pour garder le système en marche, pas juste pour le verrouiller.
La plupart des incidents ERP se résument à une phrase : quelqu'un avait un accès qu'il n'aurait pas dû avoir. Corrigez cela avec des rôles basés sur les emplois réels, en n'accordant que le minimum dont chaque rôle a besoin — un utilisateur de l'entrepôt lit les stocks et écrit les mouvements, mais ne voit jamais la paie ; un comptable voit le grand livre mais ne peut pas modifier une période clôturée. Séparez l'utilisateur quotidien de l'administrateur, exigez l'authentification à deux facteurs pour quiconque dispose de privilèges administratifs ou financiers, et examinez les comptes dormants chaque trimestre : un compte sans connexion depuis 90 jours doit être désactivé, et chaque départ doit être décompté le jour même, pas à la fin du mois. Écrivez les rôles, faites-les valider par les chefs de service, et auditez-les face à la réalité deux fois par an — les permissions s'élargissent avec le temps et ne se réduisent jamais toutes seules.
L'application ERP ne doit jamais se connecter à sa base de données en tant que superutilisateur ou administrateur. Créez un utilisateur de base de données aux privilèges limités exactement aux schémas et tables dont l'application a besoin — pas de suppression, pas de gestion des utilisateurs — pour qu'une faille dans l'application ne puisse pas effacer le grand livre. Gardez chaque identifiant, clé API et secret de passerelle de paiement hors du dépôt de code et hors du répertoire de configuration de l'ERP en clair : chargez-les depuis l'environnement du serveur ou un gestionnaire de secrets, et pivotez-les quand un employé ayant accès part. Chiffrez le trafic entre l'application et la base de données plutôt que de faire confiance au réseau local, et activez le chiffrement au repos pour le volume de la base de données. Enfin, gardez les données de production hors des environnements de non-production : un serveur de staging avec une copie de vrais enregistrements clients est une fuite en attente, donc anonymisez-les avant de les copier ailleurs.
Quand un chiffre est faux en fin de mois, la première question est qui l'a modifié et quand. Un journal d'audit qui enregistre l'utilisateur, l'écran, l'enregistrement et l'horodatage — conservé là où même un administrateur ne peut pas le modifier, et gardé au moins un an — répond à cette question en quelques minutes au lieu de plusieurs jours, et c'est aussi ce qu'un régulateur demande après un incident. Les sauvegardes vont de pair, avec une seule règle : une sauvegarde n'est pas une sauvegarde tant que vous ne l'avez pas restaurée. Prenez des sauvegardes quotidiennes automatisées, conservez des copies hors du serveur et hors du site, activez la récupération ponctuelle pour pouvoir revenir à l'heure qui précède un mauvais import, et lancez un véritable exercice de restauration chaque trimestre dans un environnement jetable. L'exercice est le seul test qui compte, et les entreprises qui le sautent sont celles qui découvrent que la sauvegarde échouait silencieusement au moment même où elles en avaient le plus besoin.
Ne mettez pas l'interface d'administration de l'ERP sur l'internet public. Restreignez-la à une liste d'adresses IP autorisées ou au VPN de l'entreprise, placez un pare-feu applicatif devant, et n'exposez que ce dont le personnel et les intégrations ont réellement besoin. Maintenez la pile à jour à un rythme fixe — le cœur de l'ERP, la base de données, le système d'exploitation et chaque intégration — et testez chaque mise à jour dans un environnement de staging avant qu'elle ne touche la production, car une mise à jour ERP non testée peut casser un flux de paiement aussi facilement qu'elle bouche une faille. Puis nommez une seule personne responsable : quelqu'un qui possède la checklist, mène l'exercice de restauration trimestriel, examine les anomalies d'audit et rend compte à la direction. Le travail de sécurité qui appartient à tout le monde n'appartient à personne, et sur un ERP c'est ainsi que les contrôles se relâchent discrètement jusqu'à ce qu'un audit — ou un incident — les trouve.
Non, et confondre les deux est la raison pour laquelle des failles subsistent. Le durcissement du serveur — clés SSH, pare-feu, mises à jour automatiques, TLS — est la base, et c'est par là qu'on commence. Mais le risque ERP concerne surtout les données : qui peut atteindre quels enregistrements, si la connexion à la base de données est sur-privégiée, si les changements sont traçables, et si vous pouvez vraiment restaurer. Un serveur durci qui fait tourner un ERP aux rôles ouverts et avec une sauvegarde non testée n'est qu'à un mauvais clic d'un problème de données.
Un exercice de restauration complet au moins une fois par trimestre, dans un environnement jetable, puis une vérification que les données restaurées sont utilisables — ouvrez le grand livre, lancez un rapport, confirmez que les totaux correspondent. Les sauvegardes quotidiennes automatisées avec copies hors site sont la base, et la récupération ponctuelle permet d'annuler un mauvais import à l'heure près. L'exercice trimestriel est la partie que la plupart des équipes sautent, et c'est la seule qui prouve que le reste fonctionne.
Le contrôle d'accès basé sur les rôles avec le moindre privilège. C'est le seul contrôle qui réduit le rayon d'action de chaque autre défaillance — un mot de passe fuité, un import cliqué par erreur, un ordinateur compromis — parce que l'attaquant ou l'erreur se heurte à un mur de permissions qui n'inclut ni la paie ni le grand livre clôturé. C'est aussi le moins cher à corriger : il suffit d'une réunion avec chaque chef de service et d'un passage en revue de ce dont chaque rôle a réellement besoin.
ERP et systèmes d'entreprise construits avec contrôle d'accès basé sur les rôles, journaux d'audit et pratiques de déploiement testées — réservez une session de cadrage gratuite.
Le guide compagnon : ce que coûte réellement un projet ERP, ce que inclut le devis, et comment transformer une fourchette en prix fixe.
La base au niveau du serveur sur laquelle cette checklist s'appuie — clés SSH, pare-feu, mises à jour automatiques, TLS et sauvegardes quotidiennes.
EGYmass gère l'hébergement, la sécurité et la maintenance continue - pour que vous puissiez vous concentrer sur votre produit.
Consultation gratuite