EPM cloud ou on-premise

Choisir un EPM cloud ou on-premise consiste à déterminer son mode de fourniture et son lieu d’installation, puis à répartir les responsabilités d’exploitation. Le SaaS (Software as a Service) est un logiciel fourni comme un service accessible par réseau, dont le fournisseur assure l’exploitation technique selon le contrat ; il est souvent commercialisé par abonnement. Tous les hébergements cloud ne sont pas du SaaS.

• Comparer des services équivalents, pas des étiquettes. Une offre SaaS peut inclure l’hébergement, les mises à jour et certaines sauvegardes, conservations de copies permettant une récupération ultérieure, mais pas la construction du modèle financier, c’est-à-dire l’organisation des données, hypothèses et règles de calcul utilisées pour le pilotage. Une installation on-premise nécessite de chiffrer ces mêmes services, qu’ils soient réalisés en interne ou achetés. Le périmètre exact, les exclusions et les obligations de chaque acteur doivent être explicités avant toute comparaison économique.
• Partir des contraintes du pilotage. La disponibilité pendant la clôture, processus de finalisation et de validation des comptes d’une période, les accès des filiales, la confidentialité des données salariales et les échanges avec les systèmes comptables orientent le choix. Le cloud peut alléger certaines tâches d’exploitation ; il ne supprime ni la gestion des accès ni les contrôles financiers. L’on-premise permet de maîtriser certains choix techniques, mais cette maîtrise exige des compétences et des ressources.
• Prévoir la continuité et la sortie dès le départ. La réversibilité est la capacité à récupérer les données et les éléments nécessaires pour quitter une solution ou un hébergement. Elle concerne aussi les règles de calcul, les historiques, les pièces justificatives et les droits d’utilisation. La restauration est la remise en état d’utilisation d’éléments sauvegardés. Un choix solide associe donc coût complet, responsabilités documentées, preuve de restauration et modalités de sortie, plutôt qu’une préférence générale pour une technologie.

Sans arbitrage explicite sur l’hébergement, la direction financière découvre souvent ses dépendances au moment où elles deviennent bloquantes. Un chargement comptable échoue pendant la clôture, une filiale ne peut plus se connecter ou une mise à jour modifie un calcul : chacun pense alors que le problème relève d’une autre équipe. Le choix cloud ou on-premise sert d’abord à rendre ces responsabilités visibles.

Des coûts incomplets dans la décision

Le coût total de possession (TCO) est l’ensemble des coûts nécessaires pour acquérir, déployer, exploiter et quitter une solution sur une période définie. Comparer un abonnement cloud au seul prix d’une licence installée ignore les serveurs, les sauvegardes, l’administration, les tests et les interventions internes. À l’inverse, présenter le cloud comme un service sans coûts additionnels masque les interfaces, mécanismes d’échange entre systèmes, les environnements supplémentaires ou l’accompagnement des évolutions. Un environnement est une instance de la solution dédiée à un usage, comme les tests ou le service opérationnel.

Une continuité financière mal protégée

La clôture tolère mal une indisponibilité non anticipée. Une application accessible ne garantit pourtant pas que les données soient à jour : la chaîne d’alimentation peut être interrompue alors que l’écran fonctionne normalement. La finance doit donc décrire le service attendu de bout en bout, depuis les sources jusqu’aux restitutions, c’est-à-dire les présentations des résultats aux utilisateurs.

Des contraintes découvertes trop tard

La résidence des données désigne les lieux géographiques où elles sont stockées et traitées. Elle ne suffit pas à déterminer qui peut y accéder, ni les obligations juridiques applicables. Il faut également examiner les accès de support, les sous-traitants, les transferts et la conservation.

L’arbitrage doit ainsi s’inscrire dans une architecture de données finance, c’est-à-dire une organisation cohérente des systèmes, des données et de leurs échanges. Il évite de choisir un hébergement techniquement séduisant mais incompatible avec les échanges de données, les compétences disponibles ou les échéances financières.

La mécanique consiste à décomposer le service EPM, puis à attribuer chaque tâche à un responsable. Le lieu des serveurs ne suffit pas : une application installée sur une infrastructure cloud peut rester administrée par l’entreprise, contrairement à une offre SaaS où davantage de tâches techniques sont prises en charge par le fournisseur.

