Un ERP est, par nature, le système d'information le plus sensible d'une PME. Il concentre ce que l'entreprise a de plus précieux et de plus exposé : données clients, contrats, fiches de paie, coordonnées bancaires, parfois des numéros de sécurité sociale. La sécurité ERP RGPD n'est donc pas un sujet qu'on traite en fin de projet, en cochant quelques cases avant la mise en production. C'est une contrainte d'architecture qui doit être pensée dès les premières lignes de code. Voici comment nous l'abordons chez Revolucy, avec ce que ça donne concrètement sur nos projets.
Pourquoi un ERP est une cible particulièrement sensible
La plupart des dirigeants ont bien intégré qu'il faut sécuriser leur messagerie ou leur site web. L'ERP est souvent moins bien perçu comme une cible, parce qu'il est moins visible de l'extérieur. C'est précisément ce qui le rend dangereux : un accès non autorisé à un ERP donne accès à tout, d'un coup, sans avoir à collecter les données pièce par pièce.
Sur Spectaclio, un de nos ERP dédiés à la gestion de production pour le spectacle vivant, le système traite des données particulièrement sensibles : numéros de sécurité sociale des intermittents, contrats CDDU, éléments de paie échangés avec le logiciel sPAIEctacle. Plusieurs compagnies clientes cohabitent sur la même plateforme, chacune devant voir uniquement ses propres données. Une faille dans l'isolation entre organisations ne serait pas juste un bug : ce serait une violation de données personnelles au sens du RGPD, avec obligation de notification à la CNIL dans les 72 heures.
Ce contexte n'est pas exceptionnel. Beaucoup de PME gèrent dans leur ERP des données dont elles sous-estiment la sensibilité : historiques d'interventions chez des clients particuliers, données RH de collaborateurs, informations financières de partenaires. Le RGPD s'applique à tout ça, pas seulement aux bases de données marketing.
Ce que la conformité RGPD exige concrètement d'un ERP
Commençons par poser la ligne de partage honnêtement, parce que la confusion sur ce sujet coûte cher.
Ce que Revolucy couvre, côté architecture technique : le chiffrement des données, la gestion fine des droits d'accès, l'audit trail, l'hébergement sur des serveurs en juridiction française, les mécanismes de droit à l'oubli et de portabilité des données, la gestion du consentement. C'est le socle technique de la conformité.
Ce que le client doit gérer, côté organisationnel : la tenue du registre des activités de traitement, la désignation d'un DPO si obligatoire, la rédaction des mentions légales et des politiques de confidentialité, la gestion des contrats de sous-traitance avec ses propres fournisseurs, la formation des équipes aux bonnes pratiques. Ce sont des obligations légales qui ne se délèguent pas à un développeur.
Un ERP techniquement irréprochable dans une entreprise qui n'a pas de registre des traitements ni de politique de gestion des incidents n'est pas conforme RGPD. Les deux dimensions sont indissociables.
Les fondations techniques : ce que nous intégrons systématiquement
Chiffrement des données : en transit et au repos
Toutes nos applications Django sont déployées avec TLS (HTTPS) systématique : aucune donnée ne circule en clair entre le navigateur de l'utilisateur et le serveur. C'est le minimum, mais nous voyons encore des applications métier qui ne l'appliquent pas partout, notamment sur leurs interfaces d'administration.
Pour les données particulièrement sensibles stockées en base (données de santé, numéros d'identification, coordonnées bancaires), nous appliquons un chiffrement AES-256 au repos dans PostgreSQL. Sur le projet Célestins, cette exigence était explicitement formulée dans le cahier des charges. Sur Spectaclio, elle découle directement de la nature des données traitées. Le principe que nous appliquons : si la donnée ne devrait pas être lisible par un administrateur de base de données qui n'y a pas droit métier, elle doit être chiffrée.
Gestion des droits et isolation des données
C'est le chantier le plus long et le plus spécifique à chaque projet, parce qu'il reflète directement l'organisation du client. Sur Groupe Orizon, nous avons construit une matrice de droits CRUD granulaire sur cinq profils utilisateurs : Administrateur, Responsable, Commercial, Technicien et Assistant Commercial. Chaque profil a des droits précis sur chaque module (consultation, création, modification, suppression), et ces droits ont été validés fonctionnellement avec les équipes avant le développement.
Sur Spectaclio, la contrainte est différente : le système est multi-organisation, avec plusieurs compagnies clientes sur la même instance. L'isolation des données entre organisations est garantie au niveau de l'architecture : chaque requête en base est filtrée par l'organisation de l'utilisateur connecté, rendant structurellement impossible l'accès aux données d'une autre compagnie, même en cas d'erreur de paramétrage.
Cette approche est plus coûteuse à développer qu'un simple système de rôles basique, mais c'est ce qui garantit que la séparation des données tient dans le temps, même quand l'application évolue.
Authentification renforcée
Django intègre nativement un système d'authentification solide, mais nous le renforçons systématiquement. Sur tous nos projets, les mots de passe sont soumis à des validateurs de complexité : longueur minimale, vérification de similarité avec les données personnelles de l'utilisateur, résistance aux mots de passe trop courants. Sur UNAF CRM, ces validateurs ont été configurés en français avec des exigences précises (8 caractères minimum, 2 chiffres et 4 lettres au minimum), pour des utilisateurs peu familiers avec les contraintes de sécurité informatique.
L'authentification multi-facteurs (MFA) est proposée systématiquement sur les projets où les données sont particulièrement sensibles ou les accès distants fréquents. Elle était obligatoire sur le projet Célestins, et nous la recommandons sur tout ERP accessible depuis l'extérieur du réseau de l'entreprise.
L'audit trail : savoir qui a fait quoi et quand
C'est une fonctionnalité que les clients demandent rarement au démarrage et qu'ils apprécient énormément après. Un audit trail (ou journal d'audit) enregistre chaque action significative dans l'ERP : qui a créé un enregistrement, qui l'a modifié, qui l'a supprimé, avec l'horodatage précis et les valeurs avant/après modification.
Sur Spectaclio, nous avons implémenté un AuditModel qui s'applique en héritage à tous les modèles de données critiques. Chaque création, modification ou suppression est tracée automatiquement, sans que le développeur ait besoin d'y penser pour chaque nouveau modèle. Ce journal sert à la fois à la détection d'anomalies (qui a modifié ce contrat hier soir à 23h ?), à la résolution de conflits entre utilisateurs et à la démonstration de conformité en cas de contrôle.
Au sens du RGPD, l'audit trail contribue également à la piste d'audit fiable exigée pour certains traitements, notamment en matière fiscale et comptable.
Hébergement souverain : pourquoi la juridiction compte
Le RGPD interdit en principe le transfert de données personnelles vers des pays hors Union Européenne sans garanties adéquates. En pratique, beaucoup d'entreprises hébergent leurs applications sur AWS, Azure ou Google Cloud sans savoir précisément où leurs données sont physiquement stockées ni quelle loi s'applique en cas de réquisition.
Sur tous nos projets, nous proposons par défaut un hébergement sur des serveurs en France, à 150 € HT par an. Juridiction française, données en UE, pas d'ambiguïté sur l'applicabilité du RGPD. Pour les projets avec des exigences de souveraineté renforcées (secteur public, données de santé, données réglementées), c'est une exigence non négociable. Pour les autres, c'est une décision que nous mettons clairement sur la table, avec ses implications.
L'hébergement souverain va de pair avec une politique de sauvegardes quotidiennes et incrémentales, conservées en dehors de l'environnement de production. En cas d'incident (ransomware, erreur humaine, défaillance matérielle), la restauration des données est possible avec une perte maximale de 24 heures.
Les protections natives de Django : un socle solide
Le choix de Python/Django pour nos développements ERP n'est pas anodin du point de vue de la sécurité. Django intègre nativement des protections contre les vulnérabilités les plus courantes référencées par l'OWASP (Open Web Application Security Project) :
- Protection CSRF (Cross-Site Request Forgery) : chaque formulaire inclut un token unique qui empêche des requêtes malveillantes déclenchées depuis un site tiers.
- Protection XSS (Cross-Site Scripting) : le moteur de templates Django échappe automatiquement les données affichées, empêchant l'injection de scripts malveillants.
- Protection contre l'injection SQL : l'ORM Django paramètre toutes les requêtes en base, rendant les injections SQL structurellement impossibles sur le code standard.
- Gestion sécurisée des sessions : cookies HTTP-only, durées de session configurables, invalidation à la déconnexion.
Ces protections ne dispensent pas d'une revue de code rigoureuse, notamment sur les parties qui s'écartent du code standard Django. Chez Revolucy, les revues de code sont systématiques avant chaque mise en production, avec une attention particulière aux points d'entrée externes (API, imports de fichiers, formulaires publics).
Droit à l'oubli et portabilité : les oublier coûte cher
Deux droits RGPD sont souvent traités comme des détails en phase de conception et deviennent des problèmes coûteux à corriger après coup.
Le droit à l'oubli (ou droit à l'effacement) oblige à pouvoir supprimer ou anonymiser toutes les données personnelles d'un individu sur demande. Dans un ERP, c'est plus complexe qu'il n'y paraît : un contact peut être lié à des dizaines d'enregistrements dans plusieurs tables (commandes, factures, historiques d'interventions, notes commerciales). Supprimer le contact ne suffit pas ; il faut une procédure d'anonymisation qui préserve la cohérence des données historiques (les chiffres restent vrais, mais le nom disparaît) sans casser l'intégrité référentielle de la base.
Nous intégrons cette procédure d'anonymisation dans nos ERP dès la conception, avec un script dédié et une interface d'administration réservée aux profils autorisés. Sur Spectaclio, c'est particulièrement critique : un intermittent peut demander l'effacement de ses données à tout moment, y compris ses numéros de sécurité sociale stockés pour les déclarations passées.
La portabilité des données (droit à recevoir ses données dans un format lisible par machine) est implémentée via des exports structurés : JSON pour les données relationnelles complexes, CSV pour les données tabulaires, PDF pour les documents. Ces exports sont accessibles depuis un espace personnel ou via l'administration, selon le contexte.
Ce que nous ne faisons pas : les limites à connaître
Nous développons des architectures techniquement sécurisées et conformes RGPD. Nous ne réalisons pas de tests d'intrusion (pentest) formels en interne. Pour les projets qui requièrent un audit de sécurité externe (secteur public, données de santé, certification ISO 27001), nous recommandons de faire appel à un cabinet spécialisé. Le pentest est une prestation distincte du développement, réalisée par des équipes dont c'est le seul métier.
De même, nous ne nous substituons pas à un DPO (Délégué à la Protection des Données) ni à un juriste spécialisé RGPD. Nous pouvons documenter les traitements réalisés dans l'ERP pour faciliter la tenue du registre, mais la responsabilité légale du registre reste celle du client.
Cette clarté sur nos limites fait partie de notre façon de travailler. Un prestataire qui vous dit qu'il "gère tout le RGPD" sans distinguer le technique de l'organisationnel vous vend quelque chose qu'il ne peut pas tenir.
Sécurité ERP RGPD : comment aborder le sujet dès le cadrage
La sécurité ERP RGPD n'est pas une couche qu'on ajoute à la fin. C'est une contrainte d'architecture qui influence le modèle de données, le système de droits, le choix d'hébergement et les procédures de déploiement. Plus elle est intégrée tôt, moins elle coûte cher.
Si vous êtes en phase de réflexion sur un projet ERP sur mesure, notre article sur le développement ERP sur mesure pose les bases du sujet. Pour comprendre comment la stack technique que nous utilisons facilite ces implémentations de sécurité, notre article sur ERP Python/Django entre dans le détail. Et si vous vous posez la question du coût global d'un projet ERP avec ces exigences de sécurité, notre article sur le coût d'un ERP sur mesure et son ROI vous donnera des repères chiffrés.
Pour discuter de votre contexte spécifique et évaluer les exigences de sécurité de votre projet, prenez rendez-vous avec notre équipe. Nous vous dirons rapidement ce qui relève de l'architecture standard et ce qui nécessite des développements spécifiques.