Codage « Vibe » : où se situe la limite en matière de droits d'auteur ?

Les outils d'IA peuvent aider les développeurs à reproduire les fonctionnalités de logiciels existants. Il existe toutefois une différence importante entre créer une alternative et copier le travail de quelqu'un d'autre.

L'affirmation récente d'un développeur selon laquelle il aurait attiré 20 000 utilisateurs vers une alternative à Photoshop « codée par ambiance » soulève une question intéressante. Si l'IA peut aider quelqu'un à créer un produit concurrent, le propriétaire du logiciel d'origine a-t-il des raisons de s'en plaindre ?

On pourrait instinctivement penser que la reproduction d’un produit existant constitue nécessairement une violation de ses droits d’auteur. Après tout, le développeur d’origine a peut-être consacré des années à sa mise au point. Cependant, les droits d’auteur ne confèrent pas à une entreprise de logiciels un monopole sur les fonctionnalités de son produit. La distinction entre la copie des fonctionnalités et celle de l’expression de ces fonctionnalités a fait l’objet de nombreux procès bien avant l’apparition des outils de codage basés sur l’IA.

Même résultat, logiciel différent

Prenons l'exemple d'un logiciel de retouche photo. Un développeur peut souhaiter que les utilisateurs puissent recadrer des images, ajuster les couleurs et travailler avec des calques. Ces exigences décrivent des fonctionnalités. Le code écrit pour les mettre en œuvre est quant à lui tout autre chose.

Cette distinction est au cœur du droit d'auteur sur les logiciels. Le code source et le code objet peuvent être protégés, mais les idées et les principes qui sous-tendent un programme ne sont pas protégés en tant que tels. Par conséquent, un programme concurrent ne constitue pas nécessairement une contrefaçon du simple fait qu'il accepte les mêmes données d'entrée ou produit les mêmes résultats.

Les tribunaux anglais se sont penchés sur cette question dans l’affaire Navitaire c. easyJet [2004] EWHC 1725 (Ch). Un nouveau système de réservation aérienne avait été délibérément conçu pour fonctionner de manière très similaire au système existant, sans avoir accès à son code source. Le tribunal a rejeté l’argument principal selon lequel la reproduction de son comportement fonctionnel constituait une atteinte au droit d’auteur. Il convient toutefois de noter que certaines demandes concernant les écrans graphiques et les icônes ont été retenues. La fonctionnalité et les éléments graphiques ont nécessité des réponses différentes.

Pour quiconque développe une alternative logicielle, c'est un point de départ utile : recréer les fonctionnalités d'un produit ne revient pas à avoir le droit de reproduire tout ce que l'utilisateur voit.

En quoi la mise en place d'une salle blanche est-elle différente ?

Un processus de type « clean room » est conçu pour garantir la clarté de ces distinctions. En règle générale, une équipe étudie le logiciel existant et élabore un cahier des charges décrivant son comportement fonctionnel. Une autre équipe, qui n’a pas eu accès au code d’origine, écrit une nouvelle implémentation à partir de ce cahier des charges. Les traces du processus permettent de démontrer le caractère indépendant du développement.

Cela ne permet pas de faire disparaître le droit d'auteur d'origine. De même, le terme « clean room » n'est pas une notion juridique garantissant un résultat favorable. Son intérêt réside dans le fait de démontrer que le nouveau produit reproduit une fonctionnalité non protégée plutôt qu'une expression protégée.

L'IA soulève une question délicate : dans quel état de propreté se trouve la pièce ?

Le fait de partir d’un référentiel vide ne répond pas nécessairement à cette question. Le contenu fourni à l’outil de codage a son importance, tout comme les sources qu’il récupère. On peut également se demander si le modèle a rencontré du code pertinent au cours de son apprentissage. Ces questions ne prouvent pas qu’il y ait eu contrefaçon, mais elles rendent l’affirmation simpliste selon laquelle « l’IA l’a écrit de toutes pièces » moins rassurante qu’elle ne pourrait le paraître à première vue.

Les développeurs doivent donc faire la distinction entre demander à l'IA de mettre en œuvre un cahier des charges fonctionnel et lui demander de réécrire une base de code existante. Ces deux tâches ne doivent pas être considérées comme interchangeables.

Droit européen

L’une des décisions les plus pertinentes est l’affaire SAS Institute contre World Programming, C‑406/10. Le logiciel concurrent était destiné à exécuter des programmes écrits dans le même langage que le système d’origine et à produire les mêmes résultats. Son développeur avait étudié le produit d’origine, mais rien n’indiquait qu’il ait eu accès au code source d’origine ou qu’il l’ait copié.

Dans l’affaire C-406/10, la Cour de justice de l’Union européenne a estimé que la fonctionnalité d’un programme, son langage de programmation et les formats de fichiers de données associés ne constituaient pas des formes d’expression protégées par le droit d’auteur sur le programme d’ordinateur au sens de la directive sur les logiciels. Cette distinction a permis de préserver la possibilité de développer des logiciels compatibles sans conférer au premier développeur un contrôle exclusif sur les idées sous-jacentes.

