Les 90 premiers jours en production : ce que personne ne dit à l'équipe finance

Le système est en production. L'équipe projet célèbre. Le partenaire d'implantation commence à se retirer. Le Comité de pilotage se dissout.

Et l'équipe finance est sur le point de découvrir que rien de ce à quoi on l'a préparée n'était la bonne préparation.

La préparation au go-live est presque universellement définie comme une question technique. Le système est-il configuré ? Les données sont-elles chargées ? L'UAT a-t-il été validé ? Ce sont des points de contrôle légitimes. Mais ils mesurent si le système est prêt — pas si l'équipe finance est prête à l'exploiter. Ce sont deux choses complètement différentes, et l'écart entre les deux est là où les 90 premiers jours s'effondrent.

Cet article nomme les quatre modes d'échec qui apparaissent dans les 90 premiers jours de production — pas ceux qui figurent dans le registre des risques projet, mais ceux dont personne n'a prévenu l'équipe finance.

1. L'écart de critères de préparation

Chaque implantation a une checklist de go-live. Elle couvre la configuration système, la validation de la migration des données, les tests d'intégration, les accès utilisateurs et la bascule. Ce qu'elle ne couvre presque jamais, c'est la préparation opérationnelle — la capacité réelle de l'équipe finance à piloter le système dans des conditions réelles.

Il y a une différence critique entre ces deux choses.

La préparation système demande : le système est-il prêt à aller en production ? La préparation opérationnelle demande : l'équipe est-elle prête à exploiter le système quand quelque chose tourne mal ?

Ces questions exigent des réponses complètement différentes. Un système peut être entièrement configuré, entièrement testé, entièrement chargé — et l'équipe finance peut quand même être totalement impréparée pour la production. Parce que les conditions de la production ne ressemblent en rien aux conditions de l'UAT.

En UAT, les scénarios sont contrôlés. Les transactions du chemin nominal sont testées à répétition. Les testeurs savent quel processus ils valident. Le partenaire d'implantation est dans la salle. Les erreurs sont enregistrées et résolues sans urgence.

En production, le fichier bancaire doit partir à 15h. L'intégration paie tourne ce soir. La clôture mensuelle est dans quatre jours. Personne ne sait quelle transaction a déclenché l'erreur de validation, le contrat d'hypercare du partenaire d'implantation se termine la semaine prochaine, et l'utilisateur clé qui connaît la configuration est en vacances.

La préparation opérationnelle exige un type de validation différent — qui demande non pas « est-ce que ça a fonctionné en test ? » mais « est-ce que l'équipe sait quoi faire quand ça tombe en production ? » La plupart des checklists de go-live ne posent pas cette question du tout.

→ Voir aussi : Go-live ERP : 5 questions que tout sponsor doit poser

→ Voir aussi : Mode projet vs mode opération dans un ERP

2. La rupture des processus multi-participants

Le deuxième mode d'échec apparaît dans les premières semaines de production, et il suit le même schéma à chaque fois.

Un processus inter-systèmes tombe en panne. Pas parce que l'intégration a été mal construite — elle a été testée, elle a passé l'UAT. Elle tombe en panne parce que les conditions en production sont différentes des conditions en test, ou parce qu'un scénario hors du chemin nominal apparaît pour la première fois, ou parce qu'un participant au processus n'a pas suivi la procédure convenue.

Les intégrations paie et les fichiers de paiement bancaires sont les exemples les plus courants. Le fichier de paie arrive des RH, est traité dans D365, et doit être validé dans le Grand livre avant que les paiements ne partent. Le fichier de paiement bancaire est généré dans D365 et transmis à la banque. Ces deux processus impliquent plusieurs équipes — Finance, IT, RH, la banque, parfois un prestataire paie externe — qui opèrent sous des délais serrés sans marge pour les défaillances de coordination.

Ce qui casse n'est presque jamais la technologie. Ce qui casse, c'est la coordination.

Quelqu'un n'a pas envoyé le fichier à l'heure convenue. Le format a légèrement changé. Un nouvel élément de paie est apparu qui ne figurait pas dans le mapping initial. La personne qui gère habituellement l'exception était en réunion. La voie d'escalade n'était pas claire, donc personne n'a escaladé jusqu'à ce qu'il soit trop tard.

