À qui appartient votre modèle d'IA ?

Le projet a fonctionné. Le modèle tourne en production, les résultats sont là, l'équipe est contente. Deux ans plus tard, vous changez de prestataire, vous levez des fonds, ou un acquéreur regarde vos actifs.

Et la question tombe : ce modèle, il est à qui ?

La réponse se trouve dans un contrat signé vingt-quatre mois plus tôt, que personne n'a relu depuis. Elle est rarement celle qu'on espérait.

Un système d'IA superpose trois couches, trois régimes

Ce qu'on appelle « notre IA » n'est pas un objet unique. C'est un empilement dont chaque étage relève de règles distinctes.

Les données d'entraînement. Vos données métier vous appartiennent — sauf si elles contiennent des données clients dont l'usage est encadré par vos propres conditions générales, ou des données acquises sous licence restrictive. Beaucoup d'entreprises entraînent sur des données qu'elles n'ont pas le droit d'exploiter à cette fin, sans le savoir.

Le modèle entraîné. C'est l'angle mort le plus fréquent. Si un prestataire entraîne un modèle sur vos données, le contrat de prestation détermine qui détient les poids résultants. En l'absence de clause explicite, la réponse n'est pas automatiquement en votre faveur.

Les briques sous-jacentes. Une licence open source peut imposer des obligations qui se propagent à ce que vous construisez par-dessus. Toutes ne sont pas permissives, et certaines sont franchement contraignantes dès que vous distribuez.

Le scénario qui revient le plus souvent

Une entreprise fait développer un modèle. Le contrat prévoit la cession du « livrable ». Deux ans plus tard, elle veut reprendre la main.

Question : le « livrable » couvrait-il le modèle entraîné, ou seulement le code qui permet de l'entraîner ? Les deux lectures se défendent. Et une ambiguïté qui se défend des deux côtés, c'est un litige, ou une renégociation en position de faiblesse.

Une clause de cession qui ne nomme pas explicitement les poids du modèle, les jeux de données dérivés et la documentation d'entraînement laisse la question entièrement ouverte.

Ce qui se verrouille en amont, pour presque rien

Traitées avant le développement, ces questions coûtent quelques jours de travail juridique. Traitées après, elles coûtent un rapport de force.

• Les contrats de prestation — périmètre exact de la cession, sort des données dérivées, réversibilité.
• Vos conditions générales et contrats clients — ont-ils prévu que les données confiées puissent servir à de l'entraînement ?
• Les licences des composants — compatibilité avec votre usage commercial réel, pas théorique.
• La conformité RGPD et AI Act — base légale de l'entraînement, durées de conservation, obligations de transparence.

Pourquoi cela se traite en même temps que la technique

Parce que les deux volets se déterminent mutuellement.

Un cas d'usage techniquement séduisant peut s'avérer juridiquement inexploitable — le découvrir après six mois de développement coûte cher. À l'inverse, une contrainte de licence connue dès le départ oriente un choix d'architecture, sans rien retirer à la valeur du projet.

Mener les deux séparément, c'est accepter de découvrir l'incompatibilité au pire moment. C'est précisément la raison d'être d'une démarche commune : le Diag Stratégie PI cartographie vos actifs — code, données, modèles, marques, brevets, savoir-faire —, analyse vos contrats et votre conformité, pendant que le volet technique établit ce qu'il est pertinent de construire.

Le premier dit quoi construire. Le second garantit que ce sera bien à vous.