Dans une interview croisée, Claire Bernier (avocate), Vincent Geoffray (responsable juridique et ingénieur en informatique) et Bruce Bonnaure (expert judiciaire) nous livrent leurs points de vue relatifs à l’impact de l’intelligence artificielle sur la protection des logiciels et sur les saisies-contrefaçons. Même si l’IA génère du code, la forme finale sera celle retenue par les développeurs. Le principe de l’originalité du logiciel n’est pas remis en cause. En revanche, la contrefaçon qui sera facilitée sera plus dure à caractériser. L’IA peut en effet favoriser la contrefaçon en la masquant mais elle peut aussi permettre de la détecter. D’où la nécessité d’établir de bonnes pratiques et de conserver tout ce qui a trait aux développements, y compris les prompts.

Sylvie Rozenfeld : Ces dernières années, les méthodes de programmation ont beaucoup évolué, notamment avec le recours à l’intelligence artificielle. En 2025, l’IA ne se contente plus de suggérer des bouts de code ou de compléter des fonctions : elle est capable de générer des applications fonctionnelles, à condition d’avoir un développeur expérimenté. Lors d’une matinale de l’AFDIT consacrée à la défense de l’investissement logiciel, Claire Bernier (ADSTO Avocats), Vincent Geoffray (responsable juridique adjoint Vinci Energie, ingénieur en informatique de formation) et Bruce Bonnaure (expert judiciaire, Expertis Lab), vous avez abordé l’évolution de la contrefaçon du logiciel avec le recours à l’IA pour la conception et le développement informatique et l’impact sur la saisie-contrefaçon. J’ai été très intéressée par les regards croisés d’une avocate, d’un juriste d’entreprise et d’un expert judiciaire et j’ai pensé qu’ils pourraient intéresser les lecteurs de l’APP.

 

L’IA est-elle une aide à la contrefaçon ?

Bruce Bonnaure : D’un côté, l’IA peut permettre de générer du code en faisant en sorte de ne pas commettre de contrefaçon. On va lui demander de le faire en intégrant des filtres pour recourir au maximum à de l’open source, des bibliothèques existantes, etc. Il existe de bonnes pratiques pour éviter de copier un code existant protégé par un droit d’auteur. Il y a quelques années, j’avais été consulté par une société qui développait un système de recherche et qui m’avait justement demandé qu’elles étaient les bonnes pratiques à mettre en œuvre pour que le développeur se rapproche le moins possible de ce qui existait par ailleurs sur son marché. Dans les bonnes pratiques, il y a notamment la documentation et la traçabilité de tout ce que l’on fait, la justification des choix opérés sur les structures, les langages, les outils, etc. Quand on dispose de tous ces éléments dans un dossier technique même si le produit ressemble fonctionnellement à un autre, ça lui donne du corps.

D’un autre côté, l’IA peut également être utilisée pour détecter les contrefaçons, donc aussi pour permettre de s’en éloigner. Il existe notamment des outils pour déceler des similarités de codes. Il s’agit de demander à l’IA une analyse automatique des similarités et de coder différemment un logiciel. Ainsi, on peut volontairement changer le code pour écarter les similitudes. La structure de l’application informatique est également très importante car elle peut également dévoiler des similitudes. Certains outils utilisés par l’IA peuvent permettre d’apporter également des modifications structurelles susceptibles de masquer un acte de contrefaçon.

En présence de deux séquences informatiques écrites dans deux langages distincts sur la base de deux structures apparemment différentes, on peut néanmoins observer, dans le bytecode, qui est la partie intermédiaire entre le code source et l’exécutable, que deux applications d’apparence différente ont les mêmes finalités et utilisent les mêmes mécanismes logiques. On peut ainsi détecter l’existence d’une ressemblance entre deux développements. Certes, l’IA fournit des moyens pour masquer une certaine forme de contrefaçon ou de plagiat mais on peut utiliser l’IA, à l’inverse, pour détecter que deux applications dont l’apparence est différente ont une logique commune et une filiation.

Claire Bernier : Lorsque l’on s’adresse à l’IA dans ce contexte, l’approche est différente entre demander à quelqu’un de développer du code et d’utiliser l’IA afin de vérifier qu’il n’y a pas de copie involontaire, bien que le développeur soit parti de zéro pour rédiger son code car c’est son « empreinte » qui est à l’origine de la rédaction du code, mais il est possible qu’il ait repris inconsciemment ou involontairement des partis de codes développés par le passé, et celle qui consiste à demander à l’IA de modifier toute partie de code qui aurait été volontairement copiée pour dissimuler cette reprise de code. Cette ligne entre les deux est très ténue et l’expert va avoir du mal à les distinguer. Pour résumer, ça va être différent entre ce prompt : « dis-moi si j’ai copié des éléments du code A pour arriver au code B » où le code B a été développé à partir de zéro, et celui-là : « Fais que le code B ne soit pas une copie du code A » où le code B a été développé, voire est une copie du code A dès l’origine. Donc, l’expert va devoir mettre en exergue un faisceau d’indices pour déterminer la démarche adoptée par le développeur dans la rédaction du code B.

