Votre responsable ERP vient de partir en vous laissant une dette technique de trois ans et un contrat TMA à renégocier d’ici six mois. Ou bien votre auditeur de sécurité a rendu son rapport : votre infrastructure ERP on-premise cumule les vulnérabilités que votre équipe n’a pas les ressources de corriger. Ou encore plus simplement : vous avez 180 utilisateurs SAP Business One, une personne “référente ERP” dans votre équipe IT, et l’impression de payer trop cher pour un service trop lent.
Ces situations sont le quotidien d’une majorité d’ETI européennes. Et chacune soulève la même question structurante : faut-il continuer à piloter l’exploitation de son ERP en interne, ou déléguer tout ou partie à un prestataire externe ? Ce guide n’est pas un plaidoyer pour ou contre l’externalisation. C’est un cadre de décision pour que vous puissiez trancher avec vos propres chiffres.
Les 5 déclencheurs qui poussent une ETI à externaliser son ERP
Rare sont les DSI qui choisissent l’infogérance ERP par conviction philosophique. La décision arrive généralement sous la pression d’un des cinq événements suivants.
Équipe IT surchargée ou difficultés de recrutement ERP
Un administrateur Sage X3 ou SAP Business One compétent se négocie sur le marché à un niveau de rémunération que beaucoup d’ETI de 300 salariés peinent à tenir face à des ESN et des éditeurs en recrutement permanent. Quand votre profil ERP interne part, vous avez soit six mois pour le remplacer, soit la certitude de payer 40 % de plus que son salaire précédent, soit les deux.
Un prestataire MSP mutualise ces ressources humaines rares sur un portefeuille de clients. Vous n’achetez plus un CDI aléatoire sur le marché de l’emploi : vous achetez un niveau de service contractualisé.
Fin de contrat TMA avec l’intégrateur historique
Le contrat de TMA (Tierce Maintenance Applicative) signé juste après votre go-live expire dans six mois. C’est le moment idéal pour remettre à plat votre modèle d’exploitation — et potentiellement réduire la facture de 20 à 35 % en faisant jouer la concurrence entre prestataires TMA, MSP, et le support éditeur.
La fin de contrat est aussi le seul moment où vous avez réellement du levier de négociation. Ne le laissez pas passer sans avoir exploré les alternatives.
Migration vers un ERP SaaS : opportunité de repartir avec un modèle opéré
Quand vous migrez d’un ERP on-premise vieillissant vers SAP S/4HANA Cloud Public, Dynamics 365 Business Central ou Odoo 18 en mode SaaS, la question de l’infogérance se pose différemment. L’éditeur s’occupe de l’infrastructure. Mais quelqu’un doit toujours gérer le paramétrage, les spécifiques, les montées de version fonctionnelles et le support utilisateur de second niveau.
Confier ce rôle à un MSP certifié sur votre nouvel ERP dès le premier jour vous évite de reconstruire une compétence interne sur une technologie que vous venez d’acquérir.
Croissance internationale avec ERP multi-sites difficile à piloter en interne
Ouvrir une filiale en Pologne, un entrepôt en Espagne et une holding en Belgique, c’est multiplier les exigences réglementaires locales (facturation électronique, TVA locale, reporting statutaire) sur un seul système d’information. Piloter ça avec une équipe IT centralisée en France qui n’a jamais mis les pieds dans un KSeF polonais ou un SII espagnol, c’est s’exposer à des redressements ou des retards de déploiement coûteux.
Un MSP avec présence multi-pays ou une expertise multi-fiscalités peut absorber cette complexité à moindre coût que de l’internaliser.
Audit de sécurité défavorable sur l’exploitation ERP on-premise
La mise à jour des correctifs de sécurité sur un ERP on-premise exige une discipline opérationnelle que beaucoup d’équipes IT generalists ne peuvent pas tenir : patch Tuesday, tests de non-régression, fenêtres de maintenance planifiées, monitoring des incidents P1. Un audit ISO 27001 ou NIS 2 qui conclut que votre ERP est la principale surface d’attaque de votre SI est souvent le déclencheur qui fait basculer un DSI vers l’infogérance.
Les 3 modèles d’externalisation ERP à connaître
Ces trois modèles ne sont pas interchangeables. Choisir le mauvais coûte cher.
TMA (Tierce Maintenance Applicative) — le classique
La TMA est le modèle historique. Un intégrateur ERP prend en charge la maintenance corrective (résolution de bugs), adaptative (mises à jour réglementaires et versions éditeur) et évolutive (nouvelles fonctionnalités dans le périmètre contractuel). L’infrastructure reste sous votre responsabilité ou celle de votre hébergeur.
La TMA convient quand votre ERP fonctionne bien opérationnellement mais que vous n’avez pas en interne les ressources pour gérer les cycles de mise à jour et les tickets de niveau 2-3.
Ce que la TMA ne couvre pas : la supervision d’infrastructure, le helpdesk niveau 1, la gestion des incidents d’exploitation (base de données qui gonfle, batch qui se bloque à 3h du matin). Ces sujets tombent soit dans votre IT interne, soit dans un contrat MSP.
Managed Services ERP (MSP) — exploitation complète infra + applicatif + MCO
Le Managed Service Provider ERP gère le périmètre complet : hébergement, supervision 24/7, patch management système et applicatif, support utilisateur (souvent de niveau 1 à 3), et pilotage du MCO (Maintien en Conditions Opérationnelles). Vous achetez une disponibilité contractualisée, pas des heures.
Le MSP est adapté aux ETI qui veulent externaliser tout le “run” et garder en interne uniquement le “build” (projets d’évolution, intégrations métier). Il est aussi pertinent quand votre ERP tourne sur une infrastructure cloud privée ou hybride que vous ne voulez plus opérer vous-même.
Différence clé avec le SaaS éditeur : le MSP peut opérer votre ERP existant, très paramétré, avec vos spécifiques — sans vous imposer une réimplémentation. C’est souvent ce qui le rend incontournable pour les ERP qui ont 10 ans de personnalisations accumulées.
BPO (Business Process Outsourcing) — externalisation des processus métier avec l’outil
Le BPO va plus loin que le MSP : le prestataire n’exploite plus seulement votre ERP, il exécute vos processus métier à travers lui. Vous achetez un résultat opérationnel — “toutes vos factures fournisseurs traitées dans les 48h” ou “votre paie livrée le 25 de chaque mois” — pas un niveau de service technique.
Le BPO ERP est pertinent pour des processus bien délimités et stables : comptabilité fournisseurs, paie externalisée, gestion des notes de frais, recouvrement. Il exige en contrepartie une relation contractuelle plus longue (3 à 5 ans minimum) et une capacité à mesurer des KPIs de résultat, pas seulement des SLA techniques.
Ce que doit contenir un bon contrat d’infogérance ERP
Un contrat d’infogérance ERP mal négocié vous lie pendant trois à cinq ans à des conditions que vous regretterez au premier incident majeur.
SLA disponibilité : 99,5 % vs 99,9 % — ce que la différence coûte vraiment
Un SLA de disponibilité de 99,5 % autorise 43,8 heures d’indisponibilité cumulée par an. Un SLA de 99,9 % en autorise 8,7 heures. La différence en valeur nominale semble faible. Sauf si cette indisponibilité tombe pendant votre clôture mensuelle ou votre période d’inventaire annuel.
Négociez deux choses systématiquement : premièrement, la définition exacte du calcul — les “fenêtres de maintenance planifiées” sont-elles exclues du compteur ? (Souvent oui dans les contrats standardisés.) Deuxièmement, les pénalités applicables quand le SLA n’est pas tenu. Un SLA sans pénalité contractuelle n’est qu’une promesse marketing.
PRA/PCA : les RTO et RPO à négocier impérativement
Le RTO (Recovery Time Objective) définit le délai maximum pour restaurer le service après un incident majeur. Le RPO (Recovery Point Objective) définit la quantité maximale de données acceptables à perdre. Ces deux métriques doivent figurer noir sur blanc dans votre contrat, par niveau de criticité.
Pour un ERP de gestion comptable et commerciale, un RTO de 4 heures et un RPO de 1 heure sont des ordres de grandeur raisonnables en mode production. Un RTO de 48 heures est inacceptable si votre ERP supporte des opérations en temps réel.
Gouvernance : comité de suivi et escalade
Un bon contrat d’infogérance prévoit une gouvernance documentée : comité de suivi mensuel avec reporting d’incidents, procédure d’escalade pour les incidents P1 (astreinte 24/7 ?), délais de prise en charge par priorité (P1 : 30 min, P2 : 4h, P3 : 24h), et un interlocuteur nommé côté prestataire.
L’absence de gouvernance formalisée est la première source de litiges en fin de contrat — “Vous n’avez jamais escaladé correctement, donc le pénalité ne s’applique pas.”
Réversibilité : le nerf de la guerre
La clause de réversibilité est le point le plus négligé dans les contrats d’infogérance et le plus coûteux à rattraper. Que se passe-t-il quand vous décidez de changer de prestataire ou de réinternaliser ? Vous avez besoin d’une base de données propre, dans un format exploitable, avec la documentation technique à jour.
Négociez explicitement : format des exports de données (SQL brut, pas uniquement des sauvegardes propriétaires), délai de mise à disposition (30 jours maximum), et accompagnement technique pendant la période de transition (1 à 3 mois). Certains prestataires proposent des clauses de “portage” payantes — intégrez ce coût dans votre TCO dès la signature.
Sécurité : les certifications à exiger
Pour un MSP ERP en 2026, demandez systématiquement la certification ISO 27001 (management de la sécurité de l’information), et pour les prestataires qui hébergent chez un hyperscaler, un rapport SOC 2 Type II récent (pas plus de 12 mois). Si votre ERP contient des données de santé (pharma, dispositifs médicaux), ajoutez la qualification HDS (Hébergeur de Données de Santé). Et quel que soit le périmètre, un DPA (Data Processing Agreement) conforme RGPD signé est non négociable.
Infogérance vs ERP SaaS natif : quand l’un est meilleur que l’autre
ERP SaaS natif (Dynamics 365, SAP RISE, Odoo Cloud)
Un ERP SaaS natif inclut la maintenance applicative, les mises à jour, et l’infrastructure dans son abonnement. C’est le modèle le plus simple opérationnellement : votre prestataire interne n’a plus à gérer les correctifs, la supervision ou les sauvegardes. Les cycles de mise à jour sont automatiques (ou semi-automatiques selon l’éditeur).
La contrepartie : moins de personnalisation possible, une dépendance forte aux choix de l’éditeur pour les évolutions fonctionnelles, et une portabilité des données à anticiper dès le départ.
Préférez le SaaS natif quand : votre ERP actuel n’a pas de spécifiques lourds, votre équipe IT est petite, et votre priorité est la simplicité opérationnelle plutôt que le contrôle.
Infogérance d’un ERP on-premise ou cloud privé
L’infogérance MSP est pertinente quand votre ERP est fortement paramétré, avec des développements spécifiques qui ne survivraient pas à une réimplémentation. Elle vous permet de continuer à exploiter votre investissement logiciel tout en déléguant l’opérationnel à un tiers compétent.
Préférez l’infogérance MSP quand : votre ERP a 5 ans ou plus de paramétrages accumulés, votre intégration avec d’autres systèmes (MES, WMS, CRM) est complexe, et une migration vers un SaaS imposerait un projet de réimplémentation de 12 à 24 mois que vous n’avez pas le budget ni la bande passante pour absorber maintenant.
Le cas du lift-and-shift : une fausse économie souvent évitable
Le “lift-and-shift” consiste à migrer votre ERP on-premise existant chez un MSP ou un hyperscaler sans modification de l’architecture ni modernisation. Le serveur physique disparaît, il est remplacé par une VM dans un datacenter tiers. La facture infrastructure diminue de 20 à 30 %. Mais la dette technique reste intacte — voire s’accumule plus vite, parce que personne ne se sent responsable des modules non maintenus.
Avant de signer un contrat lift-and-shift, posez cette question à votre MSP : “Qu’est-ce qui vous empêche de faire cela en natif cloud ?” Si la réponse est “votre version de l’ERP n’est plus supportée par l’éditeur”, vous n’avez pas résolu votre problème. Vous avez déplacé votre dette technique vers un prestataire qui sera rémunéré pour la conserver.
Combien coûte l’infogérance ERP ? Ordres de grandeur 2026
Fourchettes de coût mensuel par taille d’ERP
Les fourchettes ci-dessous sont indicatives et varient significativement selon le périmètre inclus dans le contrat (TMA seule, MSP complet, BPO partiel), la complexité du paramétrage, et la localisation du prestataire.
| Taille ERP | TMA seule | MSP complet |
|---|---|---|
| 50 utilisateurs (PME) | 1 500 à 3 500 €/mois | 3 000 à 7 000 €/mois |
| 150 à 200 utilisateurs (ETI) | 4 000 à 9 000 €/mois | 8 000 à 18 000 €/mois |
| 400 à 500 utilisateurs (ETI grande taille) | 10 000 à 22 000 €/mois | 18 000 à 45 000 €/mois |
Ces fourchettes partent du principe que l’ERP est un progiciel standard avec des spécifiques modérées. Un ERP fortement customisé avec des interfaces critiques (EDI, MES, WMS) peut faire doubler la fourchette haute.
Comparaison TCO 5 ans : exploitation interne vs TMA vs MSP vs SaaS natif
Le TCO d’une exploitation interne est souvent sous-évalué : il faut compter le salaire complet du responsable ERP (chargé social inclus), la formation continue, le matériel, les licences infrastructure, et surtout le coût caché des incidents non traités qui s’accumulent faute de ressources.
Sur un horizon de 5 ans, les ordres de grandeur observés chez les ETI de 150 à 200 utilisateurs placent souvent le MSP complet à un niveau de coût total comparable à l’exploitation interne — avec un niveau de service contractuellement garanti que l’interne ne peut pas toujours tenir. Le SaaS natif reste en général la solution la moins coûteuse en TCO brut, mais uniquement si la migration ne nécessite pas de réimplémentation lourde.
Comment sélectionner un prestataire d’infogérance ERP : 8 critères
- Certifications sur votre ERP : est-il partenaire Gold/Platinum de votre éditeur ? Combien de consultants certifiés sur votre version ?
- Modèle de support : le helpdesk est-il internalisé ou sous-traité offshore ? Quel est le délai de prise en charge réel (pas nominal) constaté chez ses clients actuels ?
- PRA/PCA opérationnel : a-t-il déjà activé son PRA en conditions réelles ? Demandez une référence de client ayant subi un incident P1.
- Taille et similarité du portefeuille client : gère-t-il des clients de votre taille et dans votre secteur ? Un MSP habitué aux PME de 30 utilisateurs ne sera pas à l’aise avec votre ETI de 300 utilisateurs.
- Certifications sécurité : ISO 27001 à jour, SOC 2 Type II si applicable, localisation des données (dans l’UE obligatoirement pour la conformité RGPD).
- Transparence sur les sous-traitants : un MSP qui héberge chez AWS ou OVHcloud doit vous indiquer explicitement sa chaîne de sous-traitance et vous permettre d’auditer sa conformité RGPD.
- Modèle tarifaire et pilotage des dérives : le contrat est-il à forfait fixe, à la consommation ou hybride ? Comment les dépassements de périmètre sont-ils facturés et maîtrisés ?
- Réversibilité : quelle est sa politique documentée de sortie de contrat ? Un prestataire qui refuse de détailler ses conditions de réversibilité lors des négociations initiales vous répondra encore moins favorablement quand vous voudrez partir.
Matrice de décision simplifiée
Avant de passer à l’appel d’offres, répondez aux cinq questions de cette matrice :
| Question | Vers TMA | Vers MSP | Vers SaaS natif |
|---|---|---|---|
| Votre équipe IT interne peut-elle gérer l’infra ERP ? | Oui | Non | Non |
| Votre ERP a-t-il des spécifiques lourds ? | Oui | Oui | Non |
| Pouvez-vous absorber un projet de migration complet ? | — | — | Oui |
| Votre secteur est-il fortement réglementé ? | Voir avec TMA | Oui (SOC 2, ISO 27001) | Selon éditeur |
| Votre priorité est-elle le coût ou le contrôle ? | Contrôle | Contrôle | Coût |
Si vous répondez “Non” à la première question et “Oui” à la deuxième, le MSP est votre scénario naturel. Si vous répondez “Non” à la deuxième et “Oui” à la troisième, explorez le SaaS natif avec une migration planifiée sur 12 à 18 mois.
Pour approfondir les aspects contractuels avant de lancer votre appel d’offres d’infogérance, consultez notre guide des 8 clauses à négocier dans un contrat TMA ERP et notre analyse des leviers d’optimisation des coûts ERP post-go-live. Si votre réflexion part en sens inverse — revenir de l’infogérance cloud vers une exploitation plus contrôlée — lisez aussi notre article sur la répatriation cloud vers on-premise.
