Le besoin de comprendre les conséquences du problème de l’an 2000 est plus urgent que jamais, car le temps qu’il nous reste est limité. Même pour les petites entreprises, munies de quelques ordinateurs, le temps requis pour comprendre le problème, faire un inventaire, développer un plan d’action et l’exécuter peut prendre des mois. Ce qui est encourageant, c’est que l’expertise et les outils nécessaires pour devenir compatible à l’an 2000 sont présentement disponibles. Mais l’objectif ne sera pas atteint si nous ne commençons pas à entreprendre les démarches dès maintenant.

Les mythes qui entourent le problème de l’an 2000 sont abondants. La peur ne doit pas être la raison de votre action. Cette dernière doit découler d’une compréhension adéquate des conséquences qui peuvent accompagner cette erreur de calcul et qui doit vous guider dans votre stratégie de résolution du problème. Il ne faut pas non plus assumer que ce problème ne vous causera pas d’inconvénient. La question à se poser n’est pas "est-ce que le problème va nous affecter ?" , mais plutôt "est-ce qu’on peut minimiser les conséquences reliées à cette erreur ?".

La réponse à ces deux questions est un grand ‘’OUI’’. La direction à prendre pour aboutir à une solution valable est le sujet du présent rapport. Les grandes lignes qui encadrent notre plan d’action sont basées sur des standards reconnus par l’industrie des technologies de l’information. Les résultats de nos interventions vous assurent qu’une transition plus douce est en fait possible.

Le problème de l’an 2000, sans doute, devient de plus en plus le point de mire technologique de toute entreprise informatisée. Pour comprendre l’importance de ce problème, il faut donc prendre conscience de son étendue. Presque personne n’échappera aux conséquences de cette erreur de calcul qui est enracinée dans de nombreux instruments et applications. Pour minimiser les effets adverses de cette erreur de calcul incontournable, vous devriez commencer immédiatement à vérifier si vous êtes compatible à l’an 2000.

La vérification et la correction de la compatibilité à l’an 2000 engendre quatre étapes regroupées dans deux phases :

Phase I :

• Inventaire :

• Inventaire des logiciels et de l’équipement
• Utilisation des outils d’essai sur les ordinateurs, les systèmes d’exploitation et les applications
• Communication avec les fabriquants des applications et des équipements utilisés par la compagnie

• Développement d’un plan d’action pour la phase II (rapport préliminaire) :

• Détermination des points à corriger
• Actions à prendre pour résoudre les incompatibilités possibles
• Etablissement d’un échéancier et des coûts pour les actions à prendre
• Planification d’une période de simulation et d’essai

Phase II :

• Réparation, mise à jour ou remplacement des applications et des équipements incompatibles :

• Application des outils de réparation sur les BIOS (Basic Input Output System), sur les RTC (Real Time Clock) et sur les systèmes d’exploitation
• Mise à jour ou remplacement des applications non compatibles
• Essais et simulation pour s’assurer que les changements sont fonctionnels
• S’il y a lieu, le parcourt automatique, semi-automatique ou manuel des données (fichiers) des applications à la recherche de champs incompatibles

• Résolution :

• Finalisation du rapport décrivant les étapes suivies et les actions prises
• Développement d’un plan de recouvrement en cas de désastre

La démarche proposée vous assure une transition moins périlleuse. Il est important de noter que cette procédure va aussi établir votre compatibilité pour les dates problématiques moins connues. Certains outils d’essai vérifient jusqu’à 13 dates. Par exemple, 09-09-1999 peut causer des erreurs parce que plusieurs programmeurs utilisaient 9-9-99 pour effectuer des calculs de comparaison et pour détecter les dates fautives.

Si un ou des problèmes sont détectés, vous devez agir très rapidement. Les besoins de chaque entreprise diffèrent et la réparation de certaines applications peut prendre beaucoup de ressource et de temps. Pour certaines applications, l’inspection des lignes de code et leur modification peuvent être requises.

1.1 C’EST QUOI LE PROBLEME DE L’AN 2000 ?