1. Décrire la chaîne de service. Identifier les sources comptables, les transferts, les calculs, les validations et les restitutions. Pour chaque interface, préciser le sens du flux, sa fréquence et le traitement des erreurs. Le résultat attendu est un schéma compréhensible par la finance comme par l’informatique.
2. Répartir les responsabilités. Distinguer infrastructure, application et contenu financier. En SaaS, le fournisseur exploite généralement l’infrastructure et le logiciel selon son contrat ; l’entreprise conserve la responsabilité de ses données, de ses règles et de ses habilitations, autorisations accordées aux utilisateurs pour consulter ou modifier certaines informations. En on-premise, elle organise aussi l’exploitation technique, directement ou par délégation.
3. Encadrer les accès et les changements. Définir qui crée les comptes, valide les droits et les retire. Les mises à jour doivent être précédées de vérifications des interfaces et des calculs critiques, même lorsque leur installation est gérée par le fournisseur. Documenter les contrôles, leurs résultats et la décision d’accepter le changement.
4. Définir la reprise du service. Le RPO (Recovery Point Objective) est la perte maximale de données acceptable, exprimée en durée par rapport au point de référence de l’incident. Le RTO (Recovery Time Objective) est la durée cible de rétablissement du service au niveau convenu après une interruption. Ces objectifs doivent couvrir les composants nécessaires au pilotage, pas seulement l’application centrale.
5. Vérifier les preuves. Examiner les engagements contractuels, les comptes rendus de restauration, les procédures d’incident et les exports, c’est-à-dire les extractions de données hors de la solution. Vérifier que les sauvegardes peuvent effectivement être restaurées et utilisées. La décision devient robuste lorsque les engagements écrits correspondent aux tests réellement effectués.

Cet exemple est entièrement fictif : un groupe industriel compare deux solutions EPM de périmètre fonctionnel équivalent pour 100 utilisateurs sur 3 ans. Les montants sont en euros hors taxes, sans actualisation, calcul ramenant des montants futurs à leur valeur présente, ni inflation, c’est-à-dire hausse générale des prix. Ils représentent des coûts économiques, sans préjuger de leur traitement comptable.

| Poste | Cloud SaaS | On-premise | |---|---:|---:| | Licences initiales | 0 | 120 000 | | Déploiement initial | 60 000 | 60 000 | | Abonnement ou maintenance, par an | 90 000 | 24 000 | | Infrastructure et services techniques, par an | 12 000 | 30 000 | | Travail interne d’exploitation, par an | 18 000 | 36 000 | | Total initial | 60 000 | 180 000 | | Total annuel récurrent | 120 000 | 90 000 | | Coûts cumulés sur 3 ans hors sortie | 420 000 | 450 000 |

Recalculer chaque total

Cloud, coût initial : 0 + 60 000 = 60 000 €. Coût annuel : 90 000 + 12 000 + 18 000 = 120 000 €. Coûts cumulés hors sortie : 60 000 + (3 × 120 000) = 420 000 €.

On-premise, coût initial : 120 000 + 60 000 = 180 000 €. Coût annuel : 24 000 + 30 000 + 36 000 = 90 000 €. Coûts cumulés hors sortie : 180 000 + (3 × 90 000) = 450 000 €.

Différence cloud moins on-premise : 420 000 − 450 000 = −30 000 €, en faveur du cloud sur ce périmètre hors sortie. Le travail interne annuel diminue de 36 000 − 18 000 = 18 000 €, soit 18 000 / 36 000 × 100 = 50 % ; ce temps disponible ne constitue pas automatiquement une économie de trésorerie.

Le coût moyen hors sortie par utilisateur et par an vaut coûts cumulés hors sortie / (utilisateurs × années) : cloud, 420 000 / (100 × 3) = 1 400 € ; on-premise, 450 000 / (100 × 3) = 1 500 €.

Interpréter sans généraliser

