RAPPORT DE STAGE -...

RAPPORT de STAGE :Projet Farandole

StagiaireMathieu Changeat

ISTY

IBM FranceSous le tutorat de M. Matiachoff

D I R E C T I O N D U B U D G E T

Projet FARANDOLE

Table des Matières

1INTRODUCTION.................................................................................................................................................3

2PRÉSENTATION D’IBM....................................................................................................................................4

2.1INTRODUCTION.....................................................................................................................................................42.2HISTORIQUE........................................................................................................................................................42.3IBM CORPORATION.............................................................................................................................................42.4IBM FRANCE.....................................................................................................................................................52.5STRUCTURES.......................................................................................................................................................5

2.5.1IBM Global Services...............................................................................................................................62.5.2IBM Business Consulting Services..........................................................................................................62.5.3Application Innovation Services.............................................................................................................6

3FARANDOLE........................................................................................................................................................8

3.1CONTEXTE..........................................................................................................................................................83.1.1Le client...................................................................................................................................................83.1.2La loi organique relative aux lois de finances .......................................................................................93.1.3Objectif des prestations.........................................................................................................................113.1.4L’architecture fonctionnelle attendue...................................................................................................11

3.2LE PROJET.........................................................................................................................................................133.2.1L’équipe.................................................................................................................................................133.2.2Planning................................................................................................................................................133.2.3Architecture applicative........................................................................................................................143.2.4Nomenclatures.......................................................................................................................................173.2.5L’application.........................................................................................................................................17

3.2.5.1Moteur d’instanciation.....................................................................................................................................173.2.5.2Moteur de navigation.......................................................................................................................................173.2.5.3Moteur de saisie...............................................................................................................................................173.2.5.4Moteur de production.......................................................................................................................................183.2.5.5Contrôleur........................................................................................................................................................183.2.5.6Base de Données / Persistance.........................................................................................................................183.2.5.7Authentification / Habilitations / Workflow....................................................................................................18

4LE STAGE...........................................................................................................................................................19

4.1ENVIRONNEMENT MATÉRIEL ET TECHNOLOGIQUE.....................................................................................................194.2MISSION...........................................................................................................................................................204.3TRAVAUX.........................................................................................................................................................20

4.3.1Les contrôles de cohérence des nomenclatures d’exécution.................................................................204.3.2L’aide en ligne.......................................................................................................................................254.3.3Les mouvements de crédits....................................................................................................................274.3.4Autres travaux.......................................................................................................................................31

4.4DÉROULEMENT DU PROJET...................................................................................................................................324.4.1Gestion des ressources..........................................................................................................................324.4.2Rapports et réunions.............................................................................................................................334.4.3Planning................................................................................................................................................354.4.4Transferts de compétences....................................................................................................................37

5BILAN..................................................................................................................................................................38

Document : Rapport_de_Stage_Mathieu_Changeat_08-09-2005_v0.3.doc Date : 02/10/2005Version : 1.0Auteur : Mathieu Changeat Page : 2/39


Projet FARANDOLE

1 Introduction

Dans le cadre de la formation ingénieur de l’ISTY, j’ai effectué mon stage de fin d’étude à La

Défense-Courbevoie, chez IBM France au sein de la division Business Consulting Services.

Le stage de 6 mois, d’avril à octobre 2005, s’est effectué au sein de l’équipe de développement

de l’application Farandole, sous le tutorat de M. Christophe Matiachoff.

La présentation de l’entreprise où s’est déroulé le stage sera suivie d’une description du projet.

Nous décrirons l'environnement mis à disposition sur le projet. Puis nous développerons la mission et

les travaux confiés au stagiaire pour la durée du stage. Ensuite, nous verrons comment se déroulait le

projet. Enfin nous finirons par un bilan.



Projet FARANDOLE

2 Présentation d’IBM

2.1 Introduction

IBM, leader mondial des technologies de l'information, a pour mission de concevoir, produire

et commercialiser des matériels, des logiciels, des technologies et des services qui s'intègrent dans des

solutions informatiques globales adaptées à la demande de chacun des clients, afin de leur procurer un

avantage compétitif réel et un positionnement privilégié dans le domaine de l'e-Business.

Au travers de son réseau mondial de professionnels en services et solutions, IBM transforme

ces technologies avancées en valeur ajoutée au bénéfice des entreprises, quelle que soit leur taille.

2.2 Historique

Le 15 juin 1911, la Computing Tabulating Recording Company (CTR) naît aux Etats-Unis, à

Endicott dans l'Etat de New York, de la fusion de plusieurs sociétés qui produisent des balances,

calculatrices, machines électro-comptables...

En 1914, celle-ci s’installe en France et prendra en 1948, comme la CTR en 1924, le nom

d’IBM (International Business Machines), devenant ainsi IBM France.

2.3 IBM Corporation

International Business Machines Corporation, dont le siège se trouve à Armonk, dans l’Etat

de New York, est la plus grande entreprise mondiale de technologies de l'information.

En 2004, IBM était le numéro un mondial, en termes de chiffre d’affaires pour :

• les services informatiques : 46 milliards de $;



Projet FARANDOLE

• le matériel : 31 milliards de $;

• la location et le financement d'équipements informatiques : 3 milliards de $.

60% des revenus de la compagnie sont obtenus en dehors des Etats-Unis.

IBM emploie quelque 329000 personnes et opère dans environ 170 pays et a réalisé en 2004 un

chiffre d'affaires global de 96 milliards de dollars.

2.4 IBM France

La société IBM est implantée en France depuis 1914. Françoise Gri en est actuellement le

Président Directeur Général. IBM emploie à l’heure actuelle 12700 personnes dont 7200 dans des

activités de service.

Le groupe IBM France est constitué d’IBM France et de ses filiales : Altis Semiconductor,

Anelia, HR T&M, IFF (IBM France Finance), LGS, Montics, MDTVision, SDDC, Sysmedia. Le

siège d’IBM France, ainsi que celui d’IBM Europe, Moyen-Orient et Afrique est basé à Paris - La

Défense.

Quelques chiffres :

• Chiffre d'affaire consolidé du groupe IBM France : 3,99 milliards d'euros

• Chiffre d'affaires intérieur : 3,41 milliards d'euros

• Chiffre d'affaires export : 582 millions d'euros

• Effectifs : 12700 personnes.

2.5 Structures

Les informations qui suivent concernent uniquement la hiérarchie de services dans laquelle le

stagiaire a officié.



Projet FARANDOLE

2.5.1 IBM Global Services

IBM Global Services a réalisé un CA de près de 46 milliards de dollars en 2004. IBM Global

Services est le moteur de la croissance d’IBM.

IBM Global Services propose une gamme complète de services. En alliant maîtrise des

dernières innovations technologiques et expertise métier, IBM Global Services aide les entreprises

dans la conception, la mise en oeuvre de solutions e-business dans les délais les plus courts et

l’industrialisation de leurs processus en utilisant leur système d’information comme levier stratégique.

2.5.2 IBM Business Consulting Services

L’entité IBM Business Consulting Services est née de la fusion en 2002 de

PricewaterhouseCoopers Consulting et de la division Business Integrated Services d’IBM Global

Services.

Business Consulting Services est la plus grande organisation de conseil au monde, avec plus

de 60 000 professionnels intervenant dans 160 pays. BCS intervient de la stratégie jusqu’à la

conception et la mise en oeuvre de solutions complètes et intégrées. Les équipes IBM Business