La base du problème de l’an 2000 est la présence de champs de deux caractères pour enregistrer l’information désignant l’année. Dans ce cas, ‘’1999’’ est mis dans les champs en tant que ‘’99’’. Quand l’an 2000 arrive, l’ordinateur interprète cette date comme s’il s’agissait de ‘’1900’’. Donc, toute information basée sur cette date sera erronée. Cette erreur peut se situer dans le BIOS (Basic Input Output System), dans l’horloge RTC (Real Time Clock), dans le système d’exploitation, dans les applications utilisées, dans les fichiers créés par les usagers et même intégrée dans les puces de divers équipements. Il est même possible que certains problèmes soient déjà apparents dans les calculs des événements au-delà de l'an 2000.

1.2 LES ÉTAPES DE L’INVENTAIRE

1. Inventaire de tous les ordinateurs de l’entreprise.
2. Inventaire de toutes les applications utilisées, de leurs versions et des fabriquants
3. Les caractéristiques des ordinateurs en question :

• L’ordinateur est un poste client, un serveur ou une machine autonome
• Modèle de l’ordinateur
• Type de processeur
• Date et version du BIOS
• Les systèmes d’exploitation utilisés, leurs versions et les mises à jour (patches) installées
• Les modules spécifiques à un fournisseur installés sur le disque dur
• Les modules développés par l’entreprise même
• Les bases de données et les fichiers de tableur (spreadsheet) utilisés régulièrement par les usagers
• L’identité des équipements sur le réseau

1. Rassemblement des données

2- VÉRIFICATION

2.1 LES ESSAIS

Pour les ordinateurs, les tests du BIOS (Basic Input Output System) que nous possédons vont nous confirmer si la transition vers des dates spécifiques est valide. Ces outils nous permettent ainsi de vérifier si l’horloge du système va changer à la date requise, durant la transition. Il y a de bonnes chances que ce test échoue sur la plupart des machines. Si le BIOS est récent, il va probablement rectifier le problème avant que les applications l’utilisent. Mais plusieurs applications tirent leur date directement du RTC (Real Time Clock, l’horloge interne du système), ce qui peut avoir des conséquences graves. Même certains Pentiums, durant la nuit du 31 décembre 1999, peuvent souffrir de problèmes dus au RTC. En fait, cela va à l’encontre de la croyance populaire, selon laquelle les nouvelles machines sont immunes au problème de l’an 2000.

Les fabriquants des applications utilisées par l’entreprise doivent être contactés. Pour chacune des versions de leur produit, il faut leur demander si leur produit est compatible à l’an 2000. Si ce n’est pas le cas, différentes stratégies de résolution doivent être implantées.

Si certaines applications ont été développées à l’interne, par l’entreprise même ou si les concepteurs d’une application ne sont plus disponibles, nous pouvons effectuer les tests requis afin de confirmer la compatibilité de l’application à l’an 2000. Si l’application n’est pas compatible, nous pouvons proposer des solutions, allant de la modification au remplacement. Le développement d’une nouvelle application peut également être proposé comme une solution viable.

2.2 LES ERREURS DOUCES

Il s’agit ici de déterminer si certaines applications mettent en mémoire la date de l’année sous format de 2 caractères. Il faut déterminer si les macros, les champs de base des données et les cellules de tableur (spreadsheet) créés par les usagés traitent les fonctions de temps de façon appropriée.

2.3 Les dates suivantes doivent être vérifiées :

• 12/31/98
• 1/1/99
• 1/4/99
• 9/9/99
• 12/31/99

2.4 Les dates suivantes doivent être vérifiées si le temps le permet :

• 1/1/2000
• 1/2/2000
• 1/3/2000
• 1/4/2000
• 1/5/2000
• 1/31/2000
• 2/28/2000
• 2/29/2000
• 3/1/2000
• 10/10/2000
• 1/1/2001
• 2/29/2004

La documentation de chaque étape est nécessaire pour rendre les essais valides. Ceci nous permet de définir un critère sur lequel s’appuie notre définition de la compatibilité à l’an 2000.

L’inventaire et les essais vont nous donner l’information nécessaire pour effectuer les démarches requises sur la compatibilité à l’an 2000 des applications. Suite à ces démarches, nous allons être en mesure de présenter les solutions disponibles.

2.5 RAPPORT PRÉLIMINAIRE

Après l’inventaire et la vérification, la rédaction du rapport préliminaire est entreprise. Ce document décrit la situation dans laquelle l’entreprise se trouve face au problème de l’an 2000. Ce rapport présente l’état des machines et le relevé obtenu des fabriquants ou des fournisseurs des applications concernant la compatibilité à l’an 2000 de leur produit. Si des produits s’avèrent incompatibles, les solutions disponibles sur le marché ou que nous pouvons vous offrir sont identifiées. La durée et les coûts associés avec cette démarche sont également identifiés.