Ces défaillances sont prévisibles. La procédure existe sur papier. Mais elle a été conçue, approuvée et validée pendant l'implantation — par des personnes qui ne l'avaient jamais exécutée dans des conditions de production. La différence entre connaître une procédure et l'avoir internalisée par la répétition est énorme, et cet écart est maximal dans les 90 premiers jours.

La solution pratique est simple et presque jamais mise en œuvre : avant le go-live, organiser des réunions de coordination récurrentes pour chaque processus inter-systèmes impliquant plusieurs participants. Hebdomadaires le premier mois, bimensuelles ensuite. Les planifier dans les agendas avant le go-live. Y inclure Finance, IT, les responsables métier concernés et les interlocuteurs des intégrations. Les utiliser pour passer en revue ce qui a fonctionné, ce qui n'a pas fonctionné et quels cas limites ont émergé. Ne pas attendre qu'une défaillance survienne pour réunir tout le monde.

💡 FitGap Toolkit : Si vous avez besoin d'une structure claire sur qui possède quoi dans chaque processus inter-systèmes — avec des voies d'escalade explicites — la Matrice RACI ERP + Descriptions de rôles (FR) couvre ce sujet directement → https://fitgapfinance.gumroad.com/l/erp_raci_roles_responsabilites_fr

→ Voir aussi : Rôles et responsabilités dans un projet ERP

3. L'écart de connaissances de configuration

C'est le mode d'échec que personne ne nomme explicitement, mais que chaque équipe finance ayant vécu un go-live reconnaît immédiatement.

Pendant l'implantation, les utilisateurs clés valident des résultats. Ils participent aux ateliers, examinent les documents de conception fonctionnelle (FDD), testent des scénarios et signent l'UAT. Leur rôle est de confirmer que le système produit les bons résultats. Si la balance de vérification se rapproche, si le paiement fournisseur se valide correctement, si le workflow du bon de commande se déclenche comme prévu — ils approuvent.

Ce qu'on ne leur demande presque jamais de comprendre, c'est pourquoi.

Les utilisateurs clés ont validé que le système fonctionne. On ne leur a pas demandé de comprendre comment il est configuré pour fonctionner ainsi.

Cette distinction ne compte pas pendant l'implantation. Elle compte énormément en production.

En production, une erreur de validation apparaît. L'auxiliaire ne se rapproche pas du Grand livre. L'import du relevé bancaire crée des transactions en double. Une facture fournisseur est validée sur le mauvais compte. L'utilisateur clé qui possède ce processus est maintenant le premier niveau de support. On attend de lui qu'il trie l'incident, détermine s'il s'agit d'un problème de configuration ou de processus, et soit le résolve, soit l'escalade vers la bonne personne.

Rien de tout cela n'est possible s'ils savent seulement à quoi ressemble le bon résultat — pas comment le système le produit.

L'écart de connaissances de configuration apparaît pour la première fois au pire moment : pendant la clôture mensuelle, sous pression temporelle, quand le partenaire d'implantation n'est peut-être plus disponible rapidement. Les utilisateurs clés découvrent que l'écart entre « je sais que ça fonctionne » et « je sais pourquoi ça fonctionne et comment le corriger quand ça ne fonctionne pas » est bien plus grand qu'anticipé.

La solution exige un investissement délibéré avant le go-live que la plupart des programmes évitent. Pas plus de formation utilisateur — les utilisateurs clés ont eu de la formation. Un transfert de connaissances de configuration : des sessions ciblées où le partenaire d'implantation explique aux utilisateurs clés les décisions de configuration spécifiques derrière les processus qu'ils possèdent. Pas « voici comment passer une écriture. » Mais « voici pourquoi le profil de validation est configuré ainsi, voici ce qui se passe s'il change, voici où chercher en premier quand cette transaction ne se valide pas comme prévu. »

C'est différent de la formation. C'est la différence entre savoir conduire une voiture et en savoir assez sur son fonctionnement pour diagnostiquer pourquoi elle ne démarre pas.

→ Voir aussi : Utilisateurs clés : les réalités d'un projet ERP

→ Voir aussi : Signaux d'alerte ERP

4. L'effondrement de l'ownership à la première réconciliation