Consulting Services aident les entreprises à créer de nouveaux modèles, à transformer leurs processus

et à les mettre en application pour accéder à un mode de fonctionnement à la demande. En fonction

des problématiques métiers spécifiques des clients, BCS travaille à l’élaboration du plan d’exécution

le plus efficace et à la solution technologique la mieux adaptée à leur besoin.

Du lancement de la démarche à la maintenance de solutions en passant par l’organisation, la

conception, le déploiement et les phases de recette, BCS accompagne ses clients tout au long de leur

projet.

En France, IBM Business Consulting Services regroupe aujourd’hui 3 000 consultants,

directeurs de projets, experts techniques, architectes et développeurs qui accompagnent les entreprises

dans la conception et la mise en œuvre d’un système d’information performant et novateur capable de

leur procurer des avantages compétitifs.

2.5.3 Application Innovation Services



Projet FARANDOLE

AIS est la structure au sein de BCS chargée des nouvelles technologies. A ce titre, sa mission

est d’aider les clients et les autres entités d’IBM à réussir la mise en œuvre de nouvelles technologies,

en fournissant des solutions de bout en bout : évaluation des besoins, design de la solution,

planification, implémentation et opérations.



Projet FARANDOLE

3 Farandole

Au sein d’AIS j’ai travaillé sur l’application Farandole. Farandole a pour objectif principal la

production automatique de documents budgétaires de l’Etat Français (aux formats DOC, RTF et

PDF). Les documents budgétaires présentent des données chiffrées et textuelles saisies dans les

ministères à l’aide d’une interface WEB. Ces données sont stockées en base.

3.1 Contexte

3.1.1 Le client

La Direction du Budget du Ministère des Finances joue un rôle essentiel de conception et

d’exécution dans le pilotage des finances publiques. A ce titre, la direction est naturellement chargée

de la préparation du projet de loi de finances.

La loi organique relative aux lois de finances (LOLF) n°2001-692 du 1er août 2001 transforme

en profondeur les lois de finances, la direction du Budget joue un rôle central dans le pilotage de cette

réforme majeure.

Elle se doit notamment de mettre en oeuvre avec ses partenaires (ministères, parlement) le

contenu des projets de loi de finances et de leurs annexes.

La LOLF vise à moderniser la gestion publique et à renouveler la nature et les outils du

contrôle parlementaire, en confiant aux gestionnaires publics davantage de liberté en contrepartie

d'une plus grande responsabilité.

Son principal objectif est de passer d'une culture de moyens et d'une responsabilité de

conformité, à une culture et une responsabilité de performance. La gestion publique sera donc

orientée vers les résultats et la recherche de l'efficacité, tandis que la transparence des informations

budgétaires et la portée de l'autorisation parlementaire sont renforcées.

La loi organique impose que le projet de loi de finances 2006, préparé durant l’été 2005 soit

conforme à celle-ci.



Projet FARANDOLE

De ce fait, la direction doit complètement refondre l’ensemble de son système de production

des documents budgétaires. Ce système concourt à la préparation budgétaire de l’Etat et réfère

l’ensemble des données de prévision débouchant sur la loi de finances initiale (LFI) permettant

l’initialisation des systèmes de gestion de la dépense.

3.1.2 La loi organique relative aux lois de finances

Cette loi est le cœur du projet Farandole. Dans le but d’éclaircir quelque peu les propos

techniques tenus dans la suite du document, il est nécessaire de comprendre quelles sont les grandes

lignes de cette loi.

La LOLF est née de limitations de la précédente loi datant de 1959. En effet, les conditions de

discussion des lois de finances étaient largement insatisfaisantes, dans la mesure où le Parlement ne

disposait pas d'une connaissance précise du coût des politiques publiques ou du nombre d'emplois

dans la fonction publique. Aujourd'hui, le budget de l'État est voté par titre (au nombre de 7 :

dotations des pouvoirs publics, dépenses de personnel, dépenses de fonctionnement, charges de la

dette de l’Etat, dépenses d’investissement, dépenses d’intervention, dépenses d’opérations

financières) et spécialisé par chapitres (dont le nombre atteint les 850). Le Parlement vote ainsi de

manière très détaillée les moyens alloués aux différents ministères, sans que ces moyens soient mis en

relation avec des objectifs et des résultats déterminés.

D'autre part, la gestion du budget de l'État était très déficiente : elle ne comportait aucune

incitation à l'économie et à l'efficacité de la dépense. Par ailleurs, les gestionnaires de crédits publics

sont soumis à des règles très strictes d'emploi des deniers publics, qui nuisent à l'efficacité de la

dépense.

En résumé, la loi organique

• modifie en profondeur les règles de présentation et de vote des lois de finances

• renforce les moyens d'information et de contrôle du Parlement sur les finances publiques

• et améliore la lisibilité de la comptabilité de l'État.

Les crédits seront spécialisés par dotation ou programmes (dont le nombre est de 150

environ). Ces derniers regrouperont les crédits destinés à mettre en oeuvre une action ou un ensemble

cohérent d'actions relevant d'un même ministère et auquel sont associés des objectifs précis, définis en



Projet FARANDOLE

fonction de finalités d'intérêt général, ainsi que des résultats attendus et faisant l'objet d'une

évaluation. Au sein d'un programme, les crédits seront déployés entre les titres budgétaires, à

l'exception des crédits de personnel qui ne pourront être majorés par des crédits en provenance d'un

autre titre, et ce, afin d'éviter une augmentation des dépenses de personnel, engageant l'État pour

plusieurs décennies.

Les programmes sont regroupés par « missions ». Celles-ci comprennent un ensemble de

programmes concourant à une politique publique définie relevant d'un ou plusieurs services d'un ou

plusieurs ministères. Dans un premier temps, et en vue d’une adaptation à cette nouvelle loi, chaque

ministère n’a qu’une seule mission, dont chacun des programmes ne concerne que lui. Cependant par

la suite, des missions pourront regrouper plusieurs programmes attribués à plusieurs ministères de

sorte à améliorer les coopérations entre les diverses actions de l’État. Par exemple, une mission

pourrait très bien regrouper des programmes concernant les ministères de la Justice, et celui de

l’Intérieur pour mener une action collective contre la délinquance.

Lors de la présentation d'un projet de loi de finances, chaque programme devra être

accompagné d'un projet annuel de performance comportant notamment la présentation des actions,

des coûts associés, des objectifs poursuivis, des résultats obtenus et attendus pour les années à venir

mesurés au moyen d'indicateurs précis dont le choix est justifié.

Les comptes de l'État, devront donner une image fidèle de son patrimoine et de sa situation

financière.

Par ailleurs, le Parlement sera plus étroitement associé à l'exécution du budget, par le biais de

procédures d'information ou d'avis concernant les mouvements réglementaires de crédits intervenant

en cours d'année.

Enfin, les pouvoirs de contrôle des Commissions des finances des deux assemblées seront

accrus, et le droit d'amendement sera élargi, puisqu'un parlementaire pourra modifier, au sein d'une

mission, la répartition des crédits entre plusieurs programmes.



Projet FARANDOLE

3.1.3 Objectif des prestations

La direction du Budget a entrepris dans le cadre de la mise en œuvre de la loi organique

relative aux lois de finances d’août 2001, la définition et la réalisation des nouvelles applications de

production budgétaire.

La prestation demandée consiste à réaliser pour la direction du Budget (maître d’ouvrage),

l’ensemble des applications nécessaires à la production des documents budgétaires adapté à la loi

