RAPPORT DE STAGE -...

RAPPORT de STAGE :Projet Farandole

StagiaireMathieu Changeat

ISTY

IBM FranceSous le tutorat de M. Matiachoff

Projet FARANDOLE

Table des Matières

1 INTRODUCTION.........................................................................................................................................4

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

2.1 INTRODUCTION.......................................................................................................................................52.2 HISTORIQUE............................................................................................................................................52.3 IBM CORPORATION................................................................................................................................52.4 IBM FRANCE..........................................................................................................................................62.5 STRUCTURES...........................................................................................................................................6

2.5.1 IBM Global Services.........................................................................................................................62.5.2 IBM Business Consulting Services....................................................................................................82.5.3 Application Innovation Services.......................................................................................................8

3 FARANDOLE................................................................................................................................................9

3.1 CONTEXTE..............................................................................................................................................93.1.1 Le client.............................................................................................................................................93.1.2 La loi organique relative aux lois de finances................................................................................103.1.3 Objectif des prestations...................................................................................................................123.1.4 L’architecture fonctionnelle attendue.............................................................................................12

3.2 LE PROJET.............................................................................................................................................143.2.1 L’équipe..........................................................................................................................................143.2.2 Planning..........................................................................................................................................143.2.3 Nomenclatures................................................................................................................................163.2.4 L’application...................................................................................................................................17

3.2.4.1 Moteur d’instanciation...........................................................................................................................173.2.4.2 Moteur de navigation.............................................................................................................................173.2.4.3 Moteur de saisie.....................................................................................................................................173.2.4.4 Moteur de production.............................................................................................................................173.2.4.5 Contrôleur..............................................................................................................................................183.2.4.6 Base de Données / Persistance...............................................................................................................183.2.4.7 Authentification / Habilitations / Workflow..........................................................................................18

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

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

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

4.4 DÉROULEMENT DU PROJET...................................................................................................................334.4.1 Gestion des ressources....................................................................................................................334.4.2 Rapports et réunions.......................................................................................................................344.4.3 Planning..........................................................................................................................................354.4.4 Transferts de compétences..............................................................................................................36

5 Bilan..............................................................................................................................................................38

Document : document.doc Date : 23/09/2005Version : 0.2Auteur : Mathieu Changeat Page : 2/40

Projet FARANDOLE

Table des Figures

FIGURE 1: ARCHITECTURE FONCTIONNELLE....................................................................................................13Figure 2: Organigramme de l’équipe..............................................................................................................14


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 $;

le matériel : 31 milliards de $;


Projet FARANDOLE

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 les de services dans lesquels

laquelle le stagiaire a officié.

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.


Projet FARANDOLE

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


Projet FARANDOLE

2.5.3 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. La création de la nouvelle entité IBM Business Consulting Services répond aux besoins

stratégiques des entreprises soucieuses de bénéficier d’une offre complète, allant du conseil jusqu’à la

mise en œuvre de 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.4 Application Innovation Services

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 futurs 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 seront renforcées.

La loi organique impose que le projet de loi de finances 2006, préparé durant l’été en 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. En effet, aAujourd'hui, le budget de l'État est voté par titre (au nombre de 7

et qui sont par exemple les dépenses de fonctionnement, la charge de la dette de l’État ou encore les

dépenses d’investissement : 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.

A terme, lLa loi organique devrait donc :

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

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

et développer la comptabilité de l'État.

Les crédits seront spécialisés par dotation ou programmes (dont le nombre pourrait êtreest de

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


IBM_USER, 23/09/05,

Je ne comprends pas ce dernier point.

Projet FARANDOLE

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

définis en 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 seront regroupés par « missions ». Celles-ci comprendront 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’aura 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.

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


Projet FARANDOLE

Figure 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

Figure 2: Organigramme de 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, celle-ci ne pourra excéder 7 mois augmentés de 3

mois au titre des opérations de vérificationdont la réalisation a débutée en janvier 2005. La première

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


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

Architecture applicative

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.

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

3.2.4 Nomenclatures


Projet FARANDOLE

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

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

3.2.5 L’applicationL’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.

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


IBM_USER, 23/09/05,

Je ne suis pas sûr que le moteur de saisie s’en occupe lui-même. Ne le délègue-t-il pas ?

Projet FARANDOLE

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 et est 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).

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

choisie.


Projet FARANDOLE

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 ».

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


Projet FARANDOLE

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 pouvoir être misesmettre en relation entre 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.

Les schémas suivant illustrent cette arborescence :


Projet FARANDOLE

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 est 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.

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


Projet FARANDOLE

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.


IBM_USER, 23/09/05,

Rafraîchir l’exemple ? Ne correspond plus à la dernière présentation.

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 :Document : document.doc Date : 23/09/2005Version : 0.2Auteur : Mathieu Changeat Page : 25/40

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.

4.3.3 Les mouvements de crédits

Les mouvements de crédits, dans le calendrier, devaient être traités dans le lot 2 tranche 3.

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.


IBM_USER, 23/09/05,

Je ne comprends pas la phrase

Projet FARANDOLE

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.

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).


Projet FARANDOLE

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.


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

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.

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.


Projet FARANDOLE

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. De sorte à ceAfin 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. L’inverse est également

envisageable.

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 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, qui atteignent les 60, 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.


IBM_USER, 23/09/05,

Je ne comprends pas cette phrase

Projet FARANDOLE

Ainsi, il était aisé de sorte à 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 au 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.

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.


Projet FARANDOLE

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

que ce soit 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.2. 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.


IBM_USER, 23/09/05,

Mettre à jour le lien

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 de nombreux échanges inter hiérarchiques et inter

servicesl’arbitrage de plusieurs niveaux hiérarchiques ont a été nécessaires 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 de

sorte à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 à qu’engendrait l’existence

de trois exemplaires fois ldes 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.


Projet FARANDOLE

Les problèmes étaient assez hétéroclites et 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.

Farandole est également ponctuée de réunions clés dans la gestion du projet. Ainsi,

mensuellement deux fois par mois est organisé un comité Comité directeur Directeur entre

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

Macé,

l’architecte fonctionnel IBM, accompagné Benoît Gloanec,

l a responsable commerciale IBM chargée du Ministère des finances, l’architecte ainsi

que les représentants des services financiers d’IBM, 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,

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

opérationnel du projet pour la maîtrise d’ouvrage.

. Les responsables du projet à la direction du Budget participent également à cette réunion.

Ainsi, le schéma directeur défini lors de ces réunions,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 Comités de pilotage Pilotage sont également organisés chaque semaine, à un

moindre niveau hiérarchique. Les intervenants de ces réunions sont sensiblement les mêmes, mais ne

font pas intervenir les plus hauts responsables dans la hiérarchie. 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 à


Projet FARANDOLE

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 de sorte à répartir la facturation sur

les projets internes.

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, c’est pourquoi au sein même des phases de réalisations, des livraisons sont

effectuées au ministère, avant la fin de l’étape en cours. Ceci est également intéressant pour nous

autresles développeurs dans la mesure où avant même la fin de l’étape, notre 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 moins de

Vérification Au Bon Fonctionnement et deux mois de Vérification en Service Régulier. Celle-ciLa

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


Projet FARANDOLE

période de la possibilité de demander la correction prioritaire d’anomalies, voire la demander d’ajouts

de fonctionnalités mineures. 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 seules toutes les anomalies rencontrées doivent contractuellement être corrigées. Les

nouveaux 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.

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.


Projet FARANDOLE

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

sorte à 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 une autre employée, 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


Projet FARANDOLE

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

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 -...