Cybersécurité pendant un projet ERP : 8 risques à maîtriser de la sélection au go-live

Un projet ERP mobilise, pendant 12 à 18 mois, une dizaine d’intervenants externes avec des droits d’accès étendus à vos données les plus sensibles. Comptes de résultat transmis dans un appel d’offres, dump de production copié dans l’environnement de test, VPN consultants actifs 24h/24 sans journalisation individuelle : la phase projet ouvre une surface d’attaque que la plupart des politiques de sécurité en production ne couvrent pas.

Cet article traite exclusivement des risques de sécurité propres à la période de projet (de la sélection à la fin de la période d’hypercare), par opposition aux risques de sécurité du système ERP en production, abordés dans notre guide cybersécurité ERP.

Pourquoi le projet ERP est une fenêtre de vulnérabilité unique

Un système ERP en production est, dans les organisations matures, encadré par des politiques d’accès, des revues de droits régulières et des outils de supervision. La phase projet inverse cette logique : elle multiplie les accès temporaires, souvent octroyés dans l’urgence, sans revue systématique ni durée de vie bornée.

Trois facteurs amplifient le risque :

1. Les prestataires externes accèdent directement aux données : intégrateurs, éditeurs, cabinets de conseil ont besoin d’accéder aux environnements, parfois aux bases de données, pour paramétrer, tester et migrer. Cet accès est structurellement différent d’un prestataire de maintenance qui n’intervient qu’en cas d’incident.

2. Les environnements se multiplient : recette, pré-production, formation, sandbox. Chaque environnement est un point d’entrée potentiel, souvent moins surveillé que la production.

3. NIS2 étend votre responsabilité aux prestataires : la directive (UE) 2022/2555, transposée en France par la loi du 22 juillet 2024, impose aux entités importantes et essentielles de gérer les risques de sécurité de leur chaîne d’approvisionnement numérique (article 21, Directive NIS2). Un intégrateur ERP externe relève de ce périmètre.

Phase Sélection : risques 1 et 2

Risque 1 : partage de données sensibles dans le RFP et les démos

Pour rédiger un cahier des charges réaliste et évaluer les démonstrations, les équipes projet partagent souvent avec les éditeurs et intégrateurs candidats des données représentatives de l’activité : plan comptable, liste des fournisseurs, volumes de commandes, parfois un extrait du fichier clients.

Ces données circulent par e-mail ou via des espaces de partage non chiffrés, auprès de plusieurs prestataires qui ne remporteront pas le marché et n’ont aucune obligation contractuelle de sécurité à ce stade.

Ce qu’il faut faire :

• Classer les données transmises dans l’appel d’offres (données publiques, internes, confidentielles) et limiter les données confidentielles aux seuls finalistes.
• Exiger la signature d’un NDA avant toute communication de données, même de volumétrie.
• Préparer des jeux de données fictifs réalistes pour les phases de démonstration : formats identiques aux vraies données, volumes représentatifs, mais sans aucune donnée personnelle ou commerciale réelle.
• Pour les démos sur un tenant de l’éditeur, vérifier la politique de rétention des données de démonstration.

Risque 2 : clauses contractuelles de sécurité insuffisantes avec l’intégrateur

Le contrat avec l’intégrateur ERP couvre généralement les délais, la méthodologie et les livrables. Les clauses de sécurité, elles, sont souvent absentes ou limitées à une référence générique à la “confidentialité”.

Or, dès lors que l’intégrateur accède à des données personnelles (salariés, clients, fournisseurs), le RGPD impose la signature d’un Accord de traitement des données (DPA, Data Processing Agreement) selon l’article 28 du règlement. Ce DPA doit spécifier la nature des traitements, les obligations de sécurité, les modalités de notification d’incident, et l’obligation de destruction des données en fin de prestation.

Ce qu’il faut faire :

• Inclure un DPA conforme RGPD Art. 28 dans tout contrat d’intégration ERP.
• Préciser contractuellement les modalités d’accès distant : protocoles autorisés (VPN avec MFA, pas de RDP direct), fenêtres horaires, journalisation.
• Fixer une clause de notification d’incident dans les 24 heures (alignée avec les délais NIS2).
• Prévoir une clause d’audit permettant à l’entreprise de vérifier les pratiques de sécurité du prestataire pendant et après le projet.
• Imposer la destruction vérifiable des données après la fin de la prestation.

Phase Installation et paramétrage : risques 3 et 4

Risque 3 : accès VPN/RDP non maîtrisés des équipes intégrateur

Dans la pratique courante, les consultants de l’intégrateur reçoivent un accès VPN permanent pendant toute la durée du projet, sans restriction horaire, depuis n’importe quel poste de travail. Les connexions sont logguées au niveau réseau mais rarement corrélées à une identité individuelle.

Ce modèle crée plusieurs problèmes : un consultant qui quitte le cabinet intégrateur peut conserver l’accès si le compte n’est pas désactivé. Un poste compromis chez le prestataire ouvre un accès direct à votre environnement. Et l’absence de journalisation individuelle rend toute investigation forensique très difficile.