organique d’août 2001. Il a été décidé de procéder en deux étapes principales :

• La réalisation d’une application évolutive spécifique qui sera utilisée dès l’année 2005.

• L’évolution de l’application spécifique se fera par ajout de fonctionnalités et d’interfaces de

type EAI.

3.1.4 L’architecture fonctionnelle attendue

Les fonctions attendues du système comprennent 4 volets :

• Une application workflow qui gère les statuts et les états du suivi des processus de production

des documents budgétaires.

• Une application « Traitement » qui est composée des fonctions suivantes :

o Saisie / interfaçage

o Stockage

o Agrégation.

• Une application « Editique » qui permet la réalisation de documents avec des tableaux

complexes, ainsi que des graphiques. Cette application est destinée à perdurer quelque soient

les évolutions futures.

• Une application référentiel nomenclature qui est basée selon un principe de méta-

nomenclature.



Projet FARANDOLE

Ci-dessous le schéma de l’architecture fonctionnelle.


Dessin 1 : Architecture fonctionnelle

Ministères

Workflow

ApplicationTraitementDépenses prévisionnelles

Application Editique

Nomenclatures

Recettes prévisionnelles

Exécution (N-1; N-2)

BDD interne

1

2 3

par destination

4

recettes

emplois

Direction du Budget


Projet FARANDOLE

3.2 Le projet

3.2.1 L’équipe

3.2.2 Planning

Le marché est passé pour une durée qui n'excédera pas 36 mois à compter de sa date de

notification effectuée le 5 décembre 2003. La prestation se décompose en tranches fermes (1) et

conditionnelles (5) ayant pour objet la fourniture des travaux.

Le stage s’est déroulé dans la 2ème tranche, dont la réalisation a débutée en janvier 2005. La

première tranche, quant à elle, est en production depuis avril 2005.


Dessin 2 : Organigramme de l'équipe

Christophe MatiachoffManager Opérationnel

Benoît GloanecArchitecte Fonctionnel Equipe de Développement :

Ahmed Arbaoui Corinne Blanchard Eric Bonnet Cécile Pham Denis Duault, Vincent Huynen Jean Helou Thierry Sitbon Emilie Habermacher et moi-même.

Stéphane MacéChef de Projet Junior


Projet FARANDOLE

3.2.3 Architecture applicative

Farandole est une application J2EE constituée de :

• un Poste Client

Il accueille le navigateur. Vu du poste client, l’application Farandole est une suite de pages HTML

(client léger), reposant sur des feuilles de style CSS et intégrant pour les comportements dynamiques

du Javascript (contrôles locaux, gestion des arborescences).

• un Serveur HTTP

Le serveur HTTP est un logiciel permettant de rendre accessibles à de nombreux ordinateurs (les

clients) des pages stockées sur le disque ou bien construites dynamiquement via le Serveur

d’Applications.

• un Serveur d’Applications

Le Serveur d’Applications est un logiciel accueillant un ensemble de programmes Java dédiés à la

production de réponses à certaines requêtes HTTP et s’interfaçant à la plupart des services du système

d’information (accès aux bases de données, invocation de Services Web).

• un Serveur d’Authentification

L’authentification est le mécanisme qui permet d’identifier l’utilisateur et de récupérer les

informations le concernant permettant de vérifier ses droits d’accès.

• un Serveur de Données

Le Serveur de Données représente la mémoire des données de l’application. Trois bases de données

logiques sont utilisées : une base pour la préparation du budget de l’année suivante, un base pour les

modifications du budget de l’année en cours et une base pour accéder à l’année précédente.



Projet FARANDOLE

• un Serveur Editique

Il consiste à produire un document complet (en sous-traitance).

Le schéma ci-dessous présente une vue globale de l’architecture applicative. Y sont

représentés les principaux composants et leurs relations.



Projet FARANDOLE

Serveur d’Applications J2EETomcat

UploadDownloadServlet

Session(Hibernate)

Log4JXercesXalanJavaMail

Services Web(Axis)

Persistance

Habilitation

Configuration(Hibernate)

Routage Import

Actionsgénériques

(Action Struts)

Actionsspécifiques

(Action Struts)

Interprète deNomenclature

JSPTagLib

Transformer

ObjetsMétiers

Poste ClientServeurHTTPApache

HTTPHTTPS

Navigateur

HTMLCSS

JavaScript

ActiveX

HTTPHTTPS

Serveurd’authentification

LDAP

Serveur Editique

ConvertisseurRTF -> EDI

RéférentielEDI

Assemblage

Composition

ServicesWebRoutage

JavaMail

struts-config.xml

hibernate.properties

XMLMapping

ActionServlet(Struts)

Documentsbudgétaires

Systèmesexternes

SOAP

NomenclatureXML

Modèles dedocuments

SOAP

Serveur de données

BaseBleue

BaseBlanche

BaseRouge

SGBD Oracle

JDBC

A

Légende

B Le composant A appelle (directement ou non) le composant B. Le retour d’une valeur est implicite.

D A Le composant A reçoit le document D en entrée.

D A Le composant A produit le document D.

Logiciel Microsoft Word.

JavaMail Outil ou API Java.

Feuilles destyle XSL

FichiersXML



Projet FARANDOLE

3.2.4 Nomenclatures

Le projet est construit sur la technologie XML et est complètement générique ; en effet en

modifiant un des fichiers XML (en respectant le XML-Schéma) pour répondre à une nouvelle attente,

l’application s’adaptera automatiquement.

Les nomenclatures sont des descriptions XML - conforme à une grammaire XSD – qui

précisent les données en base à visualiser sur le poste client, leurs conditions de saisie, et les fonctions

qui leur sont applicables, ou la structure des documents budgétaires à produire.

Les nomenclatures sont le cœur de l’application à produire, puisqu’elles servent de modèles

au parcours des données et aux documents manipulés.

3.2.5 L’application

L’application est structurée en modules.

3.2.5.1 Moteur d’instanciation

L’objectif du moteur d’instanciation est de créer un arbre à partir d’une nomenclature donnée.

Il doit charger depuis la base les enregistrements, les assembler et les enrichir (calcul) suivant la

description de la nomenclature.

3.2.5.2 Moteur de navigation

Le moteur de navigation prépare - à l’aide de l’arbre auparavant instancié - le flux XML de

navigation qui s’affichera sur le poste client après transformation XSLT. Il gère toute la navigation

dans le site (hormis les fonctions de service au démarrage). Il permet de fait d’accéder aux autres

pages gérées par les autres moteurs.

3.2.5.3 Moteur de saisie

Le moteur de saisie s’occupe des pages proposant la saisie d’informations.



Projet FARANDOLE

Il récupère ensuite ces données qu’il manipule pour les rendre compréhensibles (généricité

oblige) pour la base de donnée. Il s’occupe d’accéder à la persistance afin de sauvegarder les données

en base.

3.2.5.4 Moteur de production

Le moteur de production est l’élément terminal de l’application, c’est à l’issue de ce module

que sont créés les documents.

3.2.5.5 Contrôleur

Le contrôleur gère tous les échanges entre les différents moteurs, il est, avec le moteur

d’instanciation, le point central de l’application.

3.2.5.6 Base de Données / Persistance

Ces deux modules fonctionnent de concert pour rendre transparent tous les fonctionnements

de la base de donnée, que se soit la manipulation de données ou la récupération de données via des

requêtes SQL. En effet, un framework de persistance d’objets pour Java (Hibernate) est utilisé pour

s’interfacer avec la base de données.

