Le bogue de l'an 2000   


Si tous les journaux grand public ainsi que les magazines spécialisés voire les revues techniques n’éditant pas dans le domaine informatique ont pu traiter du bogue de l’an 2000 à la suite des réactions et prédictions souvent alarmistes des plus grandes entreprises ou institutions nationales, ce n’est pas tant par effet de mode que par volonté de faire prendre conscience des risques et conséquences du bogue redouté.

Ledit bogue attendu est celui du 01er janvier 2000 qui engendrera un dysfonctionnement des systèmes d’exploitation et de toutes les applications ayant une date pour paramètre essentiel. En effet, les puristes de l’informatique nous expliquent que certains langages de programmation (dont Cobol et Fortran) sont construits de telle façon que l’instruction 9.9.99 correspondant à la date du 09 septembre 1999 pourrait être interprétée comme un message d’erreur générale entraînant l’arrêt rétif du système pendant un jour. Mais, à plus grande échelle, la datation 00 pour l’an 2000 correspondra à l’année 1900 puisque seuls deux digits ont été retenus pour dater les Bios. En conséquence, le retour à l’année 1900 après 1999 étant chronologiquement illogique pour vos progiciels, ceux-ci risquent de s’arrêter de fonctionner entraînant ainsi indifféremment, le non versement des prestations sociales, l’arrêt des systèmes de navigation aériens, le blocage des distributeurs de billets de banque, l’effacement des fichiers boursiers, comptables ou de gestion voire l’extinction permanente de votre réseau. Pour avoir une idée du sérieux de l’événement, observons que les compagnies aériennes Lufthansa et Northwest prévoient l’annulation de leurs vols durant la dernière nuit du siècle.

Il est donc important que les utilisateurs et les prestataires de services informatiques aient conscience de l’urgence à mettre leurs logiciels ou leurs développements à jour de façon à ce qu’ils soient compatibles an 2000. L’objet de la présente chronique est de donner quelques indications sur la définition du responsable en cas d’incident lié au bogue et sur les modalités de recouvrement ou de paiement des frais engendrés par le bogue.

La question présente un intérêt pratique tant au regard des utilisateurs qui seraient dans l’impossibilité de poursuivre leurs activités qu’à celui des ingénieurs de SSII qui développeraient un produit conforme au cahier des charges mais impropre à passer l’an 2000.

Il ne fait pas de doute que mis à part l’hypothèse résiduelle du client professionnel de l’informatique, le fournisseur du matériel informatique ou du progiciel développé pourra être déclaré seul responsable sous certaines conditions variables selon la nature de l’action intentée contre lui.

En effet, si votre programme informatique ne passe pas le 1er janvier de l’an 2000, vous disposez de recours judiciaires dont l’efficacité dépend des fondements juridiques retenus à l’appui de votre action. Les premiers ont une issue techniquement incertaine alors que les seconds nous paraissent plus efficaces.

Au rang des premiers figurent la Directive communautaire 85-374 du 25 juillet 1985 sur les produits défectueux, les règles de la dissimulation dolosive et la Loi du 19 mai 1998 relative à la responsabilité du fait des produits défectueux.


Certaines réponses ministérielles (dont JOANQ p.1221 du 10/03/97) estiment que votre fournisseur peut-être poursuivi en dommages-intérêts sur la base des normes européennes ; malgré les options libérales du juge communautaire, il nous semble que la directive peut difficilement être appliquée en raison de la définition prétorienne limitée du produit dont l’utilisation doit entraîner des conséquences matérielles pour les individus ou l’environnement.

La dissimulation dolosive fait référence à la situation, marginale, où soit le fournisseur avait connaissance des défauts du programme délivré et a eu recours à des manœuvres visant à vous induire en erreur pour vous cacher les insuffisances de son programme, soit vous à délivrer un produit non compatible malgré les interrogations que vous avez formulées. Cette situation se rencontre le plus souvent chez certains revendeurs indépendants de matériel informatique, ou chez des programmeurs qui pensent à tort se décharger par une délivrance conforme au cahier des charges ou par le prononcé de la recette après des jeux de test apparemment concluants.

La loi du 19 mai 1998 est rédigée dans des termes qui la rendent plus applicable que la Directive européenne mais elles posent quelques problèmes pratiques au rang desquels, la limitation du nombre de bénéficiaires puisque seuls les programmes informatiques acquis après le 19 mai 1998 entreraient dans son champ d’application. Par ailleurs, nous craignons que sa rédaction ne vise que les dommages matériels faits aux personnes et aux biens excluant ainsi les dommages économiques tels que les préjudices commerciaux ou financiers issus du bogue de l’an 2000.

