Informatique et vices cachés

L’article 1641 du Code civil dispose : « Le vendeur est tenu de la garantie à raison des défauts cachés de la chose vendue qui la rendent impropre à l'usage auquel on la destine, ou qui diminuent tellement cet usage, que l'acheteur ne l'aurait pas acquise, ou n'en aurait donné qu'un moindre prix, s'il les avait connus. »

Cette notion de vice caché, si elle est très souvent utilisée en matière de vente de biens corporels, se retrouve fort peu en jurisprudence dans des affaires portant sur les défauts d’un logiciel, bien de nature incorporelle. Plusieurs raisons peuvent expliquer cette absence.

D’une part, la réticence d’assimiler un logiciel à une chose en raison de la nature incorporelle des logiciels, qui relèvent des œuvres de l’esprit (article L. 112-2 13° du Code de la propriété intellectuelle).

D’autre part, dans la plupart des cas, le vice, pour caché qu’il soit, sera qualifié de bogue, c’est à dire de défaut de conception du logiciel qui se traduira par une ou des anomalies dans le fonctionnement du logiciel.

Il faut alors distinguer selon l’objet acquis par le client.

Si l’acquisition porte sur les droits d’utilisation (par exemple) d’un progiciel (« logiciel sur étagère », c’est à dire vendu en grand nombre), il trouvera très vraisemblablement auprès de l’éditeur les « patchs » qui assureront la correction de ces bogues. Si l’acquisition porte sur une œuvre de commande, le client refusera de prononcer la recette du logiciel qui lui sera livré ou fera jouer la garantie du prestataire de développement ou, si la période de garantie est écoulée, sollicitera le prestataire en charge de la maintenance du logiciel.

Dans ces conditions, le périmètre de ce que peut recouvrir un vice caché en matière logicielle peut paraître ténu.

Il faut pourtant aborder une pratique courante chez les prestataires de développement informatique qui consiste, notamment lorsque les rapports avec le client se tendent (du fait de retards dans les livraisons, de mise en cause de la qualité des livrables…) à insérer au sein du logiciel en cours de développement des lignes de code dont l’objet est d’interdire le fonctionnement du logiciel passé un délai ou une date.

Le déclenchement de ce code conduit au blocage du logiciel voire, même, à ce que l’utilisateur ne puisse y avoir accès. Celui-ci est même – ironiquement – le plus souvent invité à s’adresser au prestataire.

Tant que le projet avance et que les relations entre le prestataire et le client sont bonnes, le code est modifié et la date ou le délai reporté. Mais, lorsque les relations deviennent délétères, il n’est pas rare que le client souhaite interrompre le projet tout en exploitant les modules qui peuvent l’être d’un logiciel qui lui a déjà (estime-t-il) coûté suffisamment cher. C’est alors que, le prestataire ayant malignement insérer ou laissé le code de blocage au sein du logiciel, l’usage en est bloqué quelques jours ou semaines plus tard.

Cet état de fait peut donc se révéler catastrophique pour un client qui aura fait le choix de mettre en production les premiers modules du logiciel qu’il a commandé. Et ce, d’autant plus si les migrations de données d’un ancien système vers le nouveau ont déjà été effectuées et que le blocage du nouveau système empêche de « rebasculer » ces données vers l’ancien qui devient vite la seule et unique porte de sortie.

Dès lors, comment qualifier un tel blocage ?

A reprendre la définition de l’article 1641 du Code civil précité :
- un tel blocage du programme en constitue bien un défaut qui était caché par le prestataire au client,
- ce défaut caché rend le logiciel impropre à l’usage auquel il était destiné puisque, par hypothèse, il empêche tout usage du logiciel.

Par conséquent et si l’on estime qu’un logiciel peut être assimilé à une « chose », les critères posés par l’article 1641 du Code civil semblent bien remplis en pareil cas.

La réaction du client est souvent, surtout s’il en a les compétences en interne, de forcer l’usage du logiciel. Si cette réaction est compréhensible, notamment lorsque le projet à pris des mois de retard et que les budgets consommés par le prestataire ont été plus que dépassés ou lorsque l’urgence d’éviter la paralysie d’une entreprise l’exige, il faut se garder d’une réaction trop hâtive.

En effet, un tel comportement du prestataire doit permettre d’obtenir la résolution du contrat et donc la restitution du prix payé (en ce compris de ses dépassements), mais également des dommages et intérêts en cas de préjudice supplémentaire subi par le client : mobilisation d’une équipe de suivi de projet, de l’entreprise pour un changement de système, pertes de données, retards et donc pertes d’exploitation et d’image consécutives, etc.

Il s’agit donc, avant toute autre chose, de faire constater l’état de la machine en présence d’un huissier de justice accompagné d’un expert informatique. Une telle démarche pourra certainement permettre au client, dans le cadre d’un débat judiciaire, d’envisager de faire l’économie d’une demande de nomination d’un expert en informatique. En effet, celle-ci est généralement faite lorsque le client prétend que le logiciel qui lui est livré ne correspond pas à ce qu’il avait commandé. Il s’agit dans ce cas de comparer le cahier des charges du client aux livrables fournis par le prestataire. Dans le cas décrit, il ne s’agira pas de savoir si le logiciel fonctionne correctement puisque, par hypothèse, même si tel était le cas, son blocage empêche de le vérifier. Ce qu’il s’agit donc de faire constater de la manière la plus circonstanciée possible.

Une telle incidente n’est pas neutre, notamment en termes de délais et de coûts d’une procédure contentieuse à l’égard du prestataire. La présence d’un expert informatique à un constat d’huissier est en effet infiniment moins coûteuse que la rémunération des diligences de ce dernier dans le cadre d’une expertise judiciaire.

Frédéric GUENIN, avocat & Régis Carral, avocat associé