Dans l’appel ultérieur devant les juridictions anglaises, dans l’affaire SAS Institute c. World Programming [2013] EWCA Civ 1482, la décision en faveur de la réimplémentation fonctionnelle a été confirmée. Toutefois, certaines conclusions de contrefaçon relatives à la copie entre manuels ont été maintenues. Comprendre un produit à partir de sa documentation est une chose ; reproduire une expression protégée à partir de cette documentation en est une autre.

Dans le cas d'un logiciel de retouche photo, cela offre une analogie utile. Écrire du code indépendant pour prendre en charge un format de fichier existant ne revient pas automatiquement à copier le programme d'origine. Il n'en découle toutefois pas que le code, la documentation ou tout autre élément protégé associé à ce format puisse être simplement repris.

Google n'a-t-il pas eu le dernier mot dans le débat sur les API ?

On évoque souvent le long litige qui a opposé Google et Oracle devant les tribunaux américains pour établir que les interfaces de programmation d'applications, ou API, ne peuvent pas être protégées par le droit d'auteur. Ce n'est toutefois pas la conclusion à laquelle la Cour suprême des États-Unis est finalement parvenue.

Une API permet aux programmeurs d'appeler des fonctions sans avoir à écrire eux-mêmes l'implémentation sous-jacente. Lors du développement d'Android, Google a écrit son propre code d'implémentation, mais a repris environ 11 500 lignes de code de déclaration ainsi que la structure organisationnelle associée de la plateforme Java, permettant ainsi aux programmeurs d'utiliser des commandes qui leur sont familières.

Après des décisions contradictoires rendues par les juridictions inférieures, la Cour de cassation a statué, en avril 2021, dans l’affaire Google c. Oracle, que la copie relevait du « fair use » (résumé ici). Il est important de noter qu’elle a considéré, aux fins de statuer sur l’affaire, que la protection au titre du droit d’auteur existait, sans se prononcer sur la question de savoir si le contenu en question était susceptible d’être protégé par le droit d’auteur.

Cette décision n'établit donc pas que les API puissent être librement copiées dans tous les cas. Il ne faut pas non plus confondre son raisonnement relatif à l'« usage loyal » américain avec l'approche européenne adoptée dans l'affaire SAS Institute c. World Programming, qui portait sur la portée du droit d'auteur sur les logiciels et autorisait l'étude d'un programme. Ces affaires viennent étayer la compatibilité et la réimplémentation, mais par des voies juridiques différentes.

Le nouveau code ne tranche pas la question

Un développeur peut éviter de copier le code d'origine tout en reproduisant son interface de manière très fidèle. Cela soulève une autre question.

Dans l’affaire « Bezpečnostní softwarová asociace », C‑393/09, la Cour de justice européenne a estimé qu’une interface utilisateur graphique n’était pas protégée en tant qu’expression d’un programme d’ordinateur au sens de la directive sur les logiciels. Néanmoins, une interface pouvait bénéficier d’une protection au titre du droit d’auteur en tant que telle si elle constituait une création intellectuelle propre à son auteur. Les éléments dictés uniquement par une fonction technique ne remplissaient pas cette condition d’originalité.

Dans le cas d’un éditeur de photos basé sur l’IA, la distinction réside entre le fait de proposer des fonctions d’édition courantes et celui de reproduire des graphismes originaux ou toute autre expression protégée de l’interface. Demander à un outil de programmation de recréer un écran à partir d’une image ne doit pas être considéré comme sans risque simplement parce que le code obtenu est nouveau. C’est là l’implication pratique du fait de traiter l’interface séparément du programme qui la met en œuvre.

Que devraient faire les développeurs et les entreprises de logiciels ?

Pour les développeurs, nous recommandons de définir les fonctionnalités requises avant de générer l’implémentation. Conservez une trace des spécifications, des consignes et des sources utilisées, et examinez séparément le code et les ressources visuelles obtenus. Un processus de développement documenté est plus utile que de se contenter d’une description telle que « généré par l’IA » ou « écrit à partir de zéro ».

Pour les entreprises de logiciels bien établies, ces affaires mettent également en évidence les limites d'un recours exclusif au droit d'auteur. Le droit d'auteur peut protéger des codes, des graphismes et de la documentation de grande valeur, mais il n'empêche pas nécessairement un concurrent de mettre en œuvre de manière indépendante les mêmes fonctionnalités. D'autres droits et obligations, notamment les brevets, les secrets d'affaires et les restrictions contractuelles, doivent faire l'objet d'un examen distinct.

Les récentes avancées en matière de « vibe-coding » devraient servir de point de départ à cette discussion.

La question centrale reste la même : le développeur a-t-il créé une nouvelle façon de faire la même chose, ou a-t-il reproduit l'œuvre protégée de quelqu'un d'autre ? L'IA peut certes modifier la manière dont le logiciel est conçu, mais l'argument selon lequel « c'est l'IA qui l'a écrit » ne saurait se substituer à une réponse à cette question.

Si vous développez un logiciel concurrent ou compatible, ou si vous craignez qu'un produit ne reproduise le vôtre, contactez votre avocat habituel chez Barker Brettell afin de discuter des questions relatives à la propriété intellectuelle.