Face à ces mises en cause incertaines, il existe d’autres moyens plus efficaces de mise en œuvre de la responsabilité du fournisseur dont la source est tantôt légale tantôt contractuelle.

Ainsi, du point de vue légal, les utilisateurs de programmes informatiques bénéficient d’obligations à la charge de leur fournisseur. Ce sont les obligations d’information, de délivrance conforme et la garantie des vices cachés.

On entend par obligation d’information, le devoir pour votre fournisseur de vous renseigner, de vous conseiller et de vous mettre en garde.

Le renseignement doit porter sur les caractéristiques techniques principales du programme acquis ou développé. Généralement, la facture ou le cahier des charges en font foi et tiennent lieu de documents contractuels.

Le conseil suppose de la part du fournisseur un avis sur la structure du programme dont vous avez besoin sachant que dans ce domaine l’utilisateur a une obligation de collaboration pour aider le fournisseur à donner un avis pertinent. Il va de soi que cette obligation de collaboration tend à rétrécir l’étendue de l’obligation de conseil lorsque le contrat met en relation deux professionnels de l’informatique, le client ne pouvant plus alors se prévaloir du défaut de conseil là où il est irréfragablement réputé par les tribunaux être aussi compétent que son fournisseur.

La mise en garde fait obligation au fournisseur de mentionner au contrat toutes les contraintes inhérentes à l’utilisation du programme et à sa pérennité. En vertu de cette obligation et dès lors que la capacité pour un programme de fonctionner au-delà du 1er janvier 2000 doit être considérée comme une qualité substantielle du produit en cause, le fait pour un fournisseur de s’abstenir d’apporter cette précision avant l’achat ou la commande du programme suffit à entraîner sa responsabilité.

Le fait que le programme ait fonctionné normalement avant l’an 2000 n’a aucun effet sur l’obligation de mise en garde ; néanmoins, en l’absence de jurisprudence ayant statué sur la question (et pour cause, les préjudices n’étant pas encore subis) il nous semble pertinent de relever que la date d’acquisition du programme « bogué » sera importante dans l’issue des contentieux qui ne manqueront pas d’être engagés. En effet, compte-tenu de la durée de vie d’un programme ou de son délai d’obsolescence technologique, il nous semble que l’obligation de mise en garde à la charge du fournisseur variera selon que le programme en cause est plus ou moins récent ; on comprendrait difficilement la condamnation du fournisseur d’un programme datant de 1981 alors qu’un programme de 1997 doit pouvoir passer l’écueil du bogue an 2000 à moins que le client profane ait renoncé explicitement à cette exigence.


L’obligation de délivrance conforme varie selon que l’on est en présence d’un programme courant acheté dans le commerce ou d’un programme développé par un professionnel pour le compte spécifique du client.

Dans le premier cas, la délivrance est conforme lorsqu’elle s’effectue dans les conditions prévues par la documentation (facture, spécifications, et manuel-système). A cela et pour les programmes récents, on ajoute la capacité à passer le 01er janvier 2000, condition d’achat implicitement convenue et commune aux parties.
Dans le second cas, si le cahier des charges prévoie la compatibilité an 2000, la recette du logiciel sera refusée et le fournisseur responsable d’une délivrance non conforme. Par contre si la recette du logiciel a déjà été prononcée, il semble que le client ne puisse plus invoquer la non conformité malgré la révélation ultérieure du bogue, et ce depuis le jugement du T.com. Créteil du 16/06/1998 très favorable au fournisseur et qui prend appui sur le fait qu’à la date de réalisation du programme les impératifs an 2000 n’étaient pas pris en compte par les professionnels. Cet argument, si peu juridique, ne devrait pas résister pas à l’appel surtout après le revirement de la Cour de Dijon.

Si l’obligation de délivrance conforme prête à discussion, le client lésé disposera toujours de l’action en garantie des vices cachés.

Les thuriféraires du droit des technologies nouvelles tentent souvent de faire croire que l’informatique présente de telles caractéristiques que les textes actuels ne seraient pas applicables. Ainsi a-t-on pu lire et entendre sur des ondes très écoutées que le bogue du 01er janvier 2000 n’est pas un vice caché parce que le choix de deux digits répondaient à des impératifs économiques de gestion de la mémoire de systèmes et que ce même choix était connu des utilisateurs puisqu’apparents sur l’interface.

