INFORMATIQUE SEPTEMBRE 1996

Liste-guide à l'usage des décideurs
pourbien préparer le passage a l'euro


Ce document au format Word

Sommaire

Avant-propos

Des questionsgénérales...

Des questions techniques...


Avant-propos

Le passage à l'euro n'est pas une simple transformationmécanique des applications informatiques. C'est quelque chosede plus complexe. En effet, dans cette opération de nombreusespersonnes sont concernées à des titres divers, lesclients, les assujettis, les usagers, les utilisateurs desapplications, toutes en subiront les conséquences. Elle nesera réussie que si tout le monde, depuis les décideursjusqu'aux informaticiens en passant par les utilisateurs, mettentleurs ressources en commun.

Car tôt ou tard, nous devrons vivre un jour ou l'autre dansun monde où le franc sera remplacé par l'euro, tantvaut-il s'y préparer, dès à présent,correctement.

Les échéances prévues pour cetteopération (1er janvier 1999 et au plus tard le 1er janvier2002) paraissent, à certains, encore lointaines, c'est uneillusion. Les délais nécessaires pour la modificationdes applications concernées sont en réalitétrès serrés puisque dans certains cas tout doitêtre prêt, testé et opérationnel pour le 31décembre 1998 au plus tard. Il importe donc d'êtreparticulièrement vigilant dans le séquencement desopérations, leur planification et leur budgétisationpour les années 1997 et 1998.

Qualité du lecteur

Ce document ne sera pas " lu " de la mêmefaçon suivant la " qualité dudécideur ", directeur administratif ou informatique... Ils'adresse en priorité aux responsables qui auront àsuivre ce projet en tant que maître d'ouvrage et à quile chef de projet, maître d'oeuvre, rendra compte.

Ce document n'a pas la prétention de couvrir tous les caset de répondre à toutes les questions. Il va essayer defaire comprendre, surtout à ceux qui ne sont pasfamiliarisés avec la technique informatique, lesdifficultés de l'opération, les bonnes questions qu'ilfaut se poser, à qui et pourquoi. En un mot, de définirun minimum minimorum de ce qu'il faut faire ou faire faire.

Sommaire

 

Des questionsgénérales...

Il importe de se poser, tout d'abord, des questions surl'organisme lui-même, et en l'envisageant dans chacune de sesfonctionnalités (juridique, comptable, informatique...), en lereplaçant dans la période d'évolution versl'euro (1996-2002).

Sommaire

Votre organisme :

1. ses missions sont-elles appelées à changer dansles cinq prochaines années ?
2. son statut est-il appelé à évoluer dans lescinq prochaines années ?

Sommaire

Tutelle etdépendance :

1. par qui est exercée la tutelle administrative,économique et financière, etc. ?
2. inversement, exercez-vous une tutelle sur d'autresorganismes ?

3. devez-vous avoir des actions coordonnées avec d'autresorganismes ? Si oui, lesquelles ?

Risques :

Pouvez-vous faire une estimation de l'importance des risques quepeut subir l'organisme ou qu'il est susceptible de faire subirà d'autres acteurs administratifs ou économiques en casde défaillance dans le passage à l'euro ?

Sommaire

Environnementconcurrentiel :

L'organisme agit-il dans un contexte où le passage àl'euro peut être un élément de concurrence ?

Si oui, nature et degré des principaux risquesde concurrence :

provenant du secteur public national, européen,mondial
provenant du secteur marchand national, européen, mondial.

Sommaire

Stratégie dessystèmes d'information et l'euro :

Existe-t-il un plan stratégique général ou unprojet d'entreprise ?

Existe-t-il un schéma directeur des systèmesd'information ?

Si oui, ont-ils étémodifiés dans l'année dans la perspective de l'euro oude l'an 2000 ?

