Quand on lance un projet ERP, le premier mur n’est pas technique. C’est le moment où l’équipe projet découvre que les processus internes ne sont documentés nulle part, ou que trois services utilisent le même terme pour désigner des réalités différentes. Le déploiement d’un ERP dans le cloud amplifie ce problème, parce qu’il impose un rythme plus court que les anciens projets on-premise et laisse moins de place à l’improvisation.
La décision de déployer un ERP dans le cloud oblige à trancher sur des sujets que beaucoup d’entreprises repoussent depuis des années : périmètre fonctionnel réel, niveau de personnalisation acceptable, responsabilités entre l’éditeur et l’équipe interne. Autant de points qu’on retrouve systématiquement dans les projets qui dérapent.
Conformité réglementaire européenne et choix d’hébergement ERP
Un ERP cloud connecté à d’autres systèmes d’information peut tomber sous le périmètre de plusieurs réglementations européennes en même temps. La directive NIS2 impose des obligations de cybersécurité et de gestion des risques. Le règlement DORA cible la résilience numérique dans le secteur financier. Le futur cadre CRA ajoute une couche sur la sécurité des produits logiciels.
En pratique, cela change la manière dont on négocie avec un éditeur ou un infogéreur. On ne peut plus se contenter d’un contrat standard.
- Journaux d’audit exportables : la capacité à extraire les logs de sécurité dans un format exploitable par vos propres outils de supervision devient un critère de sélection, pas une option
- Preuves de sécurité fournisseur : certaines entreprises exigent désormais des certifications ou des rapports d’audit indépendants avant de signer, ce qui allonge la phase de contractualisation
- Clauses de sortie contractuelles : la réversibilité des données, leur format de restitution et les délais associés doivent figurer noir sur blanc, surtout si l’on héberge des données sensibles dans un cloud public
- Localisation des données : les architectures souveraines ou hybrides gagnent du terrain en Europe, portées par la volonté de garder certaines données critiques sur le sol national
Cartographie des processus avant déploiement ERP cloud
On voit régulièrement des projets démarrer par le choix de l’éditeur, puis tenter de mapper les processus internes sur les modules du logiciel. C’est l’inverse qui fonctionne. La cartographie des processus métier existants, même sommaire, permet d’identifier les écarts entre ce que fait l’entreprise et ce que propose la solution standard.
Sur le terrain, la difficulté principale n’est pas technique. Elle vient du fait que chaque service a sa propre version du processus réel. Le service commercial saisit les commandes d’une certaine manière, la logistique en attend une autre, et la comptabilité corrige à la main les incohérences. Un ERP cloud en mode SaaS laisse peu de marge pour reproduire ces bricolages.
Standard ou spécifique : un arbitrage, pas une fatalité
Les personnalisations lourdes héritées d’un ancien système ne se transfèrent pas telles quelles dans un environnement SaaS : le modèle repose sur un socle commun mis à jour par l’éditeur, et chaque développement hors standard devient un point de vigilance à chaque montée de version. Présenté comme une contrainte subie, ce constat masque pourtant l’essentiel : c’est un arbitrage à conduire, et l’un des exercices les plus structurants du projet.
Car toutes les personnalisations ne se valent pas. Certaines ne sont que la trace d’un contournement devenu habitude et s’abandonnent sans perte. D’autres portent un vrai savoir-faire : une règle de tarification propre au métier, un circuit de validation imposé par la réglementation. La distinction est métier, pas technique, et tient à une question simple : que se passe-t-il si ce fonctionnement disparaît ? Si l’on perd du temps, le standard fera l’affaire. Si l’on perd un client ou la conformité, le besoin est légitime.
Reste à le traiter au bon endroit. Entre paramétrage, automatisation low-code et extension isolée du cœur applicatif, un même besoin peut survivre aux mises à jour ou les bloquer durablement, un écart qui ne se mesure pas au déploiement, mais deux ans plus tard. Une migration d’ERP vers le cloud bien conduite ne consiste donc pas à tout aligner sur le standard, mais à savoir où le spécifique crée encore de la valeur, et où il ne fait que coûter cher.
Gestion du changement et adoption ERP par les équipes
La formation ne suffit pas. Former les utilisateurs au nouveau logiciel sans avoir travaillé en amont sur le pourquoi du changement produit un effet prévisible : les gens contournent l’outil. Ils continuent à utiliser leurs tableurs en parallèle, et l’ERP devient une coquille vide alimentée a minima pour satisfaire la direction.
Ce qu’on observe dans les projets qui fonctionnent, c’est une implication des utilisateurs-clés dès la phase de cadrage. Pas en tant que spectateurs d’une démonstration, mais comme contributeurs actifs à la définition des règles de gestion. Quand un responsable d’entrepôt a participé à définir le circuit de validation des réceptions, il défend le processus auprès de ses collègues au lieu de le subir.
Indicateurs concrets d’adoption
Plutôt que de mesurer le nombre d’utilisateurs connectés (un indicateur facile à gonfler), on peut suivre des signaux plus révélateurs :
- Le taux de saisie directe dans l’ERP par rapport aux corrections manuelles effectuées après coup
- Le nombre de tickets support liés à des incompréhensions fonctionnelles, qui doit baisser dans les semaines suivant le déploiement
- La disparition progressive des fichiers Excel parallèles, signe que l’outil répond aux besoins opérationnels réels
Les retours varient sur ce point selon la taille de l’entreprise et la culture interne, mais le principe reste le même : l’adoption se mesure par l’abandon des outils de contournement.
ERP cloud : privilégier une architecture adaptée aux réalités du terrain
Le cloud public s’impose aujourd’hui comme le modèle de référence pour moderniser un ERP. Il permet notamment aux entreprises de s’appuyer sur une infrastructure évolutive et de faciliter l’évolution de leur système d’information. Cette dynamique se confirme à l’échelle mondiale : selon Gartner, les dépenses des utilisateurs finaux en services de cloud public étaient estimées à 723,4 milliards de dollars en 2025, soit une hausse de 21,5 % par rapport à 2024.
Pour autant, passer à un ERP cloud ne signifie pas ignorer les réalités du terrain. Dans l’industrie notamment, la latence réseau de certains sites, les volumes de données issus des équipements connectés ou encore la coexistence temporaire avec des systèmes historiques doivent être pris en compte dans la conception de l’architecture.
L’enjeu n’est donc pas d’opposer cloud et infrastructure locale, mais de construire une architecture cohérente autour d’un ERP cloud, capable de communiquer efficacement avec les applications, machines et systèmes qui restent présents sur les sites industriels.
Enfin, le déploiement d’un ERP cloud ne se résume pas à une migration informatique. Il transforme les processus, les habitudes de travail et parfois les responsabilités au sein de l’entreprise. Sa réussite repose donc autant sur la technologie que sur l’accompagnement des équipes et l’évolution des processus métiers.