Au bout du bout et si l’on pousse ce raisonnement à l’extrême, dans les situations dans lesquelles l’IA a été sollicitée pour rédiger le code B à partir du code A en dissimulant cette copie, on pourrait se demander si au final ce qu’a créé l’IA n’est pas original tellement le code est très différent bien que cela soit au départ une volonté de copier un code existant. Cela peut aussi poser la question du parasitisme.

 

Comment masque-t-on la contrefaçon grâce à l’IA ?

B. B. : À différents niveaux. D’abord par l’utilisation de filtres. On peut par exemple demander à l’IA d’utiliser des structures différentes, des langages et syntaxes différents, des règles de nommage différentes, d’exclure toutes formes de similarités, d’opérer des transpositions. L’IA peut aller assez loin. Par analogie avec un roman : si on traduit celui-ci du français vers l’anglais, il n’aura pas la même forme mais ce sera le même roman. Si on le modifie ou on l’adapte, il deviendra du plagiat. On y retrouvera des éléments structurels, des idées, des personnages, un cheminement… En matière de logiciel, il existe des outils d’analyse des arbres syntaxiques qui permettent de détecter, dans une application transposée, que le code reformulé est en fait très proche d’un autre. Cela va permettre au développeur de détecter des formules ressemblantes ou une structure qui, même reformulée, dévoile un développement trop proche de l’original. Le développeur va se poser des questions et pouvoir apporter des modifications.

C. B. : Et la difficulté sera de déterminer la contrefaçon et l’empreinte de la personnalité de l’auteur. Il ne suffit pas d’être proche d’une autre application pour être une contrefaçon. En effet, un programmeur peut utiliser un outil pour se détacher au maximum de ce qui s’est fait avant, mais ça peut se retourner contre lui car si cela montre une volonté de se détacher -donc une conscience de l’existant- cela montre également sa volonté de faire de même que ce qui existe.

B. B. : Il y a la forme du code source mais aussi la structure et l’objectif de l’application. Aujourd’hui, le recours à des outils assez fins et à des techniques d’obfuscation permettent de masquer un grand nombre d’éléments de similitude. Cependant, certains de ces outils permettent, à l’inverse, de déceler ces procédés. De fait, l’analyse du code informatique compilé est intéressante. Il est intéressant d’analyser le bytecode, pour repérer les similitudes entre deux réalisations, car il est possible d’observer l’existence de codes sources distincts engendrant des ressemblances manifestes au niveau des exécutables d’une application informatique.

 

Le code source est-il moins important qu’avant ?

B. B. : Il reste important mais moins qu’avant.

Vincent Geoffray : Ce n’est plus le code source seul qui incarne la personnalité de l’auteur. Le prompt va montrer qu’un résultat correspond à des choix, des directives qui amène à un code final. La documentation révèle ainsi l’existence des choix opérés. Je n’ai jamais vu de programmation qui ne suppose pas l’intervention d’une décision humaine pour prendre une forme, hormis quelques exceptions tout à fait anecdotiques, comme de rares interfaces.

 

Vous ne pensez pas qu’on se dirige vers une automatisation accrue avec les agents ?

V. G. : Mais l’automatisation répond toujours à une demande. Il n’y a rien qui va naître sui generis, de sorte que le code va s’autodévelopper. Il y a forcément une intervention avec l’aide d’outils perfectionnés qui facilite la pensée de l’homme. L’IA est un outil qui remplace en partie l’homme mais uniquement dans sa capacité à coder dans un langage particulier.

 

Finalement, est-ce que le recours à l’IA a un impact sur l’originalité et donc sur la protection du logiciel ?

B. B. : Toute seule, l’IA ne peut pas générer de la contrefaçon car, en l’état elle est un outil qui fait ce qu’on lui demande. Quoi qu’elle n’hésite pas à émettre des suggestions.

V. G. : Par principe, l’originalité repose sur l’existence d’un choix humain, dès l’instant qu’il n’y a pas de contrainte par la machine. Même si l’IA génère du code à la suite de prompts, la forme finale sera celle retenue par l’homme. L’originalité ne posera pas trop de problème à démontrer, mais la contrefaçon qui sera facilitée sera plus dure à caractériser. Du moment que la forme qui en sera issue n’est pas copiée d’une autre, elle sera originale.
Aujourd’hui, on est face à une incompréhension profonde du monde judiciaire sur la manière de caractériser et d’appréhender l’originalité d’un logiciel. Des arrêts récents de la cour d’appel de Paris commencent à remettre en cause cette tendance à ne pas reconnaître l’originalité d’un logiciel, considérant que tout serait contraint. Ce qui est faux, car développer c’est inévitablement faire des choix marqués par la personnalité du programmeur.

