|
Compte rendu de l'intervention de Ambroise Soreau , lors d 'une conférence à la chambre de commerce internationale de Paris en Mars 2004, le thème "Informatique et droit de la failllite"
Le déploiement d’une solution informatique est un acte qui engage l’entreprise pour plusieurs années. L’investissement peut être coûteux et il n’est pas rare que l’activité de la société soit suspendue au bon fonctionnement du système informatique installé. C’est pour ces raisons que les entreprises désirent de plus en plus souvent garantir la pérennité de l’utilisation des solutions informatiques qu’elles acquièrent. Elles souhaitent s’assurer que le logiciel fera l’objet d’une maintenance corrective, évolutive et réglementaire pendant une durée leur permettant un retour sur investissement suffisant. Cette volonté est néanmoins menacée par la mise en redressement ou liquidation judiciaire du fournisseur de la solution informatique. La survenance d’une procédure collective se traduira souvent en effet par un arrêt de maintenance. Soit parce qu’il y aura eu une liquidation de la société sans reprise des engagements par un tiers soit encore en raison d’un arrêt des contrats de maintenance par l’administrateur.
Conflit d’intérêts : Pour résoudre cette insécurité liée à la procédure collective, l’acquéreur a tout intérêt à se réserver un accès au code source du logiciel. En effet, ce code est souvent nécessaire pour modifier le logiciel et donc permettre la reprise de la maintenance. Cet accès est cependant loin d’être acquis. La volonté de l’utilisateur de se prémunir peut se heurter à la volonté du titulaire de droit sur le logiciel de protéger son savoir faire et sa propriété intellectuelle en conservant le code source secret. A côté des dispositifs techniques de protection et de l’arsenal légal, le secret du code source constitue de fait un rempart efficace contre la contrefaçon. Le désir de sécurité de l’utilisateur se trouve ainsi en conflit avec le désir de secret de l’auteur pour protéger son logiciel.
La loi n’organise pas l’accès au code source. La loi ne règle pas ce conflit d’intérêt. Il n’existe aucune disposition organisant au profit des utilisateurs l’accès à ce code. Certes le législateur autorise, en l'absence de stipulations contraires, l'utilisateur à reproduire et modifier le logiciel aux fins de correction des erreurs1 mais il reste muet sur les modalités pratiques de correction lorsque le code source est nécessaire. Le droit de décompiler le logiciel, c’est à dire d’obtenir le code source par traduction du code exécutable est quant à lui strictement limité à la recherche des informations nécessaires à l’interopérabilité (art. L 122-6-1CPI) . C’est ainsi que face au silence des textes, la pratique a été conduite à recourir au contrat pour aménager un accès au code source au moment de la procédure collective.
Le contrat d’entiercement : La solution contractuelle prend souvent la forme d’un contrat nommé que l’on retrouve sous les termes de contrat d’entiercement ou contrat de séquestre ou encore de d'escrow agreement. Cependant, rien n’exclut que cette autorisation prenne la forme d’une clause dédiée dans un contrat d’édition ou de maintenance par exemple. La seule exigence est que l’autorisation soit donnée par le titulaire des droits. Celui-ci est en effet le seul capable d’autoriser l’accès au code source. Le mécanisme contractuel consiste alors à faire intervenir un tiers de confiance tel que l’Agence pour la Protection des Programmes et à le constituer séquestre des sources qu’il reçoit en dépôt. Le contrat détermine les conditions à réunir pour que le tiers de confiance soit autorisé à communiquer à l’utilisateur une copie des sources du programme. L’intervention de ce tiers permet d’éviter notamment une rétention abusive du code au moment de la mise en redressement ou liquidation judiciaire.
Dépôt des codes sources – Avant d’entrer dans le détail de ce type de contrat, il convient de préciser que le dépôt du code source, en vue d’organiser son accès, ne doit pas être confondu avec le dépôt légal des progiciels et ce essentiellement pour deux raisons. Tout d’abord ce type de dépôt ne vise pas tous les progiciels mais seulement ceux « qui sont considérés comme représentatifs des catégories de progiciels et systèmes experts existants, sur proposition de la commission consultative prévue par la loi du 20 juin 1992 ». Ensuite le dépôt légal impose que le progiciel soit déposé tel qu’il est communiqué au public, c’est-à-dire sous sa forme exécutable. Si le dépôt légal peut néanmoins s’accompagner du dépôt des sources dans la pratique cette situation sera très rare. On remarquera également que rien n’est prévu pour permettre l’accès et les reproductions qui s’imposent aux fins de maintenance. La reproduction des sources du progiciel faisant l’objet d’un dépôt légal serait alors ni plus ni moins qu’un acte de contrefaçon. Enfin, le dépôt des codes sources ne doit pas non plus être confondu avec le dépôt des logiciels intervenant dans les comptabilités informatisées auprès des organismes de défense des programmes (Voir Instruction fiscale du 24 décembre 1996) Ce type de dépôt réserve, sauf mention contraire, l’accès aux services fiscaux et non aux utilisateurs du logiciel.
Accès et droit d’auteur : Une fois ces précisions faites quant au dépôt, la notion d’accès est sans doute la première des notions nécessitant d’être explicitée. Elle doit tout d’abord être pensée au regard du code de la propriété intellectuelle. Il convient de commencer par relever qu’en aucun cas l’accès au code source n’est translatif de propriété. L’utilisateur qui accède à ce code est d’ailleurs souvent tenu à des obligations de confidentialité et demeure responsable de la sécurité des sources auxquelles il accède. Il est en général d’usage de considérer que l’accès au code source doit permettre l’exercice des droits concédés par la licence ou encore de réaliser les prestations de maintenance attendues du fournisseur défaillant. Pour que cet objectif puisse être atteint, il est important de garder à l’esprit le formalisme du code de la propriété intellectuelle. L’existence d’un écrit avec une clause d’accès faisant l’objet d’une mention distincte est un minimum nécessaire pour que l’autorisation soit considérée comme donnée. Il ne sera sans doute pas inutile chaque fois que possible de déterminer précisément l’étendue de l’accès quant à sa destination, quant au lieu et à sa durée (Voir L 131-3 du code de la propriété intellectuelle). Il sera intéressant par exemple d’articuler la notion d’accès avec les différentes étapes de la procédure et notamment la reprise des engagements de maintenance par un tiers.
Accès et procédure collective. La notion d’accès doit aussi être pensée au regard de la procédure collective dont la finalité est de redresser l’activité de l’entreprise ou de permettre la liquidation de ses actifs en vue du paiement des créanciers. On s’aperçoit à ce niveau que les co-contractants ont souvent tendance, à tort, à faire du redressement ou de la liquidation judiciaire une condition suffisante de l’accès aux sources. Or si en période de redressement cet accès nous paraît légitime en cas de défaillances caractérisées (erreurs bloquantes non corrigées par exemple) ce même accès semble se heurter à l’ordre public de la procédure collective lorsque cette même défaillance n’est pas établie. Dans le même ordre d’idée, il semble qu’il y ait une distinction à faire dans le contrat entre la liquidation judiciaire avec reprise des engagements par un tiers et la liquidation sans reprise. En effet, seul le dernier cas met en péril l’utilisateur et justifie un accès aux sources. Il est donc important lors de la rédaction des clauses de veiller au respect de l’ordre public protecteur de la procédure collective sans quoi ces clauses pourraient être privées de tout effet. Enfin, on précisera dans le même ordre d’idée, que des contrats prévoyant un accès au source passés pendant la période suspecte pourront également être annulés(voir Voir L 621-107 du code de commerce.).
La notion de source. Le code de la propriété intellectuelle ne définit par la notion de logiciel. Il ne faut donc pas s’étonner qu’il ne définisse pas non plus celle de source. C’est en fait une définition pragmatique qui doit s’imposer dans les contrats d’entiercement. Les sources doivent notamment être considérées comme l’ensemble des informations nécessaires pour assurer la maintenance corrective, évolutive, et réglementaire du logiciel. L’utilisateur devra veiller à ce que les sources déposées correspondent à l’exécutable qui lui a été remis. L’Agence pour la Protection des Programmes propose à ce titre la procédure de dépôt contrôlé. Il peut être utile également de s’assurer de la qualité de la source déposée en faisant effectuer un diagnostic de pérennité. Cela permettra de vérifier si les sources ont été rédigées dans les règles de l’art et sont correctement documentées pour qu’un tiers puisse sans difficulté en reprendre la maintenance. Ce diagnostic sera l’occasion de lister les outils de développement nécessaires à l’exploitation des sources. On retiendra que si des outils de développement spécifiques sont identifiés, il sera sans doute utile de veiller à ce qu’ils soient également déposés avec le source lui-même. Dans ce cas, le contrat de séquestre devra prévoir une licence d’utilisation des outils pour l’exercice des droits d’accès.
Ambroise Soreau - Avocat à la Cour
|