INTRODUCTION
Le 31 décembre 1999, à zéro heure, quand
résonnera le 12ème coup de minuit… les prédictions des informaticiens
sont des plus pessimistes : les avions ne devraient pas décoller, les satellites se
percuteront, les bateaux se perdront, les ascenseurs se bloqueront... Bref, le pire
n’est certes pas toujours le plus probable, mais nul doute que le coup sera rude (1).
Les problèmes posés aux systèmes informatiques par l’an 2000
sont maintenant bien connus, les solutions techniques de résolutions du problème de
même (2).
Certes, alors que l’on aurait pu croire que les informaticiens
allaient se diriger vers une solution unique, chacun semble faire un peu sa cuisine dans
son coin.
Le terme "chacun" peut s’avérer un peu trop
généraliste, car force est de constater que tout le monde n’a pas dans cette
affaire forcément les moyens de ses ambitions et de ses besoins (3)
Que constate-t-on ? Les gros fournisseurs de système
d’information voient dans cette affaire une occasion incroyable de se refaire une
santé, et ceci dans un marché fluctuant ou la guerre des prix fait rage. Sous la forme
du factory ces derniers proposent les adaptations au passage an 2000. Mais cette solution
ne peut satisfaire toutes les entreprises. Certes, elles se déchargent bon gré, mal gré
de leurs responsabilités, mais le coût financier laisse réfléchir plus d’unes.
En effet le factory propose une adaptation des programmes ce qui
sous-entend qu’en sus il faudra mettre en œuvre des tests de simulations au
passage an 2000 et d’intéropérabilité à l’environnement informatique de
l’entreprise.
Or, les tests de simulation représentent la garantie absolue de
fiabilité pour l’entreprise. Mais ces derniers, d’une part, devront se rajouter
à la prestation de factory, et d’autre part, provoquent une procédure très longue,
alors que l’entreprise doit minimiser ses coûts et ne peut se permettre de perdre du
temps.
De fait la prise en compte de ces impératifs financiers par les
entreprises (4) modifie
l’approche du problème et la détermination de ses solutions (5).
En effet, la plupart des grands utilisateurs ont finalisé leurs
études d’impact (6)
au passage à l’an 2000. Entre elles et leurs clients ou sous-traitants les
communications sur les offres an 2000 vont bon train. C’est au terme de ces échanges
que nombreuses entreprises (7) se sont inquiétées, alors que d’autres partenaires sous estiment
l’ampleur du problème. Aussi n’est-il pas étonnant que parmi les solutions qui
s’offrent aux entreprises, certaines commencent à avoir une approche juridique.
Ainsi tel le Big Bang, l’écho qui résonne aux oreilles des
informaticiens (8) et qui
provient des managers n’est plus uniquement axé sur le plan technique mais tout
naturellement sur le plan juridique ; qui de l’utilisateur ou du fournisseur
supportera la charge financière du changement de millénaire ? (9)
Or force est de constater que tout comme dans le domaine technique les
juristes ne parviennent pas non plus à proposer une solution figée.
Tout d’abord, la problématique de la responsabilité du passage
à l’an 2000 ne peut se résoudre à une réflexion dichotomique qui se
résumerait à faire supporter le coût financier du passage : soit à l’entière
charge de l’utilisateur soit à l’entière charge du fournisseur.
C’est pourquoi un impératif absolu de nuance et de précision
s’impose.
Par ailleurs, aucune jurisprudence ne semble avoir résolue cette
question. En effet, le préjudice, quoique pouvant être certain et prévisible,
n’est pas encore actuel et semble ne pas avoir généré dans notre droit interne
d’actions en justice.
Les quelques demandes introduites devant les
tribunaux nous importent peu pour le moment. Les délais raisonnables de jugement
devant les juridictions judiciaires nous projettent bien au-delà de l’an 2000 pour
obtenir une solution jurisprudentielle. Enfin, la diversité des objets des contrats
informatiques (contrat de licence, de maintenance, de vente, de matériel, de
réalisation…) ne permettra pas aux magistrats de dégager une solution unique à
tous les contrats.
Avant tout, l’entreprise doit et
devra avoir les moyens de passer l’an 2000 (10).
En effet malgré la spécificité de la matière il convient de
rappeler que nous nous situons essentiellement dans un rapport contractuel (11). Or le droit commun des contrats et
plus précisément des obligations a démontré sa richesse et notamment sa capacité
d’adaptation à l’objet même du contrat (12). De sorte que c’est en rappelant les principes fondamentaux du droit des
contrats que l’on peut être amené à résoudre les difficultés liées au
changement de siècle.
C’est dans l’acte de volonté, et uniquement dans l’acte
de volonté, que l’on pourra interpréter la commune intention de parties.
Cependant, le caractère complexe des contrats ayant pour objet des
systèmes d’information ne doit pas être minoré et plus précisément à travers
les obligations qu’ils font peser sur les parties. Ainsi dans le domaine de la
micro-informatique existe-il des principes, notamment dans la distribution des matériels
et logiciels, qui font de ces contrats, des contrats spéciaux à part entière. De même,
très tôt les tribunaux ont affirmé la nécessité plus encore de maintenir un
équilibre entre les parties (13).
Au-delà de ces réflexions qui effraient ou rassurent le praticien du
droit dans la détermination de solutions conformes, le juriste devra, dans un premier
temps, orienter sa réflexion dans l’état du droit positif.
Confronté aux attentes concrètes de l’entreprise, il lui
appartiendra alors de mettre en place des actions concrète pour résoudre la
problématique "an 2000" dans la mesure du possible.
I. APPROCHE GENERALE DU PROBLEME
A. La responsabilité du fournisseur ou son absence de
responsabilité reposera sur trois fondements juridiques
1. Obligation de délivrance conforme
La prestation, objet du contrat de fourniture du système informatique,
doit correspondre aux besoins du contractant. Ce caractère spécifique est beaucoup plus
affirmé dans ce genre de contrat dans la mesure où la prestation va toucher au fondement
et à la structure même de l’organisme auquel elle s’applique.
Cependant nous constaterons que l’intensité
du conseil varie selon la compétence du client (14) et de la complexité de la prestation.
La jurisprudence aurait pu être tentée de généraliser, à la charge
du fournisseur, une obligation de résultat comme elle a pu le faire en matière de
contrat de vente portant sur la livraison d’un bien corporel.
Or, en matière de logiciel spécifique, la nature varie en fonction de
la complexité de la prestation fournie et de l’importance de la prestation
intellectuelle par rapport à la prestation matérielle. En fonction de ces éléments,
l’obligation sera de moyen ou de résultat.
Malgré les faisceaux d’indices rappelés ci
dessus, force est de constater que les tribunaux français (15) ont préféré
retenir une obligation de moyen. Dans le silence du contrat, la Cour a en effet
considéré, que les conséquences de l’automatisation dépendaient de trop de
facteurs pour qu’on puisse assurer au départ qu’elles seront favorables.
Certes, nous ne cherchons pas à analyser
l’ensemble de la jurisprudence en la matière. Tout simplement car celle-ci est loin
d’être fixée (16). En outre, il nous apparaît
difficile de définir un principe général car, si la distinction des deux obligations
est nette dans son principe, elle demeure encore floue en pratique.
Quoiqu’il en soit et selon une jurisprudence constante ( 17) le fournisseur ou prestataire doit
bien délivrer une chose conformément à ce qui a été convenu au contrat.
En pratique, dans un contrat de licence d’utilisation de logiciel,
les parties pourraient tout à fait prévoir une clause au sein du contrat ou bien
intégrer dans un préambule disposant :
-
que le passage à l’an 2000 a conditionné la volonté des parties de contracter,
-
que le fournisseur s’engage à une obligation de résultat sur la conformité du
logiciel.
En l’absence de telles clauses, il faudra interpréter la volonté
des parties (cf. 1156 et suivant du Code Civil et la recherche de faisceaux
d’indices).
Ainsi, pour un contrat de vente de logiciel, on pourra regarder la date
de vente du logiciel, sa nature (application lourde ou logiciel simple qui déterminera la
nature de l’obligation moyen ou résultat), la valeur du logiciel, la qualité de
l’acheteur (un professionnel de l’informatique ne pourra pas opposer une erreur
sur les qualités substantielles de la chose dans la mesure où le
professionnalisme de ce dernier devait l’amener à une commande la plus précise
possible).
Sur le fondement de la conformité de la livraison, il apparaît que
cette appréciation est principalement effectuée lors de la recette du logiciel.
Il convient de distinguer la nature du contrat pour les opérations de
recettage : cette opération est déterminante en terme de charge de la preuve, en
effet si le client la refuse le fournisseur ne sera dégagé de son obligation de
délivrance conforme qu’après avoir prouvé qu’il l’a dûment exécutée (18). Alors que si le client la prononce,
la conformité est présumée acquise et le client doit alors prouver non seulement la
conformité mais encore qu’il ne pouvait raisonnablement s’en apercevoir lors de
la recette.
On vise ici les hypothèses de réalisation de logiciel et
d’intégration de systèmes. Il faudra apprécier les recettes effectuées.
Il faut vérifier que le recettage à l’aptitude à l’an 2000
a bien été effectué.
Ceci étant il est constant que le silence de l’utilisateur dans
le recettage ne saurait être néanmoins retenu contre lui, si le cahier de recette a
été établi par le fournisseur.
Nous verrons dans les actions à mettre en œuvre que les
utilisateurs ont donc tout intérêt à vérifier les phases de recettage. En effet le
fait de recetter le logiciel rendra difficile la soutenance devant les tribunaux que celui
n’était pas conforme.
2. La garantie des vices cachés
Cette garantie correspond à un vice inhérent à la chose, antérieur
au contrat, et rendant la chose impropre à l’usage auquel elle est destinée (19).
Cette garantie n’est applicable que dans les contrats de vente de
logiciel. Cette note n’a pas pour objet de revenir sur les nombreuses interrogations
portant sur la nature du contrat de licence d’utilisation de logiciel (20). Simplement précisons qu’un
défaut constitue un vice s’il rend le bien impropre à l’usage auquel il est
destiné. Le vice doit être caché en ce sens que l’utilisateur ne doit pas avoir
été en mesure de le déceler lors de la délivrance
La garantie des vices cachés est une garantie contractuelle qui se
distingue du contrat de maintenance.
Cette garantie légale n’est pas adaptée à tous les contrats
informatiques puisqu’elle vise uniquement les contrats de vente.
Par ailleurs l’obsolescence d’un bien ou l’usure normale
ne pourra pas être considérée comme un vice caché (21). De plus, l’application de ce
fondement de garantie suppose que l’on admette que le vice puisse s’apprécier
différemment dans le temps. Ainsi jusqu’en 1999, le logiciel ou progiciel n’est
pas vicié, au 1er janvier 2000 il le devient. A y réfléchir cette analyse
pourrait paraître séduisante mais on ne peut occulter la question de l’espérance
de vie du logiciel qui sera déterminante : le logiciel était-il censé fonctionner
après le 1er janvier 2000 ?
Autre difficulté liée à son action, elle devra s’effectuer à
bref délai. Autrement dit il devient à ce jour difficile de soutenir pour des logiciels
de 10 ans d’âge que l’on vient de découvrir le vice…
3. Le devoir d’information, de conseil et de mise en garde
L’obligation d’information du fournisseur envers son client
sera différente selon que le client est un professionnel ou un profane.
De sorte que la question, principalement dans un rapport entre
professionnel, ne sera pas de savoir s’il appartenait au fournisseur d’informer
son client de l’existence même du passage à l’an 2000 mais plutôt s’il
appartenait à ce dernier de préciser si le logiciel, objet du contrat de licence,
"ne passait pas " l’an 2000.
On constate que l’obligation d’information ou de
renseignement consiste essentiellement à mettre à la charge de celui qui fournit le
logiciel, l’obligation de renseigner sur les caractéristiques, notamment techniques,
du logiciel.
Il convient d’apprécier a posteriori si
l’intégration du passage à l'an 2000 constitue une
"caractéristique " du logiciel.
Mais il y a bien plus. S'accordant avec certains auteurs (22), la Cour de Cassation considère que
l’obligation de conseil ne s’applique pas aux faits qui sont de la connaissance
de tous (23).
Autrement dit, cette obligation de "conseil " ne peut
recevoir application pour le passage à l’an 2000. Dans la mesure où cet événement
est connu de tous, il ne peut être reproché au fournisseur de ne pas avoir informé son
client, celui-ci étant tenu de se prémunir contre les conséquences inhérentes à un
tel évènement.
Cette obligation qui pèse sur le prestataire suppose que le client ait
informé le prestataire sur ses réels besoins. Il est bien sûr évident que la portée
d’une telle obligation s’apprécie différemment selon que le client est plus ou
moins averti, et/ou selon que le fournisseur aura pu identifier plus ou moins
précisément ledit besoin
Ainsi, dans la mesure où le fournisseur connaissait l’existence
d’un tel besoin chez son client (vu la nature du logiciel et les activités du client
…) et qu’il n'a su préconiser un produit adéquat, on pourra s’interroger
sur le manquement du fournisseur à son devoir de conseil ou "de
préconisation " (25).
La prise en compte de l’opinion et des besoins du client pendant
la phase pré-contractuelle, c’est à dire dans la négociation, dans
l’établissement du cahier des charges, sa participation aux discussions, etc. seront
déterminants (il faudra examiner ses documents et pourquoi pas les éventuels préambules
des contrats)
On vise ici l’hypothèse où le prestataire devrait mettre en
garde son client sur la nécessité de contracter un contrat de maintenance afin de
permettre à son logiciel de passer le cap de l’an 2000.
Dans cette hypothèse, les juges considèrent que le fournisseur doit
anticiper sur le danger qu’une information incohérente pourrait engendrer (26).
Cette obligation qui incombe au fournisseur, trouve sa force dans la
mesure où le client n’est pas un professionnel d'une part, et d’autre part,
dans les limites de viabilité généralement admises pour les logiciels (appréciation à
la date d’acquisition).
Ainsi, il sera difficile de reprocher à un fournisseur de ne pas avoir
mis en garde tel client si le contrat a été passé au début des années 80, dès lors
qu’il est généralement légitime d’estimer la durée de vie d’un produit
logiciel à quinze ans.
B. Les
institutionnels face à la problématique "AN
2000"
Faisant suite à notre approche théorique et fortement juridique, nous
recensons ici les questions des " acteurs " de la problématique
"'an 2000" avant d'aborder les éléments de réponses qui nous sont proposés.
1. Des questions sur toutes les lèvres
L’ensemble des acteurs intéressés par la problématique an 2000 se trouve
confronté à des interrogations communes.
-
L’an 2000 doit-il être considéré comme un fait incontournable et connu de
tous ? (rappel : la Jurisprudence semble écarter le devoir de conseil pour les faits
connus de tous).
-
Dans quelle mesure le contrat de maintenance peut-il constituer un fondement aux
prestations d’adaptation d’un logiciel pour qu’il puisse fonctionner après
l’an 2000 ?
-
Pour l’AFNOR la maintenance ne concerne que le matériel, quelles en sont les
conséquences ?
- An 2000 est-ce une anomalie ou une bogue ?
Doit on considérer le passage an 2000 :
- au titre de la maintenance curative, visant à corriger des défauts
de conception entraînant des anomalies de fonctionnement ? Le problème de l'an 2000
serait alors défini comme une bogue.
- ou bien au titre de la maintenance évolutive, tendant à assurer la pérennité des
logiciels et leur évolution technique, et à apporter de nouvelles versions avec simple
correction des dysfonctionnements, ou de nouvelles fonctionnalités ? Il s'agirait alors
d’une anomalie.
- Jurisprudence, CA PARIS 20.05.1986, un contrat de maintenance (27) d’un système n’oblige pas
le mainteneur à fournir gratuitement un logiciel adapté au nouveau plan comptable. Mais
a contrario, cette même Cour a pu néanmoins reconnaître que la modification du Plan
Comptable ne constituait pas un fait connu de tous et incontournable. Peut on raisonnablement appliquer cette jurisprudence à la
problématique an 2000, comme certains le laisse penser ?
- A propos de la durée prévisible d’utilisation d’un logiciel, à partir de
quelle date un logiciel, qu’il soit vendu ou mis en location, doit être capable de
passé l’AN 2000 ?
2. Des réponses
Pour les Professionnels du droit :
Il conviendra d’apprécier la durée de vie habituelle des logiciels considérés
et notamment la date d’acquisition du produit.
De même pour ces derniers, si l’application de mise à
disposition a eu lieu après 1995, et que le passage à l’an 2000 n’a pas été
envisagé, il faut considérer sauf circonstances particulières que le fournisseur a
manqué à son obligation d’information et de conseil.
Parmi les circonstances particulières figurent comme nous l’avons
évoqué ci - avant le professionnalisme du client.
3. La position des
institutionnels
-
Pour le CIGREF (Club Informatique des Grandes Entreprises), il apparaît qu'il faut
envisager la prise en charge du passage à l’an 2000, par le fournisseur des
interventions portant sur des équipements acquis après 1990 (28).
-
Le SYNTEC (29) quant à
lui refuse cette position et réfute par la même occasion les fondements juridiques
avancés par les professionnels du droit et relayés par le CIGREF: vice caché,
obligation de conformité, directive communautaire sur les produits défectueux,
obligation de maintenance, le devoir de conseil, la jouissance paisible et l'erreur sur
les qualités substantielles. Dans son approche du problème le SYNTEC omet cependant de
s’intéresser aux contrats de maintenance ou de suivi des logiciels qui pourraient
ici trouver à s’appliquer.
-
Réponse ministérielle du 20.01.1997 (30) pour les logiciels livrés après le 01.01.1990, ce seront les fournisseurs qui
paieront lorsqu’ils auront conservé la titularité des droits d’auteur sur le
produit, et pour ceux qui auront été livrés avant cette date, ce seront les
utilisateurs à travers le contrat de maintenance.
Alors que l’on aurait pu s’attendre à une position un peu
plus rigoureuse de la part de nos autorités, la plupart des professionnels ne
désespéraient pas de voir à l’horizon une vraie réponse commune se dégager.
Comme à l’accoutumée nos pouvoirs publics par la voix de
Messieurs Strauss-Kahn et Pierret ont défini une solution dite " à la Française
" ! Mais cette fois-ci, la création d'une commission a été évitée. Le
gouvernement vient de confier une mission à M.Gérard Théry. Le Ministre de
l’Economie des Finances et de l’Industrie et son Secrétaire d’Etat ont
fixé à leur chargé de mission trois objectifs bien nobles (31), mais curieusement, l’ordre de mission ne précise pas si M.Théry devra
appréhender les problèmes de responsabilité…
Les esprits malveillants seraient tentés de dire que l'attitude de nos
gouvernants ne relève en rien de l’incompétence, ceux-ci ils se reposeraient
simplement sur les solutions émanant des instances communautaires (qui, comme chacun
sait, supplée de plus en plus les solutions de ces Etats membres).
Aussi convient il de s’attarder sur les solutions préconisées par le droit
communautaire :
Tout d’abord, la " fameuse " Directive sur les produits
défectueux (32).
L’article 11 de cette directive dispose que la responsabilité du producteur en
raison de la défectuosité de son produit s’éteint dix ans après la mise en
circulation du produit incriminé. Cette directive organise un mécanisme
d’obligation de résultat du producteur.
La Commission européenne a pu déjà se prononcer sur
l’applicabilité de cette directive aux logiciels (33).
La plupart des juristes se sont interrogés sur la portée de cette
dernière et sur les raisons qui poussaient le gouvernement français à ne pas la
transposer dans notre droit interne, condition "d’intégration " à
notre droit positif.
Plusieurs auteurs ont alors cherché à interpréter les positions du
ministre qui semblait estimer que le droit français était en conformité avec la
directive précitée, et qu'en conséquence il devrait trouver toute sa force devant nos
tribunaux (34).
Tout vient à point à qui sait attendre, puisqu’un arrêt
d’Assemblée du Conseil d’Etat du 6 février 1998 " Téo (35)" vient de sonner le glas
d’une longue résistance de notre interne.
Dorénavant dans tous les cas de figure, il semble que les juges
français, (le juge judiciaire étant sur ce point plus progressiste que le juge
administratif) imposeront l’application du droit communautaire.
Aussi, quand bien même cette directive n’a pas été transposée
dans notre droit interne, la récente évolution du droit français permet de penser que
cette transposition ne conditionnera pas son application. Dès lors, il nous est permis
d’affirmer qu'il existe dans les règles de notre droit une obligation de maintenance
du logiciel pendant 10 ans à la charge exclusive du fournisseur ou producteur.
A cette position, il convient d'ajouter deux précisions apportées par
la Commission dans une communication du 25 février 1998.
1.- la Commission constate le faible niveau de préparation des Etats
membres au problème informatique de l’an 2000. Force est de constater que son
analyse s’arrête là, la Commission se gardant bien de donner des pistes de
solutions pour les questions de responsabilité ! Seule indication, sous la forme de
lapalissade : la résolution du problème incombe aux fournisseurs et aux utilisateurs de
systèmes informatiques…
2.- la Commission annonce un certain nombre d’actions de
sensibilisation (il est grand temps !) ainsi qu'un effort de circulation de
l’information et d’échanges des expériences.
Le passage à l’an 2000 devra dorénavant être inscrit de façon
constante à l’ordre du jour de toutes réunions ministérielles et autres
concernées.
Pour mémoire le Premier ministre anglais, la Grande Bretagne
présidant en ce moment l’Union Européenne, avait décidé dès janvier
d’évangéliser l’Europe sur le bug de l’an 2000. Certes il a prévu
d’inscrire la problématique an 2000 au menu du G7 de Birmingham en mai
prochain ; mais nous restons un peu sur notre faim suite au première mesure de son
"règne " sur l’UE. Il est vrai que la lutte anti-Y2K ( y comme
year, K comme 1000) fait depuis des mois et des mois les grands titres de la presse
anglo-saxonne et la fortune des consultants spécialisés (36).
Nous remarquons que les fondements juridiques que nous évoquions
peuvent susciter un vrai débat juridique. Chaque fondement doit s’apprécier au cas
par cas en prenant en compte, certes les dispositions contractuelles, mais aussi les
compétences de l'utilisateur, sa participation active aux pourparlers contractuels,
notamment si il a défini précisément son besoin ou encore la date d’acquisition du
logiciel.
Après l’évocation de ces approches théoriques et
institutionnelles notre travail ne pouvait s’arrêter là, dans la mesure où notre
objectif premier est d'appréhender les solutions destinées aux entreprises.
II. LES ACTIONS A METTRE EN
PLACE
Afin d’envisager l’intégralité des solutions, nous devons
apprécier la relation entre le fournisseur et le client au fil du temps. En effet, cette
approche nous permettra de fixer toutes les étapes où client et fournisseur devront
appréhender dans la relation le problème du passage à l’an 2000. Ainsi on
distinguera trois situations :
Les actions à mettre en place sur les contrats conclus et recettés ;
Les actions à mettre en place sur les contrats conclus mais non recettés ;
Les actions à mettre en place sur les contrats non conclus et non recettés.
A. Gérer le passé (des actions sur les contrats conclus et
recettés)
Recensement des contrat en cours et audit des contrats par les informaticiens
(tests de simulation an 2000 devront être réalisés), adopter des méthodes de
recherche garantissant que ce dépistage est exhaustif :
a. Dans un premier temps une simulation par le client : TEST
DE NON – REGRESSION
Tests avant an 2000 avec des données après an 2000 pour valider les fonctions
à l’approche de la charnière entre les deux siècles ( avec PV contradictoire).
Si la simulation est réussie, le client constate l’aptitude du
logiciel.
Cependant comme nous avons pu l’expliquer auparavant les tests
sont coûteux et longs. Or, vu l’urgence du problème, l’entreprise ne peut
mobiliser des moyens financiers et humains aussi considérables pour aboutir à un
résultat conforme.
b. Aussi existe-t-il une autre démarche :
Si le client échoue dans sa réalisation de tests ou s’il ne peut
pas les effectuer, quelles solutions s’ouvrent à lui ?
-
Dans un premier temps obtenir par écrit les confirmations de l’aptitude an 2000
(préparation d’une lettre type d’engagement du fournisseur à moduler selon la
date de mise en œuvre du produit). Le client doit obtenir du fournisseur une
confirmation écrite constatant que dans un environnement informatique strictement
identique au sien, l’aptitude du produit est conforme.
En fonction de la réponse plusieurs actions sont à mettre en œuvre :
- Soit la réponse est positive, c’est à dire le produit dans la
version que possède le client est compatible an 2000.
Afin de disposer d'un engagement clair et précis du fournisseur, il
sera opportun de lui soumettre en retour, pour signature, un document qui reprend la
réponse mais qui revêt un formalisme plus contractuel (avenant au contrat initial).
Notamment ce document devra expliciter le plus exhaustivement possible ce que l'on entend
par la conformité an 2000 du produit, mentionner précisément les
caractéristiques techniques de son contexte d'utilisation, et énoncer les engagements du
fournisseur en cas de problème lié à l'an 2000 (maintenance corrective) ainsi que la
caractéristique intrinsèque de l’an 2000, à savoir une année bissextile. Chaque
lettre d’engagement étant soumise à un délai de réponse.
Ensuite la solution la plus favorable consistera à négocier un
avenant au contrat.
- Soit la réponse est négative (il nous faut proposer plusieurs
attitudes) :
On envisage ici l’hypothèse où le fournisseur a répondu par la négative
concernant le passage à l’an 2000 du produit.
La plupart du temps ce dernier propose un plan d'évolution plus ou
moins rigoureux : nouvelle version disponible ou en cours de développement avec des dates
de disponibilité plus ou moins précises et les contraintes techniques et modalités
financières bien souvent omises.
Pour pouvoir prendre rapidement une décision, l’entreprise doit
obtenir un engagement plus précis du fournisseur sur le passage à l’an 2000 et la
prise en compte que l’an 2000 est une année bissextile.
Ainsi, il convient de soumettre à la signature du fournisseur un
engagement ferme qui sera le cas échéant complété par un document qui reprend les
éléments de sa réponse ainsi que des affirmations émanant du client : délais,
coûts, contraintes (compatibilité de la nouvelle version par rapport à la précédente,
besoin ou non de migration des données,...). Ce document précisera que la réponse devra
intervenir par tous moyens (sauf verbaux) dans un très bref délai.
- D'autres enfin ne répondent pas du tout. Il faut alors les "mettre en
demeure de répondre". Toujours par courrier (AR), constater leur absence de réponse
et les conséquences que le client tire de cette absence de réponse (volonté de
dénonciation, demande de recourir à un tiers pour la maintenance, rappel des
dispositions du contrat initial…).
Il est dorénavant impératif, pour le client de répertorier tous les
documents que lui transmettent les fournisseurs. Aussi, il convient d’obtenir de leur
part uniquement des documents écrits et par conséquent aucun engagements verbaux. Tous
ces engagements devront être visés par une autorité techniquement compétente et si
possible par un juriste.
En tant qu’utilisateur dans le cadre d’un contrat de logiciel
qui fait l’objet d’un contrat de maintenance ( compris ou distinct) peut-on
imposer à un prestataire que les travaux soient pris en compte dans le cadre de ce
contrat au titre de la maintenance corrective ou évolutive ? Et ceci en sachant bien
entendu que ce contrat est silencieux sur le point précis de l’an 2000.
Au regard des solutions avancées, il apparaît que de nombreux
fondements juridiques peuvent servir d’outils de réponse. Mais nous avons pu nous
apercevoir également que ces solutions juridiques prêtaient le flanc au débat.
A la vérité, dans un tel cas de figure, il appartiendra aux juristes
d’éplucher les contrats en question au cas par cas en prenant en compte les
dispositions contractuelles mais aussi tous les éléments que nous avons pu évoquer
ci-dessus ( date d’acquisition, professionnalisme ou non du client…).
B. Le présent et le futur
1. Gérer le présent ( contrat conclu et
recette non effectuée )
NE FAIRE DES RECETTES QU’AVEC DES RESERVES.
Etablir une recette précise par les informaticiens sur l’aptitude
ou l’inaptitude du logiciel à passer l’an 2000. Pour ce faire conditionner la
recette définitive au passage an 2000 (cf. un exemple ci-après)
Dans certains contrats, il existe une faculté pour le client de faire
lui-même les corrections, si le fournisseur (dans le respect des dispositions du contrat)
l’autorise à acquérir une mise à jour du logiciel. La transmission des codes
sources est quasi impossible en pratique. Certes des décisions de justice ont reconnu un
droit au client de se faire communiquer dans le silence du contrat de licence, les sources
qu’il utilise pour en assurer la maintenance. Dans cette hypothèse il reste à
savoir si la transmission des sources sera payante ou encore si le client est
compétent pour faire lire ces dernières et les exploiter.
C’est pourquoi, avant d’entreprendre de telles démarches, le
client doit s’assurer, de sa capacité à exploiter lesdites sources afin de ne pas
prendre un risque trop important.
2. Gérer le futur (contrat non conclu et
recette non effectuée)
a. Rôle des informaticiens
Dans la négociation le client devra exiger le passage An 2000, obtenir toutes les
garanties techniques, ne jamais recetter tant que le contrat n’a pas été discuté
et négocié.
C’est à dire, toutes attitudes tendant à démontrer une
acceptation même tacite ou équivoque du produit pourrait être préjudiciable pour le
client.
Transmettre le résultat des négociations, du projet de contrat, du projet
d’avenant, bref de tous documents constatant un quelconque engagement du prestataire
sur l’aptitude du produit ou un quelconque refus de vouloir intégrer ce
problème…au service juridique.
b. Rôle des juristes
Dans un premier temps réaliser un audit et un contrôle de tous les documents
d’engagement du fournisseur.
Ensuite au cours de la négociation contractuelle et avant toute signature insérer des
clauses d’engagement sur l’an 2000 dans les contrats, plus caractéristique
année bissextile.
Ci-dessous nous vous proposons des " clauses-types "
susceptibles d’être intégrées au contrat lors de sa rédaction ou conclusion.
Exemple de clause susceptible d’être intégrée dans un
contrat : " Le fournisseur s’engage au terme du présent contrat à ce
que le traitement des dates et des calculs de dates soit conforme aux impératifs de
changement de siècle et compatible et interopérable avec les différents composants du
contexte d’utilisation du logiciel."
Ou bien :
" Le fournisseur garantit au client que le produit dont il
a concédé la licence d’utilisation est apte au passage de l’an 2000,
c’est à dire capable lorsqu’il est utilisé dans les conditions prévues dans
sa documentation, de traiter correctement, fournir et/ou recevoir toute donnée relative
aux dates des ou entre les vingtième et vingt et unième siècles, et ceci quels que
soient les matériaux, logiciels microprogrammes avec lesquels ledit produit opère."
Ou encore :
" Les parties ont convenu d’un commun accord au terme
du contrat, de la nécessité de mettre en place un contrat de maintenance spécifique en
vu de réaliser l’adaptation du Logiciel au changement de siècle. "
De même :
" Le produit objet du contrat respecte les spécifications
fonctionnelles prévues, notamment lorsque dans les fonctions assurées interviennent des
dates antérieures ou postérieures à l'an 2000 et ceci quelque soit la date d'exécution
de ces fonctions (avant ou après le 1/1/2000).
Le produit sait distinguer sans ambiguïté les dates fournies en
entrée ou restituées en sortie (y compris le siècle quand il y a risque de confusion) .
Le produit maintient l'intégrité des dates fournies ou calculées
(valorisation correcte de la zone siècle lorsque celle-ci est rajoutée aux dates dans
les fichiers, pas d'écrasement intempestif du siècle par 19 , ...).
Le produit gère sans ambiguïté les circonstances particulières qui
ont à voir avec le temps (échéances indéterminées ou infinies, dates d'effet
"depuis toujours", critères d'archivage, de suppression, d'historisation,...).
Le produit intègre le fait que l'an 2000 est bissextile.
Le produit est "interopérable" avec son contexte technique
d'utilisation (système d'exploitation,...) dans lequel il est prévu de fonctionner.
C’est pourquoi le fournisseur par la présente est en mesure de
garantir au client que :
D’une part, le produit objet du contrat a fait l'objet d'un
inventaire. Au terme de cet inventaire, toutes les dates ont été recensées et toutes
les références à ces dates ont été repérées dans tous les composants du produit .
D’autre part , le produit a fait l'objet de tests de
simulation an 2000:
1. Tests avant l'an 2000 avec des données après l'an 2000 pour
valider les fonctions à l'approche de la charnière entre les 2 siècles. Avec en outre,
dans le cas où le produit comporte un traitement devant être réalisé dans la nuit du
31/12/1999 au 1/1/2000, un test de passage à l'an 2000.
2. Tests sur un système positionné après l'an 2000 sur des données
postérieures à l'an 2000, sans oublier la date du 29/2/2000.
3. Tests sur un système positionné après l'an 2000 sur des données
antérieures à l'an 2000 pour valider les fonctions liées à l'historisation,
l'archivage, les sauvegardes/restaurations."
Enfin, même si le client peut obtenir les garanties nécessaires pour
le passage à l’an 2000 au sein d'un même du contrat, il est vivement recommandé de
conserver une sécurité complémentaire notamment à travers les opérations de
recettage :
Ainsi, il est impératif de mettre en place un système de recette en deux
temps :
-
d’une part une réception provisoire : " L’installation
sur chaque site donnera lieu à la signature d’un procès-verbal contradictoire de
recette provisoire, sous réserve de la constatation par le client des fonctionnalités du
logiciel aux fonctionnalités liées au passage à l’an 2000, ainsi que celles
décrites au cahier des charges
Dans l’hypothèse où la procédure de vérification donnerait
lieu à des réserves de la part du client, le prestataire procédera, dans les délais
compatibles avec le calendrier arrêté en Annexe, aux corrections requises et à la
livraison correspondante des codes sources et de la documentation associée ".
-
d’autre part une recette définitive : " La
réception définitive du logiciel sera acquise lorsqu’il sera constaté sur une
période de ….jours consécutifs, courant à compter de la date de signature de la
recette provisoire, que l’ensemble des éléments composant le logiciel répond non
seulement aux spécifications contractuelles, aux normes en vigueur et aux règles de
l’art, mais surtout aux fonctionnalités liées au passage à l’an 2000, et que
le logiciel est exploitable dans un environnement réel, sans anomalie apparente. ".
Ou bien on peut envisager une recette définitive à l’exclusion
de l’an 2000, en prévoyant une recette distincte pour les impératifs de changement
de siècle.
Pour ce faire nous renvoyons soit aux clauses ci avant qu’il faut
simplement aménager et/ou aux clauses classiques en matière de réception ou de
recettage que l’on trouve dans les manuels ou contrats types (37).
Enfin, nous attirons l’attention des clients sur la nécessité de
se méfier de certains contrats où la maintenance matériel est bien distincte de la
maintenance logiciel. Ce qui peut amener la confusion dans l’esprit du client,
confusion savamment organisée par le fournisseur.
Quelle assurabilité des risques liés au passage à l’an
2000 ?
-
Le client en tant que contractant peut permettre la transition entre cette garantie et
la maintenance, notamment par l’Assurance (38), dans la mesure où les compagnies semblent bien vouloir assurer les
entreprises qui ont tout mis en œuvre pour favoriser la migration de leur système
d’information.
-
De sorte que, le client a tout intérêt à avoir une bonne connaissance du niveau de
garantie dont bénéficie le prestataire.
Le plus efficace est de pouvoir se faire communiquer une copie du
contrat d’assurance. A défaut, la communication d’une attestation
d’assurance permettra de vérifier que le prestataire est suffisamment assuré pour
la prestation envisagée, à condition toutefois que l’attestation soit précise.
Pour plus de sécurité, le client peut énumérer les risques et leurs
origines et demander que l’assureur atteste précisément que le prestataire est
assuré pour de telles hypothèses, même si l’origine du dommage provient du
changement de millénaire.
Le client a tout intérêt à vérifier que le prestataire
bénéficiera tout au long du contrat du même niveau de garantie.
Ce dernier pourra s’engager à conserver les même modalités
d’assurance tout au long de l’exécution du contrat, voir même fournir au
client, lorsqu’il le réclame, un certificat de paiement des primes, toute carence du
niveau d’assurance pouvant alors permettre au client de résilier le contrat pour
manquement grave.
Autrement dit indépendamment de ces informations le client se verra
ouvrir deux solutions distinctes si il souhaite recourir à l’assurance :
Mais tout ceci relève de la négociation et uniquement de la
négociation, ainsi que de l’opportunité pour le client d’appréhender
véritablement les problèmes liés aux changements de millénaire.
A n’en pas douter les entreprises qui auront su mettre toutes les
chances de leur coté seront certainement gagnantes et dès maintenant proposent un aspect
attractif sur le marché.
A. M.
Notes et références
1 "La grande panne de l'an
2000" in Business Week n°1328 du 28/02/1998, p.III.
2 V. Yves TALLINEAU "Pour ne pas avoir peur de l'an 2000 " in
L'informatique Professionnelle n°147 du 10/96.
3 Cf. article in Libération du 03/04/1998 p.18 et s.
4 Parmi la quantité de témoignages voir l'article du 11.03.1998 in La
Tribune "Le patron d'Intel s'alarme du bug de l'an 2000".
5 Cf. article in Enjeux Les Echos n°134 mars 1998 p.92 : dans leur
dernière étude qui était certes consacrée à la préparation à l'Euro, les experts de
KPMG / Peat Marwick mettent l'accent sur le retard pris par les entreprises sur le terrain
des techniques de l'information. Alors que 78% déclarent que l'informatique est le
principal poste nécessitant des investissements, un quart n'ont pas encore établi de
budget et près de la moitié prévoient que les coûts seront couverts par les budget
informatiques existants. Par ailleurs au terme de cette étude on constate encore que 32%
des entreprises prévoient de " détourner " les fonds prévus pour le projet an
2000 vers le budget Euro…
6 Voir réponse de Boréal, JP GRIMA in, Banque et Informatique fev/mars
1998.
7 Voir l'enquête sur le passage à l'an 2000 faite en février 1998 par
le Secrétariat de la Commission Bancaire donne une image contrastée de ce chantier : 40
%des banques sont en phase de planification du processus. Il reste encore du travail à
accomplir pour que le changement de millénaire se passe sans anicroches ; in Banque
n°591 avril 98.
8 Les notes bleues de Bercy du 1er au 15/01/1998 p.126 et s "Le
passage à l'an 2000 dans les contrats informatiques ".
9 Un des premiers article sur le sujet in les Echos du 18.09.1996
Frédérique DUPUIS-TOUBAL et Stéphane LEMARCHAND " Les aspects juridique du passage
an 2000 des systèmes d'informations ".
10 Article du 11.03.1998 in La Tribune précité.
11 J.HUET et H.MAISE "La commercialisation des systèmes de
traitement : matériels et logiciels ".
12 WEILL et TERRE Les Obligations p.130 et s.
13 Voir RTDC 1986.765 obs. J.HUET.
14 Cour de Cassation 3/01/1996 JCP Ed G.n°23, II 22654.
15 V. arrêt de la Chambre Commercial de la Cour de Cassation du
3.12.1985 RTDC 86.p372 obs Remy.
16 V. Cour d'Appel de Paris du 27.03.1984 D 85.IR de Droit de
l'Informatique p42 et s obs J.Huet " Dans un contrat clé en main le matériel est
vendu avec les logiciels destinés à remplir des fonctions précises, l'obligation du
fournisseur est de résultat quant au service de l'ensemble.
17 Cour de Cassation Ch.Com 09/12/198 Sigma c/ Locabail et autres D
87.p.122.
18 Cf. article 1315 du code civil.
19 J. HUET, Les Contrats Spéciaux, n°11318.
20 Voir la pléthore de notes du Professeur J.HUET sur le sujet.
21 A contrario une usure trop rapide pourrait être constitutive d'un
vice caché, ibid HUET Com 27/11/1973, bull civ, n°345.
22 Danièle VERAT "Qui doit payer les frais du passage à l'an 2000
?", 01 informatique, 29/03/1996.
23 Civ 3émé, 20/11/1991 bull. civ. II; n°284.
24 Voir I.de LAMBERTIE in Les contrats informatiques, litec 1983 n°28 et
s.
25 Voir article de F.DUPUIS-TOUBOL, I.GAVANON, S.LEMARCHAND in expertise
n° 200 p.120 et s.
26 V. Jugement du Tribunal de Commerce de Nanterre selon lequel manque à
son obligation de conseil (au sens de l'obligation d'information ) le fournisseur qui n'a
pas informé de façon explicite le client sur les limites du logiciel qu'il offre.
Tribunal de commerce de Nanterre 30.06.1995 in revue Expertise, mai 1996 p.174.
27 Jurisprudence, CA PARIS 25é ch 20.05.1986, in "droit de
l'informatique et des télécommunications ", J.HUET et H MAISL, litec, p.407.
28 V. Revue Expertise n°200, p.419.
29 V. Silex n°974, 4ème trimestre 1997, p1. ou Expertise n°212 p 5.
30 P.12221 JO Déb.ASS.Nat du 10.03.1997, n°47262.
31 In liberation article précité.
32 Directive du Conseil n°85/374 du 25 juillet 1985 relative au
rapprochement des dispositions législatives réglementaires et administratives des Etats
membres en matière de responsabilité des produits défectueux. L’assemblée
nationale le 25 mars 1998 a adopté en première lecture la proposition de loi relative à
la responsabilité du fait des produits défectueux. In expertise mai 98 p.125.
33 Réponse du 15/11/1988 in JOCE du 08/05/1989 n° L 144/42.
34 Note Stéphane LEMARCHAND in Expertise mai 97 p77.
35 TEO (à paraître).
36 V. article "Informatique : le flip du grand bug de l'an
2000", in Libération du 25/01/1998.
37 V. MEMENTO -
GUIDE Alain BENSOUSSAN, "L'informatique et le Droit
" Tome II, édition Hermes.
38 Article in Le Figaro 09/03/98 "Assurer les risques
informatiques".
A consulter sur Juriscom.net :
- Commentaire du jugement du 16 juin 1998 - Tribunal de commerce de
Créteil
(Espace "Professionnels"), d'Alexandre Menais ;
- Bug de l'an 2000 : première
décision en faveur des utilisateurs - Tendance ou cas d’espèce ?
(Espace "Professionnels") d'Alexandre Menais ;
- L'audit des contrats informatiques
(Espace "Professionnels"), d'Alexandre Menais
;
- Que faire à l'aube de l'an
2000 ? (Revue de presse), de Juliette Aquilina ;
- Texte du jugement du
Tribunal de commerce de Créteil du 16 juin 1998 (affaire Novatel) ;
- Texte de l'arrêt de la
Cour d'appel de Dijon du 4 février 1999 (affaire Bel Air Informatique).
|