L’ANSSI recommande, dans son guide sur la sécurisation des accès prestataires, de restreindre les accès externes aux seules plages horaires nécessaires et d’exiger une authentification multifacteur pour tout accès distant (ANSSI, Recommandations sur la sécurisation des systèmes d’information).

Ce qu’il faut faire :

• Restreindre les plages d’accès VPN aux horaires de travail déclarés (exemple : lundi-vendredi, 8h-19h) avec désactivation automatique hors plage.
• Exiger l’authentification multifacteur pour tout accès distant au SI.
• Journaliser les sessions individuellement (identifiant nominatif, heure, actions effectuées) et conserver les logs au moins 12 mois.
• Organiser une revue mensuelle des accès actifs et désactiver tout compte dont l’intervenant n’est plus en mission.

Risque 4 : comptes “super-admin” projet partagés entre plusieurs consultants

Pour simplifier la configuration initiale, les équipes projet créent souvent un ou deux comptes d’administration partagés entre l’ensemble des consultants de l’intégrateur. Ces comptes disposent de droits étendus sur l’ensemble du système.

Ce partage est une violation du principe d’imputabilité : si un incident se produit (modification de paramétrage erronée, exfiltration de données, déploiement d’un script malveillant), il est impossible d’identifier quel individu était connecté. C’est aussi une violation des recommandations NIS2 sur la gestion des identités.

Ce qu’il faut faire :

• Créer des comptes individuels et nominatifs pour chaque consultant, même pour les accès temporaires.
• Appliquer le principe du moindre privilège : chaque consultant accède uniquement aux modules et données nécessaires à sa mission.
• Documenter la matrice des droits projet (qui accède à quoi, à quelle phase, avec quel niveau de permission).
• Pour les opérations d’administration sensibles (modifications de paramétrage de production), mettre en place une validation à deux personnes.

Phase Recette (UAT) : risques 5 et 6

Risque 5 : utilisation de vraies données de production dans l’environnement de recette

C’est le risque le plus fréquent et le moins visible. Pour rendre les tests de recette réalistes, les équipes projet copient régulièrement un dump de la base de production dans l’environnement de test : données clients, salaires, numéros SIRET, coordonnées personnelles.

Cette pratique est une violation directe du RGPD : les données personnelles ne peuvent pas être utilisées en dehors du contexte pour lequel le consentement a été recueilli, et les environnements de test ne disposent généralement pas des mêmes mesures de sécurité que la production (accès plus larges, logs moins rigoureux, sauvegardes moins fréquentes).

Ce qu’il faut faire :

• Définir dès le lancement du projet une politique d’anonymisation des données de test.
• Utiliser des outils d’anonymisation ou de génération de données synthétiques (plusieurs solutions open source existent pour les SGBD courants).
• Si l’utilisation de données réelles est jugée indispensable pour certains scénarios de test, soumettre le cas au DPO et documenter la décision avec les mesures compensatoires.
• Contrôler les accès à l’environnement de recette au même niveau que la production dès lors qu’il contient des données personnelles.

Risque 6 : environnements de test non supprimés après le go-live

Les environnements de recette, de formation et de pré-production créés pendant le projet restent souvent actifs plusieurs mois après le go-live, faute de procédure de décommissionnement formalisée. Ces environnements conservent les anciens comptes d’accès (dont ceux des consultants), des données de test issues de la production, et des configurations de sécurité allégées.

Ces environnements oubliés sont des cibles de choix : ils sont moins surveillés, contiennent des données sensibles et donnent souvent accès aux mêmes bases de données ou à des répliques proches de la production.

Ce qu’il faut faire :

• Inclure une procédure de décommissionnement des environnements temporaires dans le plan de go-live.
• Fixer une date d’expiration automatique pour chaque environnement hors production créé pendant le projet.
• Documenter l’inventaire des environnements existants et l’inclure dans les livrables de fin de projet.
• S’assurer que les environnements de test ne partagent pas les bases de données de production (même en lecture seule) après le go-live.

Phase Migration des données : risque 7

Risque 7 : données personnelles exposées pendant les scripts de migration et les fichiers ETL

La phase de migration génère des volumes importants de fichiers intermédiaires : extractions de l’ancien système, fichiers de transformation (CSV, Excel, JSON), scripts de chargement dans le nouvel ERP. Ces fichiers contiennent systématiquement des données personnelles (clients, salariés, fournisseurs) et circulent entre les équipes internes et l’intégrateur.

Les canaux utilisés sont souvent peu sécurisés : e-mail, partage de fichiers non chiffrés, transfert FTP sans TLS. Ces fichiers s’accumulent sur des postes et serveurs sans procédure de destruction planifiée.

La CNIL rappelle que les données personnelles doivent être protégées pendant toute leur durée de traitement, y compris les phases de transfert, et que les fichiers temporaires contenant des données personnelles doivent être détruits une fois leur utilisation terminée.

Ce qu’il faut faire :

