Qui possède le code écrit par une IA ?

La question arrive toujours après coup, une fois que les assistants sont déjà installés sur tous les postes : à qui appartient le code qu’ils produisent ?

Elle se pose en réalité deux fois, et les deux réponses vont dans des directions opposées. La première porte sur ce que la machine produit : qui en est titulaire ? La seconde porte sur ce qu’elle a pu reproduire : à qui cela appartenait-il déjà ?

Nous avons vu dans l’article précédent ce qu’un contrat doit dire de la propriété du code. Voici ce que l’intelligence artificielle y change.

Première question : ce qui est produit n’appartient peut-être à personne#

Le droit d’auteur repose sur deux conditions : une création originale, et un auteur personne physique. Une production entièrement machinale ne satisfait ni l’une ni l’autre. Il en découle une conséquence qui surprend la plupart des dirigeants : un code intégralement généré n’est, en principe, protégé par rien.

Ce n’est pas un vide juridique : c’est une absence de titre. Personne ne vous le prend, mais vous ne pouvez pas non plus en interdire l’usage à un concurrent qui obtiendrait le même résultat.

En pratique, la situation est heureusement plus nuancée. Le code livré n’est presque jamais une sortie brute : quelqu’un a défini l’architecture, choisi le découpage, formulé les demandes, rejeté trois propositions, corrigé la quatrième, intégré l’ensemble dans un existant et écrit les tests. C’est cet apport humain qui est protégeable, et il est en général substantiel.

Encore faut-il pouvoir le montrer. D’où une recommandation simple, et qui ne coûte rien : conservez la trace du travail humain. Un historique de versions granulaire, des messages de commit qui décrivent des décisions, des revues de code signées. Ce que vous appelleriez de la bonne hygiène de développement devient ici la preuve de votre titularité.

Deuxième question : ce qui a pu être reproduit#

C’est le risque sérieux, et il est documenté : un modèle peut restituer des fragments très proches de textes vus pendant son entraînement — code compris, licence comprise.

Trois précisions pour ne pas paniquer inutilement :

• La complétion de trois lignes n’est pas le problème. Une boucle standard, une gestion d’erreur usuelle, un appel d’interface : ces formes ne sont originales chez personne.
• Le problème, c’est le gros bloc. Cinquante lignes cohérentes, un algorithme complet, une classe entière acceptée d’un geste par quelqu’un qui n’aurait pas su l’écrire. Là, la probabilité que la formulation reproduise une source identifiable devient réelle.
• Le risque de licence est le plus concret. Si le fragment provient d’un projet placé sous une licence à réciprocité, l’obligation attachée voyage avec lui. Pour un logiciel exploité en ligne, certaines de ces licences imposent des contraintes incompatibles avec un modèle propriétaire — et personne ne s’en aperçoit avant l’audit.

Les parades existent, aucune n’est suffisante seule : les filtres de correspondance proposés par certains outils, l’analyse de composition logicielle sur le dépôt, et surtout la règle humaine la plus élémentaire — on n’intègre pas un bloc qu’on ne saurait pas réécrire.

Ce que cela change dans vos contrats#

Rien de fondamental. Une clause suffit à couvrir l’essentiel, et c’est celle qui existait déjà : la garantie d’éviction.

Votre prestataire vous garantit qu’il détient les droits qu’il cède et vous couvre si un tiers revendique quelque chose. Cette garantie ne doit pas être affaiblie par l’usage d’assistants, et c’est précisément ce que certains contrats tentent aujourd’hui d’introduire : une exclusion de responsabilité pour le code « assisté ». Refusez-la. Si le prestataire ne veut pas garantir ce qu’il livre, la question n’est plus de savoir comment il l’a écrit.

Trois lignes complémentaires, utiles et faciles à obtenir :

1. Le prestataire déclare recourir à des assistants, et lesquels.
2. Il s’engage à relire tout bloc significatif et à ne pas intégrer de code qu’il ne comprend pas.
3. Il fournit l’inventaire des dépendances et de leurs licences avec le livrable.

Symétriquement, ne demandez pas à un prestataire de s’engager sur ce qu’aucun outil ne permet de vérifier. Une garantie que personne ne peut tenir n’a pas plus de valeur qu’une absence de garantie.

Côté employeur : là où la protection se déplace#

Pour les salariés, l’article L. 113-9 du code de la propriété intellectuelle prévoit une dévolution automatique des droits sur les logiciels créés dans l’exercice de leurs fonctions. Elle continue de jouer : rien de ce qui précède ne prive l’entreprise de quoi que ce soit.

Mais elle ne peut transmettre que ce qui existe. S’il n’y a pas de création originale, il n’y a pas de droit à dévoluer — et la protection que vous croyiez avoir n’a jamais existé.

D’où un déplacement qu’il faut assumer : la valeur juridique passe du droit d’auteur au secret des affaires. L’article L. 151-1 du code de commerce en pose trois conditions cumulatives — l’information n’est pas publique, elle tire sa valeur de ce secret, et elle fait l’objet de mesures de protection raisonnables. Ce dernier point est le seul sur lequel vous ayez la main : dépôt privé, accès nominatifs et révoqués au départ, engagements de confidentialité signés, journalisation des accès.

Ce ne sont pas des formalités administratives. Ce sont elles qui rendent la protection opposable le jour où un ancien salarié part avec le dépôt.

Ce que nous faisons, et ce que nous conseillons#

Nous utilisons des assistants de code. Le dire ne nous coûte rien : ce serait invérifiable autrement, et les cacher n’aurait aucun sens.

Nos règles internes tiennent en cinq lignes, et c’est exactement ce que nous recommandons d’écrire à nos clients :

1. Les outils autorisés sont nommés. Pas d’usage d’un service inconnu sur du code client.
2. Aucun code client n’est envoyé à un service dont les conditions n’ont pas été lues — la question porte sur la réutilisation des données transmises, et elle se vérifie contrat en main.
3. Tout bloc significatif est relu par un humain qui saurait l’écrire.
4. L’historique de versions reste fin, parce qu’il est la preuve du travail humain.
5. L’inventaire des dépendances est produit à chaque livraison.

Aucune de ces règles ne ralentit une équipe. Toutes se vérifient. Et surtout, aucune ne repose sur une interdiction générale : nous avons expliqué ailleurs pourquoi interdire l’IA en entreprise ne fait que rendre son usage invisible — donc impossible à encadrer.

Ce qu’il faut retenir#

Le sujet est moins effrayant qu’il n’y paraît, à condition de renverser la question. Ne demandez pas « à qui appartient le code écrit par l’IA ? », qui n’a pas de réponse unique. Demandez :

• Qu’est-ce qui, dans ce projet, porte une décision humaine ? C’est ce qui est protégé.
• Qu’est-ce qui pourrait appartenir à un tiers ? C’est ce qui doit être garanti.
• Qu’est-ce que je protège autrement que par le droit d’auteur ? C’est ce qui doit être tenu secret.

Trois questions, trois réponses écrites. C’est un après-midi de travail, et cela vaut mieux que la certitude tranquille de posséder quelque chose qu’on ne possède pas.