Le Système d’information comptable (SIC) subit de constantes évolutions pour résoudre des anomalies rencontrées en production ou bien dans le cadre de l’implémentation de nouveaux besoins réglementaires. La mise en place d’IFRS 9 l’a encore récemment montré.

Ces transformations impliquent une adaptation de la configuration existante dont la gestion s’avère rapidement lourde et délicate. La volumétrie des objets impactés et le nombre d’utilisateurs/développeurs susceptibles de travailler simultanément au sein du SIC, sur des périmètres différents, peut rapidement occasionner des effets collatéraux non maîtrisés.

Le recours à un outil de gestion de configuration peut ainsi apparaître comme une arme efficace pour gagner en traçabilité et en tranquillité en évitant tout effet de bord malencontreux. Et ce pour trois bonnes raisons.

Conserver l’historique des modifications apportées au paramétrage comptable

Cet historique est précieux. Par exemple, dans le cadre de la mise en place de la norme IFRS 9, la quantité d’objets impactés au sein du SIC est telle (plusieurs milliers) que la création du paramétrage se fait en masse (via des copiés/collés notamment). Ainsi, la probabilité de supprimer ou d’écraser une partie du paramétrage existant par erreur est tout à fait plausible.

Face à ce risque, l’outil de gestion de configuration du SI comptable permet de :

  • Garder une trace de l’ensemble des modifications effectuées sur le paramétrage : qui a fait quoi ? quand ? sur quel périmètre ? pourquoi ? Chaque nouvelle version du paramétrage dans le SIC (ou commit) s’accompagne d’un commentaire rédigé par le business analyst lui-même qui explique la nature de ses changements.
  • Réaliser un rollback des évolutions opérées en récupérant des versions anciennes des données.
  • Se prémunir de fausses manipulations puisque que le retour arrière est possible.
  • Comparer deux versions d’un même objet pour mettre en lumière et comprendre les changements réalisés entre la version 1.0 et 2.0.

Cette première bonne raison n’est pas à sous-estimer. Le logiciel comptable subit régulièrement des mises à jour (montée de version, copie de l’environnement A sur le B, etc). Ceci écrase les données historiques et empêche ainsi de consulter la totalité de l’historique des modifications effectuées sur chaque objet. Tout retour en arrière devient alors impossible. Quand bien même le SIC propose une consultation de l’historique des évolutions, elle s’avère quasiment illisible.

Sécuriser le travail collaboratif et … la production !

Deuxième bonne raison : un outil d’automatisation de la gestion de configuration du SI comptable facilite et sécurise le travail collaboratif. Ce n’est pas un mince avantage à l’heure d’un fort développement du télétravail ou d’implantations géographiques des équipes distinctes. Par exemple, un projet comme IFRS 9 mobilise de nombreuses ressources situées en France et/ou à l’étranger mais partageant les mêmes environnements de travail et ignorant parfois le scope d’intervention exact de chacun.

Ainsi :

  • Les modifications effectuées par une personne sont accessibles à tous.
  • Une ou plusieurs personnes peuvent modifier un même objet :
    • Personne n’écrase les données des autres.
    • Chacun a sa propre « working copy » et peut y travailler indépendamment et simultanément. In fine, les versions peuvent être fusionnées au sein d’une seule et même version finale. De cette façon, si deux utilisateurs changent des parties non-communes d’un fichier, l’outil fusionne les modifications. A l’opposé, dans le cas de modifications conflictuelles, le conflit est clairement signalé et doit être résolu manuellement.

Ce type d’outil permet d’alerter chacun quant au fait qu’il n’est pas le (ou la) seul(e) à travailler sur un même objet. Cela évite de livrer accidentellement des objets en production avec des modifications issues d’un autre développeur et potentiellement en cours de tests ou de validation risquant d’entraîner des effets de bord non maîtrisés.

Autre avantage : le travail simultané sur un même objet évite que le développeur B attende que le développeur A ait fini ses mises à jour pour démarrer ses propres développements. Chacun est synchronisé avec les modifications des autres.

Stabiliser l’ensemble des environnements (DEV, IST, UAT, Pré-PROD, etc…)

Le maintien à jour des environnements de manière régulière permet de s’assurer de la bonne cohabitation des sujets relevant du « business as usual » avec des thématiques projet. En reprenant l’exemple d’IFRS 9, l’enjeu réside dans l’ « étanchéité » du paramétrage IFRS 9 vis-à-vis du paramétrage préexistant en French GAAP. Cela revient par exemple à garantir que les écritures comptables attendues en French GAAP vont toujours bien “déclencher” des schémas comptables French GAAP et non pas IFRS 9.

Ainsi, plusieurs typologies d’environnements « cohabitent » et ce, pour des besoins ou usages spécifiques. L’environnement de développement (DEV) sera exploité par les développeurs afin d’y mettre en place (et de tester) les changements de paramétrage qu’impliquent les diverses demandes émanant du Métier.

Par conséquent, chaque modification de paramétrage devra d’abord être réalisée manuellement en DEV, avant d’être livrée dans un environnement de tests dédié au Métier (UAT) puis d’être déployée en Production (PROD).

La livraison des modifications doit donc s’opérer au moins à deux reprises. Dans le but de fluidifier la mise à jour des objets ayant été changés par les développeurs, et surtout de gagner du temps, l’outil de gestion de configuration peut permettre d’automatiser le déploiement des objets impactés par des évolutions dans plusieurs environnements à la fois et à des plages horaires déterminées à l’avance.

L’avantage ? Synchroniser TOUS les environnements sans oublier un seul objet, contrairement à une actualisation manuelle qui présente toujours un risque d’oubli et donc in fine de désalignement des environnements. De fait, certains objets peuvent être interdépendants. Dans ce cas, le logiciel comptable remonte un message d’erreur indiquant que l’objet A ne peut être livré sans l’objet B (y compris dans le cadre d’une livraison manuelle). Néanmoins, les objets mis à jour ou nouvellement créés ne possèdent pas toujours de dépendances avec d’autres composants : ce genre d’alerte n’est donc pas systématique.

Conclusion

Instaurer une gestion de configuration exige de la part de la DSI d’avoir le contrôle sur cette branche d’activité. De plus, d’un point de vue technique, cela requiert de mixer l’utilisation de plusieurs outils tels qu’un logiciel de gestion de versions (GIT, Subversion, etc), des scripts ainsi qu’un système de gestion des incidents (JIRA) ; et ce, pour aboutir à une véritable autonomie de l’outil de gestion de configuration.

Bien que complexe et longue à mettre en place, la gestion de configuration automatisée présente de solides atouts : sécurisation de la plateforme comptable en prévenant des régressions, historisation des évolutions sur un objet donné, gain de temps via l’automatisation des déploiements dans les différents environnements utilisés par l’IT et le Métier.