GitHub Copilot, Cursor et JetBrains : comment les juristes évaluent l’AI dans les environnements de développement

Sur Habr, une analyse est parue sur la manière dont les assistants AI transforment les environnements de développement habituels, d’un outil en un coauteur presque à part entière. Un juriste IT chez ecom.tech explique : la commodité de GitHub Copilot, Cursor et JetBrains AI apporte non seulement de la vitesse, mais aussi de nouveaux risques juridiques.

Comment l’AI est arrivée

L’auteur divise le marché en trois groupes. Le premier regroupe les IDE et éditeurs classiques comme Visual Studio, VS Code, JetBrains IDE, 1С:EDT et GigaIDE, où l’AI joue le rôle d’une fonction supplémentaire. Le deuxième regroupe les plugins et assistants comme GitHub Copilot, Amazon Q Developer, GigaCode et SourceCraft, qui s’intègrent dans un environnement déjà familier et prennent en charge la génération. Le troisième regroupe les éditeurs AI-first comme Cursor et Windsurf, où le dialogue avec le modèle et l’application automatique de modifications constituent la base de tout le produit.

La différence entre ces catégories n’est pas cosmétique. L’architecture détermine le volume de code source envoyé à un service externe, l’endroit où il est traité et la personne qui répond ensuite du résultat. Là où l’AI ne propose que de l’autocomplétion, le rôle du développeur reste clair. Là où un agent, à partir d’une commande textuelle, écrit un module, refactorise un projet et crée des tests sans retouche manuelle, il devient plus difficile de tracer la frontière entre travail humain et génération machine.

Où les risques apparaissent

La question principale est celle de la paternité. En droit russe, seul un être humain est reconnu comme auteur si le résultat repose sur sa contribution créative. Mais les scénarios varient : un développeur peut accepter une seule ligne suggérée, retravailler un grand fragment fourni par le modèle, ou insérer le code généré presque sans modification. Moins il y a d’édition et de décisions autonomes, plus l’argument selon lequel le fragment final est protégé par le droit d’auteur en tant qu’œuvre humaine s’affaiblit.

Un autre risque est lié aux données d’entraînement. La plupart de ces systèmes ont été entraînés sur des dépôts publics, si bien que les correspondances avec du code tiers ne relèvent pas d’un problème purement théorique. Si un fragment assorti d’exigences de licence strictes se retrouve dans un produit commercial, le litige naîtra non pas du fait que le modèle a généré le code, mais du fait qu’un morceau protégé appartenant à autrui a été utilisé. L’exemple le plus visible est l’action américaine Doe v. GitHub, qui vérifie précisément si Copilot peut reproduire du code open source tiers sans respecter les conditions des licences.

« Aujourd’hui — un outil. Demain — une question. »

Ce que promettent les fournisseurs

Une partie distincte de l’article est consacrée aux accords de licence. Formellement, presque tous les fournisseurs affirment que les droits sur le code de l’utilisateur et sur le résultat de la génération restent au client, mais les détails diffèrent fortement. Pour le développement en entreprise, c’est plus important que de belles démos, car c’est précisément dans le contrat que l’on découvre si les données d’entrée peuvent être utilisées pour entraîner les modèles, combien de temps elles sont conservées et qui assumera les coûts si une réclamation au titre du droit d’auteur apparaît.

• GitHub Copilot for Business et Enterprise promet de ne pas entraîner les modèles sur le code du client et offre une protection d’entreprise contre les réclamations
• Amazon Q Developer ajoute un reference tracker et indique si la sortie ressemble à du code open source
• JetBrains AI Assistant et Cursor laissent les droits à l’utilisateur, mais ne suppriment pas l’obligation de vérifier le résultat
• GigaCode et SourceCraft autorisent un usage plus large du contenu utilisateur pour faire fonctionner le service et améliorer les modèles

Il en ressort la conclusion pratique de l’auteur : pour un juriste et un CTO, il ne suffit plus de choisir l’assistant le plus pratique. Il faut lire les conditions de conservation des données, vérifier séparément si le service peut se réentraîner sur les prompts et le code, et décider à l’avance quels outils sont admissibles dans des projets commerciaux fermés. Cela concerne tout particulièrement les entreprises qui gèrent des données personnelles, des secrets commerciaux et leurs propres bibliothèques, qu’on ne peut pas envoyer à la légère à un modèle externe.

Ce que cela signifie

L’AI dans les environnements de développement fait déjà partie du travail quotidien, mais sur le plan juridique elle reste encore une zone grise. L’approche pratique est simple : considérer le code généré comme un brouillon, le vérifier du point de vue des licences et de la sécurité, et fonder le choix de Copilot, Cursor, JetBrains ou d’alternatives locales non seulement sur la commodité, mais aussi sur la manière dont le service traite votre code.