Les postes annuels couvrent ici les services techniques et tests récurrents nécessaires ; aucun renouvellement matériel exceptionnel n’est prévu sur l’horizon. Les coûts de sortie ne sont pas encore chiffrés : ces totaux ne sont donc pas des TCO complets. L’écart de 30 000 € ne permet pas de conclure sur le TCO avant leur ajout aux deux options. Le résultat dépend aussi de la durée retenue et des hypothèses ; il ne démontre pas que le cloud est toujours moins coûteux.

Le déploiement commence par une décision documentée, puis transforme les engagements en procédures testables. La finance porte les besoins de pilotage ; l’informatique, la sécurité, les achats et le juridique valident leurs contraintes respectives.

1. Définir les usages et les contraintes. Recenser les processus, les utilisateurs, les périodes sensibles, les données confidentielles et les systèmes sources. Distinguer les obligations impératives des préférences. Livrable : une note de besoins avec critères d’acceptation et responsable de chaque exigence.
2. Construire les options comparables. Décrire pour chaque option les services inclus, les responsabilités conservées, les compétences nécessaires et les exclusions. Chiffrer le déploiement, l’exploitation, les évolutions et la sortie. Livrables : matrice de responsabilités et comparaison du TCO avec hypothèses explicites.
3. Tester les points décisifs. Une preuve de concept (POC) est un essai limité destiné à vérifier la faisabilité sur des cas représentatifs. Ce test de faisabilité doit porter sur un chargement réel, un calcul significatif, les droits d’une filiale et un export exploitable. Livrable : résultats observés, limites et conditions de validation.
4. Contractualiser le service. Définir la disponibilité, les accès de support, la localisation des traitements, les sauvegardes, les modalités de reprise et les changements de version du logiciel. Livrables : engagements validés et procédure de suivi des incidents, avec les dépendances et exclusions clairement identifiées.
5. Préparer puis valider la mise en service. La recette utilisateur est la vérification, par les utilisateurs métier, que la solution répond aux besoins définis. Comparer les résultats avec les sources, tester les accès et répéter un cycle complet. Livrables : procès-verbal de recette et décision de démarrage assortie d’un plan de retour à la situation précédente.
6. Organiser l’exploitation durable. Former les administrateurs, planifier les revues d’accès et les tests de restauration, puis désigner les remplaçants. Livrables : manuel d’exploitation, calendrier de contrôles et dossier de réversibilité tenu à jour.

Raisonner à périmètre constant

Comparer les mêmes usages, volumes de données, catégories d’utilisateurs et niveaux de service. Une option qui exclut les sauvegardes restaurables ou un environnement de test n’est pas directement comparable à une offre qui les comprend. Un environnement de test est une instance séparée utilisée pour vérifier les changements sans modifier le service en production, c’est-à-dire celui utilisé pour les opérations courantes. Son coût et ses règles de rafraîchissement des données doivent être visibles.

Protéger les périodes financières sensibles

Aligner le calendrier des changements sur la clôture et les campagnes de préparation budgétaire. En SaaS, vérifier les modalités de notification, de test préalable et les marges de report réellement disponibles. En on-premise, ne pas confondre liberté de calendrier et permission de différer indéfiniment les correctifs de sécurité. Toute exception doit avoir un responsable et une mesure compensatoire.

Limiter les droits et vérifier leur usage

Le principe du moindre privilège consiste à n’accorder que les droits nécessaires à une tâche. Séparer, autant que possible, l’administration technique, la modification des règles et la validation financière. Réexaminer les droits après une mobilité interne, un départ ou une réorganisation. Cette discipline reste nécessaire quel que soit l’hébergement.

Tester la reprise de bout en bout

Restaurer une application ne suffit pas si ses interfaces, ses justificatifs ou son service d’authentification, qui vérifie l’identité des utilisateurs, restent indisponibles. La continuité d’activité est l’organisation permettant de maintenir ou de reprendre les activités essentielles après une perturbation. Tester un cycle financier représentatif après restauration permet de vérifier que les données, les calculs et les accès sont cohérents.

Rendre la sortie concrète

Conserver la description des règles, les structures de données et les formats d’export. Vérifier qu’un tiers autorisé peut comprendre et réutiliser les éléments récupérés. Un export de tableaux ne remplace pas nécessairement la récupération des historiques et de la logique de calcul. Cette préparation réduit la dépendance à des connaissances individuelles et facilite aussi les évolutions internes.