3.2.5.7 Authentification / Habilitations / Workflow

La partie Authentification est un module permettant de récupérer des informations présentes sur

un serveur de type LDAP (ici un serveur Active Directory supportant les requêtes LDAP).

Ces informations sont traitées dans la partie Habilitation afin d’obtenir les actions autorisées à

l’utilisateur qui vient de se connecter suivant ses droits d’accès aux données en base.

Le Workflow gère les statuts et les états du suivi des processus de production des documents

budgétaires.



Projet FARANDOLE

4 Le stage

4.1 Environnement matériel et technologique

Les machines mises à disposition du stagiaire pendant le stage est la suivante :

• IBM ThinkPad T23 (PIII 1.13 MHz 1Go RAM) avec Windows XP.

Tous les développements seront réalisés via Eclipse.

L'archivage des sources s'effectue avec CVS, et les divers documents internes et externes sont

déposés sur un serveur Lotus. Les principales fonctionnalités de ce serveur d’archivage sont :

l'échange de documents, l'agenda commun des meetings du projet, la liste des contacts etc.

Le projet Farandole fait appel à plusieurs technologies.

• Oracle, pour la base de données ;

• Le framework Java Hibernate pour la persistance ;

• Apache pour le serveur http ;

• Tomcat pour le conteneur de servlets ;

• Struts pour la gestion des JSP et des Servlets ;

• Axis pour les Web Services.

L’ensemble du projet est basé sur la technologie XML et nous utilisons deux types de parseurs :

JAX-B, pour la partie instanciation de l’arbre, et Betwixt dans la partie production des documents

budgétaires. Les transformations XSL de flux XML vers des pages HTML sont réalisées à l’aide de

Xalan.

La partie permettant la saisie de nouveaux textes a été réalisée par un prestataire sous forme

d’un ActiveX pilotant MS Word.

La partie Authentification (login - mot de passe) est réalisée grâce à la technologie Microsoft

Active Directory. Cette technologie n’est pas à proprement parler un annuaire LDAP (elle n’en

respecte pas les spécifications) mais supporte cependant les requêtes de ce type. Et c’est via cet

intermédiaire que nous le consultons (API du JDK Jaas).



Projet FARANDOLE

Pour les tests unitaires (tests des classes, tests des méthodes …) c’est l’API JUnit qui a été

choisie.

Un logiciel de gestion des anomalies Mantis est mis à disposition sur Internet, il permet aux

développeurs et à la Direction du Budget de répertorier les anomalies rencontrées et de suivrent leur

évolution.

4.2 Mission

Mon travail a consisté en plusieurs tâches. En effet, j’ai été affecté à un projet qui avait déjà

plus d’un an d’existence. Mon arrivée correspondait aux lots 2 et 3 de la deuxième tranche et début de

troisième. J’ai donc été confronté à deux problématiques :

• Comprendre l’architecture générale de l’application, en lisant la documentation produite

ainsi qu’en la testant, afin de pouvoir développer les parties manquantes du lot 2.

• Concevoir et participer à la conception de la partie technique des spécifications fournies

par l’architecte du projet pour le lot 3.

4.3 Travaux

4.3.1 Les contrôles de cohérence des nomenclatures d’exécution

La première tâche que j’ai eu à accomplir consistait à effectuer des contrôles de cohérence.

Ce chantier venait en complément du travail d’un des membres de l’équipe, Vincent Huynen.

Afin de comprendre l’intérêt du contrôle de cohérence, il faut savoir que le budget général de

l’Etat est divisé en trois grands types de montants : les dépenses, les équivalents temps plein et les

recettes.

Le contrôle de cohérence ne concernant que les dépenses, nous ne détaillerons pas les deux

autres montants.

Les dépenses sont organisées suivant deux axes qui forment une « matrice ».



Projet FARANDOLE

L’axe principal est celui de la « destination ». Les missions se décomposent en programmes,

eux-mêmes découpés en actions, voire sous actions. Cet axe représente ce que l’on cherche à faire. On

y attache des objectifs et des indicateurs (Plan Annuel de Performance), et la justification des crédits

demandés se fait principalement par rapport à cet axe (Justification au Premier Euro).

Le deuxième axe est celui de la « nature » des dépenses. La LOLF structure cet axe suivant

une organisation en terme de Titres et Catégories. Cette vision est de nature plus « comptable », et

différentie les dépenses de personnel, d’investissement, de fonctionnement, d’intervention, …

Chaque « cellule » de dépense est donc attachée à une destination (Mission, Programme,

Action) et à une nature (Titre ou Catégorie).

Dans les faits, les crédits sont alloués au niveau le plus fin : Action (ou sous action) –

Catégorie. Les agrégations successives suivant les deux axes permettent de calculer des montants plus

synthétiques.

Ceci représente donc une partie de ce que définit la loi de finances votée chaque année. Ce

sont les prévisions de budgets pour l’année suivante. Ce travail correspond à la tranche 1 du projet.

L’année suivante, les montants réellement dépensés sont saisis à leur tour et comparés à ceux

qui étaient prévus. Dans un but de facilité et lisibilité comptable, les nomenclatures d’exécution ont

été introduites, pour mettre en relation les prévisions et les dépenses réelles.

On peut trouver dès les programmes des nomenclatures d’exécutions. Ces dernières

permettent d'affiner la décomposition mission / programme / action / sous action afin de ventiler la

dépense selon le plan comptable.



Projet FARANDOLE

Les schémas suivant illustrent cette arborescence :

Arborescence des missions et programmes 1

Arborescences sous un programme 1



Projet FARANDOLE

Cette arborescence est saisie via l’application Farandole. Chaque nœud possède ses propres

attributs, allant du libellé à des codes d’articles... Il est également précisé si le nœud mettra en œuvre

des moyens ou humains ou matériels uniquement ou les deux à la fois.

Des erreurs peuvent néanmoins apparaître lors de cette saisie. Par exemple, si un nœud non

feuille indique qu’il ne met en œuvre que des moyens de personnel, tous ses fils doivent également

mettre en œuvre uniquement des moyens de personnel.

Tous les contrôles à effectuer ont été définis par le Ministère des Finances. Certains sont

effectués dès la saisie, notamment ceux qui peuvent être corrigés sans changer d’écran, d’autres ne

sont testés que lors d’un contrôle de cohérence global.

Ce dernier balaie tous l’arbre et se charge d’effectuer tous les contrôles, même ceux qui ont

été effectués lors de la saisie, et génère à la fin un rapport détaillant toutes les erreurs qu’il a

détectées. Certains des contrôles doivent vérifier la cohérence d’attributs intergénérationnels (comme

l’exemple des moyens de personnels que nous avons décrit).

Dans des buts de performance, le contrôle de cohérence global parcourt l’arbre une seule fois

et se charge d’effectuer tous les tests sur cet unique passage. La présentation des messages produits

est une hiérarchie qui suit la même arborescence, en n’affichant que les chemins erronés, de sorte que

l’erreur soit facilement localisée pour la correction.



Projet FARANDOLE

Voici une illustration du résultat du contrôle de cohérence :

Illustration 1 : Compte rendu d'un contrôle de cohérence

Ces contrôles de cohérence sont particulièrement utiles dans un cas précis d’utilisation de

l’application. En effet, lorsque la nomenclature d’exécution d’un programme est entièrement saisie et

sans erreur, pour lui apporter des modifications, la procédure mise en place au ministère ne permet

pas que celle-ci s’effectue immédiatement sur l’arborescence. Il est nécessaire de créer des

