0
) du topic sur le crash du 15 octobre.Le bogue(et oui c'est le terme français pour ceux qui ne le saurait pas
) de l'an 2000 est un mythe, ou sommes nous face a un réel crash évité. Allons nous reconduire le soucis avec nos serveur UNIX et le Timespand?
Pour UNIX une chose est sur c'est un grand NON. C'était pour être technique un problème de variable signé.. en gros elle allait se retrouver dans le négatif. Mais la majorité des distrib Unix on corriger le Bogue en rendant la variable Unsigned. En gros aucun Bogue pour l'an 2038....
.Une simple mis a niveau des system et hop corriger.
Alors la question est était ce pareil avec le bogue de l'an 2000 ??
Élément de réponse :
Citation
Contrairement à ce que laisse entendre l'appellation commune de « bogue de l'an 2000 », le problème de l'an 2000 n'était pas à proprement parler un bogue, comme l'ont bien souligné plusieurs experts Y2K aux États-Unis, mais une erreur de conception systémique[1]. Cette erreur a nécessité dans bien des cas de revoir en profondeur l'architecture des systèmes d'information selon une approche systémique, en particulier lorsque certains composants critiques du système d'information ne pouvaient pas être réparés parce qu'ils étaient trop anciens et n'étaient plus maintenus. Il a donc souvent fallu remplacer complètement des systèmes d'information, généralement spécifiques, par des progiciels du marché compatibles an 2000. Les systèmes plus récents ont pu être réparés par conversion.
Citation
Migration vs conversion [modifier]
Revenons aux deux types de stratégies adoptées par les grandes entreprises dans la décennie 1990, pour en analyser les forces et les faiblesses :
La migration des anciennes applications vers de nouvelles applications,
très souvent des progiciels de gestion intégrés (PGI), sous Unix (dans l'industrie principalement). En Europe, ce type de stratégie a présenté l'avantage de coupler le passage à l'an 2000 et à l'euro, donc de réduire globalement les coûts. En effet, le passage à l'euro consistait alors en une mise à jour vers une version euro, puis en une bascule à l'euro selon les spécifications du fournisseur de PGI. L'autre avantage réside dans le passage à des systèmes complètement rénovés, avec des architectures informatiques mieux normées. Environ 60% des grandes entreprises françaises ont adopté ce type de stratégie selon un expert du CIGREF.
La réparation (ou conversion).
Ce deuxième type de stratégie a concerné les entreprises moins prévoyantes, ou dont la complexité des systèmes ne permettait pas de mieux anticiper le problème. En Europe, il comportait l'inconvénient de nécessiter une double conversion pour le passage à l'an 2000 et à l'euro, donc d'augmenter les coûts. D'autre part, ces entreprises sont restées avec d'anciennes architectures d'applications informatiques moins normées. Environ 40% des grandes entreprises françaises ont opté pour cette stratégie selon le même expert du CIGREF.
Les plus petites entreprises avaient des problèmes beaucoup plus légers, dans la mesure où elles étaient déjà équipées de progiciels, qu'il suffisait de mettre à jour vers des versions conformes an 2000 et euro.
Revenons aux deux types de stratégies adoptées par les grandes entreprises dans la décennie 1990, pour en analyser les forces et les faiblesses :
La migration des anciennes applications vers de nouvelles applications,
très souvent des progiciels de gestion intégrés (PGI), sous Unix (dans l'industrie principalement). En Europe, ce type de stratégie a présenté l'avantage de coupler le passage à l'an 2000 et à l'euro, donc de réduire globalement les coûts. En effet, le passage à l'euro consistait alors en une mise à jour vers une version euro, puis en une bascule à l'euro selon les spécifications du fournisseur de PGI. L'autre avantage réside dans le passage à des systèmes complètement rénovés, avec des architectures informatiques mieux normées. Environ 60% des grandes entreprises françaises ont adopté ce type de stratégie selon un expert du CIGREF.
La réparation (ou conversion).
Ce deuxième type de stratégie a concerné les entreprises moins prévoyantes, ou dont la complexité des systèmes ne permettait pas de mieux anticiper le problème. En Europe, il comportait l'inconvénient de nécessiter une double conversion pour le passage à l'an 2000 et à l'euro, donc d'augmenter les coûts. D'autre part, ces entreprises sont restées avec d'anciennes architectures d'applications informatiques moins normées. Environ 40% des grandes entreprises françaises ont opté pour cette stratégie selon le même expert du CIGREF.
Les plus petites entreprises avaient des problèmes beaucoup plus légers, dans la mesure où elles étaient déjà équipées de progiciels, qu'il suffisait de mettre à jour vers des versions conformes an 2000 et euro.
Citation
Aspects économiques [modifier]
De nombreuses estimations ont été avancées sur le coût de la correction du bogue, surtout aux États-Unis. Les plus sérieuses sont celles du cabinet d'analyse stratégique Gartner Group, qui a estimé en 1995 que le projet Y2K coûterait environ 300 à 600 milliards de $ dans le monde, sur la base de 300 à 600 milliards de lignes de programme existant dans le monde, et 1 $ par ligne de programme à convertir.[2]
Le coût est extrêmement variable selon qu'on le restreint aux conversions de code proprement dites, ou bien si l'on y inclut le coût de mise en œuvre de tous les progiciels qu'il a fallu déployer au cours de la décennie 1990 pour remplacer d'anciennes applications devenues obsolètes.
On a estimé que ce coût s'est réparti à peu près à parts égales en Amérique, en Europe, et en Asie.
Le projet a donc coûté entre 100 et 200 milliards de $ en Europe.
Le traitement du passage informatique à l'an 2000 a créé un important appel d'air sur le marché de l'emploi informatique, d'autant plus qu'en Europe cette échéance était quasi-simultanée avec le passage à l'euro. Même si les systèmes internet étaient peu concernés, la bulle internet a aussi encore accru cet appel d'air. Les sociétés d'informatique (constructeurs informatiques et sociétés de services en informatique) ont alors fortement augmenté leurs effectifs.
La surcharge de travail autour de l'an 2000, aggravée encore par le passage à l'euro, a aussi entraîné une dépression sur le marché informatique à partir de 2002.
De nombreuses estimations ont été avancées sur le coût de la correction du bogue, surtout aux États-Unis. Les plus sérieuses sont celles du cabinet d'analyse stratégique Gartner Group, qui a estimé en 1995 que le projet Y2K coûterait environ 300 à 600 milliards de $ dans le monde, sur la base de 300 à 600 milliards de lignes de programme existant dans le monde, et 1 $ par ligne de programme à convertir.[2]
Le coût est extrêmement variable selon qu'on le restreint aux conversions de code proprement dites, ou bien si l'on y inclut le coût de mise en œuvre de tous les progiciels qu'il a fallu déployer au cours de la décennie 1990 pour remplacer d'anciennes applications devenues obsolètes.
On a estimé que ce coût s'est réparti à peu près à parts égales en Amérique, en Europe, et en Asie.
Le projet a donc coûté entre 100 et 200 milliards de $ en Europe.
Le traitement du passage informatique à l'an 2000 a créé un important appel d'air sur le marché de l'emploi informatique, d'autant plus qu'en Europe cette échéance était quasi-simultanée avec le passage à l'euro. Même si les systèmes internet étaient peu concernés, la bulle internet a aussi encore accru cet appel d'air. Les sociétés d'informatique (constructeurs informatiques et sociétés de services en informatique) ont alors fortement augmenté leurs effectifs.
La surcharge de travail autour de l'an 2000, aggravée encore par le passage à l'euro, a aussi entraîné une dépression sur le marché informatique à partir de 2002.
Voila manque plus que la suite des postes et une bonne discussion bien animée.