« Le cloud est forcément moins cher »

L’abonnement peut simplifier certains postes d’exploitation, mais le coût dépend du contrat, des usages et des services retenus. Les interfaces, le stockage additionnel, les environnements et l’assistance peuvent modifier le total. Éviter ce piège en demandant une décomposition des coûts et en simulant les évolutions plausibles du périmètre.

« Sur nos serveurs, les données sont forcément plus sûres »

Le contrôle physique ne garantit ni une bonne configuration ni une surveillance suffisante. À l’inverse, un hébergement cloud ne prouve pas à lui seul la conformité ou la sécurité. Comparer les dispositifs effectivement déployés : accès, protection des échanges, sauvegardes, gestion des incidents et compétences disponibles.

Confondre résidence et souveraineté

La souveraineté des données désigne la capacité à maîtriser leur traitement et leur accès au regard des dépendances techniques et des cadres juridiques applicables. Un stockage dans une zone donnée ne répond pas, à lui seul, aux questions sur les accès de support ou les transferts. Faire examiner le contrat et la chaîne de sous-traitance par les fonctions compétentes, sans transformer un critère géographique en garantie universelle.

Oublier ce qui reste à la charge de la finance

Le fournisseur ne valide pas les hypothèses budgétaires et ne corrige pas automatiquement les règles mal conçues. Nommer un responsable métier pour chaque donnée et chaque calcul important. Documenter les contrôles qui distinguent un incident technique d’une erreur de modèle.

Croire qu’une sauvegarde assure la reprise

Une copie peut être inutilisable, incomplète ou trop ancienne. Exiger un test de restauration et vérifier la cohérence des données récupérées avec les sources. Distinguer la capacité technique de reprise de l’engagement contractuel et de son périmètre réel.

Ignorer l’obsolescence ou la dépendance

En on-premise, une version non maintenue peut compliquer les évolutions et la sécurité. En SaaS, des changements réguliers exigent des tests et une veille fonctionnelle. Dans les deux cas, conserver des compétences internes et préparer la réversibilité plutôt que compter sur une stabilité indéfinie.

Un indicateur clé de performance (KPI) est une mesure suivie pour évaluer un objectif et orienter une décision. Pour l’hébergement EPM, les indicateurs doivent mesurer le service utile à la finance, et non seulement l’état des serveurs. Chaque formule nécessite un périmètre, une période d’observation et une source identifiés ; les ratios supposent un dénominateur non nul.

• Disponibilité observée = (durée de service attendue − durée d’indisponibilité sur cette plage) / durée de service attendue × 100. Définir les plages sensibles et le traitement des maintenances. Suivre séparément la disponibilité contractuelle, dont les exclusions peuvent différer de l’expérience utilisateur.
• Taux de chargements conformes = chargements terminés à l’heure et validés / chargements attendus × 100. Un transfert techniquement réussi n’est conforme que si les contrôles de complétude et de cohérence passent. Préciser comment sont comptés les relancements pour éviter de masquer les échecs.
• Coût complet par utilisateur actif = coût total sur la période / nombre d’utilisateurs actifs défini pour cette période. Un utilisateur actif est ici un utilisateur ayant réalisé une action métier sur la période. Documenter cette convention ; ne pas la confondre avec la règle contractuelle de facturation des licences.
• Taux de tests de restauration réussis = tests respectant les critères de reprise / tests réalisés × 100. Suivre aussi les tests prévus mais non exécutés. Comparer au RPO l’intervalle entre le point de référence de l’incident et le dernier point de données cohérent effectivement récupéré. Comparer au RTO la durée écoulée entre le début de l’interruption et le rétablissement du service au niveau convenu.
• Écart budgétaire = réel − budget, le budget étant le plan chiffré de référence approuvé pour une période. Appliqué aux coûts : coût réel − coût budgété. À périmètre identique, un écart positif est défavorable et un écart négatif favorable. Isoler les changements de périmètre avant de conclure à une dérive d’exploitation.

Les livrables associés sont la comparaison du TCO, la matrice de responsabilités, le registre des interfaces, les comptes rendus d’incident et de restauration, ainsi que le dossier de réversibilité. Une revue commune finance-informatique relie chaque mesure à une action : corriger une interface, revoir une capacité, ajuster un contrat ou renforcer un contrôle.

