Les projets de modernisation du SI Finance s’imposent aujourd’hui comme une priorité dans de nombreuses organisations : remplacer un ERP vieillissant, fiabiliser les flux financiers, automatiser les processus de clôture, améliorer la qualité du reporting, ou encore intégrer les nouvelles capacités offertes par l’intelligence artificielle et les agents autonomes. Et la pression s’intensifie : la fin du support de SAP ECC au 31 décembre 2027, avec une maintenance étendue optionnelle jusqu’en 2030, contraint des milliers d’entreprises à lancer un projet différé pendant plusieurs années.
Ces projets représentent un enjeu majeur : selon plusieurs études, le taux d’échec des déploiements ERP dépasse 50 %, et certaines estimations de Gartner le situent jusqu’à 75 %. Mais l’échec complet n’est pas le seul risque à considérer. Il existe une catégorie de difficultés bien plus fréquente, et souvent plus insidieuse : les projets qui « passent » techniquement, mais qui fragilisent durablement la performance opérationnelle de la fonction finance dans les mois qui suivent.
Ce que les projets SI Finance sous-estiment systématiquement
La majorité des projets ERP sont pilotés sous un angle technologique : choix de la solution, intégration des systèmes, migration des données, recette fonctionnelle. C’est légitime. Mais les tensions observées après le go-live proviennent rarement de l’outil lui-même. On pense moderniser un système mais en réalité, on désorganise une fonction critique sans vraiment pouvoir mesurer le coût.
Ces tensions viennent d’ailleurs : des processus qui ont changé sans que les équipes aient pu les appréhender, des contrôles internes qui ont disparu dans la standardisation, des flux financiers devenus plus opaques à mesure qu’ils se sont automatisés.
Ces risques, appelons-les risques opérationnels post-déploiement, ont une caractéristique commune : ils n’apparaissent pas dans les tests de recette. Ils apparaissent lors de la première clôture réelle, ou lors du premier incident non anticipé par les procédures.
Pour autant, ces risques ne sont pas une fatalité. Ils sont identifiables et surtout gérables, à condition d’être intégrés dans la trajectoire du projet dès sa conception.
La dégradation des cycles de clôture
C’est souvent le premier signal. Même quand la solution fonctionne correctement, les équipes doivent reconstruire leurs repères opérationnels : les écrans ont changé, les référentiels ont évolué, certaines opérations se déroulent différemment dans le système.
Lors des premières clôtures, une partie significative du temps est consacrée à comprendre le comportement des flux, identifier l’origine d’une écriture, vérifier un rapprochement, comprendre pourquoi une opération reste bloquée dans un workflow, plutôt que de produire l’information financière.
Ce phénomène est bien documenté dans les projets ERP. Le déploiement ne s’arrête pas à la date de migration : la première clôture comptable constitue une étape critique à part entière, qui doit être anticipée avec autant de rigueur que la mise en production elle-même.
Dans les organisations où le calendrier de reporting est déjà contraint, une ou deux clôtures dégradées peuvent rapidement créer des tensions avec la direction générale ou les actionnaires, et installer un doute durable sur la fiabilité du système.
Un contrôle interne fragilisé par la standardisation
La modernisation du SI Finance implique presque toujours une refonte des processus. Les nouveaux systèmes automatisent certaines validations, introduisent des workflows différents et redistribuent les responsabilités entre équipes. Dans la pratique, il est rare de pouvoir reproduire l’organisation existante à l’identique dans un ERP moderne.
Or, dans de nombreuses entreprises, une partie substantielle du contrôle interne repose sur des pratiques opérationnelles construites dans la durée : vérifications croisées informelles, habitudes de rapprochement, réflexes d’alerte entre équipes. Ces pratiques ne figurent dans aucune documentation de projet.
Lorsque les processus sont standardisés dans le système, ces mécanismes disparaissent, sans nécessairement être remplacés par des équivalents. Le dispositif de contrôle peut ainsi perdre en robustesse de manière progressive et silencieuse, jusqu’à ce qu’un écart significatif le révèle.
Le risque n’est pas théorique. Il concerne concrètement la capacité de l’organisation à détecter les anomalies, à justifier ses positions en cas d’audit, et à maintenir la qualité de ses états financiers.
Des tensions sur le cash, directement imputables à la phase de transition
Les difficultés opérationnelles post-déploiement peuvent avoir des effets mesurables sur la trésorerie. Deux mécanismes sont fréquemment observés.
D’un côté, des retards dans le traitement des factures fournisseurs ou dans les circuits de validation interne : le DPO (Days Payable Outstanding) se dégrade temporairement, non par choix stratégique, mais par perte de fluidité dans les processus. De l’autre, des retards dans l’émission ou le suivi des factures clients : le DSO (Days Sales Outstanding) se tend, avec des effets directs sur le besoin en fonds de roulement.
Ces dérives ne sont généralement pas liées à un défaut de l’outil. Elles résultent d’une phase d’adaptation des équipes aux nouveaux processus, dans un contexte où les automatismes n’ont pas encore été reconstruits. Dans les organisations où la trésorerie est suivie de près, notamment dans les groupes avec des covenants bancaires ou des objectifs de cash explicites, quelques semaines de dérive peuvent avoir des conséquences réelles.
La perte de lecture financière des flux
Il s’agit peut-être le risque le plus difficile à quantifier, mais il est fréquemment cité par les équipes finance après une migration.
Dans un environnement encore partiellement manuel, les équipes comprennent la mécanique des écritures comptables : elles savent comment une opération se traduit dans les comptes et comment elle se reflète dans les états financiers. Cette compréhension est le fondement de leur capacité à analyser les écarts, à challenger les données, à détecter les anomalies.
Avec les ERP modernes, une partie croissante de cette mécanique devient invisible. Les écritures sont générées automatiquement par des règles système, des interfaces entre applications, des traitements automatisés. Le fonctionnement est plus efficace, mais aussi plus opaque.
Le résultat, observé dans plusieurs projets : les équipes savent utiliser l’outil, mais leur capacité à lire et à interpréter les flux financiers s’est réduite. Ce n’est pas un problème de formation. C’est un problème de conception de la transition, qui n’a pas suffisamment investi dans la transmission de la logique métier du nouveau système.
Le change management n’est pas un livrable de projet, mais une condition de réussite opérationnelle
Face à ces enjeux, le change management est trop souvent traité comme une composante périphérique du projet, une ligne budgétaire pour la formation et la communication interne, activée en fin de programme une fois les choix techniques arrêtés.
Cette vision est non seulement trop étroite, mais elle est aussi contre-productive.
Une transformation du SI Finance modifie en profondeur la manière dont les flux circulent, dont les équipes travaillent et dont les responsabilités sont réparties au sein de l’organisation. Le change management a précisément pour rôle d’anticiper ces effets et de sécuriser la transition opérationnelle, pas seulement l’adoption de l’outil. Pour remplir ce rôle, il doit être intégré au projet dès la phase de conception, et non greffé en amont du go-live.
Concrètement, cela suppose trois choses.
Rendre les nouveaux flux lisibles, pas seulement documentés
Les processus cibles sont généralement bien décrits dans la documentation de projet, mais cette documentation demeure souvent éloignée de la réalité du travail quotidien. Ce dont les équipes ont besoin, c’est de comprendre comment fonctionnent les flux dans le système : à quel moment une écriture est générée, dans quels cas une opération se bloque, et comment une anomalie peut se propager.
Une approche qui fait ses preuves dans ce domaine est la preuve par les pairs. Plutôt que de confier cette transmission aux seuls consultants externes, on identifie en amont des utilisateurs clés (key users) qui sont pleinement formés à la solution et en deviennent les véritables experts internes. Ce sont eux qui forment ensuite leurs collègues, expliquent la logique des flux et répondent aux questions du quotidien.
L’effet est double : la compréhension du système est plus ancrée dans la réalité opérationnelle, et l’adoption est facilitée parce qu’elle vient des pairs plutôt que d’un intervenant externe. Ce n’est pas une question de manuel utilisateur, c’est une transmission de logique financière, et elle ne peut fonctionner que si les équipes projet ont elles-mêmes suffisamment investi dans la maîtrise des processus métier, et pas seulement dans leur paramétrage.
Cartographier les impacts organisationnels avant le go-live, pas après
Les transformations SI déplacent des points de responsabilité : des validations intégrées dans un workflow, des tâches qui disparaissent avec l’automatisation, de nouvelles responsabilités qui apparaissent dans des équipes qui ne s’y attendaient pas. Ces évolutions doivent être identifiées dès la fin de la phase de conception, pas au moment de la formation, et encore moins après le go-live.
Cette cartographie a une double utilité. Elle sert de base au dispositif de change management, en permettant d’adresser les bons sujets aux bonnes équipes au bon moment. Mais elle structure aussi la phase de recette : organiser les tests autour des nouveaux processus, et non autour des fonctionnalités de l’outil, permet aux opérationnels de s’approprier les logigrammes en situation réelle, de valider que les responsabilités sont bien réparties et de détecter les zones grises avant qu’elles ne deviennent des problèmes en production. La recette devient ainsi un moment d’apprentissage collectif, pas seulement un exercice de validation technique.
Traiter les premières semaines post-go-live comme une phase projet à part entière
C’est la période la plus sensible et la plus souvent sous-dotée. C’est à ce moment que les équipes découvrent le comportement réel des flux, que les règles métier apparaissent dans toute leur complexité et que certains dysfonctionnements non anticipés par la recette font surface.
Dans les projets les mieux préparés, cette phase est planifiée bien avant le go-live : équipes projet maintenues mobilisées sur les premières clôtures, utilisateurs clés positionnés comme relais opérationnels, dispositif d’escalade clair pour les situations bloquantes. À cela s’ajoute un élément souvent négligé : le niveau de support de l’éditeur ou de l’intégrateur dans les premières semaines. Ce dispositif d’hypercare, de disponibilité renforcée, de temps de réponse garantis et d’interlocuteurs dédiés doit être pensé et contractualisé bien en amont du go-live, pas négocié dans l’urgence une fois les problèmes apparus. C’est un filet de sécurité dont la valeur se mesure précisément dans les moments où tout le monde est sous pression.
L’objectif n’est pas de prolonger le projet indéfiniment, c’est de ne pas laisser s’installer des pratiques dégradées qui deviendront ensuite très difficiles à corriger. Les bénéfices d’un déploiement ERP se matérialisent généralement dans les 12 à 24 mois suivant la mise en production, à condition que les premières semaines ne compromettent pas la trajectoire.
En résumé
La modernisation du SI Finance est souvent pilotée comme un projet technologique. Elle est en réalité une transformation des pratiques opérationnelles de la fonction finance.
Les difficultés post-déploiement les plus fréquentes ne viennent pas de l’outil. Elles viennent de l’écart entre les nouveaux processus et la capacité des équipes à les maîtriser rapidement. Lorsqu’il n’est pas anticipé, cet écart génère une dette opérationnelle invisible : des clôtures qui se tendent, un contrôle interne qui perd en robustesse, des indicateurs de cash qui dérivent le temps de la transition.
Réduire cet écart est précisément l’enjeu du change management dans ces projets. Non pas comme une activité d’accompagnement au sens générique du terme, mais comme un travail rigoureux d’anticipation des impacts opérationnels et de reconstruction rapide de la maîtrise des équipes sur leurs flux financiers.
C’est sur cette double dimension qu’Althéa intervient auprès de ses clients. Notre approche combine une expertise en finance opérationnelle, une compréhension des processus de clôture, des mécanismes de contrôle interne, des enjeux de cash et une pratique du change management ancrée dans les réalités terrain des directions financières. Pas pour accompagner le déploiement d’un outil, mais pour sécuriser la transition dans sa globalité : de la cartographie des impacts organisationnels en phase de conception jusqu’à la stabilisation des équipes sur les premiers cycles d’exploitation.
Rédaction
Tristan Garreau
Consultant People & Transformation