bordereaux, qui permettent la modification de certains attributs des nœuds, sans pour autant affecter

les informations contenues par ces derniers. Dans la mesure où ces modifications par bordereaux

peuvent affecter plusieurs nœuds, il devient rapidement difficile d’estimer si les modifications

n’entraînent pas de nouvelles incohérences, car le but final est d’attribuer aux nœuds les informations

renseignées dans les bordereaux.

Lors d’un contrôle de cohérence sous bordereau, les valeurs considérées seront donc celles

des bordereaux qui ont été saisies, pour les nœuds qui en ont. Pour les valeurs non saisies sous

bordereau, ou pour les nœuds n’ayant pas été soumis à bordereau, le contrôle de cohérence tient

compte des valeurs directement présentes sur les nœuds.

Ainsi, il travaille sur une image de ce que serait la nomenclature d’exécution si les

modifications avaient directement affecté les nœuds.

Si le contrôle ne relève pas d’incohérence, alors la validation des bordereaux devient possible,

c'est-à-dire que les modifications peuvent être appliquées sur les nœuds concernés, et dans ce cas, les

bordereaux sont « détachés » des nœuds.



Projet FARANDOLE

Cette première tâche m’a donc permis de mieux appréhender l’usage final mais aussi le

fonctionnement de l’application, notamment au niveau des objets métiers, et également des méthodes

utilisées pour le travail dans l’équipe de farandole.

4.3.2 L’aide en ligne

L’aide en ligne consiste à donner sur chacune des pages de l’application, la possibilité

d’accéder à une page d’aide, qui donne des informations sur le contenu de la page d’où elle a été

appelée.

Les spécifications étaient simples, il fallait pouvoir ajouter facilement une page d’aide en

rapport à une nomenclature. Cependant, si une nomenclature ne possède pas d’aide spécifique, dans la

mesure où elles appartiennent à des ensembles (saisie, navigation, …), l’aide doit dans ce cas afficher

une aide sur le type de la nomenclature.

Pour ce faire, il a fallu que j’étudie une autre partie de l’application, qui est située plus près

du serveur Tomcat, puisque je suis intervenu au niveau des actions STRUTS, mais également sur les

pages JSP et transformations XSLT en collaboration avec Emilie Habermacher.

J’ai donc conçu le mécanisme général de l’aide en ligne, que j’ai ensuite développé. Il est

conforme au reste de l’application, et respecte le modèle MVC (modèle/vue/contrôleur). De ce fait, le

traitement « métier » est bien séparé de l’affichage.

Les nomenclatures étant des fichiers XML stockés dans une arborescence de fichier, j’ai donc

utilisé la même méthode pour l’aide. Chaque fonction, représentée par une nomenclature, peut donc

être pourvue d’une aide, si un fichier portant le nom de la fonction est placé dans le répertoire des

fichiers d’aide.

Dans un but de simplicité, les fichiers d’aide peuvent être saisis via Word, en étant enregistrés

en HTML. Cependant, pour que la présentation soit uniforme, lors du traitement, seul le corps (ce qui

est situé entre les balises <body> et </body>) est pris en compte, et intégré dans une page dont

l’entête et le feuilles de styles ont été définies au préalable.

Le cheminement du mécanisme est donc le suivant :



Projet FARANDOLE

• L’utilisateur clique sur l’icône d’aide

• Celui-ci est un lien hypertexte désignant l’action STRUTS correspondant à l’aide,

comprenant un champ variable qui a pour valeur le nom de la fonction de la page

courante.

• L’action STRUTS déclenche via le contrôleur un traitement métier.

• Ce dernier vérifie qu’il existe le fichier correspondant à la fonction. Il cherche

également la présence d’un fichier correspondant au type de celle-ci. Dans tous les cas

(absence du premier, absence du second, absence des deux) il génère le contenu du

corps de la page HTML résultante, et retourne le résultat au contrôleur.

• Le contrôleur retourne le résultat à l’action STRUTS qui l’avait invoquée.

• L’action STRUTS retourne dans la session, le contenu des variables du formulaire

STRUTS.

• La page JSP de l’aide est invoquée et les remplacements des variables par leur valeur

sont effectués par STRUTS.

Le travail sur l’aide en ligne m’a donc permis de découvrir le fonctionnement du framework

STRUTS, mais également son utilisation au sein du projet.

D’autre part, cela m’a permis de mettre au point un service dans l’application, en partant

simplement des spécifications, et en concevant puis développant l’intégralité du mécanisme, puis en

l’intégrant au reste du projet.



Projet FARANDOLE

4.3.3 Les mouvements de crédits

Comme cela a été expliqué dans 4.3.1, dans les nomenclatures d’exécution est défini comment

sont répartis les différents budgets alloués aux ministères.

Pour comprendre le concept des mouvements de crédits, il est nécessaire d’expliquer la

gestion d’un exercice budgétaire.

Pour la suite du document les acronymes suivants seront utilisés :

• PLF : Projet de Loi de Finances

• PLFR : Projet de Loi de Finances Rectificatives

• LFI : Loi de Finances Initiale

La gestion d’un exercice budgétaire pour une année N s’étale sur les trois années N-1, N et N+1.


N-1

N

N+1

Préparation du budget par ministère. Arbitrages du premier ministre

Octobre : Présentation du Budget aux l’assemblées (PLF, annexes Budget Général, Budgets Annexes et Comptes Spéciaux)

Revue des budgets par les députés. Amendements, et vote des budgets

Fin décembre : Mise en place de la LFI (Loi de Finance Initiale). Publication du Décret de Répartition(DR) au JO

Mouvements de Crédits (modifications diverses)

Avril : éventuel PLFR, revu et voté par les députés => LFR « de printemps », et DR associé

Mouvements de Crédits (modifications diverses)

Octobre : PLFR, revu et voté par les députés => LFR « d’automne » et DR. Systématique

Récupération des éléments sur l’exécution effective de l’année NPréparation des Rapports Annuels de Performance

Avril :, Vote de la Loi de Règlement.


Projet FARANDOLE

L’année N-1 est consacrée à la préparation du budget de l’année N (PLF puis LFI)

L’année N voit apporter des modifications en cours de gestion sur le budget (Mouvements de

Crédits et (P)LFR), en parallèle de la capture des recettes et dépenses effectives suivant la

nomenclature d’exécution affinée.

L’année N+1 est consacrée au rapport sur l’exécution du budget (Loi de Règlement et

Rapports Annuels de Performance associés).

Durant une année civile donnée, on travaille donc à la fois à l’élaboration du budget de

l’année suivante, à l’enregistrement de l’exécution et à la modification du budget de l’année en cours,

et au rapport sur l’exécution du budget de l’année budgétaire précédente.

Les mouvements de crédits recouvrent les moyens prévus par la Loi Organique relative aux

Lois de Finances pour apporter, en cours de gestion, des ajustements mineurs (plafonnés à quelques

pourcents) aux budgets de l’année.

Ces mouvements de crédits sont validés par le Ministère de l’Économie et des Finances et

publiés au Journal Officiel.

Les Lois de Finances Rectificatives apportent des ajustements potentiellement plus

conséquents.

Elles sont organisées d’une façon similaire à celle d’un Projet de Loi de Finances même si elles

ne traitent que de modifications apportées aux budgets, et sont votées par les députés suite à

amendements.

Le cas général est celui d’une LFR (en automne) par an. Il est également possible d’avoir une

