Trois couches, et celle qui décide
La licence du fournisseur, le contrat de prestation et la cession au client forment trois couches, et c'est la plus interne qui contraint réellement. On discute surtout de la première, qui est la moins limitante.
La licence du fournisseur dit ce que vous avez le droit de faire du code produit par l'outil. Les offres professionnelles accordent en général des droits larges sur les sorties.
Le contrat de prestation dit ce que vous vous êtes engagé à livrer, et sous quelles garanties. C'est là que se trouvent les clauses de propriété et de garantie d'éviction.
La cession au client, enfin, est ce que vous transférez effectivement. Vous ne pouvez céder que ce dont vous disposez, et c'est cette contrainte qui remonte toute la chaîne.
Ce qui est raisonnablement établi
Le code produit par un assistant vous appartient dans les mêmes conditions que le reste, sous réserve de la licence du fournisseur. Ce point est stable dans les offres professionnelles.
Ce qui l'est moins, et qu'il faut regarder : certaines offres gratuites ou grand public accordent des droits plus restreints, ou se réservent des usages sur les sorties. La différence entre l'offre individuelle et l'offre entreprise du même produit est parfois considérable sur ce point précis.
La vérification prend dix minutes et se fait une fois, sur l'offre effectivement souscrite, pas sur la page marketing du produit. Elle s'archive avec la documentation, comme les autres pièces fournisseur décrites dans ce qui doit descendre la chaîne.
Ce qui reste ouvert, et qu'il faut traiter par le contrat
- La reproduction de code sous licence. Un modèle entraîné sur du code public peut restituer des fragments reconnaissables. Le risque est faible et non nul.
- La garantie d'éviction que vous donnez à votre client : vous garantissez que le code livré ne porte atteinte à aucun droit. Cette garantie ne se délègue pas au fournisseur de l'outil.
- L'indemnisation offerte par certains fournisseurs, qui existe et dont il faut lire le périmètre : elle couvre souvent l'usage du service, pas votre relation client.
- La traçabilité de ce qui a été généré, utile si la question se pose un jour. Voir l'observabilité des systèmes IA.
Ce que je fais figurer dans un contrat de prestation
Une clause qui mentionne l'usage d'outils d'assistance, et qui n'en fait pas une exclusion de garantie. Le silence est la pire option des trois possibles.
La première option, ne rien dire, laisse le client découvrir la chose par ailleurs et créer un incident de confiance sur un sujet qui n'en méritait pas.
La deuxième, exclure sa garantie pour le code généré, est refusée par tout client sérieux et à juste titre : elle transfère un risque qu'il n'a aucun moyen d'évaluer.
La troisième, celle que je retiens, mentionne l'usage d'outils d'assistance et maintient la garantie pleine et entière. Elle correspond à la réalité : c'est vous qui relisez, testez et livrez, donc c'est vous qui répondez du résultat.
Cette position a l'avantage d'être simple à tenir, et elle est cohérente avec ce que j'écris ailleurs sur la responsabilité : ce qu'on ne délègue jamais à un modèle.
Le cas du client qui interdit l'usage
Certains clients interdisent contractuellement l'usage d'assistants sur leur code, et cette clause se rencontre de plus en plus. Il faut la lire attentivement avant de signer, parce qu'elle est parfois plus large qu'annoncé.
La formulation courante interdit « l'utilisation d'outils d'intelligence artificielle générative ». Prise au pied de la lettre, elle couvre la complétion de ligne, l'aide à la rédaction de tests, et parfois la simple recherche documentaire.
Une clause aussi large est rarement l'intention réelle du client, qui veut protéger son code source d'un transfert. La négociation utile consiste à la restreindre à ce point précis : pas de transmission de code à un service tiers, ce qui laisse ouvert l'usage d'un modèle local.
Cette distinction rejoint celle qui structure tout le sujet : ce n'est pas l'outil qui pose problème, c'est le trajet de la donnée. Voir choisir un assistant de code en entreprise.
La vérification à faire une fois, et à archiver
Relire les conditions de l'offre effectivement souscrite, pas la page produit, sur un point : quels droits vous avez sur les sorties, et ce que le fournisseur se réserve. Dix minutes, et cela vaut pour tous les projets.
Ce que ça change à l'organisation d'une équipe
La question se règle au niveau de l'organisation, une fois, pas au niveau de chaque développeur à chaque projet. C'est ce qui évite les décisions individuelles non tracées.
Le document utile tient en une page : quels outils sont autorisés, sur quels dépôts, avec quelles restrictions par client. Il se relit quand un nouveau client impose une clause ou quand un outil change ses conditions.
Sans ce document, chaque développeur arbitre seul, personne ne sait ce qui a été utilisé sur quel projet, et la question devient impossible à traiter le jour où elle se pose.
C'est la même logique que la classification des dépôts par sensibilité : une décision prise une fois, écrite, et applicable sans réfléchir. Elle se range avec la fiche des systèmes décrite dans écrire la fiche d'un système d'IA.
Questions fréquentes
À qui appartient le code produit par un assistant ?
À vous, dans les mêmes conditions que le reste, sous réserve de la licence du fournisseur. Les offres professionnelles accordent des droits larges ; les offres grand public du même produit parfois non.
Peut-on exclure sa garantie sur le code généré ?
En théorie, et aucun client sérieux ne l'acceptera. C'est vous qui relisez, testez et livrez : la garantie pleine est la position cohérente et la plus simple à tenir.
Que faire si un client interdit ces outils ?
Lire la clause : elle est souvent plus large que l'intention. La négociation utile la restreint au point réel, la transmission de code à un service tiers, ce qui laisse ouvert le modèle local.
Faut-il le mentionner au contrat ?
Oui. Le silence laisse le client le découvrir autrement et crée un incident de confiance sur un sujet qui n'en méritait pas.