{"id":9904,"date":"2026-03-27T19:25:32","date_gmt":"2026-03-27T18:25:32","guid":{"rendered":"https:\/\/arc-guides.com\/docs\/prism\/support\/structuration-de-la-maintenance-applicative\/"},"modified":"2026-05-31T23:08:56","modified_gmt":"2026-05-31T21:08:56","slug":"structuration-de-la-maintenance-applicative","status":"publish","type":"docs","link":"https:\/\/arc-guides.com\/en\/docs\/prism\/support\/structuration-de-la-maintenance-applicative\/","title":{"rendered":"Structuration de la maintenance applicative"},"content":{"rendered":"
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

ERP en production : comment g\u00e9rer les \u00e9volutions sans perdre le contr\u00f4le ?<\/h1>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Votre ERP est en place, le go-live est derri\u00e8re vous \u2014 et pourtant les demandes d’am\u00e9lioration s’accumulent, les utilisateurs r\u00e9clament des ajustements, et vous sentez que chaque modification pourrait fragiliser ce que vous avez mis des mois \u00e0 construire ? Dans la m\u00e9thode PRISM, vous \u00eates dans la phase SUPPORT<\/span>, au c\u0153ur de son deuxi\u00e8me pilier : la maintenance applicative et la gestion des \u00e9volutions<\/span>. Dans cet article, d\u00e9couvrez comment transformer ce flux de demandes en un processus ma\u00eetris\u00e9 \u2014 sans d\u00e9stabiliser votre syst\u00e8me, sans freiner vos \u00e9quipes.
<\/p>

<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

\ud83c\udfaf L’essentiel<\/h2>
  • Un ERP en production n’est jamais fig\u00e9 : les besoins \u00e9voluent, la r\u00e9glementation change, les utilisateurs progressent. Ne pas cadrer ce flux, c’est prendre le risque de voir votre syst\u00e8me se fragmenter<\/strong> \u2014 ou vos \u00e9quipes le contourner avec des fichiers Excel.<\/li>
  • La RFC (Request for Change<\/em>) est l’outil cl\u00e9 : elle transforme une demande informelle en d\u00e9cision document\u00e9e, arbitr\u00e9e et trac\u00e9e. Toute \u00e9volution qui entre dans l’ERP doit passer par ce canal.<\/li>
  • L’enjeu n’est pas de dire oui ou non \u00e0 chaque demande, mais de prioriser par la valeur<\/strong> : ce qui prot\u00e8ge l’activit\u00e9, ce qui am\u00e9liore la productivit\u00e9, et ce qui peut attendre \u2014 ou \u00eatre refus\u00e9.<\/li><\/ul>

    <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

    \n\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
    \n\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    Pourquoi les \u00e9volutions sont in\u00e9vitables\u2026 et dangereuses si mal g\u00e9r\u00e9es<\/h2>

    Une fois en production, votre ERP va recevoir des sollicitations de tous c\u00f4t\u00e9s. Les utilisateurs trouvent des cas non couverts. La r\u00e9glementation \u00e9volue. Un processus qui fonctionnait bien en th\u00e9orie s’av\u00e8re trop rigide en pratique. C’est normal, et c’est m\u00eame le signe que votre outil est utilis\u00e9.<\/p>

    Le danger, c’est de tomber dans l’un des deux extr\u00eames :<\/p>

    Tout accepter<\/strong> conduit \u00e0 la sur-customisation. Chaque d\u00e9veloppement sp\u00e9cifique ajout\u00e9 alourdit le syst\u00e8me, complique les futures mises \u00e0 jour et g\u00e9n\u00e8re une dette technique qui finit par rendre l’ERP impossible \u00e0 maintenir. Quand plus de 25 \u00e0 30 % du budget total du projet est absorb\u00e9 par des d\u00e9veloppements sp\u00e9cifiques, les mont\u00e9es de version deviennent un chantier \u00e0 part enti\u00e8re \u2014 co\u00fbteux et risqu\u00e9.<\/p>

    Tout refuser ou ignorer<\/strong> conduit au Shadow IT. Si vos \u00e9quipes ne trouvent pas de r\u00e9ponse dans l’ERP, elles construisent leurs propres outils en dehors : fichiers Excel partag\u00e9s, outils SaaS non r\u00e9f\u00e9renc\u00e9s, bases Access maison. Le r\u00e9sultat ? Des donn\u00e9es fragment\u00e9es, des processus non tra\u00e7ables, et une adoption de l’ERP qui recule silencieusement.<\/p>

    <\/p>

    <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

    \n\t\t
    \n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t
    \n\t\t\t
    \n\t\t\t<\/i>\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t

    Attention :<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
    \n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    La prolif\u00e9ration de fichiers Excel apr\u00e8s le go-live n’est pas un probl\u00e8me de discipline utilisateur \u2014 c’est un signal que le syst\u00e8me ne r\u00e9pond pas \u00e0 leurs besoins r\u00e9els. Avant de sanctionner, interrogez-vous sur ce qui manque dans l’outil.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

    \n\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    L’\u00e9quilibre \u00e0 trouver, c’est celui d’une am\u00e9lioration continue structur\u00e9e et arbitr\u00e9e : \u00e9voluer r\u00e9guli\u00e8rement, mais de fa\u00e7on contr\u00f4l\u00e9e, en gardant un ERP qui reste maintenable et upgradeable sur le long terme.<\/p>

    La RFC : transformer une demande en d\u00e9cision<\/h2>

    La Request for Change<\/strong> (RFC) est la brique de base de votre gouvernance des \u00e9volutions. C’est un formulaire standardis\u00e9 \u2014 souvent int\u00e9gr\u00e9 \u00e0 votre outil de ticketing \u2014 qui formalise toute demande de modification de l’ERP.<\/p>

    Son principe est simple : aucune \u00e9volution ne part en production sans avoir \u00e9t\u00e9 document\u00e9e, analys\u00e9e et valid\u00e9e<\/strong>. Cela peut sembler lourd au d\u00e9part, mais c’est ce qui vous \u00e9vite les modifications \u00ab\u00a0\u00e0 chaud\u00a0\u00bb qui d\u00e9stabilisent le syst\u00e8me et personne ne sait qui a fait quoi.<\/p>

    Le cycle de vie d’une RFC suit plusieurs \u00e9tapes cl\u00e9s :<\/p>

    1. Soumission<\/strong> \u2014 L’utilisateur ou le Key User d\u00e9crit son besoin en langage m\u00e9tier, avec l’impact attendu et la justification.<\/li>
    2. Qualification<\/strong> \u2014 L’\u00e9quipe applicative v\u00e9rifie si le besoin peut \u00eatre couvert par le standard de l’ERP avant d’envisager un d\u00e9veloppement. C’est l’\u00e9tape la plus importante : chercher d’abord dans ce qui existe d\u00e9j\u00e0.<\/li>
    3. Analyse d’impact<\/strong> \u2014 Estimation de l’effort, des risques techniques et des impacts sur les autres modules.<\/li>
    4. Arbitrage<\/strong> \u2014 La RFC passe devant un comit\u00e9 de d\u00e9cision qui la priorise ou la rejette.<\/li>
    5. R\u00e9alisation et tests<\/strong> \u2014 D\u00e9veloppement en environnement isol\u00e9, tests de non-r\u00e9gression, puis validation utilisateur (UAT).<\/li>
    6. Mise en production et suivi<\/strong> \u2014 D\u00e9ploiement contr\u00f4l\u00e9, avec un plan de retour arri\u00e8re en cas de probl\u00e8me.<\/li><\/ol>

      \ud83d\udccc N’oubliez pas :<\/strong> Le principe directeur de toute RFC doit \u00eatre \u00ab\u00a0Standard d’abord\u00a0\u00bb<\/strong>. Si une fonctionnalit\u00e9 standard de l’ERP couvre le besoin \u00e0 80 %, la bonne r\u00e9ponse est souvent d’adapter le processus \u2014 pas de d\u00e9velopper un sp\u00e9cifique pour les 20 % restants.<\/p><\/blockquote>

      Au c\u0153ur de ce processus, le BPO (Business Process Owner)<\/strong> joue un r\u00f4le pivot. C’est lui qui porte la responsabilit\u00e9 m\u00e9tier du backlog des \u00e9volutions pour son domaine (Finance, Supply Chain, RH\u2026). Il challenge les demandes, \u00e9value leur valeur r\u00e9elle pour l’activit\u00e9, et donne l’aval final avant la mise en production. Sans BPO impliqu\u00e9, la gouvernance des \u00e9volutions devient rapidement un catalogue de tickets IT d\u00e9connect\u00e9 des enjeux m\u00e9tier.<\/p>

      \ud83d\udd0d Arbitrer intelligemment : valeur, co\u00fbt, risque<\/h2>

      Toutes les demandes d’\u00e9volution n’ont pas la m\u00eame valeur. L’enjeu du comit\u00e9 d’arbitrage, c’est pr\u00e9cis\u00e9ment de distinguer ce qui est indispensable<\/strong>, ce qui est utile<\/strong>, et ce qui peut attendre \u2014 ou \u00eatre refus\u00e9.<\/p>

      Une grille de priorisation simple repose sur trois niveaux :<\/p>

      • Priorit\u00e9 1 \u2014 Killers :<\/strong> Ce qui bloque une mission critique ou r\u00e9pond \u00e0 une obligation l\u00e9gale. Pas de n\u00e9gociation possible \u2014 c’est trait\u00e9 en priorit\u00e9 absolue. Exemple : une \u00e9volution de TVA r\u00e9glementaire.<\/em><\/li>
      • Priorit\u00e9 2 \u2014 Optimisations :<\/strong> Ce qui apporte un gain de productivit\u00e9 significatif, avec un ROI d\u00e9montrable, mais pour lequel un contournement temporaire est possible. Exemple : l’automatisation de la saisie des temps de production via douchettes \u2014 investissement de 15 k\u20ac pour un retour en 10 mois.<\/em><\/li>
      • Priorit\u00e9 3 \u2014 Nice to have :<\/strong> Ce qui am\u00e9liore le confort utilisateur sans impact op\u00e9rationnel majeur. Ces demandes entrent dans la file d’attente, et sont souvent les premi\u00e8res sacrifi\u00e9es en p\u00e9riode de forte charge.<\/li><\/ul>

        <\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

        \n\t\t\t\t\t
        \n\t\t
        \n\t\t
        \n\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t\t\t
        \n\t\t\t
        \n\t\t\t<\/g><\/g> <\/path> <\/polygon> <\/polygon> <\/polygon> <\/path> <\/path> <\/path> <\/path> <\/path> <\/path> <\/g> <\/path> <\/g><\/svg>\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t

        Exemple concret <\/b><\/p>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

        \n\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t

        Une \u00e9quipe demande la d\u00e9sactivation du blocage automatique des commandes client en cas de d\u00e9passement de cr\u00e9dit, jug\u00e9 \u00ab\u00a0trop rigide\u00a0\u00bb. Avant d’accepter cette RFC, le BPO identifie que le vrai probl\u00e8me est un manque de formation sur le processus de d\u00e9blocage manuel par le service financier. R\u00e9sultat : \u00e9conomie du co\u00fbt de d\u00e9veloppement, maintien de la s\u00e9curit\u00e9 financi\u00e8re, et une session de formation plut\u00f4t qu’un sp\u00e9cifique.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

        \n\t\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t

        Trois red flags<\/strong> doivent vous alerter que votre gouvernance des \u00e9volutions d\u00e9croche :<\/p>

        • La sur-customisation<\/strong> : chaque nouveau besoin d\u00e9clenche automatiquement un d\u00e9veloppement, sans exploration du standard. Signe que le processus RFC n’est pas respect\u00e9 ou que les BPO ne challengent pas suffisamment les demandes.<\/li>
        • Le backlog explosif<\/strong> : les RFC s’accumulent sans \u00eatre arbitr\u00e9es, les utilisateurs ne croient plus que leurs demandes aboutiront, et les contournements se multiplient.<\/li>
        • Le Shadow IT<\/strong> : vos \u00e9quipes recr\u00e9ent en dehors de l’ERP ce qu’elles ne trouvent pas dedans. C’est le sympt\u00f4me ultime d’une gouvernance des \u00e9volutions qui ne fonctionne plus.<\/li><\/ul>

          \ud83d\udd0d G\u00e9rer le risque de non-r\u00e9gression<\/h2>

          C’est l’angle souvent sous-estim\u00e9 de la gestion des \u00e9volutions : toute modification d’un module ERP peut impacter d’autres parties du syst\u00e8me<\/strong>. Un ajustement dans le module achats peut perturber la comptabilit\u00e9. Un changement de param\u00e9trage sur les stocks peut affecter la facturation. C’est ce qu’on appelle le risque de non-r\u00e9gression.<\/p>

          La r\u00e8gle d’or est simple : ne jamais tester ni d\u00e9ployer directement en production.<\/strong> Toute \u00e9volution doit suivre une cha\u00eene d’environnements s\u00e9par\u00e9s :<\/p>

          DEV \u2192 TEST \u2192 UAT \u2192 PRODUCTION<\/strong><\/p>

          Chaque \u00e9tape a son r\u00f4le : le d\u00e9veloppement et les tests techniques se font en DEV et TEST, la validation m\u00e9tier se fait en UAT avec des cas r\u00e9els, et seulement apr\u00e8s validation formelle du BPO la modification passe en production.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

          \n\t\t\t\t\t
          \n\t\t
          \n\t\t\t\t
          \n\t\t\t\t
          \n\t\t\t\t\t\t\t
          \n\t\t\t
          \n\t\t\t<\/g><\/g><\/path><\/path><\/path><\/path><\/path><\/path><\/path><\/path><\/g><\/svg>\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
          \n\t\t\t\t
          \n\t\t\t\t\t

          M\u00e9mo<\/b><\/p>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

          \n\t\t\t\t
          \n\t\t\t\t
          \n\t\t\t\t\t\t\t\t\t

          Maintenez toujours un plan de retour arri\u00e8re<\/span> (rollback<\/span>) pour chaque d\u00e9ploiement. Si un incident survient apr\u00e8s une mise en production, vous devez pouvoir revenir \u00e0 l’\u00e9tat pr\u00e9c\u00e9dent rapidement \u2014 sans avoir \u00e0 improviser sous pression.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

          \n\t\t\t\t\t
          \n\t\t\t\t
          \n\t\t\t\t
          \n\t\t\t\t\t\t\t\t\t

          Les organisations les plus matures construisent progressivement un catalogue de sc\u00e9narios de test par processus<\/strong> (Order-to-Cash, Procure-to-Pay, paie\u2026) qui sont rejou\u00e9s \u00e0 chaque modification. C’est un investissement initial, mais il \u00e9vite les mauvaises surprises en cascade.<\/p>

          Les KPI pour piloter vos \u00e9volutions<\/h2>

          Sans indicateurs, la gestion des \u00e9volutions se fait \u00e0 l’intuition \u2014 et les d\u00e9rives passent inaper\u00e7ues. Quatre KPI essentiels suffisent pour avoir une vision claire :<\/p>

          • Taille du backlog en semaines de capacit\u00e9<\/strong> : combien de semaines de travail repr\u00e9sentent vos RFC en attente ? Un backlog sain se situe entre 2 et 4 semaines. Au-del\u00e0 de 6 semaines, c’est un signal d’alerte \u2014 la demande d\u00e9passe la capacit\u00e9 ou la priorisation est insuffisante.<\/li>
          • Lead time moyen d’une RFC<\/strong> : temps \u00e9coul\u00e9 entre la soumission et la mise en production. Suivez-le par cat\u00e9gorie (correctif, \u00e9volutif, r\u00e9glementaire) pour voir o\u00f9 le pipeline se bloque.<\/li>
          • Taux de succ\u00e8s des changements<\/strong> : pourcentage de RFC d\u00e9ploy\u00e9es sans incident dans les jours suivant la mise en production. Cible : plus de 95 % pour les changements standardis\u00e9s.<\/li>
          • Part de RFC \u00ab\u00a0sur-mesure\u00a0\u00bb<\/strong> : si la proportion de d\u00e9veloppements sp\u00e9cifiques augmente r\u00e9guli\u00e8rement, c’est que votre principe \u00ab\u00a0Standard d’abord\u00a0\u00bb ne tient pas.<\/li><\/ul>

            Sur la question du mod\u00e8le de gouvernance<\/strong>, deux approches s’opposent \u2014 et la r\u00e9alit\u00e9 des organisations performantes est souvent hybride :<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

            \n\t\t\t\t\t
            \n\t\t\t\t
            \n\t\t\t\t
            \n\t\t\t\t\t\t\t\t\t
            \n \n \n \n \n \n \n
            Mod\u00e8le<\/th>\n Forces<\/th>\n Limites<\/th>\n <\/tr>\n <\/thead>\n
            Gouvernance annuelle<\/strong><\/td>\n Stabilit\u00e9, pr\u00e9visibilit\u00e9 budg\u00e9taire<\/td>\n Lent, rigide, effet tunnel<\/td>\n <\/tr>\n
            Mod\u00e8le agile (sprints)<\/strong><\/td>\n R\u00e9activit\u00e9, livraisons fr\u00e9quentes<\/td>\n N\u00e9cessite discipline et automatisation des tests<\/td>\n <\/tr>\n <\/tbody>\n <\/table>\n<\/div>\n\n