@TITRE:Les préconisations du Cigref

@CHAPO:Il faut mener la bataille de l'an 2000 sur le plan technique (et en particulier aux "bas niveaux" des microprocesseurs et des automatismes) et sur le plan juridique: tout produit livré après le 1/1/1990 doit passer le cap au frais de son fournisseur, estiment les grandes entreprises françaises.

@TEXTE:La précision de l'étude menée par le Cigref (Club informatique des grandes entreprises françaises) aussi bien que sa volonté d'action ont été bien mises en valeur par Vincent Balouet, chargé de mission, au cours de la journée récemment organisée par le CMGF (Computer measurement group France). Il note d'ailleurs que la préparation de cette échéance est actuellement une des principales activités du Cigref. .

@INTER:Partager les coûts avec les fournisseurs

@TEXTE:Le Cigref s'insurge contre une position, exprimée par un grand cabinet juridique, qui mettrait tous les coûts à charge des entreprises utilisatrices. Dans cette optique, l'an 2000 s'impose à tous, tout le monde savait qu'il allait arriver, c'est donc aux utilisateurs de payer.

Le Club estime ce point de vue indéfendable juridiquement, malgré l'inadaptation du droit français aux nouvelles technologies et à l'an 2000 en particulier. D'abord le problème posé par l'an 2000 à l'informatique n'est pas un problème universel, que l'on pourrait supposer connu de tous. Ce n'est pas un problème en soi, par exemple, pour les fournisseurs de champagne. Il s'agit au contraire d'un problème spécifique, celui de la représentation technique des dates dans les systèmes. Or cela n'appartient pas au métier des entreprises clients, les compagnies d'assurances par exemple. De plus, les entreprises peuvent faire jouer notamment trois principes importants: vice caché, jouissance paisible, obligation de mise en garde.

Le vice caché concerne plutôt les machines, les produits achetés. La jouissance paisible relève du louage d'objets, et concerne donc les locations. On n'ira pas jusqu'à l'appliquer à un mainframe oublié dans un coin de l'entreprise, même s'il est maintenu par son propriétaire. Noter qu'en matière de location, c'est le droit du pays où elle s'effectue qui s'applique.

Enfin, le devoir de mise en garde, classique en jurisprudence informatique, s'applique tout particulièrement aux développements. Autrement dit, même si les spécifications d'une application ne prévoyaient pas explicitement le passage à l'an 2000, le fournisseur (à partir du 1/1/1990) aurait du prévenir son client des problèmes à venir. Et doit donc prendre l'évolution à sa charge. Sauf bien sûr si le fournisseur avait pris la précaution de dégager explicitement sa responsabilité sur ce point, ou d'avoir précisé les coûts supplémentaires à prévoir.

@INTER:Une ligne de partage au 1/1/1990

Le Cigref ne prône pas pour autant un extrémisme inverse qui rejette intégralement la charge sur les fournisseurs. Et, à la limite, sur les vendeurs de méthodes de développement. L'objectif n'est pas de ruiner les SSII, mais de corriger les systèmes dans les délais. Chacun doit prendre sa part aux travaux. Il faut trouver un équilibre entre deux extrêmes, faire le partage des responsabilités et des coûts entre les entreprises utilisatrices et les fournisseurs. Reste à le faire "de manière intellectuellement admissible et juridiquement fondée".

Les utilisateurs doivent, en toute hypothèse, corriger à leurs frais leurs propres développements. Notamment les dictionnaires de données, les spécifications, et leurs moyens propres de tests.

Les fournisseurs doivent corriger à leurs frais les versions de matériels et logiciels installés. Mais il serait excessif de l'exiger pour des matériels ou logiciels très anciens, 25 ans, par exemple. Où établir la coupure?

Le Cigref a d'abord pensé au 1er janvier 1986, date d'entrée en vigueur d' un décret sur le régime juridique du logiciel. Mais ce serait tout de même remonter trop loin, et la date du 1er janvier 1990. Elle fait référence à une directive européenne sur la maintenance des produits, elle correspond à la durée normale de vie d'une grosse application. C'est à cette date que l'on a commencé à parle de l'an 2000. Enfin, de grands cabinets juridiques se sont ralliés à cette date de partage.

@INTER:Mettre la pression au plan juridique

@TEXTE:Le Club ne se contente pas de poser des principes. Il préconise de prendre contact avec tous les fournisseurs concernés. Une lettre recommandée avec accusé de réception leur demandera de fournir tous les moyens permettant d'acquérir la certitude que le système est conforme aux exigences du passage à l'an 2000. Il faut exiger que la mise à jour des systèmes existants puisse se faire sans "montée de version à marche forcée". Ce sont les produits livrés depuis le 1/1/1990 qui doivent passer le cap, pas des produits de remplacement plus coûteux. Sinon on assisterait à une forme de racket.

Faute de réponse satisfaisante à bref délai, il faut immédiatement agir, faire monter la pression et la maintenir jusqu'à satisfaction. Il faut faire confiance aux fournisseur pour apporter des réponse à ces questions: les utilisateurs ne peuvent les résoudre à eux seuls. D'ici deux à trois mois, on saura qui doit faire quoi, et les utilisateurs verront alors ce qu'ils doivent faire.

