Changer d’outil comptable : SaaS ou On Premise ?

Dans le cas d’une solution Software as a service ou SaaS, l’hébergement du logiciel est externalisé. L’accès fonctionne sur le principe de l’abonnement ou du forfait.

Les avantages de ces offres tiennent à leur coût et à leur facilité de maintenance. La facture dépend de l’usage (nombre de licences, options retenues…), sur le principe du « pay as you go ». Autre avantage : leur scalabilité. La solution suit la montée en charge et en volume selon les besoins des utilisateurs. Une part importante de la maintenance est prise en charge directement par l’éditeur, qui procède également à des montées de version régulières et fournit un support de service et d’assistance.

Ces solutions supposent néanmoins des tests de non-régression par les utilisateurs à chaque montée de version, et entraînent une relation de dépendance à l’égard du prestataire. Par ailleurs, le coût de l’abonnement ne donne pas lieu à amortissement.

Dans le modèle On Premise, l’entreprise utilisatrice héberge le logiciel sur ses propres serveurs en interne. Elle est ainsi en mesure de contrôler ses données, dont elle reste propriétaire et peut amortir le coût d’investissement. Cette solution permet ainsi de répondre à des exigences plus pointues en termes de confidentialité des données. Un sujet particulièrement sensible dès lors que des données de santé ou de populations sensibles (agents de l’Etat, forces de l’ordre…) transitent dans cet outil.

Quant aux inconvénients, ils tiennent principalement à une maintenance plus lourde, car non standard, et à un niveau accru de charges courantes liées à l’entretien des équipements (serveurs) et aux équipes de maintenance.

Changement d’outil comptable : privilégier une approche Adapt ou Adopt ?

Le plus souvent, un changement d’outil fournit l’occasion de repenser les processus et de résoudre les éventuels dysfonctionnements. Deux approches sont envisageables : Adapt ou Adopt.

Dans l’approche ADAPT, le logiciel s’adapte aux processus internes.

Quel que soit le type de solution retenue (SaaS ou On Premise), le choix de cette approche suppose de réaliser des développements spécifiques qui peuvent se révéler complexes à implémenter, onéreux – chaque écart identifié par rapport au standard faisant l’objet d’une facturation supplémentaire – et présenter un risque sur la durée du projet. Rassurante sur le papier, cette approche alourdit la charge de maintenance côté DSI. Une charge qu’il convient aussi de bien évaluer de façon à pouvoir la comparer au coût d’un projet de transformation des processus en interne.

Dans le cas particulier du SaaS, les éditeurs sont réticents à faire du spécifique car cela nécessite de maintenir une version sur-mesure pour le client. L’ajout d’une fonctionnalité est ainsi souvent conditionné à un process long d’intégration à une feuille de route éditeur, arbitrée en cas de remontée récurrente de besoins utilisateurs. Ainsi, même si une approche Adapt est possible, elle entre en contradiction avec le principe même du SaaS et s’avère donc peu recommandée.

Adopt : une pratique vertueuse, mais des barrières à l’entrée

L’approche ADOPT constitue la pratique la plus vertueuse mais avec une barrière à l’entrée plus importante. En effet, elle se traduit dans la plupart des cas par une transformation des processus pour s’adapter au standard et ainsi bénéficier des best practices de marché proposés par le logiciel. 

La couverture des besoins fonctionnels reste le mot d’ordre. Il ne s’agit pas ici de rogner sur les besoins métiers mais de questionner en profondeur les procédures en vigueur en vue de les faire rentrer dans le cadre délimité par l’outil.

Par ailleurs, les contraintes techniques inhérentes à l’outil peuvent aussi être à l’origine de transformations sur le plan opérationnel. Par exemple, les fichiers d’import en masse d’écritures comptables doivent parfois être retravaillés pour pouvoir respecter la structure acceptée dans le nouvel outil.

Intégrer les enjeux de reportings

Un enjeu important concerne les possibilités offertes en termes de reporting pour répondre à la fois aux besoins d’analyse / justification et aux exigences réglementaires. En cas de besoins non couverts par le standard, et pour éviter l’écueil des développements spécifiques complexes à maintenir et onéreux, les intégrateurs peuvent proposer le recours à Excel Add-in qui permet d’interroger la base de données et de récupérer celles qui ne figurent pas dans les états de restitution en natif.

S’agissant d’un moyen de requêter comme un autre, cela suppose une formation des utilisateurs pour utiliser à bon escient cette solution de contournement.

Il devient alors possible de reproduire l’équivalent des états BO (SAP Business Object) par exemple – cas fréquemment rencontré– ou alors produits manuellement avec des temps d’exécution écourtés.

Exemples : 

  • Reconstituer une balance de flux comptables validés et en statut provisoire à partir d’un Grand Livre lorsque l’édition d’une balance en standard n’est possible que sur les flux ayant été validés 
  • Détail d’une campagne de règlement 
  • Ordre d’exécution de virement (bordereau pouvant être converti en pdf) 
  • etc.

Cette approche suppose de dresser l’état des lieux des états de restitution et de faire le tri en séparant les « Must have » / « Nice to have », dans une logique de rationalisation et de gain en homogénéité des reportings. Il s’agit ainsi d’éviter que les comptables aient chacun leur propre rapport pour répondre à un même besoin.

Changement d’outil comptable : points d’attention dans la conduite de projet

L’orientation vers une solution SaaS ne peut donc se limiter à une étude financière. La couverture des besoins fonctionnels d’une part, et l’évaluation de la sensibilité des données d’autre part, sont des critères discriminants à prendre en considération. De même que les réponses apportées aux exigences technico-fonctionnelles doivent faire l’objet d’une revue rigoureuse.

Saas ou On Premise ? Pour un même éditeur, il arrive que les fonctionnalités proposées ne soient pas exactement les mêmes (ex. module additionnel inclus dans la version de base On Premise vs en option dans la version SaaS). Il s’agit d’un point de vigilance à soulever lors de l’avant-vente.

Si le choix de la solution SaaS n’est pas toujours la moins onéreuse, elle permet aux DSI de réallouer l’économie de la charge de maintenance de leurs outils comptables pour se concentrer sur la modernisation des SI périphériques ou leur décommissionnement lorsqu’ils sont en fin de vie.

Envisager de revoir l’organisation des équipes

Les projets de changement d’outil comptable répondent bien souvent à une réelle volonté de rendre les processus plus fluides quitte à revoir l’organisation au sein des équipes. Dès lors, les réticences au changement ne doivent pas être négligées. Au-delà de la comitologie projet « classique », nous préconisons la mise en œuvre d’une stratégie de conduite du changement incluant : 

  • une étude d’impact,
  • un travail de pédagogie auprès des utilisateurs finaux (formations, guides, FAQ etc.),
  • un plan de communication adapté en direction des parties prenantes qui ne sont pas mobilisées sur le projet,

qui seront des facteurs clés de la réussite du projet.

Par ailleurs, ces projets ne sont pas isolés mais s’inscrivent dans un paysage à la fois réglementaire et technique qu’il faut intégrer. Parmi les défis à relever : 

  • anticiper les évolutions réglementaires ; 
  • ne pas minimiser les chantiers préparatoires pour que la migration se passe dans de bonnes conditions (qualité de données, apurement des bas de bilan, nettoyage/enrichissement des référentiels de données etc.).

Ces défis mettent en évidence la nécessité d’une co-construction de la cible métier-DSI tout au long du projet et ce, dès la phase de cadrage avec une démarche d’amélioration continue.