Les solutions disponibles sur le marcher varient des simples outils de diagnostic à des applications qui réclament faire quasiment tout. On y trouve des outils de réparation, des outils d’automatisation, des outils de gérance spécifique à l’an 2000 et plusieurs autres. Même s’il y a une poussé phénoménale pour trouver la solution parfaite, il y a toujours des problèmes pour lesquels on ne peut trouver de solution toute prête. Pour ces cas, il faut parcourir les applications ou les données, une par une, avec ou sans l’aide d’outils spécifiques.

Il y a des situations où seul le remplacement ou la mise à jour à une version plus récente est permis. Dans le cas des machines, il faut remplacer certaines composantes et, dans le cas des applications, faire une migration des données à une version compatible à l’an 2000 ou carrément à une autre application.

3.1 LA RÉPARATION DU BIOS

Mettre à jour tous les BIOS (Basic Input Output System) est l’étape primaire de notre démarche. Il faut ensuite faire des essais et des simulations pour s’assurer de la qualité de cette intervention. L’horloge du système (Real Time Clock) doit être validée avant toute autre partie du système. S’il n’existe pas une solution semblable, il faut alors changer le BIOS si cela est possible. Si le changement de BIOS n’est pas possible, il faut alors changer la carte maîtresse de l’ordinateur.

Dans certains cas, il peut être plus rentable de changer carrément l’ordinateur pour un modèle plus récent.

3.2 LA RÉPARATION DU SYSTÈME D’EXPLOITATION

Pour la plupart des systèmes d’exploitation, des mises à jour (patches) et des ensembles de service (service packs) peuvent être installés. Dans certains cas, l’installation d’un système d’exploitation approprié peut être recommandée(Windows 98 pour remplacer DOS par exemple). Il faut souligner que la réparation du BIOS (Basic Input Output System), du RTC (Real Time Clock) et du système d’exploitation n’aboutit qu’à une solution partielle, s’il existe encore des problèmes dans les applications.

3.3 LA RÉPARATION DES APPLICATIONS

Pour les applications commerciales standards, il existe des outils qui vont détecter et réparer les problèmes existants. Pour certaines applications, il faut acquérir une mise à jour ou une version plus récente. Pour d’autres, l’achat ou la migration vers une nouvelle application est requise. Selon les circonstances et les objectifs de l’entreprise, la conception d’une nouvelle application peut être la meilleure solution.

Si l’achat d’une autre application, d’une autre version n’est pas une option, il faut s’orienter vers une stratégie de réparation ou vers la conception d’une nouvelle application. Comme cette démarche dépend des applications en place et des besoins spécifiques de l’entreprise, les détails pertinents sont généralement abordés dans le rapport préliminaire.

Finalement, il reste la détection des erreurs douces. Pour cela, il faut identifier les macros, les fichiers de tableurs (spreadsheet) et les programmes fichiers créés par les usagers de l’entreprise même. Il faut les parcourir pour détecter les erreurs qui y sont incorporées.

4.1 CONCLUSION

Même si votre entreprise a fait ses devoirs et que vous êtes prêt pour l’an 2000, plusieurs compagnies ne seront pas prêtes à temps. Pour cette raison, il serait prudent d’établir un plan d’urgence afin d’éviter les problèmes. Demandez à vos fournisseurs, vos distributeurs, vos clients et autres partenaires s’ils sont compatibles à l’an 2000.

Pour plusieurs projets, il est possible que des nouvelles erreurs soient introduites lors d’intervention sur les applications, plus spécifiquement si les lignes de codes sont modifiées. Peter de Jager, dans son livre "Managing 00", prétend que, suite à la modification de 100 000 lignes de code, de 10 à 20 erreurs seront introduites dans l’application. De plus, les ensembles de service (service packs) distribués par les fournisseurs peuvent introduire des erreurs cachées. L’important est d’avoir les ressources disponibles après l’an 2000 pour faire face aux imprévues.

4.2 QUESTIONS

Dans ce document, nous vous avons présenté un aperçu du problème de l’an 2000. Si vous avez des questions ou désirez de plus ample information, n’hésitez pas à nous contacter. Ces sites offrent également une multitude d’information pertinente au problème de l’an 2000 :