Lorsque nous entront des dates de 2 chiffres dans l'ordinateur, nous n'avons que deux options. L'on doit, soit accepter que l'on entre plus d'informations dans l'ordinateur au sujet des 2 chiffres, soit faire des suppositions sur ces 2 chiffres.  

2. Le défi des imprimés.  

Si la solution sur un plateau d'argent est de conserver la présentation à 2 chiffres sur les imprimés, alors il faudra se fier aux hypothèses que les utilisateurs retiendront sur la signification des 2 chiffres et de leur contexte.  

3. Le défi de la formation.  

Si vous décider de changer la manière d'entrer ou d'utiliser les dates dans votre organisation, il est naïf de penser que vous n’aurez pas à former votre personnel.  

4. Le défi de l'intervention humaine.  

L'on croit à tort que nous savons COMMENT les gens utilisent nos systèmes. Avant de changer 'automatiquement' le fonctionnement de votre système, vous devrez comprendre comment votre entreprise l'utilise. Tenir ceci pour acquis, c'est aller au devant de nombreux ennuis.  

5. Le défi du matériel.  

Ce défi est, à la base, d’une grande simplicité. Un logiciel ne peut pas changer la configuration matérielle de votre ordinateur. Si votre ordinateur ne PEUT PAS fonctionner après le 31/12/99, aucun logiciel ne pourra y faire quoique ce soit.  

6. Le défi de l’ambiguïté.  

La plupart des compagnies n'ont jamais eu de normes à la grandeur de l'entreprise en ce qui a trait aux dates. Les dates sont affichées sous différentes formes:  

 -  jj/mm/aa, 
 -  mm/jj/aa, 
 -  aa/mm/jj. 

Dans chaque cas la portion 'aa' nous donne un indice de la date.  

7. Le défi du contexte et du fenêtrage.  

C'est ici que ça devient amusant et que les vrais arguments contre une solution sur plateau d'argent entrent en jeu. Voici le noeud du problème. Quelle date est représentée par 13/01/24?  
Que supposera automatiquement votre solution miracle, et cela sans intervention humaine?  

 - Le 13/01/1824, la date d'achat d'un terrain? 
 - Le 13/01/1924, une date de naissance? 
 - Le 13/01/2024, la fin d'une hypothèque de 30 ans? 

8. Le défi de l'expansion et de l'espace.  

Votre solution sur plateau d'argent agrandira-t-elle les champs de 2 chiffres à 4, ou ajoutera-t-elle un code relatif au siècle?  

9. Le choix entre l'expansion et le fenêtrage.  

Si votre solution miracle doit mener à des décisions quant au choix des traitements de date dans des situations variées, alors il vous faudra tenir compte de vos différents procédés commerciaux. L'ordinateur ne sait rien de ces procédés. Ils n'existent que dans la tête des gens. Ils dépendent parfois de considérations financières.  

10. Le défi de la logique et de la compréhension.  

Il y a eu de ces moments où nous avons tous été déconcertés devant une section de code. On est là qui la regarde pendant des semaines, essayant d'en comprendre le but. Que pensait donc le programmeur qui l'avait conçue? Voici la question. Est-ce qu'une solution miracle saisira de la même façon toutes les sections de même codage ? Plus fondamentalement, est-ce qu'un ordinateur peut 'comprendre' quelque chose?  

11. Le défi du langage.  

La solution miracle de l'an 2000 laisse supposer que le problème entier sera résolu automatiquement. Cela veut dire qu'elle doit être capable de résoudre le problème automatiquement dans tous les programmes, qu'importe les langages avec lesquels ils ont été écrits, même ces uniques et curieux langages maison que les entreprises ont créés pour résoudre des problèmes particuliers.  

Bonne chance!  

12. Le défi d'une faute déjà commise.  

Chercher une solution au problème, de quelque façon, implique la lecture du codage qui n'a pas été revu depuis des années, si jamais il l'a déjà été. Quand vous faites cette lecture, vous découvrez un codage tout simplement erroné. Parfois l'erreur est mineure. Parfois il s'agit d'argent. A votre grande surprise, vous découvrez que vous faites payer trop pour vos services, ou pas assez. OU vous payez trop d'intérêts, ou pas assez. Corrigerez-vous ce genre d'erreurs? C'est à vous d'y réfléchir.  

13. Le défi du codage.  

Venons-en au fond du problème, le changement de codage. Est-ce qu'une solution miracle peut toujours le permettre avec100% d'exactitude?  

14. Le défi du triage et de la gérance de projet.  

Si vous avez une solution miracle, vous aurez à décider des programmes à convertir et dans quel ordre. En d'autres mots vous aurez à élaborer un projet de conversion en tenant compte de l'importance et de l'impact de vos programmes. Vous aurez à établir un plan pour réaliser les changements. Et ce plan devra tenir compte de la compilation de tous vos programmes de façon à ne pas affecter vos opérations en cours.  

15. Le défi de l'inconstance dans le traitement des dates.  

Un des problèmes du processus d'identification est qu'un champ de dates contenant une date dans un programme n’en contiendrait pas nécessairement dans un autre programme. Et ce qui est encore plus embêtant, c’est qu'un champ particulier pourrait contenir une date dans une partie d'un programme mais n'en contiendrait pas dans une autre partie de ce même programme.  

16. Le défi du transfert de données.  

Recevez-vous des données d'autres entreprises? Envoyez-vous des données à d'autres entreprises? Si tel est le cas, comment allez-vous partager les changements de formats lors de la réception et de la transmission des données? Faudra-t-il, encore là, qu'un être humain intervienne?  

17. Le défi de l'aiguillage de logique.  

Si le champ d'années = 99, exécuter une telle opération qui n’a rien à voir avec la date. N’oubliez pas que les programmeurs utilisaient et utilisent encore les champs de dates pour créer des conjonctures ou pour faire des opérations spécifiques quelconques. C'est plus ou moins facile de créer une solution miracle qui identifiera ces conjonctures, et même de faire un champ auxiliaire pour permettre un 'aiguillage de logique'.  

Mais c'est IMPOSSIBLE qu'une solution miracle puisse changer le code pour CHOISIR correctement la logique appropriée, i.e. est-ce un champ de dates ou un champ d'autres choses?  

18. Le défi de la mise à l'essai.  

Aussi formidable ou miraculeuse, c'est le cas de le dire, puisse être votre solution, il vous reste ENCORE à vérifier chaque code soumis à une révision. Et puisque la vérification implique habituellement 50% de la programmation, il vous restera encore au moins 50% du travail à accomplir pour résoudre le problème de l'an 2000. 
 

 Je suis un grand adepte des outils informatiques. Je crois que la seule façon de s'attaquer au problème de l'A2K est de recourir à de tels outils. Procéder autrement ne vous permettrait pas de profiter des économies de 20 à 30% (et peut-être même plus) que ces outils font déjà réaliser à plusieurs entreprises. 

 Certains vendeurs continueront certainement à prétendre qu'ils disposent d’une solution mira²cle, vous pouvez le parier. Je suppose qu'il faudra qu'ils précisent ce qu'ils veulent dire exactement, et agir en conséquence. Quant à moi, j’aurai toujours les mêmes réserves. Qu’ils me prouvent que leurs solutions miracles peut effectivement relever tous les défis dont j’ai parlé et je serai alors disposé à admettre l'existence d'un tel outil. 

 D'ici là, ma réponse à l’affirmation suivante : "Nous avons une solution sur plateau d'argent" sera toujours aussi vigoureuse et 'automatique': "Non, vous n'en avez pas!"  
 
 

Retour