Le go-live a eu lieu, la recette est signée, l’équipe projet retourne dans ses services d’origine et l’intégrateur passe en mode “garantie”. Six mois plus tard, une question simple reste sans réponse : qui possède l’ERP ? Qui décide d’ajouter un champ, de corriger un paramétrage, de refuser une demande d’évolution ? Qui sait comment la comptabilité fournisseurs est réellement configurée ?
Dans la plupart des projets que nous observons, la réponse est “personne, ou plutôt tout le monde un peu”. C’est le terrain idéal pour la dérive. Ce guide opérationnel s’adresse aux DSI et DAF d’ETI et de PME en fin de projet : comment dimensionner, organiser et gouverner l’équipe qui reste. Il se concentre sur le run au quotidien (rôles, effectifs, niveaux de support, rituels). Pour la dimension stratégique d’un centre d’excellence, voyez notre guide sur le Centre d’Excellence ERP (CoE).
Précision méthodologique : les ordres de grandeur d’effectifs donnés plus bas sont des estimations issues de l’expérience terrain, pas des statistiques publiées. Adaptez-les à votre périmètre, à votre nombre d’utilisateurs et à la complexité de vos processus.
Pourquoi l’ERP se dégrade sans propriétaire
Un ERP n’est pas un actif qui se maintient tout seul. L’activité de l’entreprise change, la réglementation évolue, l’éditeur livre des mises à jour, les collaborateurs tournent. Sans propriétaire clair, la dégradation suit un schéma assez prévisible.
À 3 mois : les anomalies de jeunesse s’accumulent dans des mails et des tableurs. Les utilisateurs contournent l’outil (“je note ça à côté, c’est plus rapide”). Le support passe par la personne qui connaît le mieux le système, généralement un ancien membre de l’équipe projet, qui n’a plus ce temps dans son agenda.
À 6 mois : les demandes d’évolution arrivent par toutes les portes (direction, métiers, intégrateur). Personne n’arbitre, donc chacun obtient un peu de ce qu’il demande, sans cohérence. Les premiers paramétrages “provisoires” deviennent définitifs. Les données maîtres (articles, tiers, plans de comptes) commencent à diverger.
À 12 mois : la connaissance du paramétrage est dans la tête de deux ou trois personnes. Une montée de version devient un sujet anxiogène. L’intégrateur est sollicité pour des questions que l’entreprise devrait savoir traiter seule, et la facture de régie grossit. Les indicateurs d’adoption s’érodent, souvent sans bruit : c’est le phénomène décrit dans notre article sur les 8 KPI de rejet silencieux après le go-live.
Le coût de cette dérive est rarement visible dans un budget unique : il se diffuse en temps perdu, en ressaisies, en clôtures plus longues et en dépendance accrue au prestataire. C’est pourquoi la question du run doit être traitée avant le go-live, pas après.
Les trois modèles : interne, mixte, externalisé
Il n’existe pas de modèle universel. Le bon choix dépend de la taille, de la criticité de l’ERP et de la capacité à recruter ou former en interne.
| Modèle | Principe | Avantages | Limites | Seuil de taille indicatif* |
|---|---|---|---|---|
| Interne | Équipe dédiée en propre, support N1 à N3 assuré en interne (hors éditeur) | Connaissance métier maximale, réactivité, maîtrise des coûts à long terme | Recrutement difficile, risque de dépendance à quelques personnes, besoin de formation continue | ETI avec un périmètre large et plusieurs centaines d’utilisateurs |
| Mixte (interne + TMA) | Pilotage et N1/N2 en interne, N3 et évolutions techniques confiés à un intégrateur sous contrat | Bon équilibre coût/compétence, flexibilité, accès à une expertise rare | Exige un contrat TMA bien négocié et un interlocuteur interne solide | Le cas le plus courant en PME et petite ETI |
| Externalisé | Run complet confié à un prestataire, avec un référent interne minimal | Pas de recrutement, montée en charge rapide | Perte de maîtrise, coût récurrent élevé, risque de pilotage “à l’aveugle” | Petites structures sans DSI, ou périmètre standard et stable |
*Seuils donnés à titre d’orientation, fondés sur l’expérience terrain et non sur une étude chiffrée.
Quel que soit le modèle, un principe ne se délègue pas : la propriété fonctionnelle de l’ERP reste dans l’entreprise. Vous pouvez externaliser le N3 technique, jamais l’arbitrage sur ce que l’ERP doit faire. Pour le détail contractuel du modèle mixte, voyez notre guide du contrat TMA ERP.
Les rôles indispensables
Cinq rôles suffisent à couvrir le run d’un ERP. Dans une PME, une même personne en cumule plusieurs ; dans une ETI, chacun peut devenir un poste à part entière. Les temps ci-dessous sont des estimations d’ordre de grandeur, exprimées en équivalents temps plein (ETP), à valider selon votre contexte.
Product owner processus
C’est le “propriétaire” de l’ERP côté entreprise. Il porte la feuille de route, priorise les demandes, arbitre entre métiers et représente l’ERP au comité d’évolution. Il vient en général de la DAF, des opérations ou de la DSI, mais doit avoir l’autorité (ou le soutien du sponsor) pour dire non.
Temps indicatif (estimation) : de 0,2 ETP en PME à 1 ETP en ETI multi-sites.
Administrateur fonctionnel
Il paramètre, teste et documente. Il traite les demandes de niveau 2, gère les droits d’accès, prépare les recettes de montée de version. C’est le détenteur du “pourquoi c’est configuré comme ça”. Sans lui, le paramétrage devient une boîte noire.
Temps indicatif (estimation) : 0,5 à 1 ETP en PME ; 2 à 4 ETP en ETI selon le nombre de modules.
Key users par domaine
Un key user par domaine fonctionnel (finance, achats, ventes, production, logistique, RH). Il connaît le métier et l’outil, répond aux questions de ses collègues (niveau 1), remonte les anomalies qualifiées et teste les évolutions. Les key users sont nommés avant la recette, pas après : ce sont eux qui valident que le système correspond au métier, et ils doivent s’approprier le paramétrage pendant le projet.
Temps indicatif (estimation) : 10 à 20 % de leur temps, soit 0,1 à 0,2 ETP chacun. Ce temps doit être inscrit dans leurs objectifs et validé par leur hiérarchie, sinon il disparaîtra en période de pic.
Référent technique et intégrations
Il suit l’infrastructure ou le tenant cloud, les interfaces (EDI, banque, e-commerce, paie), les sauvegardes, les habilitations techniques et la relation avec l’éditeur pour les mises à jour. Il est l’interface naturelle avec le prestataire TMA sur le niveau 3.
Temps indicatif (estimation) : 0,2 à 0,5 ETP en PME (souvent porté par le responsable informatique) ; 1 à 2 ETP en ETI.
Responsable des données maîtres
Souvent oublié, il est pourtant déterminant. Il pilote la création, la modification et le nettoyage des tiers, articles, nomenclatures, plans de comptes. Il définit les règles de nommage et de validation. Sans lui, la qualité de données se dégrade lentement, et avec elle la confiance dans les rapports.
Temps indicatif (estimation) : 0,2 à 0,5 ETP en PME ; 1 ETP ou plus en ETI avec de nombreux référentiels.
Pour les rôles du projet lui-même et leur articulation, reportez-vous à notre guide sur la composition de l’équipe projet et la matrice RACI : le centre de compétences est la continuation naturelle de cette équipe, pas une structure sans lien avec elle.
Les niveaux de support N1, N2, N3
Un support lisible évite que chaque question remonte au même expert. Une répartition simple fonctionne bien.
| Niveau | Qui | Périmètre | Exemples |
|---|---|---|---|
| N1 | Key users, super-users | Questions d’usage, aide à la saisie, rappel des procédures | ”Comment saisir un avoir ?”, “Où trouver ce rapport ?” |
| N2 | Administrateur fonctionnel | Anomalies de paramétrage, droits, corrections de données, petites évolutions | Droit manquant, règle de taxe mal paramétrée, workflow bloqué |
| N3 | Intégrateur / éditeur (via TMA) ou référent technique | Bugs applicatifs, développements spécifiques, interfaces, performances, montées de version | Interface bancaire en erreur, rapport spécifique à corriger |
Trois règles de fonctionnement :
- Un seul point d’entrée : un outil de tickets (même simple), pas des mails dispersés. Sans traçabilité, pas de pilotage possible.
- Qualification avant escalade : le N2 qualifie chaque ticket (anomalie, demande d’évolution, question de formation) avant de le transmettre. Une demande d’évolution n’est pas une anomalie, et ne doit pas consommer le forfait de maintenance.
- Frontière écrite avec le prestataire : le contrat TMA doit préciser ce qui relève du N3, les délais de prise en charge et les modalités d’escalade. Évitez le flou entre “support” et “conseil”.
Gouvernance : comité d’évolution et tableau de bord
Le comité d’évolution mensuel
Une réunion d’une heure à une heure et demie chaque mois, avec le product owner, l’administrateur fonctionnel, le référent technique, des représentants des domaines et, selon les sujets, l’intégrateur. L’ordre du jour est stable : revue du tableau de bord, backlog des demandes, décisions d’arbitrage, planning des mises à jour.
Règles d’arbitrage à écrire noir sur blanc :
- toute demande est consignée avec son demandeur, son processus concerné et son bénéfice attendu ;
- une demande est priorisée selon trois critères : obligation réglementaire ou arrêt d’activité, gain métier mesurable, effort de réalisation ;
- ce qui est standard de l’éditeur passe avant ce qui est spécifique ; tout spécifique doit justifier son coût de maintenance futur ;
- les désaccords entre domaines remontent au sponsor, qui tranche.
Le tableau de bord de run (5 indicateurs)
Cinq indicateurs suffisent pour commencer. Ils sont à fixer par vous, avec vos propres seuils.
- Volume et ancienneté des tickets ouverts, par niveau de support.
- Délai de résolution par criticité (bloquant, majeur, mineur).
- Part des demandes d’évolution livrées dans le trimestre par rapport au backlog.
- Taux d’adoption sur les processus clés (par exemple, part des commandes saisies directement dans l’ERP).
- Qualité des données maîtres (doublons, fiches incomplètes).
Le budget de run doit être distinct du budget projet, avec une ligne propre : support, TMA, licences et abonnements, évolutions, formation continue. Sans cette séparation, le run vit des restes du projet et disparaît à la première coupe budgétaire.
Monter le centre de compétences en 90 jours
Le plan démarre avant le go-live. Les repères de calendrier ci-dessous sont à adapter : J+0 est la date de décision de lancer le dispositif, idéalement trois à quatre mois avant la mise en production.
J+0 à J+15 : cadrer. Choix du modèle (interne, mixte, externalisé), désignation du product owner, validation du budget de run par le sponsor. Inventaire des compétences disponibles et des écarts.
J+15 à J+30 : nommer. Nomination officielle des key users et de l’administrateur fonctionnel, avec décharge de temps validée par leurs responsables. Définition du référent technique et du responsable des données maîtres.
J+30 à J+60 : transférer. Le transfert de connaissances de l’intégrateur vers l’interne se documente : sessions de binômage sur le paramétrage, dossier de spécifications à jour, procédures de clôture, cartographie des interfaces, comptes rendus de formation. Prévoyez-le dans le contrat de l’intégrateur comme un livrable, pas comme une bonne volonté.
J+60 à J+75 : outiller. Mise en place de l’outil de tickets, des niveaux N1/N2/N3, du contrat TMA aligné sur ce schéma. Première version du tableau de bord.
J+75 à J+90 : rôder. Premier comité d’évolution, formation du réseau de super-users, test de bout en bout du circuit de support sur des cas réels. Le réseau de super-users sert aussi de relais de la conduite du changement : ils expliquent, rassurent et remontent le ressenti du terrain.
5 erreurs fréquentes dans l’organisation du run
Chacune de ces erreurs est courante, et son coût n’apparaît souvent que plusieurs mois après le go-live. À chaque fois, une contre-mesure simple existe.
| Erreur | Conséquence | Contre-mesure |
|---|---|---|
| Dissoudre l’équipe projet le jour du go-live | Perte du savoir de paramétrage en quelques mois, dépendance accrue à l’intégrateur | Planifier une période de transition de plusieurs mois avec des rôles de run nommés |
| Nommer les key users après la recette | Recette peu représentative du métier, key users qui découvrent l’outil au lieu de le porter | Les désigner dès la phase de conception et les impliquer dans les tests |
| Absorber le run dans le budget projet | Le run vit des restes du projet, puis disparaît à la première coupe budgétaire | Créer une ligne budgétaire de run dès la validation du projet |
| Tout déléguer à l’intégrateur, y compris l’arbitrage | L’ERP évolue selon les priorités du prestataire, pas celles de l’entreprise | Conserver le product owner en interne et écrire la frontière N2/N3 dans le contrat |
| Laisser le temps des key users “à la bonne volonté” | Disponibilité qui s’évapore en période de pic, tickets non traités, relais de terrain absents | Inscrire ce temps dans leurs objectifs annuels, avec validation hiérarchique |
Checklist de démarrage
- Modèle de run choisi (interne, mixte, externalisé) et validé par le sponsor
- Product owner nommé, avec autorité d’arbitrage
- Administrateur fonctionnel et référent technique identifiés
- Key users nommés par domaine, temps dédié validé par leur hiérarchie
- Responsable des données maîtres désigné
- Budget de run distinct du budget projet
- Transfert de connaissances intégrateur vers interne inscrit au contrat, avec livrables
- Outil de tickets et niveaux N1/N2/N3 définis
- Contrat TMA aligné sur le partage des niveaux de support
- Comité d’évolution mensuel planifié, règles d’arbitrage écrites
- Tableau de bord de run à 5 indicateurs initialisé
- Réseau de super-users formé comme relais de la conduite du changement
Pour passer à l’action, téléchargez notre checklist projet ERP et utilisez-la pour cadrer la transition vers le run. Si vous souhaitez un regard extérieur, DigitsLane propose un audit d’organisation du run ERP. Pour aller plus loin sur la gouvernance, lisez aussi notre guide sur la gouvernance ERP post-déploiement.