Vous plaidez pour le renversement de la charge de la preuve. Cette conviction est-elle liée à l’évolution technologique ?

V. G. : Il est trop facile de rejeter toute originalité, en utilisant des méthodes démonstratives se rapprochant de celles du brevet, difficilement compréhensibles pour les juges, et qui aboutissent à fausser les jugements. J’ai en effet observé qu’on partait des fonctionnalités pour montrer l’innovation. Cet argumentaire repose sur une méprise du fait qu’il s’agit d’un produit technique, donc potentiellement innovant. Mais on fausse ainsi la démonstration. D’où la conclusion de l’arrêt de la cour d’appel de Douai du 8 février 2025 qui estime que la composition et l’expression du logiciel étaient directement commandées par ses fonctionnalités ou par l’usage par les développeurs d’outils et de technologies disponibles sur le marché. En pratique, tout se passe comme si l’expert devait démontrer une innovation alors qu’il s’agit simplement de montrer la présence d’un auteur à travers la matérialisation de son travail qu’est le code. Je suis pour l’inversion de la charge de la preuve : à celui qui affirme qu’un logiciel n’est pas original de le prouver, partant que dès qu’un choix d’écriture du code est possible, il y a présomption d’originalité.

C. B. : C’est la position du CSPLA qui plaide pour une présomption d’originalité, charge à celui qui la conteste de démontrer le contraire.

 

Comment se passe une saisie-contrefaçon aujourd’hui ?

B. B. : Lors d’une saisie-contrefaçon concernant des logiciels, il est désormais nécessaire de collecter un ensemble très vaste d’éléments destinés, le cas échéant, à prouver la contrefaçon au travers d’un faisceau d’éléments alors qu’auparavant, avant l’utilisation de l’IA, on avait tendance à ne saisir que le code source et certains éléments relatifs à la modélisation de données par exemple. Aujourd’hui, il est indispensable de saisir le dossier de conception et les dossiers techniques, si possible les outils de génie logiciel, les GitHub, GitLab et autres outils, les traces de l’utilisation de ces outils, car ceux-ci peuvent éclairer sur la démarche vertueuse ou non poursuivie.

Les éléments techniques : code source, bytecode, fichiers de création des bases de données, les prompts et requête à destination des outils sont également indispensables. C’est à partir de l’analyse de tous ces éléments qu’il sera ensuite possible de déterminer s’il existe ou non un faisceau d’éléments probants qui permettra d’affirmer que l’IA a été utilisée pour contrefaire un logiciel en retranscrivant, par exemple, un logiciel existant, sa structure, sa logique, sa syntaxe, etc.

C. B. : C’est le prompt qui va permettre à l’IA de développer une partie du logiciel. Par rapport à l’originalité, est-ce qu’on regarde le résultat du logiciel, qui va être potentiellement fourni par l’IA, ou le prompt ? Aujourd’hui, il est donc très important de conserver les prompts. Il faut avoir une documentation beaucoup plus élargie car le prompt est aussi un moyen de démontrer l’orientation qu’on a donnée. Même si on a un code proche, on n’a pas la même façon de demander à l’IA de développer. On ne peut plus se contenter de conserver et d’examiner que des codes sources et des documents préparatoires « classiques ». Dans ces documents préparatoires, il faudra conserver tout ce qui est en rapport avec ce qu’on a demandé à l’IA, y compris quand on lui a demandé d’identifier les plagiats, etc., car cela montre qu’on a connaissance de l’existant, qu’on veut s’en éloigner tout en ayant le même objectif.

B. B. : Lors de la saisie, va se poser au commissaire de justice, mais surtout à l’expert, la question de savoir ce qu’il doit collecter. Est-il dans le strict périmètre de l’ordonnance du juge ou pas ? C’est parfois difficile à savoir. Et la question de la confidentialité va nécessairement se poser. Avec le dossier de conception, on va entrer dans la stratégie d’une société et éventuellement dévoiler un savoir-faire. Une collecte excessive peut exposer à des difficultés d’exploitation mais aussi au contrôle du juge qui pourrait considérer que la mesure d’instruction s’avère trop large.

C. B. : C’est très compliqué d’autant plus que les logiciels sont aujourd’hui développés par des équipes. Cela veut dire qu’il faut saisir des masses de dossiers de conception à des équipes qui ne développent pas forcément qu’un seul logiciel. Sur un même compte-rendu, il peut être question du pilotage de six ou sept projets.