Existe-t-il une cartographie ou une modélisation desapplications informatiques (description de l'état desapplicatifs au regard du système d'information del'organisme) ?

Existe-t-il une programmation pluriannuelle des ressourcesinformatiques (matériel et personnel) ou au moins leurinventaire précis ?

Existe-t-il une commission ministérielle pourl'informatique (COMI) qui exerce un contrôle de vosprojets ?

Sommaire

Événementsimportants affectant le schéma directeur des systèmesd'information dans les années 1996-2002.

Avez-vous programmé, ou sont-elles déjà encours, des modifications importantes des applications introduisant denouvelles fonctionnalités ?

Quelle est la marge d'ajustement (financière et humaine)dont vous disposez ?

Pensez-vous avoir suffisamment de souplesse dans votrestratégie ?

Certaines modifications d'applications pour le passage àl'euro seront incontournables et devront êtreopérationnelles à la date prévue,peut-être au détriment d'autres projets. Des choix sontà faire notamment, en matière budgétaire.Avez-vous abordé ce sujet avec les responsables d'autresdépartements, ou comptez-vous le faire avant la fin del'année ?

Sommaire

Des questions plustechniques...

Existe-t-il un inventaire des diverses modifications ou desimpacts découlant du passage à l'euro, non seulementdans les applications informatiques, mais aussi dans lesméthodes de travail et la formation des personnels ?

De la même manière, avez-vous estimé lesconséquences de tous ordres découlant de ladépendance de votre organisme à l'égard desapplications dont d'autres organismes sont responsables ?

Avez-vous estimé les conséquences del'intégration des obligations du passage à l'euro dansle schéma directeur informatique de votre organisme ?

faut-il ou peut-on étaler dans letemps certaines opérations ? Si oui lesquelles ?
faut-il refaire entièrement le schéma directeur ?

Sommaire

Constitution de l'équipede projet : c'est une des premièresdécisions à prendre.

Avez-vous désigné un chef de projet d'un niveausuffisant ? Il devra superviser l'ensemble des modificationsà mettre en oeuvre ; il devra disposer d'un budget, entemps hommes et crédits.

Il devra imposer la discipline nécessaire (et les outils)à la conduite d'un projet informatique important.

En particulier, avez-vous organisé le suivi régulierdes travaux ? Celui-ci devra être fait même s'iln'est pas fait appel à la sous-traitance, et surtout s'il yest fait appel.

Sommaire

Les questions qui vont seposer et auxquelles il convient d'avoir réfléchi" avant " tout début de réalisation.

Avez-vous effectué le recensement des applications et dessystèmes à modifier ?

Avez-vous identifié et localisé les applications etleurs responsables ?

qui utilise quoi et où ?
qui maintient quoi et où ?

Pouvez-vous les classer en fonction :

des échéances prévues1999 et 2002 ?

ou de la " porosité " et de sa vitesse depropagation estimée ?

ou encore de leur état technique, de l'état de leurdocumentation, des outils utilisés pour leur écriture(ateliers de génie logiciel, bases de données et outilsassociés, langages utilisés), de la fréquencedes maintenances correctives et évolutives etc... ?

Pouvez-vous demander de faire prendre pour chaque application unedécision écrite portant sur :

le devenir de l'application et uneévaluation des ressources à consacrer à sonadaptation

sur le sort des fichiers des antérieurs (suivre lesdirectives officielles qui seront données par l'INSEE en cequi concerne la continuité des séries statistiques)

le calendrier des modifications (date au plus tôt, date auplus tard).

Au moment de prendre ces décisions, il serait bon d'avoirà l'esprit que :

la " mortalité " desapplications micro est importante et qu'il convient donc de faire" la part du feu "

profiter des circonstances pour proposer de passer à desprogiciels ou à des applications communes à plusieursministères ou entreprises permettrait de réduire lescoûts

faire établir un avenant au cahier des charges initialn'est pas une précaution inutile si la réception n'apas été prononcée. Sinon, un nouveau contratdevra être envisagé.

dans le cas des applications sous " contrat de tiercemaintenance ", il est impératif de revoir les conditionsavec la société concernée, et surtout de ne pasattendre le dernier moment pour le faire.

Sommaire

Quelques problèmesspécifiques

Utilisation d'un convertisseur en aval et/ou en amont del'application

La position du convertisseur doitêtre examinée, au fil de l'eau ou en dérivation(critères de déclenchement) en aval ou en amont del'application.

La " réversibilité " est-ellenécessaire ?

Convertisseur " maison ", faire attention à saqualité et à sa portabilité.

Convertisseurs " progiciel ", estimer les coûtscomplets (droit d'usage, paramétrage, assistancetechnique...).

Utilisation d'un convertisseur " extérieur ",estimer les responsabilité vis-à-vis des tiers.

Les convertisseurs utilisés sont-ils agréés,et par qui ?

Vérification et réception du convertisseur (ilserait préférable que le jeu d'essai soit public etagréé).

Arrondis dans les convertisseurs et/ou dans les applications

Vérifier l'utilisation de l'algorithme publié et dujeu d'essai de conformité.

S'assurer d'une nouvelle réception des applicationsaprès intégration de l'arrondi.

Seuils déclenchant une action

Traduction par opération arithmétique

Transformation des seuils en francs en seuils en euro (nombresentiers).

Examiner si dès maintenant des seuils" physiques " ne pourraient pas remplacer des seuilsexprimés en francs.

Test des applications transformées

Il convient d'examiner les incidences dela transformation sur la conception de l'application et sesperformances (temps de traitement, temps de transmission, etc.).

Ne pas sous estimer les incidences sur l'organisation desservices, la formation du personnel et sur la réglementation(décrets, arrêtés à modifier et àpublier).

Les applications modifiées devront être" recettées " par le maître d'ouvrage, unaccord de conformité au cahier des charges initial et àson avenant devra être obtenu.

Maintenance des applications transformées avant les datesfatidiques

Il faudra si possible éviter les doubles maintenances parune conception astucieuse de la modification et de son introductiondans l'application. Par exemple, l'isolation physique des programmes,les appels conditionnels de sous programmes, flagage des partiesmodifiées, etc... permettent une maintenance plus souple.

Les applications concernées sont-elles" client-serveur " ? Ne peut-on alors faire lestransformations soit dans la partie " serveur ", soit dansla partie " client " ?

Utilisation des progiciels

L'utilisation de progiciel peut éventuellement poser desproblèmes juridiques (propriété des codessources) et techniques au moment de leur transformation.

La recherche des paramètres en francs introduits par lesutilisateurs pour les transformer en euro ne suffit pas ; il estnécessaire de s'assurer que l'éditeur a fait demême pour ceux qui ne sont pas accessibles par l'utilisateur oule maître d'oeuvre. En effet, malgré tous lescontrôles et bien que cette technique de programmation soitformellement réprouvée et interdite depuis longtemps,il peut arriver que des " données " soientintroduites en " dur " dans les programmes (seuilslégaux, constantes, etc.). C'était une pratiquecourante quand on programmait en Assembleur et qui a perdurédans les programmes en Cobol. Difficilement décelables parl'utilisateur d'un progiciel (qui en général n'a pasaccès au langage source), ces données " endur " si elles sont à modifier ne peuvent l'êtreque par l'éditeur.

Avant de prendre contact avec l'éditeur pour déciderdes modifications à faire ou pour introduire un convertisseur,il sera bon de se rapprocher des groupes d'utilisateurs (ils ontaussi les mêmes problèmes) et du CXP (l'association" CXP " développe des compétences dans ledomaine des progiciels ).

Sommaire

 

Ministère de l'Économie, des Finances etde l'Industrie,15/07/1997