De l'asset à la responsabilité : la nouvelle équation de la propriété intellectuelle sous l'IA Act

Dans le paysage dynamique des contrats informatiques, la propriété des livrables a longtemps été un pilier stratégique pour les clients. En exigeant la pleine propriété des solutions développées pour eux, ils s'assuraient une maîtrise totale de leurs outils, évitant ainsi une dépendance excessive à leurs prestataires et sécurisant leurs investissements. Être propriétaire, c’était sécuriser son investissement, garantir son indépendance technique et échapper à la dépendance vis-à-vis d’un prestataire.

L'avènement de l'IA pourrait bien bouleverser ce modèle établi

Contrairement aux logiciels traditionnels, l'IA est un système évolutif qui apprend et s'adapte en continu. Avec l'entrée en vigueur progressive de l'IA Act, être propriétaire d'une solution IA ne signifie plus simplement détenir un actif : c'est aussi porter une responsabilité réglementaire qui pourrait rebattre les cartes du marché.

Un modèle historique centré sur la captation de propriété

Le marché des technologies de l'information repose sur deux modèles historiques :

• Les développements sur-mesure et le legacy fait maison, en déclin mais encore présents.
• L'achat de licences logiciels ou l’accès à des solutions SaaS standardisés dont l’utilisation ne cesse de croitre.

Dans le développement sur-mesure, l'équation était simple : le client finance, il possède. L’ESN cède tous les droits et garantit l’absence de contrefaçon. Cette propriété assure au client indépendance et valorisation de son investissement.

Ce modèle s’applique autant aux développements métiers qu’aux briques logicielles au sein de solutions plus larges : même sur un produit existant, le client cherche souvent à internaliser le code pour limiter sa dépendance.

Avec l’essor de l’IA, cette mécanique peut se gripper. Une IA n'est pas un produit statique. Elle est en partie autonome et évolutive, capable de s'adapter et d'apprendre en fonction des données qu'elle traite. Le législateur européen a pris acte de cette particularité : cette autonomie partielle nécessite une surveillance et une gouvernance continues, bien au-delà de la simple mise en œuvre initiale. L'IA Act vient ainsi encadrer ces dynamiques, imposant des obligations rigoureuses pour garantir la conformité et la transparence tout au long du cycle de vie de l'IA.

L’IA Act rebat les cartes : la propriété devient une charge

L’IA Act introduit, entre autres notions, un diptyque structurant : le fournisseur et le déployeur.

• Le fournisseur est l’entité qui développe ou fait développer un système d’IA et le met sur le marché ou en service sous son propre nom.
• Le déployeur est celui qui utilise le système.

Or, ce qui pourrait sembler une nuance juridique a le potentiel de bouleverser la dynamique contractuelle. Dans un développement sur-mesure, le client devient souvent fournisseur dès lors qu’il exige la pleine propriété du livrable.

Cependant et bien que l’IA Act impose des obligations à différents acteurs, c’est sur le fournisseur que reposent les principales contraintes, en particulier lorsque l’IA est classée comme « à haut risque ».
Dans ce cas, le fournisseur est notamment responsable d’assurer que l’IA :

1. est conçue selon des niveaux suffisants de précision, de robustesse et de cybersécurité ;
2. est gouvernée avec une gestion rigoureuse des risques ;
3. est documentée et enregistrée pour obtenir le marquage CE.

Le déployeur, avec un cahier des charges plus léger, doit principalement former ses équipes, adapter son organisation et mettre en place une surveillance active de l'utilisation de l'IA.

Un défi particulier survient quand un acteur cumule les rôles : il devra assumer l’ensemble des obligations attachées aux deux fonctions.

Cas concret : une entreprise commande à une ESN une IA pour publier des offres d’emploi et trier les candidatures.

1 - En mode Saas : le client exploite l'IA comme utilisateur

Le client exploite l’IA en tant que simple utilisateur, l’ESN reste fournisseur au sens de l’IA Act. C’est elle qui doit assurer la conformité réglementaire :

• Justifier la manière dont l’IA prend ses décisions.
• Documenter les biais potentiels et mettre en place un suivi, sujet particulièrement critique dans le cas de la gestion RH et de l’accès à l’emploi.
• Assurer la traçabilité et la conformité aux normes en vigueur.

Le client n’a qu’une obligation d’usage responsable, devant s’assurer que l’outil correspond bien à ses besoins et que ses salariés restent toujours in fine en maîtrise des résultats proposés par l’IA.

Avantage pour le client : pas de contrainte réglementaire excessivement lourde.
Inconvénient : dépendance à l’ESN pour les évolutions et la mise en conformité.

2 - Le client achète le système

• Il risque de basculer alors dans la catégorie des fournisseurs de l’IA et d’assumer pleinement l’ensemble des obligations réglementaires précédemment évoquées.
• L’ESN n’est responsable que du livrable initial et n’a plus d’obligation réglementaire de suivi, sauf engagement contractuel spécifique.

Une gouvernance obligatoire, bien au-delà du développement initial

L'IA Act ne fait pas dans la demi-mesure : il exige une gouvernance rigoureuse tout au long du cycle de vie de l'IA. Concrètement, il faudra documenter méticuleusement chaque aspect de l'algorithme, depuis sa conception jusqu'aux tests de validation.

L’IA Act impose des exigences strictes sur la gestion et le suivi d’une IA, notamment :

• Documentation détaillée : description du fonctionnement de l’algorithme et des tests effectués.
• Surveillance post-livraison : obligation d’assurer un suivi continu et des corrections en cas d’évolution des risques.
• Auditabilité et traçabilité : justification des décisions prises par l’IA, avec des preuves en cas de contentieux.

Ces obligations ne s’arrêtent aucunement au jour de mise en production de l’IA, elles représentent une charge continue, qui doit être prise en compte dès la négociation contractuelle.

L’IA Act introduit ainsi une contrainte forte : posséder un modèle IA, ce n’est pas seulement détenir un actif technologique, c’est aussi assumer une gouvernance réglementaire sur toute sa durée de vie.
Les fournisseurs doivent ainsi structurer une organisation capable de gérer la conformité sur le long terme, en intégrant les exigences combinées de l’IA Act et d’autres régulations comme la directive sur les produits défectueux (PLD).

Trois évolutions majeures possibles

L’IA Act transforme la manière de penser la propriété. Être propriétaire, ce n’est plus seulement exploiter une technologie : c’est en garantir la conformité dans le temps. Trois évolutions majeures s’esquissent :

Moins de cessions, plus de gouvernance partagée

• Des clients pourraient renoncer à la pleine acquisition pour éviter d’être fournisseurs.
• Des licences hybrides pourraient émerger, l’ESN conservant un rôle dans la conformité.
• Des modèles de co-responsabilité contractuelle se développeraient.

Généralisation du SaaS pour éviter les contraintes

• Les entreprises pourraient privilégier des solutions maintenues par l’éditeur.
• Cela renforcerait les grands acteurs IA, fournisseurs de solutions packagées.
• À terme, les IA propriétaires deviendraient plus rares, les outils plus standardisés.

Redéfinition des contrats IT sur le long terme

• L’IA impose un suivi continu, rendant caduque la notion de livrable final.
• Les contrats devront intégrer des clauses de maintenance et de conformité.
• Des équilibres hybrides pourraient apparaître.

Face à ce nouveau paradigme, les entreprises et les ESN doivent ajuster leurs approches contractuelles pour conjuguer innovation, conformité et résilience.