 Ce document au format Word |
 Introduction |
Alors que la première étape du passage àl'euro est fixée au 1er janvier 1999, denombreux travaux restent à entreprendre pour les applicationsinformatiques qui devront être opérationnelles pourcette date. Le groupe commun monté entre la Mission euro del'administration et la Chambre syndicale Syntec-Informatique a rendudeux rapports sur les incidences informatiques du passage àl'euro.
Déjà, dans le souci d'avoir une approche commune desquestions relevant du passage à l'euro et de la manièrede les aborder, la Mission de Préparation des AdministrationsPubliques à l'euro (mission Euro) et la Chambre syndicaleSyntec-Informatique (représentation des SSII et deséditeurs de progiciels) ont élaboréconjointement un premier document intitulé " Ladémarche informatique " qui s'attache à donnerun ensemble de définitions et de références destâches principales à entreprendre en distinguant quatreétapes :
Ce document de sensibilisation a été diffuséà plusieurs milliers d'exemplaires. Il a incité denombreuses directions des administrations, des établissementspublics et des collectivités à mener les étudesnécessaires à une première évaluation desenjeux et des charges. Il les a invité à mettre enplace les organisations adéquates pour adapter l'ensemble dessystèmes d'information.
Cette deuxième contribution du groupe commun montéentre la " mission Euro " de l'administration et la Chambresyndicale Syntec-Informatique s'attache à apporter unéclairage sur ce qui constituera le coeur du problèmedu passage à l'euro des applications informatiques àsavoir le convertisseur.
Comme son nom l'indique la " fonction de conversion " apour but de convertir une monnaie dans une autre et au casprésent des francs en euros et réciproquement. Lafonction mathématique qui se traduit au premier abord par unesimple division ou multiplication, se complique singulièrementlorsqu'il faut gérer des arrondis et quelques autresparamètres afin de reconstituer, par exemple, un calculà sa source.
Ce document décrit les principales caractéristiqueset fonctions attendues d'un convertisseur quelle que soit sonorigine : conception interne ou progiciel d'un fournisseur.
À l'expérience, il n'est pas toujoursnécessaire de prendre le convertisseur le plussophistiqué pour traiter des opérations relativementsimples sachant que plus la fonction de conversion sera complexe,plus les temps de calcul seront longs et plus l'espace de stockagenécessaire à la conservation des informations seraimportant.
Ainsi donc il appartiendra au maître d'ouvrage, enl'occurrence le service utilisateur final, d'établir uninventaire de ses besoins et de rechercher en interne, ouauprès du marché des logiciels, les fonctions deconversion adaptées à ses préoccupations.
Dans le cadre du passage à la monnaie unique, lesentreprises et les administrations vont devoir adapter leurssystèmes d'information et faire appel à desconvertisseurs afin de traiter des opérations franc et eurosimultanément pendant toute la phase transitoire du passageà l'euro.
D'une façon générale, un convertisseureuro/franc est défini comme un algorithme de conversion quipermet, à partir d'un montant initial en euro (ou en franc),de déterminer la valeur équivalente de ce montant enfranc (ou en euro).
Le convertisseur sera principalement utilisé pendant laphase transitoire du passage à l'euro. Celle-ci sedéroulera en deux périodes : la première du1er janvier 1999 au 31 décembre 2001verra l'introduction de l'euro, l'extension progressive de sonutilisation et le maintien d'opérations en franc, la secondedu 1er janvier 2002 au 30 juin 2002(au plus tard) donnera lieu au basculement en euro et au retrait dufranc.
La mise en place de convertisseurs prendra plusieurs formes :
Les convertisseurs à mettre en œuvre dans le cadre desprojets euro devront ainsi répondre à plusieurs typesde besoins distincts. Au-delà de la simple conversion d'uneexpression monétaire du franc vers l'euro (etréciproquement), les convertisseurs doivent disposer defonctionnalités plus larges, nécessaires par exemple,pour assurer la " traçabilité " desopérations de conversion, l'ajustement comptable desopérations traitées (problème de la gestion desarrondis) et le suivi d'exploitation des conversions de fluxopérées.
Ces fonctions ont été regroupées en sixcatégories :
La problématique de conversion des flux débute avecl'identification de celui-ci et la déterminationéventuelle d'un processus de conversion à appliquer auflux considéré. Concrètement, il estnécessaire :
L'un des éléments critiques est la capacitédes solutions mises en œuvre à gérer lesévolutions du système d'information (migration d'uneapplication du franc vers l'euro par exemple) par un simpleparamétrage destiné à activer oudésactiver un processus de conversion, plutôt que parune modification des procédures d'appel aux convertisseursdans chacun des programmes concernés.
On appelle " taux de conversion " la valeur en francsd'un euro. Ce taux sera définitivement fixé dans lespremiers jours de 1999. Il s'agira d'un nombre à 6 chiffresdont cinq après la virgule. L'utilisation du taux inverse dansles fonctions de conversion est interdite.
Si l'on transforme des francs en euros, il faut diviser le montantinitial par le taux de conversion.
Si l'on transforme des euros en francs, il faut multiplier lemontant initial par le taux de conversion.
Les convertisseurs doivent naturellement être en mesured'assurer des conversions unitaires d'une monnaie vers une autre.
A minima, ils doivent permettre de convertir un montant, ou uneliste de montants, du franc vers l'euro et réciproquement, enrespectant un certain nombre de règles :
Lorsque le convertisseur est utilisé pour effectuer uneconversion, au sein de la " zone in " d'une monnaie versune autre, la conversion doit s'opérer en deux temps :
Lorsque le processus de conversion opère sur unesérie de montants, il doit être possible d'effectuer unetotalisation " verticale " partielle ougénérale, c'est à dire restituer en sortie duconvertisseur la somme des montants convertis.
Les applications gèrent, le plus souvent, des valeurs quifont l'objet de sommations ou d'agrégats. Il est doncnécessaire qu'elles utilisent un convertisseur qui effectueà la fois la totalisation des montants initiaux et celle desmontants convertis.
En effet, le convertisseur doit effectuer :
Selon les besoins de l'application, il conviendra de retenir soitla conversion de la somme des montants initiaux, soit la somme desmontants convertis.
Le rapprochement de la somme des conversions des montantsunitaires et de la conversion du total des montants unitairesinitiaux, permet de déterminer la différenceliée à des niveaux de conversion différents. Ilest nécessaire de faire ce rapprochement lorsque deuxapplications destinées à communiquer n'appliquent pasla conversion au même niveau.
Enfin, il est souhaitable que les convertisseurs puissentréaliser différentes opérations en modifiant lecas échéant la structure de l'enregistrement :
Les règles d'arrondis ont été clairementprévues par le règlement communautaire n° 1103/97sur 17 juin 1997 et ont fait l'objet d'une récente publicationde la mission Euro, en mai 1997.
En pratique, le traitement des arrondis est différent selonles règles de gestion des applications. On peut par exempleretenir une égalité entre les deux valeurs aumillième près pour une transformation de franc en europuis en mark, au centième près pour une conversionsimple franc en euro. Une marge plus importante peut êtreautorisée dans certains cas (exemple : arrondi àla dizaine de francs inférieure).
La conversion monétaire pose différentsproblèmes liés aux arrondis effectués sur lesmontants convertis (tronqués à deuxdécimales) :
Le premier problème se présente lors de laconversion d'un montant franc en euro (pas dans l'autre sens), alorsque le problème de l'écart de totalisation se pose dansles deux sens.
Les convertisseurs doivent donc permettre une gestion de cesdifférences d'arrondis et alimenter de manièreoptionnelle (en particulier lorsque la conversion peut avoir uneincidence comptable), un ou plusieurs fichiers de notification desécarts.
Ces fichiers pourront ensuite être retraitéscomptablement afin de disposer de comptes-rendusd'événements permettant de justifier lesécritures de régularisations qui devront êtrepassées.
Un cas particulier : la conversion d'un lot comptable
Dans ce cas, le convertisseur doit être en mesured'intégrer directement dans le lot comptable uneécriture débit ou crédit derégularisation destinée à équilibrer lasomme des débits et celle des crédits aprèsconversion (faute de quoi, le lot ne saurait être pris encharge par le système comptable).
Si une application gère simultanément les deuxexpressions monétaires, le convertisseur doit :
De même, il doit être en mesure de formater lerésultat du calcul, d'opérer les bons arrondis etd'informer de la monnaie manipulée.
La présentation finale du résultat de conversion(écran ou impression) est du ressort des applicatifs, quidevront être adaptés si l'on souhaite par exemple fairedu double affichage (dédoublement des zones montant etindication du code monnaie).
Il est toutefois envisageable de créer des" convertisseurs d'écrans " au niveau du moniteurtransactionnel, activables par exemple à partir d'unetouche fonction du clavier pour donner une vue convertieindicative des différentes zones contenant des expressionsmonétaires.
Pour reconstituer les données initiales, on a besoin :
La conversion des flux doit répondre à un besoin detraçabilité. Il est donc nécessaire de pouvoirproduire la preuve du résultat de certains processus deconversion. Cela peut se faire de plusieurs manières :
La seconde méthode peut s'avérer nécessaireen particulier lorsque le processus de conversion fait appel àdes éléments de contexte qui ne peuvent êtrereconstitués (lecture d'une base de données, etc.). Cemécanisme permet de conserver la piste d'audit, mais il doitpouvoir être inhibé pour éviter la duplicationsystématique de gros volumes.
La mise en œuvre de convertisseurs doit donc s'appuyer surune historisation sélective (optionnelle) des flux enentrée et en sortie des processus de conversion.
À partir des historiques de conservation desdonnées, il doit naturellement être possible de :
Les " convertisseurs " doivent permettre auxutilisateurs comme aux exploitants d'assurer un suivi des flux etdes opérations de conversion. Pour cela, il est souhaitable dedisposer des fonctionnalités suivantes :
des fonctions de consultation :
des historiques de traitement :
des fonctions d'exploitation manuelles :
des fonctions statistiques, par exemple :
Pour ce faire, il est nécessaire d'assurer unejournalisation de toutes les opérations de conversion enconservant la trace de la date et de l'heure d'exécution desdifférents modules de conversion, des fichiersconcernés.
Cet algorithme se compose d'une opérationmathématique associée à une méthoded'arrondi.
Pour convertir des francs en euros, l'opérationmathématique est une division. La valeur initiale en francs (2décimales) est divisée par le taux de conversion (5décimales).
Pour convertir des euros en francs, l'opérationmathématique est une multiplication. Le montant en euros (2décimales) doit être multiplié par le taux deconversion (5 décimales).
Le résultat obtenu peut avoir 7 décimales (cas de lamultiplication) ou plus (cas de la division). Il convient alors dedéfinir la méthode d'arrondi retenue.
Si les conversions ont pour objet de transformer des francs eneuros puis de convertir ces euros en une autre monnaie nationale quele franc, la méthode d'arrondi doit permettre d'obtenir unrésultat en euros avec au moins 3 chiffres significatifs, ilfaut alors arrondir au millième le plus proche.
Si au contraire, les conversions ne concernent que le franc etl'euro, les montants résultats en francs et en euros devrontcomporter 2 chiffres significatifs après la virgule. Laméthode d'arrondi recommandée est celle de l'arrondi aucentième le plus proche (le centième estinchangé si le millième est compris entre 0 et 4-bornes incluses-, il augmente d'une unité si lemillième et compris entre 5 et 9 -bornes incluses-). Cetteméthode garantit de retrouver le montant initial exact lorsd'une conversion unitaire euro/franc/euro.
La nature de la production des convertisseurs variera selon qu'onles utilise pendant la première ou la seconde périodede passage à l'euro et selon que l'environnement franc ou euroest prépondérant. Il conviendra donc :
Le convertisseur est réversible lorsqu'il permet deretrouver le montant initial à partir d'un montant converti.
En effet, un montant exprimé à l'origine en francsqui est converti en euro puis reconverti en francs, peutgénérer un écart entre le montant d'origine etle montant final, cet écart pouvant être compris entre-4 et +4 centimes.
Le convertisseur sera réversible si on associe au montantinitial en francs, d'une part le montant converti en euro et d'autrepart la différence d'arrondi.
Lorsque l'ergonomie des applications le permet (en particulierlors de l'utilisation d'interfaces graphiques), le convertisseur doitpouvoir présenter à l'opérateur, sur sa demandeet dans une fenêtre indépendante, le contenu des zonesde travail et les montants intermédiaires utilisés.
À l'issue de la phase transitoire, le convertisseurdeviendra obsolète. Il convient donc de prévoir unefonction d'inhibition (par exemple : au-delà d'une datede péremption).
La première règle recommandée concerne ladétermination des codes permettant d'identifier l'euro et lefranc. Cette codification recouvre trois recommandations :
1) la codification internationale des devises impose uncode sur trois caractères. Dans cette optique l'euro doitêtre représenté par la valeur " EUR "et le franc français par " FRF ".
2) le symbole de l'euro est en cours de définitiondans les tables de transcodage informatiques (ASCII, EBCDIC, ...)comme peuvent l'être déjà certaines autresmonnaies ($ pour le dollar, £ pour la livre sterling). Cesymbole, qui devra être utilisé dans les restitutionsafin de différencier les montants francs ou euros est lesuivant :
En attendant qu'il figure sur les claviers, il conviendrad'utiliser provisoirement le code " E ".
3) le code monnaie de la facture ou du paiement(" E " ou " F ") est véhiculéà l'intérieur des applications et dans leséchanges entre les différentes applications(interfaces, transferts).
Ces différents codages étant susceptiblesd'évoluer, il est préférable de les signaler enparamètres aux applications.
Afin de procurer une meilleure lisibilité, il estrecommandé de définir une norme d'affichage desmontants sur les écrans et sur les étatsédités.
En effet, les applications seront amenées, dans un certainnombre de cas, à faire cohabiter des montants en francs et eneuros sur les mêmes grilles, il est donc important quel'utilisateur sache facilement distinguer le montant en francs dumontant en euros.
Un positionnement constant des montants l'un par rapport àl'autre est recommandé. Il peut êtredécidé, par exemple, que le montant francprécédera toujours le montant euro. Le montant en eurossera alors systématiquement positionné au mêmeniveau sur la ligne inférieure, ou à droite sur lamême ligne, par rapport au montant en francs.
© Ministèrede l'Économie, des Finances et de l'Industrie,19/11/97