Un EPM ne décide pas de l’hébergement à la place de l’entreprise. Il centralise toutefois des objets financiers qui rendent ce choix structurant : données, règles de calcul, droits, validations et historiques. La capacité à les exploiter, les protéger et les récupérer doit être évaluée pour l’offre précise envisagée.

Des fonctions à vérifier concrètement

Un workflow est un circuit organisé de tâches et de validations. Dans un EPM, il peut attribuer la saisie à une filiale, déclencher un contrôle puis solliciter une validation. Une piste d’audit est un historique permettant de retracer les actions et modifications. Sa profondeur, sa durée de conservation et ses possibilités d’export doivent être examinées.

Les fonctions utiles comprennent aussi la gestion des droits par périmètre, l’import des données, la planification des traitements et la comparaison de versions de données, jeux de données distincts représentant notamment le budget et les réalisations. Leur présence ne garantit pas leur bonne configuration. Tester les tâches métier et leur comportement après une mise à jour est plus probant qu’une simple liste de fonctionnalités.

Des éditeurs à examiner sans classement

OneStream, CCH Tagetik et Oracle EPM proposent des solutions couvrant, selon les produits, la consolidation, la planification et le reporting, production structurée de restitutions. SAP Analytics Cloud associe des capacités d’analyse et de planification. Anaplan, Pigment, Board et Workday Adaptive Planning font également partie des solutions à considérer selon les besoins de planification et d’analyse.

Cette liste n’implique pas que chaque produit existe dans les deux modes d’hébergement. Les offres, leurs périmètres et leurs modalités d’exploitation doivent être confirmés au moment de la consultation. Un panorama des éditeurs EPM aide à construire une sélection ; la décision finale repose sur les tests, le contrat et les responsabilités conservées.

La maturité ne se mesure pas au fait d’utiliser le cloud. Elle décrit la capacité à choisir, exploiter et faire évoluer l’EPM en maîtrisant ses risques. Une installation on-premise bien gouvernée peut être plus mature qu’un service SaaS dont personne ne connaît les responsabilités.

Débutant : un choix surtout technique ou commercial

L’hébergement est décidé à partir du prix apparent ou d’une préférence générale. Les tâches d’administration reposent sur une personne clé ; les coûts internes sont peu visibles. La finance connaît mal les conditions de restauration et les modalités de sortie. Les incidents sont traités au cas par cas, sans rapprochement systématique avec les échéances financières.

Le signe de progression est simple : les parties prenantes disposent d’un inventaire du service, d’un responsable par tâche critique et d’une première comparaison des coûts complets. Il ne s’agit pas encore d’optimiser, mais de rendre les dépendances explicites.

Intermédiaire : un service documenté et contrôlé

Les options ont été comparées à périmètre constant. Les droits, les interfaces et les changements sont documentés ; les coûts sont rapprochés du budget. Les objectifs de reprise existent et des restaurations sont testées. La finance participe à la validation des évolutions, au lieu de découvrir leurs effets en production.

La limite habituelle concerne la couverture des tests : une restauration technique peut être vérifiée sans rejouer un cycle financier complet. La progression passe alors par des exercices transverses, une gestion des remplaçants et un dossier de sortie réellement exploitable.

Avancé : un arbitrage réévalué et étayé

L’entreprise réexamine son choix lorsque les usages, les contrats ou les contraintes changent. Elle sait expliquer les écarts de TCO, vérifier la reprise de bout en bout et démontrer la récupération des données et des règles. Les engagements fournisseurs sont rapprochés des mesures observées.

À ce niveau, changer d’hébergement n’est pas une fin en soi. La priorité reste la fiabilité du service financier : un changement n’est engagé que si ses bénéfices attendus, ses coûts de transition et ses risques sont explicitement établis.

Cette checklist sert à préparer une décision commune entre finance, informatique, sécurité, achats et juridique. Pour chaque réponse, conserver une preuve et nommer un responsable. Une affirmation commerciale ou une procédure ancienne ne vaut pas démonstration du service réellement disponible.