• Inventorier tous les fichiers de migration contenant des données personnelles et les classifier.
• Utiliser exclusivement des protocoles de transfert chiffrés (SFTP, HTTPS, compartiment S3 avec chiffrement côté serveur) pour transmettre ces fichiers.
• Chiffrer les fichiers à l’arrêt (at rest) dès qu’ils contiennent des données personnelles.
• Définir une procédure de destruction vérifiable : après validation du chargement, tous les fichiers intermédiaires doivent être supprimés de façon sécurisée et la destruction documentée.
• Tracer le flux complet des données : qui détient quoi, sur quel support, depuis quand.

Notre guide méthodologique migration données ERP couvre les aspects techniques de ce flux en détail.

Phase Go-live et hypercare : risque 8

Risque 8 : accès consultants non révoqués après la période de garantie

Après le go-live, une période d’hypercare de 1 à 3 mois mobilise les équipes de l’intégrateur pour stabiliser le système. À la fin de cette période, les accès doivent être révoqués. Dans la pratique, ils restent souvent actifs faute de procédure formalisée.

L’ANSSI recommande une révocation des accès prestataires dans les cinq jours ouvrés suivant la fin de la mission. Ces comptes dormants avec des droits élevés constituent une vulnérabilité persistante : le prestataire peut avoir changé de collaborateurs, les postes concernés ne sont plus sous surveillance active, et un audit externe révèle régulièrement ces accès résiduels avec des droits qui auraient dû être fermés des mois plus tôt.

Ce qu’il faut faire :

• Planifier la révocation des accès dans le plan de projet, avec une date cible identifiée et un responsable nommé.
• Effectuer un audit complet des comptes actifs 30 jours après le go-live.
• Mettre en place une alerte automatique sur les comptes prestataires inactifs depuis plus de 30 jours.
• Conserver un historique des révocations d’accès (qui, quand, par qui) pendant au moins 12 mois.

Checklist RSSI : 20 points de contrôle avant réception définitive

Avant de signer la réception définitive du projet, vérifiez ces 20 points avec l’intégrateur :

Gouvernance des accès

1. Tous les comptes prestataires sont nominatifs (aucun compte partagé).
2. La matrice des droits projet est documentée et à jour.
3. Les accès VPN/distant sont protégés par MFA.
4. Les plages d’accès horaires ont été respectées (vérification sur les logs).
5. Les comptes des consultants ayant quitté la mission ont été désactivés au fil du projet.

Données

6. L’environnement de recette n’a jamais utilisé de données personnelles non anonymisées (ou une dérogation documentée par le DPO est en place).
7. Tous les fichiers de migration contenant des données personnelles ont été détruits après validation du chargement.
8. Le DPA avec l’intégrateur est signé et conforme à l’article 28 du RGPD.

Environnements

9. L’inventaire des environnements temporaires créés pendant le projet est disponible.
10. Tous les environnements hors production non nécessaires au run ont une date de décommissionnement planifiée.
11. Les environnements de test ne contiennent plus de données personnelles réelles.
12. Les bases de données de test ont été dissociées de la production.

Traçabilité

13. Les logs d’accès prestataires couvrent l’ensemble de la durée du projet et sont stockés pendant au moins 12 mois.
14. Les actions d’administration sensibles (modifications de paramétrage) sont traçables individuellement.
15. Un registre des accès prestataires (qui, droits, période) a été tenu à jour pendant le projet.

Contractuel et NIS2

16. Le contrat intégrateur inclut une clause de notification d’incident dans les 24 heures.
17. La clause de destruction des données après fin de prestation a été exécutée et documentée.
18. Le prestataire a transmis ses certifications ou preuves de pratiques de sécurité (ISO 27001, questionnaire ANSSI, etc.).
19. La chaîne de sous-traitants de l’intégrateur (éditeur, infogérance cloud) a été documentée et acceptée.
20. Un plan de révocation des accès consultants restants est planifié avec une date et un responsable.

Intégrer la sécurité projet dans votre gouvernance ERP dès le lancement

La sécurité d’un projet ERP ne s’improvise pas en fin de parcours. Elle se construit dès la phase de sélection, dans le cahier des charges, dans les contrats, dans les accès octroyés dès les premières semaines.

Le RSSI doit être impliqué dès le kick-off du projet, pas seulement convoqué pour valider le pen test en pré-production. Son périmètre pendant le projet couvre la gouvernance des accès prestataires, la protection des données de test, la validation des procédures de migration, et le suivi du plan de révocation.

La directive NIS2 vous donne un levier supplémentaire : si votre organisation est concernée (entité importante ou essentielle), les risques liés aux prestataires sont un point de contrôle explicite lors des audits. Documenter vos pratiques projet en regard des 8 risques ci-dessus constitue un début de preuve solide pour un auditeur NIS2.

Pour aller plus loin, consultez notre checklist NIS2 des preuves ERP pour audit de cybersécurité et notre guide zero-trust et gestion des accès ERP, qui couvrent la sécurité du système en phase de run.