HAL Id: dumas-01798603
https://dumas.ccsd.cnrs.fr/dumas-01798603
Submitted on 23 May 2018HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
EXoMiLe : rematérialisation et exploitation des comptes
de gestion
Paul Renier
To cite this version:
Paul Renier. EXoMiLe : rematérialisation et exploitation des comptes de gestion. Ingénierie, finance et science [cs.CE]. 2016. �dumas-01798603�
CONSERVATOIRE NATIONAL DES ARTS ET METIERS
BORDEAUX
_____
MEMOIRE
présenté en vue d'obtenirle DIPLOME d'INGENIEUR CNAM
SPECIALITE : INFORMATIQUE
OPTION : ARCHITECTURE ET INGENIERIE DES SYSTEMES ET DES LOGICIELS
Par
Paul RENIER
______
eXoMiLe
Rematérialisation et exploitation des comptes de gestion
Soutenu le 27 juin 2016
______
JURY
PRESIDENT :
M. Pierre Paradinas, Professeur, Cnam Paris
MEMBRES :
M. Richard Castanet, Professeur émérite, Bordeaux INP
M. Laurent Fallot, Maître de Conférences, Bordeaux INP
M. Mohamed Mosbah, Professeur, Bordeaux INP
M. Jean-Michel Bourrier, Directeur associé, société axYus
Remerciements
Pour leur disponibilité, leur accompagnement et l’ensemble des conseils qu’ils m’ont prodigués tout au long de la phase de réalisation et de rédaction du présent mémoire, je tiens à remercier chaleureusement M. Laurent FALLOT, Maître de Conférences de l’Institut Polytechnique de Bordeaux, et M. Mohamed MOSBAH, Professeur de l’Institut Polytechnique de Bordeaux.
Je tiens aussi à adresser de sincères remerciements aux enseignants et au personnel administratif du CNAM, en particulier Mme Nathalie GOURDIN et M. Bruno GUILLET pour leurs disponibilités et leurs précieux conseils.
Un grand merci à M. Thierry BILLARD et M. Jean-Michel BOURRIER, respectivement président et directeur associé de la société axYus, pour m’avoir permis de réaliser ce mémoire.
Un merci particulier à « mes clients » pour m’avoir fourni la documentation nécessaire à la présentation du métier et du fonctionnement des institutions.
Enfin, je ne pourrais terminer cette page sans remercier ma compagne, pour ses encouragements et sa patience durant les longues soirées de rédaction...
GLOSSAIRE
BI : Business Intelligence – Informatique décisionnelle. Bind, binding : Liaison entre
BLOB : Binary Large Object – Type de donnée permettant de stocker des données binaires dans une base de données.
BPM : Business Process Management – Vision d’ensemble des processus métier ayant pour objectif de les optimiser et de les automatiser.
Classloader : Elément de l’univers Java responsable de fournir dynamiquement les classes nécessaires à l’exécution de l’application.
CRUD : Create Read Update Delete – Acronyme désignant les quatre opérations de base pour la persistance des données.
DAO : Data Access Object – Patron de conception proposant de regrouper les accès aux données au sein d’une même couche.
DDL : Data Definition Language – Sous-ensemble du langage SQL destiné à exploiter les structures de données.
DML : Data Manipulation Language – Sous-ensemble du langage SQL destiné à manipuler les données (lecture / écriture).
Downcast : En programmation objet, défini le transtypage d’une référence d’un type de base vers un type dérivé.
FIFO : First In First Out – Structure de données de type pile. FO : Formatting Object – Format XML de rendu de données XML.
Framework : Ensemble de composants logiciels servant de fondations (cadre).
Heap / Off-heap : Dans l’univers Java, définit respectivement la mémoire utilisateur allouable dans la JVM et la mémoire allouable hors JVM (système).
I18N : Abréviation de (Internationalisation) qui désigne l’action d’adaptation d’un logiciel à des langues et cultures différentes.
JAXB : Java Architecture for XML Binding – Technologie permettant de créer un modèle objet Java à partir d’un schéma XML (XSD).
JNDI : Java Naming and Directory Interface – API Java de connexion à des annuaires (LDAP, X500…).
JPA : Java Persistence API – Interface Java permettant une abstraction objet de l’accès aux données.
JVM : Java Virtual Machine – Machine virtuelle Java. LIFO : Last In First Out – Structure de données de type file.
Mapping : Procédé permettant de mettre en correspondance deux modèles de données.
MD5 : Message Digest 5 – Fonction de hachage cryptographique.
Mimetype : Identifiant utilisé sur Internet pour définir un format de donnée.
MOA, AMOA : Respectivement Maîtrise d’OuvrAge et Assistance à Maîtrise d’OuvrAge.
MOE : Maîtrise d’Œuvre.
Multithreading : voir parallélisation.
Parser, parsing : Respectivement analyseur syntaxique et phase d’analyse syntaxique.
Parallélisation : Exécution simultanée de traitements.
Pool : Ensemble de ressources réutilisables (connexion, thread…).
Refactoring : Opération consistant à remanier le code sans ajout de fonctionnalité.
Scalabilité : Capacité d’un produit à s’adapter à la montée en charge. SGBD, SGBDr : Système de Gestion de Base de Données (Relationnelle)
SHA1 : Secure Hash Algorithm 1 - Fonction de hachage cryptographique.
SQL : Structured Query Language – Langage normalisé d’exploitation des bases de données.
Tablespace : Espace de stockage logique destiné à recevoir les données d’une base de données.
TCL : Transaction Control Language – Sous-ensemble du langage SQL destiné à la gestion des transactions.
Thread : Fil d’exécution, tâche.
Thread-safe : Code apte à être parallélisé.
TMA : Tierce Maintenance Applicative – Maintenance d’une application par un prestataire.
W3C : World Wide Web Consortium – Organisme de standardisation des technologies Web.
Workflow : Circuit de validation pouvant être représenté par un diagramme d’état transition.
XMX : Paramètre de la JVM servant à définir la taille maximale de l’espace mémoire utilisateur alloué pour la JVM (voir heap).
XPath : Langage d’interrogation dans un document XML.
XSD : XML Schema Definition – Langage de description de format d’un document XML.
XSL, XSLt : eXtensible Stylesheet Language (Transformations) – Langage de transformation de documents XML.
Sommaire
Introduction ...6
1 Le sujet et l’environnement métier ...7
1.1 Présentation du sujet ...7
1.2 Les différentes entités intervenantes ...9
1.3 Le compte de gestion, pivot de la comptabilité publique ...17
1.4 Le compte de gestion dématérialisé ...20
2 De l’expression des besoins à l’émergence d’une solution ...25
2.1 L’analyse du besoin : le périmètre fonctionnel ...26
2.2 Etat des lieux et contraintes techniques ...31
2.3 Les axes d’amélioration ...47
2.4 Les décisions organisationnelles ...58
3 eXoMiLe : Architecture logicielle et réalisations techniques ...63
3.1 Découpage : diviser pour régner ...64
3.2 La configuration de document ...67
3.3 La persistance de l’information ...74
3.4 Le cœur : entre contrat, abstraction et outillage...77
3.5 Le moteur d’interrogation fonctionnelle ...86
3.6 Communiquer avec le SGBD ...90
3.7 Indexer un document XML : maîtriser l’espace et le temps ...93
3.8 Indexer un document XAR : s’appuyer sur l’existant ... 100
3.9 Le module de rendu des documents ... 102
3.10 Retrouver des données : le module de recherche ... 107
Conclusion ... 111
Annexes ... 112
Bibliographie ... 121
Liste des figures ... 123
Introduction
Depuis de nombreuses années, les entreprises et les institutions publiques œuvrent à diminuer la quantité des échanges papiers en s’inscrivant dans une démarche de dématérialisation de leurs documents.
Au cours des années 2000, le Ministère des finances a mis en place un plan progressif de modernisation de la comptabilité publique s’appuyant sur la dématérialisation des données comptables. Le choix d’une dématérialisation orientée données1 au format XML a été retenu afin d’offrir une exploitation riche et performante
des documents.
La réalisation de ce travail a été confiée à la société axYus, prestataire informatique de longue date du Ministère des finances. Afin de prouver la faisabilité de la solution retenue, une première expérimentation a été conduite sur les documents relatifs à la paye et un outil d’exploitation a été produit. Ce travail étant concluant, le périmètre a été élargi pour intégrer l’ensemble de la comptabilité publique.
S’inscrivant en aval du processus de dématérialisation, l’outil XeMeLios permet l’exploitation et la consultation des documents dématérialisés. Malgré un franc succès dans ses débuts, l’outil n’a pas su absorber un volume de données à traiter en constante augmentation. Les problèmes techniques se sont accumulés et la satisfaction utilisateur a commencé à décliner.
Une analyse fonctionnelle et technique est donc nécessaire afin de dégager une solution et des choix organisationnels en découleront. La performance, la maintenabilité, la robustesse et l’extensibilité de l’outil seront au cœur des raisonnements. C’est le projet eXoMiLe…
1 Par opposition à la dématérialisation orientée document qui est un processus de numérisation (image, pdf…)
1 L e s u j e t e t l
’ e n v i r o n n e m e n t m é t i e r
Cette partie a pour objectif de présenter le sujet de ce mémoire, les différents acteurs intervenants et de fournir au lecteur un ensemble de connaissances métier lui permettant de poursuivre sa lecture.
Dans un premier temps, nous allons découvrir brièvement l’objet de ce document. Nous parlerons client, produit et prestataire, mais également besoin, coût et satisfaction utilisateur.
Ensuite nous détaillerons les différentes entités opérant sur la chaîne de traitements de la comptabilité publique. Nous présenterons les principales missions dont elles ont la charge en offrant un niveau de détail suffisant à la compréhension.
Puis, nous parlerons du compte de gestion. Nous verrons son rôle central dans la comptabilité publique. Nous aborderons le principe de séparation ordonnateur / comptable établi sur l’incompatibilité de ces deux fonctions. Nous pourrons ensuite détailler ce qu’est un compte de gestion.
Enfin, nous traiterons de la dématérialisation du compte de gestion. Nous détaillerons les différents éléments intervenants sur la chaîne de traitements sans aborder de sujet technique.
1.1 Présentation du sujet
La société axYus, est prestataire de services auprès de la Direction Générale des Finances Publiques (DGFiP) autrefois appelée communément Trésor Public. Elle est chargée de nombreux projets dans le domaine de la comptabilité publique, des impôts et des services financiers de l’Etat et des collectivités territoriales.
En 2004, un vaste plan de modernisation de l’administration financière a été lancé et la dématérialisation des échanges liés à la comptabilité des collectivités est alors au centre des préoccupations. Le but recherché est une réduction progressive des émissions papiers en dématérialisant la chaîne comptable sur l’ensemble de son processus, de l’ordonnateur à la chambre régionale des comptes, en passant par la facturation électronique, l’émission des titres de recette et mandats de dépense…
La dématérialisation offre de nombreux avantages dans des secteurs variés. Parmi eux nous pouvons retenir :
· simplifier et accélérer les échanges d’informations, · permettre le contrôle automatisé des données, · diminuer les coûts de gestion,
· réduire l’empreinte environnementale.
En réponse à ce besoin exprimé, axYus s’est alors positionnée et a remporté de nombreux projets. Parmi ces derniers, le projet XeMeLios s’inscrit en aval de la chaîne de dématérialisation/rematérialisation1, c’est-à-dire au niveau de l’exploitation et
de la consultation des documents (Figure 1).
Dématérialisation
Comptab le XeMeLio s
DGFiP
Figure 1 - XeMeLios dans la chaîne de dématérialisation / rematérialisation
XeMeLios se présente sous la forme d’un outil bureautique monoposte et mono-utilisateur, devant pouvoir évoluer simplement pour prendre en compte de nouveaux types de documents. Initialement conçu comme un prototype dont l’objectif était de démontrer le bienfondé de l'approche de la dématérialisation par les données, il a rapidement convaincu le client et les utilisateurs. Victime de son succès, XeMeLios a vu son périmètre fonctionnel s’agrandir et a dû être adapté pour répondre à la demande.
1 Au cours de ce mémoire le terme rematérialisation est régulièrement employé abusivement. En effet, dans l’univers de l’informatique de gestion et plus précisément de la dématérialisation, l’opération de rematérialisation qui consiste à reproduire un document dématérialisé sur un support physique est confondue avec l’étape de rendu qui la précède.
Produit comme un prototype et constamment modifié, XeMeLios souffre de déficits de conception et de réalisation. Face à des volumétries de données à traiter en constante augmentation et à des besoins utilisateurs grandissants, XeMeLios affiche désormais des difficultés de fonctionnement.
La question de l’amélioration du produit se pose alors et la DGFiP consulte axYus à ce sujet. De nombreuses interrogations techniques, fonctionnelles et organisationnelles sont soulevées et ce mémoire a pour objectif d’y répondre et de présenter les solutions retenues. La question principale étant de savoir si l’amélioration se fera par le maintien ou par la réécriture de l’application…
1.2 Les différentes entités intervenantes
1.2.1 La société axYus : une entreprise au service du Public
1.2.1.1 Création, implantation et prestations
Créée en avril 2000 par les quatre dirigeants associés actuels, Jean-Michel Bourrier, Thierry Billard, Pascal Heidet et Sébastien Wasser, axYus est une Entreprise de Services du Numérique (ESN) nationale. Comme l’illustre la Figure 2, axYus est implantée sur Paris, Bordeaux, Limoges et une personne détachée spécifiquement à un projet à Aix en Provence.
Pour axYus, les projets de système d’information doivent répondre à un besoin de création de valeurs et aux attentes du marché. Elle accompagne durablement les entreprises dans leur réussite, en restant toujours en adéquation avec les attentes des organisations métier mais aussi à l’écoute de leurs clients et leurs besoins fonctionnels.
AxYus est spécialisée dans le développement au forfait, qui représente actuellement environ 70% de ses projets contre 20% en Tierce Maintenance Applicative (TMA). En plus de proposer de la Maîtrise d’Œuvre (MOE), axYus offre également des services d'Assistance à Maîtrise d’Ouvrage (AMOA). Elle offre ainsi un éventail de prestations allant de la phase avant-projet jusqu’à la post-production.
Depuis 2004, axYus propose des services dans le Business Process Management (BPM), c'est-à-dire la modélisation informatique des processus métiers, et dans l'informatique décisionnelle Business Intelligence (BI), qui représente les solutions informatiques destinées aux dirigeants de l'entreprise cliente.
Figure 3 - Logo axYus
1.2.1.2 Clients
Le portefeuille clients de la société axYus est essentiellement composé d’entités publiques, notamment de ministères comme ceux de l’éducation, de l’intérieur et des finances, ou bien des collectivités comme la région Aquitaine, la mairie de Bordeaux ou encore la mairie de Paris. Parmi les entreprises du secteur privé, axYus travaille régulièrement avec des grands comptes comme La Poste, ERDF ou FranceTelecom. La Figure 4 représente la répartition des projets entre le secteur public et le secteur privé. La Figure 5 détaille la composition du secteur public.
Figure 4 - Répartition des projets en fonction du secteur
Figure 5 - Répartition des clients du secteur public
Privé 28% Public 72% Ministère des finances 5% Ministère de l'enseignement supérieur et de la recherche 5% InVS 5% DGAC 9%
Cour des comptes 5% Conseil régional d'Aquitaine 5% COFRAC 9% ASP 33% AIFE 19% Ministère de l'intérieur 5%
Forte de ses 15 années au service du Public, axYus s’est forgée une solide réputation ce qui lui permet d’approcher de nouvelles entités. La Figure 6 présente les principaux clients recourant régulièrement aux services de la société.
Figure 6 - Principaux clients axYus
Malgré sa taille modeste, axYus répond à des appels d’offres et entre régulièrement en compétition avec des concurrents plus importants tels Atos,
CapGemini ou Sopra ; ce qui ne l’empêche pas de remporter de beaux marchés, une récompense à la qualité et au sérieux de ses prestations.
1.2.1.3 Une croissance ininterrompue depuis sa création
Depuis sa création, axYus n’a jamais cessé de croître. En 2007 elle reçoit le label Gazelle, certification qui vise à récompenser le dynamisme et la performance des entreprises qui enregistrent les plus fortes croissances sur une année.
Cette progression sans relâche est révélatrice de la bonne gestion de l’entreprise et de la qualité des prestations produites. Trois axes peuvent être dégagés pour illustrer ce phénomène.
Sur l’axe financier présenté sur la Figure 7, en considérant le chiffre d’affaires comme principal indicateur, axYus a atteint la valeur de 7 879 800,00 € en 2014 et affiche une croissance continue depuis sa création de l’ordre de 10%.
Figure 7 - Chiffre d'affaires annuel axYus
1 248 320 € 1 826 942 € 2 675 557 € 3 196 927 €3 252 193 € 4 073 579 € 4 180 000 € 5 259 900 € 6 460 100 € 7 047 700 € 7 879 800 € 0 € 1 000 000 € 2 000 000 € 3 000 000 € 4 000 000 € 5 000 000 € 6 000 000 € 7 000 000 € 8 000 000 € 9 000 000 €
Sur l’axe humain en Figure 8, en se basant sur le nombre de salariés, axYus affiche la même dynamique et a ainsi dépassé la valeur symbolique des 50 employés en 2011.
Figure 8 - Evolution du nombre de salariés axYus
Enfin, si l’on s’intéresse au portefeuille clients en Figure 9, axYus a constamment réussi à conquérir de nouveaux marchés. En 2015, le nombre de clients recensés est évalué à 190. En 2016, la société estime avoir des projets actifs avec une vingtaine d’entre eux.
Figure 9 - Evolution du portefeuille clients axYus
11 16 18 31 37 40 44 50 54 55 62 71 0 10 20 30 40 50 60 70 80 10 20 35 55 70 75 80 105 130 150 175 190 0 20 40 60 80 100 120 140 160 180 200
1.2.2 La DGFiP : la fiscalité mais pas que…
La Direction Générale des Finances Publiques est née en 2008, résultat de la fusion entre la Direction Générale des Impôts (DGI) et la Direction Générale de la Comptabilité Publique (DGCP). Rattachée au ministère des finances, la DGFiP assure désormais les missions autrefois attribuées à la DGI et à la DGCP, elle est le cœur de la vie financière publique.
En matière fiscale, la DGFiP conçoit et élabore les textes législatifs et réglementaires relatifs à la fiscalité, au recouvrement des recettes publiques. Elle veille à la mise en œuvre du contrôle des impôts, droits, cotisations et taxes de toute nature ainsi qu'à leur recouvrement.
Dans le domaine de la gestion publique, elle contrôle la production et la qualité des comptes de l'État et élabore les règles et les procédures relatives au contrôle et au paiement des dépenses publiques.
Afin d’exercer ses fonctions au niveau local, la DGFiP dispose de services déconcentrés, les plus connus étant les Directions Départementales des Finances Publiques (DDFiP) et les Directions Régionales des Finances Publiques (DRFiP).
Techniquement, la DGFiP élabore les dispositifs de transmission des informations comptables entre les collectivités, ses services et les organismes de contrôle. Elle met à disposition les outils logiciels nécessaires à cette tâche et assure la maintenance et le support utilisateur.
1.2.3 Le contrôle des deniers publiques
La Cour des comptes a été créée par Napoléon 1er en 1807. Sa vocation était
alors de garantir la régularité de l’emploi des deniers publics. Son rôle principal reste inchangé de nos jours, mais elle a vu ses fonctions considérablement élargies à la suite de la seconde guerre mondiale et à l’instauration de la Ve République. Elle juge la régularité des comptes établis par les comptables publics dans les différents services de l’État et contrôle le bon emploi et la bonne gestion des fonds publics. Elle est également chargée de certifier la régularité, la sincérité et la fidélité des comptes de l’État et assiste le Parlement et le gouvernement pour vérifier la bonne exécution des lois de finances de l’État.
A l’origine unique et centralisée, elle s’est vue renforcée par des Chambres Régionales des Comptes (CRC) 170 ans après sa création afin d’absorber le besoin croissant de contrôle et de régulation. Une CRC est responsable d’un secteur géographique et est déléguée par la Cour des comptes pour contrôler certains établissements publics nationaux.
Son périmètre opérationnel s’étend à toutes les collectivités territoriales, qu’il s’agisse des communes, des départements et des régions, mais également de leurs établissements publics. La Figure 10 présente le découpage géographique et leur CRC respective.
Figure 10 - Les Chambres Régionales des Comptes
Depuis 2005, les CRC sont épaulées par les Pôles Interrégionaux d’Apurement Administratif (PIAA) en charge des petites et moyennes collectivités, soit 85% des traitements. Concrètement, ils agissent comme des filtres et ne transmettent aux chambres régionales des comptes que les dossiers susceptibles d’engager la responsabilité personnelle et pécuniaire des agents comptables (voir paragraphe 1.3.1). Ils interviennent en tant que prestataires de services pour les Directions Départementales des Finances Publiques (DDFiP). Au nombre de deux, ils ne traitent
que les dossiers concernant des collectivités de moins de 3500 habitants appartenant à leur secteur géographique (Figure 11).
Figure 11 - Périmètre géographique des PIAA
1.3 Le compte de gestion, pivot de la comptabilité publique
1.3.1 La séparation Ordonnateur / Comptable, un principe fondamental
Avant de définir ce qu’est un compte de gestion, il est nécessaire de s’attarder un peu sur une spécificité relative à la comptabilité publique, la séparation entre ordonnateur et comptable. Ce principe répond au besoin de garantie dans la gestion des deniers publics. Cela a pour conséquence que l’agent public qui ordonne une dépense ou bien le recouvrement d’une recette ne sera pas celui qui manipulera les fonds.
L’ordonnateur, par exemple un maire, émet un titre de recette ou un mandat de dépense à destination du comptable public. Ce dernier effectuera l’opération après un certain nombre de vérifications (diligences), ou bien la refusera. Un comptable publique n’est pas subordonné à l’ordonnateur. Pour chaque opération traitée, il engage sa responsabilité personnelle et pécuniaire.
Le Tableau I représente un récapitulatif des opérations réalisées par chacun des deux acteurs et la Figure 12 illustre le principe de séparation ordonnateur / comptable public :
Tableau I - Pouvoirs ordonnateur / comptable public
Recette Dépense
Ordonnateur Emission (titre) Engagement
Liquidation (montant) Ordonnancement (mandat)
Comptable Contrôle Paiement
Ordonnateur Comptable public
Titre / mandat Recette
DGFiP
Collectivité
Fournisseurs, sous-traitants...
Dépense1.3.2 Qu’est-ce qu’un compte de gestion ?
En comptabilité publique, le compte de gestion représente l’ensemble des opérations financières effectuées par une administration publique au cours d’un exercice. Il est établi par le trésorier avant le 1er juin de l’année N et s’appuie sur les
opérations budgétaires (dépenses et recettes) de l’année N-1.
Un compte de gestion est constitué de différents documents budgétaires. Au minimum, il doit présenter :
· une balance générale de tous les comptes tenus par le trésorier, · le bilan comptable qui décrit l’actif et le passif de la collectivité.
Le compte de gestion d’une collectivité peut concerner plusieurs budgets : un budget principal et plusieurs budgets annexes. Un budget annexe est établi pour certains services locaux spécialisés (établissements hospitaliers, assainissement…). Il permet de séparer les opérations relatives à ce service et ainsi de déterminer avec précision les dépenses et les recettes liées à ses seuls utilisateurs. L’ensemble formé du budget principal et des budgets annexes forme le budget collectivité.
Chaque budget est soumis à une nomenclature. Les nomenclatures représentent l’ensemble des comptabilités applicables selon le type de collectivité et selon la nature de l’activité exercée. Elles peuvent évoluer à chaque nouvel exercice, la représentation d’un budget est donc lié au couple nomenclature / exercice.
A la fin de l’exercice N, le comptable assignataire demande le compte de gestion afin que ce dernier soit signé successivement par :
· le comptable supérieur, à partir de l’année N+1, · le comptable assignataire,
· l’ordonnateur.
La campagne de signature d’un exercice N se déroule en général de début février à fin avril de l’année N+1.
1.3.3 Compte de gestion sur chiffres / Compte de gestion sur pièces
Le compte de gestion sur chiffres appartient à un budget collectivité. Il contient un bilan comptable consolidé, un document de synthèse arrêté à la clôture de
l’exercice budgétaire. Il synthétise pour un budget collectivité la gestion de l’année écoulée et présente la situation comptable et patrimoniale à la clôture de l’exercice.
Le compte de gestion sur pièces1 rassemble l’ensemble des éléments
budgétaires et comptables de l’exercice N. Il sert de support au contrôle des comptes d’une collectivité. Il est constitué de :
· compte de gestion sur chiffres, · état de développement des soldes, · état de restes à recouvrer,
· état de restes à payer, · fiches budgétaires,
· livre auxiliaire des comptes de tiers et financiers, · pièces justificatives.
La campagne de traitement des comptes de gestion sur pièces débute quand l’autorisation est donnée par la DGFiP, généralement à compter de juin N+1.
Une fois le compte de gestion sur pièce constitué, il est consulté, vérifié et signé par le comptable assignataire. Avant le 31 décembre de l’année N+1, il sera transmis pour contrôle à une des entités compétentes en fonction de la dimension de la collectivité et de son emplacement :
· CdC, · CRC · PIAA, · DRFiP, · DDFiP.
1.4 Le compte de gestion dématérialisé
La dématérialisation du compte de gestion offre un workflow technique qui fait intervenir différentes applications. De la saisie des opérations à la rematérialisation des documents, la chaîne de traitement est longue et ne sera pas traitée dans ce document.
1 Le compte de gestion sur pièces ne peut être constitué qu’une fois le compte de gestion sur chiffres signé par le comptable.
Néanmoins, afin d’apporter plus de clarté et de compréhension sur certains choix techniques, nous allons découvrir les principaux acteurs intervenant au cours de ce processus dont la Figure 13 offre une représentation simplifiée :
Ordonnateur HELIOS PESV2 + PJ CDGD Comptable public ASA + PESV2 Vérifie Service comptabilité Demande ATLAS Consultation PJ Consulte / Signe XeMeLios CdC, CRC... Contrôle
Figure 13 - Workflow technique de dématérialisation
Nous allons détailler les trois briques principales de cette chaîne : Helios, CDGD et Xemelios. La société axYus contribue activement aux choix d’architecture et apporte son expérience sur les échanges asynchrones entre ces applications. Elle est également en charge du développement et du maintien des applications CDGD et XeMeLios.
1.4.1 Helios : la saisie des opérations
Lorsqu’un ordonnateur demande une opération financière, il adresse cette demande à son service comptabilité qui se charge de la saisir dans le logiciel de comptabilité. Ce dernier transmet la demande à Helios via un format standardisé : le Protocole d’Echange Standard V2 (PESV2). Ce protocole permet l’envoi de données
comptables ainsi que la transmission des pièces justificatives (PJ) associées. Ces dernières sont stockées dans l’application Atlas, un entrepôt de documents divers avec scellement technique (sceau). Le PESV2 repose sur une syntaxe XML et le standard est maintenu par la DGFiP. Une fois la demande transmise à Helios, le comptable public vérifie et valide ou non la demande.
Helios est en charge de la production du compte de gestion. Historiquement, cette opération était inscrite dans une longue chaîne éditique au moyen d’un format pivot d’impression sur les plateformes IBM : le format ASA. La production de ces fichiers ASA est toujours d’actualité. Cependant ce format est peu exploitable du fait du manque d’outils capables de le manipuler. De plus, il ne permet pas un enrichissement via des métadonnées. Il n’a pas été conçu dans cette optique et il n’est donc pas un bon candidat pour une dématérialisation dans le but de l’exploitation de l’information.
L’ensemble des fichiers ASA et PESV2 est archivé dans un document communément appelé « enveloppe Helios », lequel sera ensuite transmis à l’application CDGD.
1.4.2 CDGD : De l’éditique au numérique
L’application CDGD (Compte De Gestion Dématérialisé) offre de nombreux services comme la consultation, la validation et la signature d’un compte de gestion, ou encore la constitution d’un compte de gestion sur pièces. C’est cette étape que nous allons détailler dans ce paragraphe.
La première opération consiste à produire le compte de gestion sur chiffres au format XML. Pour cela une opération de transformation du format ASA vers un format standardisé est effectuée. Le format XML permet de pallier aux manquements énoncés précédemment. De nombreux outils sont disponibles pour manipuler du XML et sa syntaxe permet aisément d’enrichir les données. Il offre également la possibilité de réaliser des signatures embarquées de documents (XADES).
La seconde opération est de constituer le compte de gestion sur pièces. Pour cela il est nécessaire de rapatrier les états comptables et les documents PESV2 correspondant aux pièces justificatives (PJ). Les PJ sont stockées dans un silo interne de la DGFiP. Il est inutile de les télécharger. La consultation se fera en ligne. Seul le fichier PESV2 de description de la PJ est nécessaire. Le tout est alors compressé dans une archive ZIP portant l’extension xar (Xemelios ARchive).
L’archive du compte de gestion sur pièces est ensuite signée et compressée dans une archive ZIP portant l’extension xas (Xemelios Archive Signed). Elle sera transmise aux organismes en charge du contrôle budgétaire (CdC, CRC, PIAA…).
1.4.3 XeMeLios : l’exploitation du compte de gestion dématérialisé
XeMeLios est l’outil intervenant en bout de chaîne. Il se présente sous la forme d’un client lourd et permet l’exploitation des comptes de gestion dématérialisés. Il a été livré dans sa première version en 2005 et a depuis évolué afin d’offrir des fonctionnalités supplémentaires aux utilisateurs, tel que le contrôle automatique de documents ou bien le support de nouveaux formats de dématérialisation.
Il est libre de droit et déployé à large échelle (http://xemelios.org/). Le nombre d’utilisateurs est estimé à 26000, comprenant divers profils comme les comptables publics ou bien les ordonnateurs, mais aussi des éditeurs logiciels qui s’appuient sur ses fonctionnalités pour les intégrer à leurs outils.
Au travers de nombreux écrans, XeMeLios permet d’exploiter les documents supportés. Parmi ces fonctionnalités principales nous retrouvons :
· L’import, indexation et suppression de document, · la consultation,
· la recherche.
Nous apporterons plus de détails à ces opérations dans le chapitre 2.1 où nous traiterons du périmètre fonctionnel.
Le support des documents est réalisé via un mécanisme simple de description de format de document afin de pouvoir les exploiter. On parle alors de « configuration de document », une brique nécessaire à la prise en charge des informations. XeMeLios est donc extensible par paramétrage et possède une documentation fournie, ce qui le classe dans la catégorie des progiciels.
Figure 14 - Capture d'écran recherche XeMeLios
2 D e l
’ e x p r e s s i o n d e s b e s o i n s à l ’ é m e r g e n c e
d
’ u n e s o l u t i o n
Après de nombreuses années de services rendus, XeMeLios n’est plus apte à répondre aux évolutions technologiques, aussi bien matérielles que logicielles. La DGFiP, a alors mandaté axYus pour la réalisation de l’état des lieux fonctionnel, l’identification du périmètre technique, et l’élaboration d’un plan de production.
Cette étape constitue la phase avant-projet, opération nécessaire où vont se succéder étude d’opportunité et étude de faisabilité.
Comme bien souvent, utilisateur et client sont rarement la même personne dans l’univers des ESN. La connaissance métier est indispensable et généralement elle ne peut être déléguée à la Maîtrise d’Œuvre (MOE). C’est la Maîtrise d’Ouvrage (MOA) qui en a la responsabilité en faisant l’interface entre un univers métier de l’utilisateur et un univers technique représenté par axYus.
L’étude effectuée par la MOA a mis en évidence les différents utilisateurs de l’outil. Nous pouvons les regrouper en deux catégories, les utilisateurs internes, c’est-à-dire ceux qui opéreront au sein de la DGFiP ou bien dans une annexe, et les utilisateurs externes, opérant depuis des structures non-affiliées à la DGFiP (Tableau II).
Tableau II - Catégories des utilisateurs de XeMeLios
Utilisateurs internes Utilisateurs externes
Administrateur de l’application Ordonnateurs
Comptables supérieurs Chambres Régionales des Comptes
Comptables assignataires Préfectures
Comptables Pôles Interrégionaux d’Apurement
Administratif Utilisateurs consultation nationale
Utilisateurs consultation départementale
Bien que les utilisateurs listés ci-dessus exercent des métiers différents, nous pouvons identifier deux profils distincts d’utilisation de l’outil :
· l’utilisateur final, limité à des opérations d’exploitations,
· l’opérateur administrateur, en charge de la maintenance et la mise à jour du système.
2.1 L’analyse du besoin : le périmètre fonctionnel
Nous avons vu précédemment deux profils d’utilisations très différents de l’outil. D’une part, nous avons l’utilisateur final dont l’utilisation sera réduite à l’exploitation des données, nous avons donc un profil purement métier. D’autre part, nous retrouvons un profil plutôt orienté technico-fonctionnel dont le but est l’administration du système.
Du point de vue de l’utilisateur final, le besoin émis est d’assurer un périmètre iso-fonctionnel avec XeMeLios et de prendre en compte quelques fonctionnalités supplémentaires exprimées par la MOA. Du point de vue de l’administrateur, l’attente est un ensemble de fonctionnalités d’administration permettant de gérer les configurations de documents et les documents supportés.
Une liste exhaustive des fonctionnalités ne sera pas proposée dans ce document mais seulement celles jugées principales. Elles sont illustrées par le diagramme UML des cas d’utilisation de la Figure 16.
2.1.1 Import, mise à jour et suppression de configurations
Comme évoqué dans le paragraphe 1.4.3, les formats de document supportés par l’outil sont définis dans un objet que l’on nomme « configuration de document ». Cette entité regroupe l’ensemble des opérations réalisables sur un document, notamment comment importer ou encore comment indexer. La Figure 17 illustre le cycle de vie d’une configuration de document.
IMPORT MISE A JOUR SUPPRESSION
Création support de données
et structure d’index Mise à jour structure d’index Suppression support de donnéeset structure d’index
Administrateur
Figure 17 - Cycle de vie d'une configuration de document
L’import d’une configuration entraine la création d’un espace de stockage où sont enregistrés les documents régis par cette configuration. De plus, si une indexation est définie, une structure organisée d’index (hiérarchie) sera créée et sera alimentée ultérieurement par les informations ciblées dans les documents.
La mise à jour est différentielle, c’est-à-dire que seules les modifications seront appliquées. Le but principal recherché dans cette fonctionnalité est la performance, notamment sur la maintenance des index associés. Les documents importés ne seront pas impactés mais uniquement les index qui sont associés.
Enfin la suppression consiste à effacer la structure d’index (si elle existe) et les documents associés.
2.1.2 Import, (ré) indexation et suppression de documents
Il est essentiel de distinguer ces trois phases. L’import consiste à insérer les données du document dans un support de persistance alors que l’indexation se résume à alimenter un système de données organisé de manière à permettre de retrouver un document selon divers critères.
Le mécanisme d’import peut déclencher une indexation mais pas nécessairement. Il est tout à fait concevable d’importer un document sans pour autant l’indexer. Pour différentes raisons une telle opération peut être souhaitable, comme par exemple, la performance ou alors simplement parce que les données indexables ne sont pas encore connues au moment de l’import du document. Une phase d’import peut entraîner la suppression d’un document existant si ces derniers entrent en collision1.
Pour répondre à cette problématique, une fonctionnalité supplémentaire est nécessaire, la ré-indexation. Elle s’appuie sur le processus d’indexation et son travail est semblable. Cependant, il est à noter une différence majeure : la ré-indexation peut s’appuyer sur un ensemble d’informations techniques permettant de reconstruire partiellement les index ou bien d’effectuer une indexation incrémentale, ce qui a un impact non-négligeable sur les performances de l’outil.
La suppression consiste à détruire l’indexation relative à un document et à libérer l’espace alloué par ce dernier sur le système de persistance.
2.1.3 Recherche de documents ou parties de documents
Un document importé doit pouvoir être retrouvé à partir de champs de recherche variés. Le premier auquel nous pensons est très probablement le nom du document, mais s’appuyer uniquement sur cette information n’aurait pas beaucoup d’intérêt, le système de fichier répond déjà à cette demande.
La recherche s’appuie essentiellement sur l’indexation. En effet, l’indexation étant définie dans la configuration de document, l’opérateur administrateur peut renseigner des informations à extraire afin de permettre de les exploiter ultérieurement.
1 Deux types de collisions sont identifiés : collision technique et collision fonctionnelle. La première concerne les documents strictement identiques au niveau du contenu alors que la deuxième s’appuie sur des informations qui les identifient comme identiques (clés).
En résumé, la recherche d’un document peut être réalisée en s’appuyant sur différents champs techniques (nom, taille…) et fonctionnels (données métier), et peut porter sur tout ou partie d’un document.
Un critère de recherche se définit par un triplé (champ, opérateur, valeur). Les opérateurs applicables sont dépendants du type de données représentées par le champ. Le « format » de la valeur est dépendant d’une part, du type de champ et, d’autre part, du contexte local (i18n). Le Tableau III présente la liste des opérateurs supportés en fonction du type de données :
Tableau III - Opérateurs de recherche par type de donnée
Type Opérateurs supportés
Alphanumérique = ≠ ~1 ~=2 =~3
Numérique = ≠ < > ≥ ≤
Date = ≠ < > ≥ ≤
Booléen = ≠
L’indexation offre également une information technique importante exploitée par la recherche : la localisation des données. Ceci permet d’effectuer des recherches partielles, c’est-à-dire portant sur une partie de document. Cette fonctionnalité est la plus utilisée par l’utilisateur final. En effet, la recherche d’éléments dans un document (par exemple des lignes de bilan comptable) est d’un point de vue métier plus intéressante que la recherche du document lui-même.
2.1.4 Rematérialisation HTML et PDF
La dématérialisation des documents offre la possibilité d’un découpage permettant la consultation partielle des données. En effet, il est courant de séparer un document en différents chapitres, différentes pages… Cette notion de découpage est couramment appelée « état » dans le milieu de la dématérialisation.
La recherche partielle couplée à un découpage du document permet de consulter un état spécifique. Cependant la possibilité de passer d’un état à un autre, en
1 Opérateur « contient »
2 Opérateur « commence par » 3 Opérateur « termine par »
respectant un ordre logique (pas nécessairement la position dans le document) ne peut être assurée par ces deux fonctionnalités.
La demande porte alors sur la possibilité de naviguer par états dans un document dématérialisé, l’ordre étant défini par la configuration en tenant compte de divers critères comme par exemple un numéro de page.
De plus, un état doit être capable d’embarquer des « liens » pointant vers d’autres états ou d’autres types de document (Figure 18). Ce besoin est issu d’un cas métier bien identifié qui se caractérise par le fait qu’au sein d’un compte de gestion, plus précisément dans la balance générale des comptes, les sommes présentées doivent pouvoir être justifiées. Les premiers éléments justificatifs se situent alors dans des états différents.
COMPTE DE GESTION Balance générale Fiches budgétaires Etats de développement des soldes
Livres auxiliaires des comptes tiers
0...∞
0...∞
0...∞
Figure 18 - Illustration liens entre état
La consultation des documents/états doit pouvoir se faire dans des formats différents. Dans un premier temps les sorties HTML et PDF ont été retenues.
2.1.5 Vers une application Web…
En tant qu’application lourde distribuée à large échelle, XeMeLios n’échappe pas à la problématique de la maintenance. En effet la diffusion des mises à jour de l’outil a un coût non négligeable pour la DGFiP. La responsabilité des développements incombe à axYus, alors que la charge de support est assurée par la DGFiP. Le support
est une tâche vaste et son périmètre va de l’utilisation du logiciel à la collecte des anomalies et des demandes d’évolutions.
De plus, une application lourde est soumise à des contraintes matérielles et logicielles. D’une part, ceci peut très vite devenir un casse-tête pour la maîtrise d’œuvre puisque les corrections et évolutions doivent assurer constamment une compatibilité ascendante vis-à-vis de l’environnement, et une rétrocompatibilité sur les configurations de documents. D’autre part, cela peut aboutir à un immobilisme de l’infrastructure technique du client si une compatibilité matérielle ou logicielle n’est pas assurée.
Fort de ce constat, la DGFiP souhaite voir son outil évoluer vers une solution Web. La possibilité d’intégrer XeMeLios dans d’autres applications est incontournable. En effet, la DGFiP possède de nombreuses applications s’appuyant sur les données dématérialisées des comptes de gestion. Fournir des fonctionnalités assurées par XeMeLios au travers d’applications tierces offrira du confort utilisateur et un gain de productivité.
Néanmoins le développement d’un outil « standalone » n’est pas exclu à moyen terme. Bien que le paradigme de développement d’une application Web diffère de celui d’une application lourde, la conception de la future solution devra tenir compte de cette remarque afin de prévoir la réutilisabilité des développements réalisés.
2.2 Etat des lieux et contraintes techniques
Le futur plan de production ne pourrait être réalisé sans une analyse technique inhérente aux besoins du client. Cette étape aura un impact sur le choix et le dimensionnement de la future solution technique détaillée au chapitre 2.3.
Dans cette section nous allons nous intéresser à la qualité de XeMeLios. Il est en général assez difficile de définir « la qualité ». C’est une notion abstraite et subjective. C’est pourquoi nous jugerons de la non-qualité du produit, notion sur laquelle nous pouvons avoir un regard objectif en s’appuyant sur des données factuelles. Nous distinguerons la qualité fonctionnelle en s’appuyant sur une étude dynamique, et la qualité structurelle en effectuant une étude statique.
Ces conclusions seront ensuite mises en parallèle avec les variations environnementales observées au cours de la période d’activité de XeMeLios. Nous pourrons ainsi juger la capacité de l’outil à s’adapter aux variations extérieures. Nous
en déduirons des prévisions afin que la future solution proposée soit la plus pérenne possible.
Enfin, un point d’attention particulier portera sur les contraintes techniques de la plateforme cible. Comme évoqué dans le chapitre 2.1.5, la DGFiP souhaite proposer les fonctionnalités de XeMeLios au travers des applications Web, nous devrons donc nous conformer à une infrastructure matérielle et logicielle cible. Du fait de la sensibilité des données manipulées nous devrons assurer la sécurité et l’intégrité des informations.
2.2.1 Identification des faiblesses de XeMeLios
2.2.1.1 Analyse dynamique
XeMeLios souffre de nombreux défauts ressentis lors de son utilisation. La DGFiP remonte régulièrement des problèmes de performance, de stabilité, de compatibilité, de fuite mémoire… Il n’est pas possible d’étudier l’ensemble des problèmes remontés par les utilisateurs, le temps consacré serait bien trop important compte tenu de la demande initiale. Nous allons uniquement nous intéresser aux problèmes de performances et de consommation mémoire qui constituent de loin le principal malaise vis-à-vis de l’outil.
Pour mettre en évidence ce constat, une étude a été réalisée. Elle consiste en l’application répétée du scénario décrit par la Figure 19.
Figure 19 - Scénario d'analyse dynamique
L’environnement est garanti identique entre chaque répétition par la remise à l’état initial du système (suppression des fichiers, purge de la base de données…).
Suppression des fichiers temporaires Purge de la base de données Lancement de XeMeLios Import du document Collecte des indicateurs
XeMeLios est écrit en Java et s’exécute sur une JVM 1.6. La collecte des indicateurs a été réalisée avec des outils comme MAT ou bien des scripts dédiés à cette tâche.
La machine utilisée est composée d’un processeur Intel I5-4570, de 8Go de RAM et d’un disque dur de 500Go à 7200 T/min. Le système d’exploitation installé est un Windows7 64 bits. Afin d’exclure des facteurs réseaux, toutes les opérations sont réalisées en local.
Indicateur 1 : le temps de traitement
Le temps de traitement nous permet de vérifier le ressenti utilisateur vis-à-vis des problèmes de performances. Cet indicateur nous permet de nous faire une première idée sur la performance globale de l’outil. Une affirmation simple et réaliste, est de supposer qu’il existe une relation de proportionnalité entre volume de données en entrée et temps de traitement. En effet, les opérations effectuées sur le document sont identiques quelle que soit sa taille.
Les résultats obtenus présentés sur la Figure 20 nous révèlent une tendance exponentielle du temps de traitement en fonction du volume de données en entrée. Plusieurs éléments peuvent être à l’origine de ces résultats, comme par exemple un choix inadapté de structure de données (arbre, graphe, liste…), ou encore une sollicitation trop importante de périphériques lents comme le disque dur.
Figure 20 - Analyse dynamique, temps de traitement
4,26 9,48 21,33 48,76 85,33 136,53 213,33 0 50 100 150 200 250 300 5 10 20 40 60 80 100 Temps de traitement (M)
Indicateur 2 : l’utilisation du processeur
Contrairement au temps de traitement précédemment abordé, l’utilisation moyenne du processeur au cours du processus d’import est censée être constante quel que soit le volume de données à traiter. L’algorithme s’appuie sur un automate à états finis pour analyser le document et sur un ensemble d’itérations pour en extraire les informations nécessaires. Afin de bien interpréter les résultats il est important de noter que XeMeLios n’a pas été développé pour exécuter des traitements parallèles.
Monitorer l’utilisation du processeur nous permet de déterminer si ce dernier est exploité à saturation, dans ce cas il pourrait être un facteur limitant, ou bien au contraire, s’il est sous-exploité, ce qui pourrait être expliqué par une mauvaise exploitation des ressources matérielles, de goulots d’étranglements logiciels (tampon sous/sur dimensionné par exemple)…
L’interprétation des résultats de la Figure 21 nous confirme une utilisation faible du processeur aux environs de 16%-17%, il n’est donc pas un facteur limitant de la performance de l’application. Cependant une utilisation plus importante serait préférable et confirmerait une exploitation correcte des ressources physiques de la machine.
Figure 21 - Analyse dynamique, utilisation CPU (moyenne)
16% 15% 18% 15% 17% 16% 16% 0% 5% 10% 15% 20% 25% 5 10 20 40 60 80 100 Utilisation processeur
Indicateur 3 : la consommation mémoire (RAM)
Monitorer la consommation mémoire du processus offre un aperçu sur la bonne ou la mauvaise gestion de cette ressource. En effet, à l’instar du temps de traitement, une consommation proportionnelle au volume de données en entrée est attendue. Des écarts importants à la hausse abonderaient dans le sens d’une mauvaise gestion. Un élément important à prendre en considération est la libération de la mémoire une fois les opérations d’import terminées. Son absence indique une (des) fuite(s) mémoire(s).
Les résultats de la Figure 22 nous indiquent une consommation à tendance exponentielle de la mémoire en fonction du volume de données en entrée. Comme pour les indicateurs précédents, les causes peuvent être multiples. Néanmoins les cas les plus couramment rencontrés sont l’allocation dans des itérations, la portée trop large des variables et les références circulaires.
Figure 22 - Analyse dynamique, consommation mémoire
La collecte de cet indicateur une fois le processus d’import terminé nous confirme une fuite mémoire. En effet la mémoire consommée n’est jamais libérée. La multiplication des imports au sein d’une même instance de XeMeLios produit une saturation et l’arrêt impromptu de l’application.
123 178 236 375 751 1081 1606 2440 0 500 1000 1500 2000 2500 3000 0 5 10 20 40 60 80 100
Consommation mémoire (Mo)
Indicateur 4 : les échanges disque
Le disque dur est un périphérique lent, son utilisation a un impact important sur la fluidité de l’application. Comme pour le monitoring de l’utilisation du processeur, l’analyse des échanges disques nous permet de vérifier que ce dernier n’est pas un facteur limitant dans les performances de XeMeLios.
La Figure 23 nous montre clairement une utilisation intensive du disque dur. Les valeurs avoisinent 100% sans jamais l’atteindre, le reste étant probablement utilisé par des services du système d’exploitation.
Figure 23 - Analyse dynamique, échanges disque
Une analyse plus fine met en évidence la création de nombreux fichiers temporaires alimentés par des données destinées à être réutilisées par le processus d’import. Il est à noter que ces fichiers ne seront pas supprimés une fois le processus terminé et l’application fermée, ce qui conduira à terme à des ralentissements1 plus
importants des accès disque jusqu’à une saturation.
1 La structure d’allocation d’un système de fichier augmente avec le nombre de répertoires et de fichiers stockés. Par conséquent, le parcours de la structure est plus important et les accès en lecture sont plus lents.
89% 96% 93% 98% 88% 94% 90% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 5 10 20 40 60 80 100
Utilisation du disque dur
2.2.1.2 Analyse statique
L’analyse dynamique nous a permis de vérifier le sentiment des utilisateurs vis-à-vis de XeMeLios et d’émettre certaines hypothèses techniques sur l’origine des problèmes. Dans ce chapitre, nous allons découvrir les résultats de l’analyse statique du code. Cette dernière a été réalisée en utilisant des outils automatisés d’analyse de code tels que JDepend ou FindBugs, et d’une revue de code manuelle.
A l’instar de l’analyse dynamique, nous n’allons ici présenter qu’une partie des résultats en nous concentrant sur trois métriques « standards » considérées comme pertinentes :
· lignes de code (LOC),
· complexité cyclomatique de McCabe (CC), · couplage entre objets (CBO).
Pour l’ensemble de ces indicateurs, il est important de noter que les résultats obtenus avec des outils automatisés d’analyse de code sont soumis à une interprétation subjective. En effet, il n’y a pas de consensus établi sur l’interprétation des résultats mais uniquement des valeurs couramment admises comme seuils de référence dans l’univers du développement des logiciels de gestion. Il est alors possible de calculer l’écart entre la valeur obtenue est celle couramment admise.
Pour finir, à partir de la revue de code manuelle, nous aborderons quelques exemples représentatifs de non-qualité mais difficilement identifiables par des outils d’analyse automatisés. Nous aborderons trois problèmes couramment rencontrés dans le code de XeMeLios : les fuites de connexions, la mauvaise gestion des exceptions, et les failles de sécurité.
Indicateur 1 : Lignes de code
Bien que quantitatif, cet indicateur nous permet de porter un jugement qualitatif du code. Toutefois, ce jugement est à interpréter avec précaution du fait du nombre important de facteurs influençant la valeur finale de la mesure. Afin d’atténuer l’impact du « style » du développeur, cette analyse a été réalisée de manière logique, c’est-à-dire que la mesure est faite sur « une canonisation » du code qui ne tient pas compte des sauts de lignes physiques non-exécutées (déclaration des blocs, commentaires…).
Pour offrir une vision globale de cet indicateur, la valeur moyenne de l’ensemble des résultats a été calculée pour chaque fichier, classe et méthode du projet. Le Tableau IV présente une synthèse des résultats obtenus.
Tableau IV - Analyse statique, lignes de code
Entité analysée LOC moyen Seuil de référence Ratio1
Fichier 1320 800 165%
Classe 1080 600 180%
Méthode 282 100 282%
Le premier constat que nous pouvons faire de ces résultats est bien évidemment le dépassement du plafond pour les trois entités analysées.
Le second est le ratio qui est relativement proche pour l’analyse sur fichier et sur classe, mais qui est très élevé dans le cas des méthodes. Une interprétation possible serait que les classes de XeMeLios sont constituées de méthodes importantes mais peu nombreuses.
Cette interprétation a été confirmée par l’analyse du nombre d’objets par entité étudiée présenté sur le Tableau V. En moyenne, les classes de XeMeLios sont composées de 4,52 méthodes.
Tableau V - Analyse statique, lignes de code, nombre d'objets par entité
Moyenne
Fichiers / module 173.07
Classes / fichier 1.23
Méthodes / classe 4.52
Indicateur 2 : Complexité cyclomatique de McCabe
La complexité cyclomatique (de McCabe) se mesure en comptant le nombre d’instructions impactant le plan d’exécution d’une méthode (if, while, for, switch…). Le nombre obtenu représente le nombre de chemins d’exécution possibles d’une méthode (Figure 24). Plus cette valeur est élevée, plus la méthode est jugée complexe et difficile à comprendre.
Figure 24 - Analyse statique, complexité cyclomatique
Dans le cadre de cette étude, la valeur étudiée est la complexité cyclomatique moyenne calculée sur l’ensemble des méthodes présentes dans XeMeLios. Le résultat obtenu est une complexité moyenne de 9,2. Il est généralement admis que cette valeur devrait être inférieure à 10, représentant une méthode à forte complexité. Ce que nous pouvons déduire de ce résultat est que les méthodes de XeMeLios sont complexes, avec un nombre de chemins possibles élevé.
Ce résultat vient corroborer l’interprétation du premier indicateur, le nombre de lignes de code. En effet, un découpage plus fin de l’application aurait entraîné la baisse de ces deux indicateurs.
Indicateur 3 : Couplage entre objets
Le couplage indique le niveau d’interaction entre deux ou plusieurs composants. Il s’établit à différents niveaux, de la méthode à l’application en passant par l’objet et le module. Nous nous intéresserons ici au couplage entre objet, c’est-à-dire à la conception objet de l’application, et non au couplage entre modules résultant du découpage vertical de l’application.
Un couplage fort, c’est-à-dire un ensemble de composants présentant un nombre important d’adhérences entre eux, est un signe de non-qualité. La conséquence directe est la production de code spaghetti1 qui entrainera une
maintenabilité, une réutilisabilité et une extensibilité difficiles et coûteuses.
Le calcul du couplage est relativement simple, il suffit de référencer au sein d’une classe les types rencontrés dans les attributs, les paramètres, les variables… l’héritage en faisant partie. Plus cette valeur est importante et plus le couplage est élevé. Cependant il est important de noter que les objets étudiés sont uniquement ceux concernés par le projet, les classes de la JVM sont par exemple exclues. Le Tableau VI représente les résultats obtenus et les compare à une valeur de référence :
Tableau VI - Analyse statique, couplage entre objets
CBO XeMeLios Seuil de référence Ratio
Minimum 0 0 0%
Maximum 77 20 385%
Moyen 58 10 580%
Les résultats ne laissent aucun doute sur la gestion des dépendances dans XeMeLios. Le couplage est très important, le risque de modifications en chaîne sur l’ensemble de l’application est présent (code spaghetti) et le risque de régression est élevé. Depuis plusieurs années, la DGFiP et les développeurs intervenant sur XeMeLios ont remarqué que le temps consacré à la maintenance suivait une tendance exponentielle. Ce constat est une des conséquences d’un couplage fort en l’absence de refactoring permanent.
1 Code résultant d’une conception favorisant les dépendances voir les interdépendances entre les objets
Exemple 1 : Fuite de connexion
Une fuite de connexion se produit lorsqu’une application obtient une connexion et ne la libère pas. La saturation de la base de données ou d’un pool de connexions éventuel constituent le risque principal, entrainant en général le dysfonctionnement de l’application. Le code de la Figure 25 met en évidence une possible fuite de connexion (les lignes superflues ont été supprimées).
Figure 25 - Analyse statique, fuite de connexion
En effet, la connexion récupérée depuis le pool est stockée dans un attribut, elle n’est jamais libérée. La durée de vie de la connexion est au minimum identique à la durée de vie de l’objet qui la référence. La saturation du pool entraînera dans un premier temps un ralentissement de l’application, et pourra se terminer par un inter blocage rendant l’application inutilisable. En règle générale, il est nécessaire dans un premier temps de s’assurer de la libération explicite des ressources, et dans un deuxième temps de limiter la portée des variables.
Sur cet exemple nous pouvons également faire une remarque sur le nommage des objets. Les noms donnés ne permettent pas d’identifier rapidement le type et l’utilisation des variables. Il est important de définir une convention de nommage connue et respectée par l’ensemble des intervenants du projet.
Exemple 2 : Mauvaise gestion des exceptions
La gestion des exceptions conduit à s’interroger sur le composant le plus apte à gérer l’exception levée. En effet, le premier appelant n’est pas forcément le meilleur candidat pour traiter cet évènement et laisser remonter l’exception est souvent la solution. Par conséquent, il ne suffit pas d’intercepter l’erreur et de l’ignorer. Ce comportement conduit à des effets de bord difficiles à identifier et à corriger.
Dans l’exemple présenté par la Figure 26, les exceptions éventuellement remontées sont ignorées, le bloc catch destiné à traiter l’erreur est vide.
Figure 26 - Analyse statique, "catch" vide
Ce problème se retrouve à de nombreux emplacements dans le code, notamment sur des fonctionnalités sensibles comme l’import des données. Dans ce cas, une conséquence peut être un problème d’intégrité de données, fait qui a déjà été de nombreuses fois relevé par la DGFiP.
De plus, il est courant de trouver des interceptions sur Throwable. Ceci est une mauvaise pratique du fait du risque de capturer les erreurs de la JVM (une saturation mémoire par exemple) et d’empêcher l’arrêt de l’application qui continuera de s’exécuter dans un état instable.
Exemple 3 : Faille de sécurité
La sécurité informatique est un des piliers majeurs dans le développement logiciel. La nature du projet et la sensibilité des données manipulées sont des critères à prendre en compte pour établir la criticité du logiciel. En effet, un petit jeu pour
smartphone ne répond pas aux mêmes besoins en termes de sécurité que l’application de saisie des impôts.
Les données manipulées par les utilisateurs de XeMeLios sont qualifiées de très sensibles du point de vue de leur intégrité, et moyennement sensibles sur le plan consultatif (les comptes de gestion des collectivités sont publics). Cependant, les utilisateurs sont rattachés à un périmètre de consultation (géographique, par entité…) et il n’est pas concevable de pouvoir accéder à un périmètre sur lequel les autorisations nécessaires ne sont pas satisfaites.
L’exemple présenté ci-dessous met en évidence une faille de sécurité de type SQL Injection. Les données d’entrée ne sont pas vérifiées et sont insérées en l’état dans la requête, ce qui permet à un individu mal intentionné de modifier le champ d’application de la requête. Cette requête récupère un ensemble de dépôts pour une collectivité:
Figure 27 - Analyse statique, SQLInjection
Dans ce cas il est aisé de transformer la requête et de récupérer l’ensemble des dépôts, il suffit de donner la valeur toto' OR '1' = '1 à la variable idColl. La requête finalement exécutée sera :
SELECT * FROM IX_CG_REPOSITORY WHERE IDCOLL = 'toto' OR '1' = '1' L’introduction de la tautologie aura pour effet de ramener l’ensemble des dépôts sans aucune restriction. Cet exemple a été volontairement retenu car la fonctionnalité impactée n’est pas critique pour l’application. D’autres cas ont été détectés mais ils ne seront bien évidemment pas détaillés.
2.2.1.3 Le support de plusieurs SGBD
Dans sa version actuelle, XeMeLios supporte les bases de données Oracle et MySQL. L’abstraction du support de persistance est loin d’être suffisant. En effet, la définition s’appuie sur l’écriture de code SQL, ce qui entraine une dépendance entre la définition et le dialecte cible du SGBD. Par conséquent, l’adaptation d’une nouvelle