Le dernier mode d'échec est le plus prévisible et le moins traité.

Les utilisateurs clés ont accepté leurs responsabilités post-go-live pendant le projet. On leur a dit qu'ils seraient les experts internes. Ils ont accepté. Ils comprenaient — dans l'abstrait — ce que cela signifiait.

Ce qu'ils n'ont pas compris, c'est ce que ça ressentait en pratique.

Le moment d'effondrement de l'ownership n'est pas au go-live. C'est à la première réconciliation, quand le premier vrai problème apparaît et que la responsabilité devient concrète.

La provision paie ne correspond pas. L'élimination intercompagnies est fausse. La cession d'immobilisation a été validée sur le mauvais compte et la période est sur le point de se fermer. L'utilisateur clé qui possède ce domaine doit maintenant décider : est-ce que j'en sais assez pour corriger ça ? Est-ce que je sais qui appeler ? Est-ce que je sais comment documenter ça pour les auditeurs ?

Pour la plupart des utilisateurs clés, la réponse aux trois questions est non — et ils le découvrent pour la première fois sous pression temporelle. Le partenaire d'implantation est peut-être encore joignable mais n'est plus sous contrat pour les accompagner. Leur responsable n'a pas été informé de ce à quoi ressemble le support opérationnel. La voie d'escalade existe sur papier mais personne ne l'a testée.

Ce n'est pas un échec de l'utilisateur clé. C'est un échec de la conception de la transition. Les utilisateurs clés ont été préparés pour l'implantation — pas pour les opérations. Les compétences requises pour valider une configuration en UAT et les compétences requises pour posséder un processus financier en production ne sont pas les mêmes.

Ce que cela exige, c'est un plan de transition structuré qui cartographie explicitement, avant le go-live, qui possède chaque processus en opération — pas seulement quelle équipe, mais quel individu nommé — avec une voie d'escalade claire, une procédure de première réponse documentée pour les scénarios de défaillance les plus probables, et un calendrier pour les trois premières clôtures mensuelles qui inclut des points de support explicites.

Le plan de transition n'est pas un livrable projet. C'est la responsabilité du sponsor de l'exiger avant que le projet ne se termine.

→ Voir aussi : Ce que coûte vraiment l'exploitation d'un ERP après le go-live

→ Voir aussi : La gouvernance ERP n'est pas négociable

Conclusion

Les 90 premiers jours en production sont plus difficiles que les 90 derniers jours d'implantation. Pas parce que la technologie est plus difficile — elle ne l'est pas. Parce que la structure de support est plus mince, les enjeux sont plus élevés, et les personnes responsables du résultat exploitent un système qu'elles comprennent moins bien qu'elles ne le pensaient.

Rien de tout cela n'est inévitable. Chaque mode d'échec décrit dans cet article est prévisible et évitable. L'écart de critères de préparation se comble quand quelqu'un pose « l'entreprise est-elle prête à opérer ? » comme une question distincte de « le système est-il prêt à aller en production ? » Le vide de coordination se comble quand les réunions récurrentes sont planifiées avant le go-live, pas après la première défaillance. L'écart de connaissances de configuration se comble quand les utilisateurs clés reçoivent un transfert de connaissances de configuration ciblé, pas seulement une formation utilisateur. L'effondrement de l'ownership se comble quand le plan de transition nomme des personnes, pas des équipes, et inclut des voies d'escalade qui ont été testées avant d'être nécessaires.

Ce ne sont pas des interventions complexes. Ce sont les choses qui ne sont presque jamais faites parce que l'équipe projet est concentrée sur la livraison du système — pas sur la construction de l'opération.

La question à poser maintenant : quand le partenaire d'implantation part, qui détient la carte ?

Pour aller plus loin

• Mode projet vs mode opération dans un ERP : pourquoi la transition est plus difficile que prévu
• Ce que coûte vraiment l'exploitation d'un ERP après le go-live
• Utilisateurs clés : les réalités d'un projet ERP
• Go-live ERP : 5 questions que tout sponsor doit poser
• La gouvernance ERP n'est pas négociable
• Signaux d'alerte ERP

This article is also available in English: The First 90 Days in Production: What Nobody Tells the Finance Team