Imaginez que votre assistant IA vient de produire 200 lignes de code. Légalement, vous n'en possédez peut-être pas une seule ligne, mais légalement, vous êtes toujours responsable de chaque bug qu'il contient. Voici l'écart entre ces deux phrases et ce que cela signifie pour le code que vous fusionnerez demain.
C’est la lacune dans laquelle se situe tout ce sujet. L’outil qui a produit le code ne peut pas être poursuivi en justice. Le modèle ne peut pas être tenu responsable. Le contrat du fournisseur indique déjà clairement, dans un langage que la plupart des développeurs ne lisent jamais, que la responsabilité incombe à l'humain qui a appuyé sur Tab.
Ce qui est intéressant, ce n’est pas que cet écart existe. C'est que presque personne en ingénierie ne le traite comme il le fait. Nous avons passé deux ans à célébrer la productivité, et une fraction beaucoup plus petite de ce temps à déterminer quoi faire lorsque la vitesse répond à une réclamation en matière de droit d'auteur, à un audit de conformité ou à un incident de production. Décomposons cela : ce que les tribunaux ont réellement dit, ce que dit réellement le contrat de votre outil, où se trouvent les falaises juridiques et comment une équipe d'ingénieurs sensée gère le tout sans interdire l'IA ni prétendre que la question n'existe pas.
La propriété des logiciels était autrefois une question réglée. Vous avez écrit le code, votre employeur vous a payé pour l'écrire, votre contrat de travail leur a cédé les droits d'auteur, l'entreprise l'a expédié sous la licence de son choix. Trois parties (vous, votre employeur, l'utilisateur) et les lignes entre elles étaient claires. Si quelque chose tombait en panne, l'utilisateur se plaignait auprès de l'entreprise, l'entreprise consultait l'historique des validations et quelqu'un avait une conversation tranquille en tête-à-tête.
Les assistants IA glissent une quatrième partie dans cette image, et le contrat de cette partie ne ressemble à aucun des autres. Le mannequin n'a pas signé votre contrat de travail. Le fournisseur ne fait pas partie de votre processus de publication. Leur CLUF n'a pas la forme d'un contrat d'embauche ; cela a la forme d'un avertissement. Vous obtenez la suggestion, vous la conservez, et vous conservez également tout ce qui y est attaché : les bugs, les obligations de licence, les failles de sécurité, et tout ce que le futur régulateur décidera d'inspecter comment la suggestion est arrivée là.
Ce transfert se produit silencieusement. Il n'y a aucune case à cocher dans votre IDE indiquant "J'accepte la responsabilité légale de cet achèvement". Vous venez d'appuyer sur Tab. L'interface est conçue pour ressembler à une saisie semi-automatique, et la plupart des développeurs y étendent le modèle mental de la saisie semi-automatique : l'éditeur m'aide à taper plus rapidement, le code est toujours le mien, ma propriété de la base de code reste inchangée. Ce modèle mental est presque correct et presque complètement faux, selon la question que vous posez.
Deux choses sont actuellement au cœur du cadre juridique aux États-Unis, et toutes deux surprennent les développeurs lorsqu'ils les entendent.
La première : aux États-Unis, la protection du droit d’auteur nécessite un auteur humain. Ce n'est pas une nouvelle règle. C'est la même règle qui a décidé qu'un singe ne pouvait pas revendiquer le droit d'auteur sur un selfie en 2018, mais elle a été récemment testée dans l'affaire Thaler contre Perlmutter, une affaire concernant une image générée par un système d'IA san...
[Courte citation de 8% de l'article original]