LFR au printemps (en particulier en cas de changement de gouvernement). En théorie, on pourrait

même avoir plus de 2 LFR dans l’année, même si le temps matériel de mettre en place une telle loi

limite naturellement les possibilités.

Les mouvements de crédits autorisés entrent dans une des dix catégories prévues par la loi, telle

« Dépenses accidentelles et imprévisibles » ou encore « Provision relative aux rémunérations

publiques » …

La restitution d’un mouvement de crédit prend la forme d’un document de quelques pages qui

comporte un texte, décomposés en articles présentant des chiffres de synthèse, et de tableaux

détaillant les différentes modifications apportées par le mouvement de crédit, par nature de

modification (annulations, ouvertures, révisions) et par nature de budget.



Projet FARANDOLE

A un instant t, la situation effective d’un programme ou d’un compte se définit comme la

synthèse de l’état initial (au moment de la LFI) et de l’ensemble des mouvements de crédits et de Loi

de Finance Rectificative qui ont apporté des modifications à cet état initial.

La Loi Organique relative aux Lois de Finances définit les nombreuses règles de gestion qui

déterminent la validité des mouvements de crédits, ces règles variant suivant la catégorie du

mouvement.

Mon travail sur les mouvements de crédits a notamment consisté en l’implémentation de ces

règles au sein de l’application.

Les mouvements de crédits sont en réalité regroupés en opérations, appartenant à une des dix

catégories, laquelle comporte un certain nombre de mouvements élémentaires.

L’application des règles se fait donc sur une opération, et l’ensemble des mouvements effectués

au sein de l’opération doit être cohérent.

De la même manière que pour les contrôles de cohérence pour les nomenclatures d’exécution,

les règles qui doivent s’appliquer sur la catégorie d’opération sont toutes effectuées, même si une

incohérence a été détectée en cours, de sorte à proposer un compte rendu global des incohérences.

D’autre part, les mouvements de crédits s’opérant parfois entre plusieurs ministères, il se peut

que plusieurs opérations soient saisies en parallèle. Afin que les différentes saisies ne créent pas

d’interférences entre elles, les mouvements d’une opération ne sont pris en compte que lorsque celle-

ci a été validée.

En effet, les opérations ont un cycle de vie, et le passage par plusieurs états est nécessaire avant

que celle-ci soit validée, et que les montants des mouvements soient pris en compte par les autres

opérations. Ces différents états correspondent à des étapes administratives que subissent les

opérations.

La validation d’une opération peut donc parfois rendre incohérent l’ensemble des mouvements

d’une autre opération, même si cette dernière était cohérente avant validation. De la même manière, si

une opération est incohérente, la validation d'une autre peut la rendre valide.

Lors de la saisie des mouvements élémentaires, certaines règles sont vérifiées avant mise à

jour dans la base de données, afin d’éviter à l’utilisateur de devoir corriger toutes ses erreurs à la fin



Projet FARANDOLE

de sa saisie. Pour permettre cette souplesse, chacune des règles peut être activée, via un fichier de

configuration, à la saisie et au contrôle général, ou au contrôle général seul. D’autre part, grâce à ce

même fichier de configuration, il est possible de définir quels sont les règles bloquantes et qui

empêchent la mise à jour dans la base, et ceux qui ne représentent que des avertissements.

La réalisation des contrôles de cohérence des mouvements de crédits a donc nécessité un long

travail de compréhension du besoin. L’explication précédente survole rapidement les points

importants des mouvements de crédits, sans entrer dans le détail. De sorte à ne pas être submergé par

le détail de chacune des 60 règles de contrôle, de nombreux documents détaillant à plusieurs niveaux

les travaux demandés m’ont été fournis. En outre, pour m’aider à me familiariser avec toutes ces

informations, j’ai assisté à une réunion au ministère des finances qui concernait l’éclaircissement de

certaines règles qui paraissaient alors ambiguës.

Tout au long de l’écriture des règles j’ai unitairement testées celles-ci, de sorte à voir si les

résultats escomptés correspondaient au détail de la règle. Au moment de les tester toutes ensemble,

j’ai mis en place une matrice comprenant les catégories de mouvements de crédits en colonne et les

différentes règles en ligne. Pour chaque règle utilisée dans une catégorie, la case correspondante était

cochée.

Ainsi, il était aisé de suivre l’évolution de chacun des tests effectués, car à chacun des tests, les

cases cochées correspondantes étaient coloriées selon un code couleur en fonction du résultat obtenu

par rapport au résultat attendu. De fait, toutes les règles ont été testées, avant la première livraison

dans l’environnement d’intégration du ministère.

Néanmoins, comme le laisse paraître l’explicatif de ce chapitre sur les mouvements de crédits,

la simplicité n’est pas leur caractéristique première. Diverses interprétations divergentes mêlées à

quelques bugs de cas non rencontrés lors de mes tests sont donc apparues lors des premiers essais à la

direction du budget.

D’autre part, chaque saisie de mouvements de crédits est soumise à quelques-unes de ces règles

de contrôle qui soient avertissent l’utilisateur d’une incohérence, soit bloque l’enregistrement de sa

saisie. Ces règles étant relativement contraignantes car la saisie doit suivre un ordre très strict, il a été

demandé à la direction du budget de fournir des jeux de tests complets. Malgré tout, la compréhension

fonctionnelle finale étant difficile à appréhender, de nombreux échanges ont été nécessaires pour

tendre vers des ouvertures d’anomalies de moins en moins nombreuses et portant sur des points de

moins en moins importants.



Projet FARANDOLE

4.3.4 Autres travaux

Pendant la durée de mon stage, j’ai eu la responsabilité de plusieurs autres travaux, d’envergure

moindre que ceux que je viens de décrire.

Ainsi, lors de la réalisation des contrôles de cohérence, j’ai été confronté à un problème que

l’architecture de Farandole ne me permettait pas de résoudre directement. En effet, ces contrôles

comme nous l’avons vu, sont en partie effectués lors de la saisie.

Si certaines règles ne sont pas vérifiées, selon leur importance cela peut impliquer que les

modifications ne doivent pas être stockées en base. Ce cas ne posait pas de problème, l’architecture

même des exceptions de Java y apporte sa solution et Farandole en tirait déjà profit. En levant une

exception, le traitement s’interrompt, et le message de l’exception est affiché à l’utilisateur.

Cependant, si la règle est considérée comme moins « critique », et que le fait qu’elle ne soit pas

vérifiée n’implique qu’un simple avertissement, aucun mécanisme n’était à ma disposition pour en

informer l’utilisateur sans bloquer le stockage des modifications.

J’ai donc mis en place un système permettant d’informer l’utilisateur sans altérer d'aucune

manière, le traitement qui l’invoque.

Il s’agit d’une classe singleton, qui possède une liste de message par utilisateur connecté à

l’application. Cette liste de messages contient le message et sa sévérité (avertissement, information,

debogage).

Pour informer l’utilisateur il suffit donc d’alimenter cette liste, en l’invoquant à la demande

dans le code Java.

Le mécanisme qui permet de lire cette liste et de l’afficher s’appuie le fonctionnement général

de l’application pour les affichages. Celui-ci consiste à transformer un flux XML en HTML avec des

feuilles de styles XSL. Avant la transformation qui permettra l’affichage de la prochaine page à

l’utilisateur, le contenu de la liste est introduit dans le flux XML. Ainsi, pour rendre les messages

visibles, il a fallu modifier les feuilles de styles XSL pour tenir compte des nouvelles balises