Certains demandent s'il faut attendre de tel ou tel organisme une liste à jour de progiciels testés. Cela ne se fera pas. D'une par les difficultés techniques sont considérables. D'autre part aucun organisme sérieux n'engagera sa responsabilité sur un tel domaine. En revanche, il faut inciter tous les fournisseurs à publier, sur Internet par exemple, le niveau de garantie qu'ils donnent sur les produits dans leurs différentes versions.

@INTER:Un schéma directeur d'urgence

@TEXTE:De toutes façons, il faut aller vite. Il ne reste que 500 jours ouvrables et l'on ne peut décaler l'échéance. Il faut peut-être sacrifier certains applications secondaires pour ne pas bloquer tout l'ensemble. Ce pourrait être une occasion de faire le ménage parmi les applications... et parmi les fournisseurs.

Le sujet est large (*), touche aux matériels comme aux logiciels. Il est donc hors de question de se limiter à la maintenance applicative pour ce problème très compliqué, multiforme. Il faut réaliser un "schéma directeur an 2000", au prix de bousculer le schéma directeur global actuel. Sa mise en oeuvre devra relever d'un directeur, pas d'un petit chef de projet à l'autorité limitée. Assisté d'un comité de pilotage, il mettra en commun les savoir-faire, et devra pouvoir décider rapidement, notamment entre une correction et une refonte. Les fonctions impliquées comprennent bien entendu la direction générale et l'informatique (études et exploitation comprises), mais aussi le réseau, l'organisation et les responsables de systèmes industriels.

La direction des Ressources humaines va devoir intervenir. En effet, les cobolistes senior vont pouvoir sortir de leurs placards (et même certains spécialistes de l'assembleur), et leur contribution pourrait être souvent indispensable. Par ailleurs, il faudra créer pour des équipes de jeunes, une sorte d' " obligation " de trois ans sur cette question. Et résoudre donc les problème de développement et de gestion des carrières qui en découlent. On fera aussi intervenir aussi les services d'Achats, la sécurité (attention aux contrats de backup) et l'audit des systèmes d'information et le service juridique. Bref, le Cigref essaye de ne rien oublier, ni personne! @SIGNATURE:Propos recueillis par Pierre Berger

(*)On ne l'élargira donc pas plus en combinant Euro et an 2000: les deux sujets n'ont rien à voir, sauf pour le planning de charges. Ne pas essayer de régler à la fois des problèmes techniques et fonctionnels. Pas de stratégie commune, mais éventuellement des modifications simultanées au cas par cas.

@LEGENDE INFOGRAPHIE

L'ensemble des composants à prendre en compte pour le passage à l'an 2000, selon le CMGF

ou titre infographie

LES COMPOSANTS A PRENDRE EN COMPTE

(source: CMGF)

@T ENCA1:EDI et RVA

@T ENCA:Il faut étudier avec les sociétés partenaires les modifications de formats d'échanges de données informatisés (EDI). Revoir en ce sens les contrats d'interchange et les protocoles techniques.

On n'oubliera pas de prévoir la synchronisation des changements. Et de penser que toutes ces modifications le même jour, combinés avec les opérations de sauvegarde devraient entraîner un encombrement des réseaux.

Si l'on passe par des réseaux à valeur ajoutée, s'assurer qu'ils pourront eux aussi passer l'an 2000, ce qui l'heure actuelle ne semble pas assuré, même pour de grands prestataires mondiaux et réputés.

Les problèmes de bas niveau: matériel et système d'exploitation

Plus que d'autres experts, l'orateur met l'accent sur les aspects "électroniques" du changement de siècle. Un ordinateur gère la date dans un composant spécialisé, et le Bios du système exploite ce composant. Dans certains cas, la date peut-être mise à jour régulièrement par des signaux radio-horaires codés (DCF77 dans l'Est de la France, France Inter...). Une part importante de ces composants ne peut passer l'an 2000. Sur les micro-ordinateurs, par exemple, on observe souvent un retour à 1980 ou un blocage sur 1999.

Les autocommutateurs actuels ne suivront pas non plus. Des tests menés sur les matériels d'un grand constructeur français ont montré que le passage se traduit sur ses produits par un arrêt machine. Il en a d'ailleurs averti sa clientèle. Parmi les problèmes complémentaire, on note la comptabilisation des communications, l'archivage et l'horodatage correct des messages.

Dans les immeubles, la GTC (Gestion technique centralisée) fait aujourd'hui très souvent appel à des micro-processeurs dont rien ne garantit qu'ils passeront bien l'an 2000. Détection incendie ou intrusion, gestion des abonnements EDF, pilotage des onduleurs et groupes électrogènes... rien ne servirait d'avoir soigneusement fait évolue les applications si, au matin de l'an 2000, les alimentations électriques s'arrêtent. Ou si un système élaboré de contrôle d'accès physique interdisait l'accès aux machines.

Enfin, dans les entreprises industrielles, on n'oubliera pas que 80% des automates programmes sont aujourd'hui à base de micro-processeurs qui ne passeront pas correctement l'an 2000.