Codes sources et défaillances de l’éditeur

1. / Le contexte sanitaire actuel a mis en exergue la vérification, par chacun, de ses plans de continuité d’activités. A ce titre, il n’est pas inutile de vérifier quelles modalités contractuelles ont été prévues dans l’hypothèse d’une défaillance de son éditeur de solutions logicielles qui ferait alors défaut au titre de ses prestations de maintenance.

Ainsi se pose la question de savoir s’il est possible d’accéder aux codes sources pour assurer la pérennité d’utilisation de la solution logicielle et son maintien, soit en interne, soit en recourant désormais à un nouveau prestataire tiers

Rappelons tout d’abord que le code source du logiciel peut se définir comme étant les instructions textuelles écrites d’un programme d’ordinateur compréhensible par l’homme. Si le logiciel objet de ce programme d’ordinateur fait l’objet d’un effort personnalisé allant au-delà de la simple mise en œuvre d’une logique automatique et contraignante (Cassation, Assemblée Plénière, 7 mars 1986, SA Babolat Maillot Witt c/ Pachot), ce dernier est éligible à la protection du droit d’auteur conformément aux dispositions de l’article L112-2, 13°, du Code de la Propriété Intellectuelle.

A la différence du code objet (programme binaire compréhensible par la machine) ou du code exécutable, pouvant être directement exécuté par la machine, seul le code source permet donc de maintenir ou faire évoluer une solution logicielle.

2. / C’est ainsi que, tout d’abord, et avant de régir un accès aux codes sources, encore convient-il de définir au titre du contrat ce que l’on entend par « code source ». Une fois la détermination de ce que recouvre la notion de « code source » il conviendra alors d’indiquer les conditions d’accès et le régime qui lui sera applicable.

3. / L’attention portée à la rédaction de cette clause est d’autant plus essentielle que les textes n’organisent aucun accès au code source, sauf hypothèse encadrée dans le cadre de l’interopérabilité (article L122-6-1 du Code de la Propriété Intellectuelle).

Ainsi, dans l’hypothèse d’une procédure collective dont ferait l’objet le prestataire (redressement où liquidation judiciaire), il n’existe aucun droit à obtenir communication desdits codes sources, en l’absence d’une clause contractuelle préexistante.

En effet, lesdits codes source étant le plus souvent le seul actif demeurant valorisable, les organes de la procédure collective recherchent à céder ces derniers à toute société qui serait alors intéressée pour fournir des prestations de maintenance aux clients n’ayant plus de prestataire à et effet, plutôt que d’en offrir l’accès à tous clients.

Notons à l’inverse que la responsabilité de l’administrateur peut être mise en cause si ce dernier ne fait pas droit à un accès au code source contractuellement prévu

Aux fins d’anticiper une telle situation, il est donc essentiel :

1. de définir où le code source est accessible. Il faut à cet effet proscrire un accès du code chez le prestataire lui-même : dans le cadre d’une liquidation judiciaire, il est toujours complexe de pouvoir accéder ou obtenir ledit code source. Il peut même arriver que les serveurs hébergeant lesdits codes aient fait l‘objet d’une vente dans le cadre de la liquidation, sans s’interroger sur la nature des données qu’ils hébergeaient !) Il faut donc privilégier le dépôt chez un tiers. Fréquemment, ces codes sources sont déposés au niveau national, auprès de l’Agence pour la Protection des Programmes, suivant des contrats d’entiercement, mais les dits codes peuvent tout aussi bien être déposés chez un autre tiers séquestre ou un officier ministériel.

2. de vérifier, une fois le code déposé, ses conditions d’accès (ouverture d’une procédure collective avec poursuite ou non des contrats souscrits, non correction d’anomalies sous un délai donné….), les justificatifs sollicités par le tiers séquestres pour donner accès aux codes sources, et ce sous quels délais

3. de s’assurer des versions du logiciel déposées et de la fréquence de leur mise à jour. En effet, une solution souscrite à un instant donné sera amenée à évoluer au titre de nouvelles versions également déployées au fur et à mesure chez le client. De même et nonobstant l’absence de nouvelles versions, l’éditeur aura pu corriger différentes anomalies de la solution concédée au titre de patchs ou de mises à jour. Il conviendra donc d’organiser la fréquence de la mise à jour des dépôts effectués suivant, par exemple, la politique de commercialisation de toute nouvelle version de l’éditeur installée chez le client, ou mieux, lors de toute mise à jour corrective significative.

4. se poser la question des mises à jour des codes sources entre ceux relevant de la solution progicielle souscrite auprès de l’éditeur et ceux relatifs à d’éventuels développement spécifiques réalisés en complément.

5. De définir quels seront les droits du client, une fois ce dernier en possession desdits codes source : utilisation uniquement afin de maintenir la solution en place, les utiliser pour de nouveaux développements, être autorisé à la confier à tiers…

Relevons enfin cette la clause d’accès aux codes sources perd de son intérêt dans le cadre de solutions souscrites en mode SaaS, compte tenu d’architectures mutualisées et/ou fournies en mode cloud computing rendant peut probable qu’un client puisse lui-même créer sa propre plateforme pour assurer une continuité de services. Dans de telles hypothèses, on s’intéressera davantage à des mécanismes contractuels organisant la récupération des données.