correspondantes.



Projet FARANDOLE

4.4 Déroulement du projet

Ce stage de fin d’année, dans une des entreprises informatiques les plus connues dans le monde

m’a tout d'abord permis de travailler dans un équipe de taille moyenne au sein d'un projet faisant

usage de technologies récentes.

D’autre part, il m’a permis de mieux appréhender les diverses fonctions occupées par chacun

au sein d’une équipe de projet, ainsi que les différentes interactions entre les membres de cette

équipe, les clients, et la hiérarchie.

La gestion de projet était pour moi une nouveauté ; mes précédentes expériences avaient eu

lieu dans de plus petites structures qui n’avaient pas réellement besoin de s’en préoccuper. Ainsi, sur

le projet où le nombre de collaborateurs a atteint une quinzaine de personnes, différentes difficultés

ont du être surmontées.

4.4.1 Gestion des ressources

La gestion des ressources en est l’une des principales. Il s’agit d’affecter les multiples tâches

du projet à un minimum de personnes, en faisant en sorte que cette répartition se fasse sur des parties

suffisamment distinctes afin de ne pas créer de dépendance qui puisse être critique dans le processus

de développement.

Dans le cas de Farandole, le « découpage » s’est effectué sur le schéma proposé en 3.2.1. Par

exemple, la partie présentation, HTML/CSS/Javascript était la mission d’Emilie Habermacher, la

partie SGBD relevait de la responsabilité de Thierry Sitbon. A l’intérieur du cadre « Serveur

d’application J2EE Tomcat » le découpage est plus fin, mais il est aisé de concevoir une répartition

cohérente des différentes tâches.

En ce qui me concerne, mes principales contributions se sont situées sur les objets métiers, les

contrôles de cohérences étant une application directe de la logique métier. En outre, l’aide en ligne

relevant davantage de la présentation, j’ai du intervenir au niveau de la partie présentation (HTML),

et JSP pour la coopération avec le mécanisme mis en place, que j’ai décrit en 4.3.2. Dans les diverses

travaux que j’ai accompli, j’ai également mis en place un service au niveau des imports.



Projet FARANDOLE

Mon arrivée dans le projet correspondait à la fin du projet, ce qui a apporté une problématique

supplémentaire dans la gestion des ressources. En effet, il fallait conserver certains développeurs, les

autres étant alors affectés à d’autres projets. Les difficultés arrivent lorsqu’un problème majeur

apparaît sur une partie bien spécifique du travail de l’un de ceux qui n’est plus sur le projet. Farandole

a été confrontée à ce problème, et l’arbitrage de plusieurs niveaux hiérarchiques a été nécessaire avant

de trouver une solution satisfaisante.

4.4.2 Rapports et réunions

Chaque semaine, une réunion rassemble tous les collaborateurs IBM du projet Farandole pour

faire un point. Chacun y explique ce qu’il a fait la semaine passée, et ce qu’il lui reste à faire pour la

semaine à venir. Christophe, le chef de projet, y expose les différents problèmes et nouveautés

rencontrés au ministère, et rappelle les prochains évènements en rapport avec le planning contractuel,

telles les phases de début de recettes, le changement de tranche, etc … Cette réunion est également

l’occasion de débattre de sujets qui impactent simultanément le travail de plusieurs membres de

l’équipe, et de faire les choix qui s’imposent ou bien ceux qui sont issus du meilleur compromis.

Dans la mesure où l’application Farandole traite sur trois années l’évolution du budget, et que

certaines générations de classes sont automatisées, il nous a fallu déterminer une solution qui évite les

inévitables duplications de code et tous les problèmes de maintenance liés à l’existence de trois

exemplaires des mêmes classes.

Nous avons également eu quelques problèmes sur la sémantique de null. Comment considérer

cette absence de valeur, que ce soit dans les calculs, dans les comparaisons, … ? Fallait-il suivre

l’exemple de SQL qui considère null comme une absence de valeur, et donc la somme avec une valeur

n’a pas de sens et vaut null ? Est-ce plutôt un calcul erroné, et donc impossible ? De plus, null

représente une information dans les tableaux des comptes budgétaires, qui est différent de zéro. Il est

donc important de ne pas considérer rapidement null comme valant zéro dans les calculs ni dans les

comparaisons. Sans entrer dans le détail de la solution choisie, il a donc fallu unifier dans l’ensemble

du projet, depuis les triggers jusqu’aux objets métiers Java, la manière d’utiliser cette information.

Les problèmes étaient assez variés. La plupart des interrogations qu’a créé ce projet étaient

très formatrices dans le sens où elles étaient parfois assez inattendues, comme l’exemple précédent

avec null, mais aussi parce qu’elles me seront sources de réflexion sur les prochains projets sur

lesquels j’aurai à travailler. En effet, sur la base de ces constatations, certains problèmes

m’apparaîtront plus évidents et je serai en mesure de les repérer voire les éviter plus tôt.



Projet FARANDOLE

De nombreux évènements ponctuent la vie de Farandole. L'ensemble de ces évènements a été

validé par la direction du budget, et de nombreux points importants du projet ont été définis et

formalisés dans un document, comme par exemple la réunion entre les membres de l'équipe IBM que

je viens de mentionner.

En outre sont définis les objectifs, les synthèses de procédures et les paramètres des

procédures pour la gestion :

• des actions

• des incidents

• des demandes de changement

• des anomalies

• des livraisons

• de la documentation

Cependant, afin de suivre au mieux l'évolution du projet, la direction du budget est réunie

avec des membres d'IBM pour des comités de pilotage et des comités directeurs.

Ainsi, deux fois par mois est organisé un Comité Directeur entre

• le chef du projet IBM, Christophe Matiachoff, et le chef de projet junior, Stéphane

Macé,

• l’architecte fonctionnel IBM, Benoît Gloanec,

• la responsable commerciale IBM chargée du Ministère des finances, Christina

Maillot-Engel,

• le sous-directeur de la Direction du Budget au Ministère des Finances, Julien

Dubertret, qui est le décisionnaire sur le projet et préside le Comité Directeur,

• le responsable métier du Ministère des Finances, Marc Dora, chef du Bureau Lois de

Finances,



Projet FARANDOLE

le chef du Bureau des Systèmes d’Information, Vincent Amilhaud, responsable opérationnel

du projet pour la maîtrise d’ouvrage.

Le Comité a pour but de donner les orientations stratégiques afin de définir grossièrement

l'articulation de la réalisation des principaux objectifs dans le temps. Il permet ainsi de définir des

priorités en terme de réalisation des objectifs et de donner une visibilité sur les ambitions de

l'organisation.

Des Comités de Pilotage sont également organisés chaque semaine, à un moindre niveau

hiérarchique. L’intérêt de ces réunions est de considérer l’avancement hebdomadaire du projet. Cet

avancement est formalisé chaque semaine sous forme d’un rapport concis et est archivé. Ainsi ces

documents permettent de savoir ce qui a été fait et à quel moment dans l’historique d’évolution du

projet, ce qui s’avère indispensable en cas de contentieux ultérieur.

Par ailleurs, pour justifier à la hiérarchie d’IBM les coûts engendrés par le projet, le chef de

projet doit régulièrement rendre des comptes.

En outre, chaque semaine, tous les collaborateurs « pointent » via un logiciel adapté sur le

projet pour lequel ils travaillent, afin de suivre les coûts et préparer la facturation.

4.4.3 Planning

Le projet, après les études nécessaires pour estimer la faisabilité et définir l’architecture