Le langage « windows-up-to-date » ne doit pas faire illusion ; à notre sens nous sommes bien en présence d’un vice conforme aux termes clairs de l’article 1641 du code civil dès lors que le programme est impropre à l’utilisation à laquelle il était destinée et ce même s’il a fonctionné auparavant. Tout au plus pourra-t-on admettre que le vice ne saurait être caché à un professionnel de l’informatique et qu’une fois de plus, la date d’acquisition du programme en cause sera déterminante. L’issue contentieuse de droit commun d’une action en garantie des vices cachés pouvant s’avérer économiquement insuffisante, il faudra établir une stratégie judiciaire de mise à jour gratuite par le fournisseur en usant des voies de contrainte judiciaire sous astreintes journalières, surtout si le client n’est pas lié à son fournisseur par un contrat de maintenance gratuite et illimitée.

Au-delà des garanties légales, il existe quelques moyens contractuels de se prémunir du risque juridique engendré par le bogue de l’an 2000 en assurant la bonne gestion des contrats passés par le client avec son fournisseur de logiciel et son assureur.

Dans la relation avec le fournisseur de logiciels, l’idéal est la mention contractuelle d’une clause an 2000 garantissant le client que le changement de millénaire n’aura aucune influence préjudiciable sur le fonctionnement de son programme. En pratique l’efficacité de cette clause est limitée aux dysfonctionnements générés par le matériel ou un programme concurrent.
Si votre contrat de logiciels n’intègre pas cette clause et qu’elle ne figure pas sur la documentation, il est absolument nécessaire de vous en préoccupez tant pour établir la responsabilité du fournisseur que pour vous mettre dans les conditions de mise en œuvre de votre contrat d’assurance responsabilité professionnelle au cas où le bogue aurait des répercussions sur vos relations commerciales.

Plus efficacement et sur la base de la jurisprudence de la Cour d’appel de Dijon du 4 février 1999, l’existence d’un contrat de maintenance et de garantie illimité vous protège efficacement des réparations, mises à jour et charges financières induites par le bogue. En effet, la Cour a contraint un fournisseur prestataire en informatique à adapter gratuitement un programme écrit depuis 1986 au passage de l’an 2000 en considérant non seulement que le client était ignorant des contraintes an 2000 et qu’en vertu du contrat d’assistance qui les liait, la mise à jour an 2000 ne pouvait pas être considérée comme un module nouveau facturable dès lors qu’elle servait à maintenir le fonctionnement normal du programme.

C’est donc la consécration implicite de la règle selon laquelle le client est en droit d’exiger que ses programmes informatiques soient aptes à l’an 2000 sans qu’une facturation supplémentaire puisse être exigée en vertu du caractère essentiel de cette fonctionnalité qui justifie l’invocabilité de la garantie des vices cachés mentionnée ci-dessus.

Enfin, les assureurs français, fidèles à leur réflexe, refuse d’ores et déjà de prendre en compte le risque an 2000 ou au contraire proposent des contrats spécifiques, en faisant valoir tantôt que le bogue an 2000 n’est pas un aléa assurable puisque nous sommes sûrs qu’il y aura un 01er janvier an 2000, tantôt que le risque et l’incertitude sont tels qu’il faille conclure une cotisation spécifique.

A notre avis, les assureurs pourront difficilement faire valoir que les contrats d’assurance responsabilité civile courants ne couvrent pas le conséquences engendrées par le bogue de l’an 2000 ; si votre société se trouve incapable d’assurer les prestations requises de vos clients à cause du bogue, il est clair qu’à défaut de clause d’exclusion de la couverture bogue expressément mentionnée au contrat, les assureurs devront faire jouer la garantie consentie au client dès lors que ce dernier pourra démontrer avoir fait le nécessaire pour s’assurer que son installation passerait le 01er janvier 2000 sans encombre. Cette condition explique la frénésie actuelle des audits juridiques et des expertises informatiques conjointes visant à attester de la conformité des programmes et de la protection juridique y afférente afin de rendre aléatoire la survenance du bogue, permettant ainsi la prise en charge des conséquences par l’assureur.

Il vous reste donc quatre mois pour faire réaliser un audit juridique et mettre à jour vos contrats pour préparer la réparation à coût zéro et la couverture à 100% des éventuelles conséquences préjudiciables du bogue de l’an 2000.
Droits réservés 3ème trimestre 1999 – Septembre 1999
Constance SOLLÉ




Paiment sécurisé avec CyberMUT
  Partage
Twitter  Facebook Google

Flux RSS
 Add to netvibes  http://www.wikio.fr  Ajouter à Google
Retrouvez toutes nos coordonnées sur Juritel.tel

Suivre Juritel sur Twitter
Suivre JURITEL sur TWITTER

 
P@rticip@tion :Azique