POINT D'ÉTAPE SUR LE CHANTIER DE MODERNISATION DES APPLICATIONS « GROS SYSTÈME »

Publié le 14/04/2015 à 15H42
Si l'administration emploie le terme « moderniser », il s'agit dans les faits de répondre aux diminutions de crédits de fonctionnement alloués à la sphère informatique. En effet, les machine gros système IBM ou BULL coûtent cher à la DGFiP. La DG a trouvé là une niche à économie.

Il est alors nécessaire de convertir les applications écrites en COBOL (et JCL) dans un autre langage. La DG a choisi le langage JAVA. Fort opportunément, un logiciel mis au point par une société privée existe : BLU AGE.
Sont théoriquement concernés :
• le domaine de la fiscalité des particuliers et des professionnels (chaînes de taxation IR et TH, fichier
FIP, MEDOC) ;
• le domaine de la fiscalité foncière (MAJIC) ;
• le recouvrement des impôts sur rôle (REC/MEN) ;
• la paye de l’État (PAYE) et le paiement des pensions (PEZ) ;
• la gestion de la clientèle des dépôts de fonds au Trésor (CEP).
Et ce sur une période de 4 ans.
Autant dire que « toutes les migrations ne se feront pas en interne » (dixit le chef de service).
Ce qu'en pense la CFDT :
Il faut d'abord rappeler que l'architecture « gros système » revêt certains avantages non négligeables. Tout d'abord, techniquement, elle est performante puisqu'elle est conçue pour traiter des masses de données considérable. De même le niveau de sécurité est bien supérieur sur un gros système que sur un serveur linux ou autre. A titre d'exemple toutes les banques ont choisi cette solution et n'entendent pas à ce jour l'abandonner. Elles doivent donc, à l'inverse de la DGFiP, l'estimer rentable par rapports aux autres solutions.
S'il est concevable, voire possible, de traduire un langage séquentiel comme le COBOL en langage objet comme le JAVA, maintenir le code généré nous paraît beaucoup plus ardu. On n'écrit pas le JAVA en 2015 comme on écrivait le COBOL en 1980. Les coûts de maintenance peuvent rapidement s'avérer faramineux et le travail désespérant pour les équipes qui seront chargées du projet.
Le délai de 4 ans est très optimiste lorsqu'on connaît les affres provoqués par les retards  pris dans les projets informatiques. Le dernier en date étant la conversion de PHP vers JAVA de l'application SISPEO qui était vendue par la DG réalisable en 4 mois et qui au final aura pris 2 ans !
Par ailleurs, la DG n'a jamais répondu aux questions relatives au coût financier des deux options. Sans aucune transparence et assurance sur les impacts budgétaires à long terme de telles mesures, la CFDT est inquiète pour la pérennité des missions informatiques.
A défaut de davantage de transparence, la CFDT estime que les DG ne gére que le court terme avec un seul objectif : rentrer dans un budget en diminution. Quant aux conséquences futures des choix opérés , les équipes futures de SI auront le plaisir et l'avantage de les gérer. Mais les agents, eux seront toujours là et risquent de faire les frais de cette politique à courte vue.
Et le meilleur pour la fin, aucune étude d'iompact sur les collègues susceptibles d'être impactés par cette mesure. Aucune proposition de faite, aucun travail réalisé sur l'aspect humain. SI ne gère que l'aspect technique du dossier.