technique, a été découpé en tranches, elles-mêmes découpées en lots. Chacune de ces étapes fait

l'objet de plusieurs livrables permettant au ministère de tester l’application au fur et à mesure de

l’avancement. Ce découpage permet de maîtriser la conformité des livrables à la définition des

besoins ainsi que de s'assurer de l'adéquation aux objectifs de coûts et de délai.

En effet, le projet Farandole est assez spécifique dans le sens où le Bureau du Service

Informatique du ministère des Finances est fortement impliqué dans le projet et a participé à la

réalisation de nomenclatures.

De ce fait, au sein même des phases de réalisation, des livraisons sont effectuées au ministère,

avant la fin de l’étape en cours. Ceci est également intéressant pour les développeurs dans la mesure



Projet FARANDOLE

où avant même la fin de l’étape, leur contribution est testée par plusieurs personnes, et permet donc

des corrections d’anomalies plus efficaces. Ces livraisons n’étaient néanmoins pas directement

intégrées en production, mais sur un serveur d’intégration propre au service informatique du

ministère. De ce fait, avant d’être véritablement livré en production, chaque ajout ou correction passe

par le serveur d’intégration interne d’IBM puis par celui de la direction du Budget.

Chaque étape est limitée dans le temps, et comprend une phase de recette : un mois de

Vérification Au Bon Fonctionnement et deux mois de Vérification en Service Régulier. La recette

permet la vérification de la conformité de l'ouvrage à la demande formulée dans le document de

conception générale de cette étape. La recette est effectuée par le ministère, et dispose pendant cette

période de la possibilité de demander la correction prioritaire d’anomalies. Contractuellement, toutes

les anomalies majeures concernant l’étape en recette doivent être corrigées.

Dès lors que la phase de recette est terminée commence la phase de maintenance pendant

laquelle toutes les anomalies rencontrées doivent contractuellement être corrigées. Les ajouts ne

peuvent pas êtres imposés par le ministère, mais le bon sens et le désir d’avoir le meilleur contact

possible nous a souvent amené à en réaliser tout de même de mineurs. Les modifications plus

importantes font l’objet de Demandes de Modifications.



Projet FARANDOLE

4.4.4 Transferts de compétences

Le projet Farandole, bien que n’ayant dénombré au maximum « qu’une » quinzaine de

personnes, a vu la quantité de code source et de documentation s’accroître au fil du projet. Dès lors,

dès que l’un des collaborateurs quitte le projet, il transmet ses compétences à un ou plusieurs autres

développeurs, en tenant compte de la proximité de ses tâches avec celles de ceux à qui il les transmet.

L’intérêt est bien sûr de pouvoir reprendre son code, et corriger d’éventuelles anomalies ou encore

d’y ajouter de nouvelles fonctionnalités.

Comme je l’expliquai précédemment, de nombreux collaborateurs ont donc quitté le projet

lorsque celui-ci s’est approché de la fin, et de nombreux transferts de compétences ont été effectués

entre les partants et les autres. Cette délicate étape s’est très bien passée dans la mesure où la majorité

des problèmes rencontrés sur les travaux réalisés par les développeurs partis ont pu être traités de

manière efficace.

Ceci a été très formateur pour moi car cela m’a permis de me rendre compte que pour rendre

cette transmission de connaissances la plus facile et rapide possible, un certain nombre de mesures

sont à prendre sur chaque travail effectué.

C’est pourquoi au tout début du projet, l’un des premiers documents que j’ai lu, concernait la

manière d’écrire le code dans le projet Farandole. De nombreuses conventions y sont établies, par

exemple sur la structure, ou encore sur la façon dont sont utilisées les Exceptions Java en fonction de

la nature du problème qui les a déclenchées, mais aussi d’autres aspects plus généraux, dont

notamment la structure des classes et la façon de les instancier, etc… Ce document est très complet et

ne laisse pratiquement pas de place à de quelconques ambiguïtés.

De ce fait, même si l’écriture peut parfois paraître contraignante, la lecture du code de

quelqu’un d’autre n’en est que plus aisée, et la problématique que la classe est chargée de résoudre

représente la seule difficulté de compréhension.



Projet FARANDOLE

5 Bilan

Cette nouvelle expérience dans le monde du travail m’a été enrichissante à plusieurs points de

vue. En effet, arriver dans une équipe au beau milieu d’un projet était totalement nouveau pour moi, et

somme toute très caractéristique de la réalité professionnelle.

Ainsi j’ai pu exercer mes capacités d’intégration à la fois à l’équipe mais également à univers

fonctionnel qui ne m’était pas familier. En effet, ni le droit ni les finances ne sont des domaines qui

ont été abordés pendant mes études et que j’ai l’habitude de pratiquer.

Comme nous l’avons vu dans la description des mouvements de crédits, l’information est

dense, la compréhension n’est pas aisée, ce qui n’a pas rendu l’immersion facile. Au tout début du

stage, cette difficulté était en outre liée à la compréhension de l’architecture générale de Farandole.

J’ai donc commencé par lire la documentation la concernant tout en essayant de concert l’application,

afin de comprendre les différents enchaînements provoqués par les clics consécutifs de souris. J’ai

également essayé d’identifier lors de cette découverte quel était le rôle de chaque développeur, de

sorte à cibler au mieux mes questions.

Mais c’est en commençant réellement que j’ai pu préciser mes questions et mieux voir les

mécanismes de l’architecture. Ensuite, les éléments fonctionnels sur lesquels j’ai travaillé ont

commencé à s’éclaircir, et leur modélisation sous forme de classe est devenue peu à peu limpide.

Ce travail en équipe au sein d’une grande entreprise m’a permis de saisir l’importance des

documentations et des notifications internes à l’équipe afin de prévenir des mises en places que l’on a

effectué; l’importance d’organiser un remplacement - et la difficulté d’en réaliser un, notamment à

cause de la perte de temps immédiate - lorsqu’une personne part en congés, ou quitte le projet.

J'ai eu en outre le plaisir d'être intégré à l'équipe comme un autre employé, sans distinction de

"grade" et j'ai par conséquent pu prendre des initiatives et être écouté lorsque je faisais des

propositions.

La gestion du projet est une application très proche de la théorie que j’ai pu lire à ce sujet. La

maîtrise des coûts et des délais, la gestion des ressources, le suivi contractuel du projet, sont autant de

considérations que la vie étudiante ne nous permet pas d’appréhender, qui sont néanmoins

indispensables dans la vie professionnelle. Cette expérience m’a donc montré tout cela et fait sentir



Projet FARANDOLE

l’importance de la rigueur de cette gestion, tant il est difficile de maîtriser tous ces paramètres à la

fois.

Par ailleurs, j’ai appris quelques aspects techniques que j’ignorais et j’ai pu me rendre compte

aussi de la souplesse des nouvelles technologies fonctionnant autour du framework J2EE et d’Oracle.

J’ai également beaucoup apprécié de participer à un projet dont l’enjeu est très concret et

relativement important, dans la mesure où il s’agissait de travailler pour le budget de l’État.

Ce stage m'a donné les moyens de montrer mes compétences techniques, de me rendre compte

de ma capacité d'intégration dans une équipe, ma motivation de vivre le projet et d'y apporter mes

qualités humaines. Le travail que j'ai effectué, et ma personnalité ont pu me mener sans encombre

jusqu’à la fin du stage.


RAPPORT DE STAGE -...

Documents

Transcript of RAPPORT DE STAGE -...