B. B. : C’est la raison pour laquelle les outils de gestion de suivi de projet de type gitHub, GitLab sont très importants car ils montrent qui a fait quoi à quel moment. Aujourd’hui, ce type de saisie-contrefaçon peut prendre un jour ou deux. Une grosse opération peut même nécessiter jusqu’à une semaine de travail pour une équipe de plusieurs experts. Dernièrement, je suis intervenu sur une saisie-contrefaçon qui a duré 3 jours et a mobilisé 5 experts.

 

Donc la rédaction de la requête n’est pas un exercice facile.

C. B. : La prise de mission et la rédaction de la requête doivent être effectuées avec l’assistance d’un expert qui ne sera pas celui qui fera la saisie.

B. B. : De toute façon, sur ce type de dossier on n’est pas trop de deux experts : un qui prépare le dossier et la stratégie avec les avocats, l’autre qui intervient sur la partie technique et la réalisation de la saisie elle-même. L’expert qui procède à la saisie-contrefaçon avec le commissaire de justice réalisera nécessairement un travail différé de tri et de remise en forme pour écarter ce qui n’entre pas dans le périmètre de l’ordonnance. C’est une lourde responsabilité car il s’agit d’une opération coûteuse qui est très intrusive.

V. G. : Un des problèmes qui se pose, c’est l’incompréhension mutuelle de chacun des intervenants, experts et avocats. Le juge reçoit ce qu’on lui donne mais a ainsi une grande difficulté à juger à partir du « matériel » fourni. Les avocats ont ainsi une compréhension assez légère de la matière informatique tout comme de l’interprétation du droit y afférent. Ils devraient se placer plus comme les jurisconsultes romains faisant le droit à partir des faits. Quant aux experts, ils répondent à une forme de facilité en ne rentrant pas vraiment dans les sources ni en apportant ce qui serait nécessaire au juge pour caractériser en faits l’originalité. Finalement, tous ces éléments fragmentés et incomplets ne permettent pas d’obtenir le jugement attendu. Je l’ai vu dans les dossiers que j’ai connus.

C. B. : Les clients souvent ne comprennent pas qu’il faut une équipe qui travaille ensemble et non pas un avocat, un commissaire de justice et un expert qui interviennent chacun de leur côté. Il faut qu’avant la requête, toute la stratégie soit mise en place. Or, il se peut que des experts arrivent en milieu de course et n’ont pas été sollicités par l’expert qui a mis en place la stratégie. A contrario, pour celui qui élabore la stratégie, il n’a pas le choix de l’expert qui va procéder à la saisie car le client en a déjà désigné un.

 

Claire, vous avez évoqué le parasitisme. Le recours à l’IA soulève aussi la question juridique de savoir si le droit d’auteur reste le meilleur moyen de protection du logiciel ?

C. B. : Les actions en contrefaçon de logiciel vont devenir de plus en plus lourdes et techniques. Et rares sont les experts qui sont capables de rentrer dans le code, dans les stratégies de contrefaçon et voir si le dossier est solide. Car une fois que la saisie-contrefaçon a été effectuée, on est tenu par ce qui est écrit, par les délais, etc. Ce n’est pas tant la question de l’adaptation du droit d’auteur au logiciel qui se pose. En revanche, va-t-on continuer à faire des saisies-contrefaçon de logiciel ou s’orienter vers d’autres voies de droit comme la concurrence déloyale ? Une saisie nécessite de gros moyens, des équipes importantes, comporte un aléa certain car quand vous assignez un adversaire, vous ne savez pas comment l’IA a été utilisée.

V. G. : Je considère que le droit d’auteur est complètement adapté mais il faut l’appliquer strictement. L’intervention de l’IA ne change rien, cela créé simplement un petit filtre supplémentaire mais la forme ultime sera bien celle d’un auteur ou d’une conjonction d’auteurs dont on arrivera à caractériser les choix arbitraires donc l’originalité. L’arrêt Pachot reste tout à fait pertinent pour peu qu’il soit bien mis en musique. Pour cela, je le complèterais en disant qu’ « est originale, la structure individualisée matérialisant un effort personnalisé allant au-delà de la simple mise en œuvre d’une logique automatique et contraignante, caractérisée dès lors qu’un choix arbitraire de son auteur a été possible ».

Il faut donc renouveler l’appréhension et peut-être le mode d’implication des experts qui ne sont peut-être pas assez payés pour une démonstration à partir des sources et non des seules fonctionnalités. Cela nous amènera probablement à un renversement de la charge de la preuve prenant en compte le fait qu’il est assez facile de montrer qu’un choix arbitraire existe. C’est la mise en œuvre de l’arrêt Pachot qui doit être renouvelée pour appréhender sereinement les apports de l’IA, comme un outil supplémentaire dont disposent les programmeurs, prolongeant les outils déjà existant que sont les ateliers logiciels.