• [ ] Les usages financiers, les utilisateurs et les périodes critiques sont-ils décrits et validés par les métiers concernés ?
• [ ] Avons-nous distingué localisation, mode de fourniture et responsabilités d’exploitation, sans assimiler tout hébergement distant à du cloud ?
• [ ] L’offre étudiée est-elle un SaaS ou un hébergement cloud dont certaines tâches techniques restent à notre charge ?
• [ ] Comparons-nous les mêmes fonctions, volumes, environnements et niveaux de service entre les options ?
• [ ] Le TCO inclut-il déploiement, interfaces, travail interne, tests, évolutions et coûts de sortie ?
• [ ] Les règles de facturation et les effets d’une extension du périmètre sont-ils compris et documentés ?
• [ ] Savons-nous où les données et leurs copies sont stockées, traitées et accessibles par le support ?
• [ ] Les obligations juridiques, les sous-traitants et les éventuels transferts ont-ils été examinés par les fonctions compétentes ?
• [ ] Chaque tâche critique a-t-elle un responsable et un remplaçant, y compris en dehors des horaires habituels ?
• [ ] Les droits sont-ils limités au besoin métier et révisés lors des départs ou changements de fonction ?
• [ ] Les interfaces disposent-elles de contrôles permettant de détecter les données absentes, tardives ou incohérentes ?
• [ ] Les changements de version sont-ils annoncés et testés sur les calculs et échanges importants ?
• [ ] Les objectifs RPO et RTO couvrent-ils toute la chaîne nécessaire au pilotage, avec des références de mesure et des exclusions connues ?
• [ ] Une restauration a-t-elle été vérifiée jusqu’à la validation des données et des résultats financiers ?
• [ ] Les exports permettent-ils de récupérer les historiques, les justificatifs et les éléments de modèle nécessaires à une sortie ?
• [ ] Le contrat précise-t-il l’assistance à la sortie, ses coûts et le devenir des copies de données ?
• [ ] Un dispositif de suivi permet-il de rapprocher qualité de service, incidents et coûts réels des engagements initiaux ?

À retenir : cloud et on-premise ne sont pas des niveaux de qualité. Il faut distinguer localisation, mode de fourniture et responsabilités d’exploitation. Le bon choix repose sur des services comparables, un TCO incluant la sortie et des preuves de reprise et de réversibilité. La finance reste responsable de ses données, de ses règles et de ses validations.

Le cloud signifie-t-il forcément SaaS ?

Non. Le SaaS fournit une application exploitée comme un service. Une entreprise peut aussi installer son application sur une infrastructure cloud et conserver la maintenance du logiciel. Il faut donc préciser qui gère chaque composant, plutôt que déduire les responsabilités du seul mot « cloud ». Un simple hébergement distant ne suffit pas non plus à caractériser une offre cloud.

L’on-premise est-il nécessaire pour les données sensibles ?

Pas automatiquement. La décision dépend des exigences juridiques, des accès, des protections et des capacités d’exploitation. Une installation interne mal administrée peut présenter des risques importants. Une offre cloud doit, de son côté, être examinée sur la localisation des traitements, les accès de support, les transferts et les engagements contractuels.

Peut-on conserver les sources comptables en interne et utiliser un EPM cloud ?

Oui, si la solution et les contraintes de sécurité le permettent. Cette organisation combine des systèmes internes et un service distant. Elle nécessite des échanges maîtrisés, des contrôles de complétude et une gestion des incidents. Il faut notamment savoir comment relancer les transferts sans créer de doublons et comment fonctionner si la liaison est interrompue.

Le fournisseur SaaS prend-il en charge tous les risques ?

Non. Son périmètre dépend du contrat. L’entreprise conserve notamment la définition des droits, la qualité des données et la validation des calculs. Elle doit aussi vérifier les dépendances externes : une application disponible ne suffit pas lorsque les données sources ou l’accès des utilisateurs sont indisponibles.

Quand faut-il réexaminer le choix d’hébergement ?

Lors d’une évolution importante des usages, des volumes, des contraintes réglementaires, du contrat ou des compétences disponibles. Une hausse des coûts ou un incident récurrent peut également déclencher une revue. Le changement doit intégrer le transfert des données et des règles, les tests et la continuité : le coût de la cible ne suffit pas à justifier la transition.